[PATCH 1/1] cx23885-dvb: fix ds3000 ts2020 split for TEVII S471
A split for ds3000/ts2020 code forgot to change the TEVII_S471 code.
Change the TEVII_S471 according the changes to TEVII_S470.
Signed-off-by: Christian Volkmann
---
drivers/media/pci/cx23885/cx23885-dvb.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 9c5ed10..be98c49 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -1038,7 +1038,6 @@ static int dvb_register(struct cx23885_tsport *port)
&tevii_ts2020_config, &i2c_bus->i2c_adap);
fe0->dvb.frontend->ops.set_voltage = f300_set_voltage;
}
-
break;
case CX23885_BOARD_DVBWORLD_2005:
i2c_bus = &dev->i2c_bus[1];
@@ -1249,6 +1248,11 @@ static int dvb_register(struct cx23885_tsport *port)
fe0->dvb.frontend = dvb_attach(ds3000_attach,
&tevii_ds3000_config,
&i2c_bus->i2c_adap);
+ if (fe0->dvb.frontend != NULL) {
+ dvb_attach(ts2020_attach, fe0->dvb.frontend,
+ &tevii_ts2020_config, &i2c_bus->i2c_adap);
+ fe0->dvb.frontend->ops.set_voltage = f300_set_voltage;
+ }
break;
case CX23885_BOARD_PROF_8000:
i2c_bus = &dev->i2c_bus[0];
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22.1: OOps during shutdown: ( kernel not tained now)
A bug report is at https://bugzilla.samba.org/show_bug.cgi?id=4819 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6 patch] i386: remove support for the Rise CPU
The SIS550 chip uses the mP6 core according to http://en.wikipedia.org/wiki/MP6 May be this code can improve the capability of these SIS550 system on a chip ? But this should be a different story. Dave Jones wrote: > On Thu, May 31, 2007 at 07:22:38AM +0200, Adrian Bunk wrote: > > On Thu, May 17, 2007 at 05:47:54PM -0400, Dave Jones wrote: > > > On Thu, May 17, 2007 at 11:28:01PM +0200, Christian Volkmann wrote: > > > > > > > - Important: somebody to check other CPU types if the same behavior > happens. > > > > > > arch/i386/kernel/cpu/rise.c > > > > > > Though, I've *never* seen or even heard of someone with one of those > CPUs, > > > so whether we need to care is questionable. The mp6 did actually make it > > > to manufacture aparently, but I don't think anyone actually bought one. > > > http://en.wikipedia.org/wiki/Rise_Technology for a pic of this mythical > beast. > > > > Considering that arch/i386/kernel/cpu/rise.o takes a few bytes in every > > i386 kernel image, what about removing it? > > I'll be amazed if someone complains. > We'll still boot fine on those CPUs without that support code too, > we just won't advertise cx8 to userspace, and /proc/cpuinfo > won't prettyprint the name. whoopdy-do. > > Should we actually find someone who a) has one and b) is crazy enough > to still run it today, we could always add this stuff back. > > Signed-off-by: Dave Jones <[EMAIL PROTECTED]> > > Dave > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOps in CIFS during shutdown, kernel 2.6.22 tainted with vmware.
Hi, I had several Oops in messages. The kernel 2.6.22 is tainted with a vmware module. Please ignore this mail if you expect vmware-modules had crashed the system. The vmware had not been used during the uptime. But may be somebody can find some errors also with a tainted kernel. I will try to use the system without the tainting module. May be this problem during the shutdown happens again. Best regards, Christian Jul 18 17:20:01 ocv kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00c8 Jul 18 17:20:01 ocv kernel: printing eip: Jul 18 17:20:01 ocv kernel: f94d0a45 Jul 18 17:20:01 ocv kernel: *pde = Jul 18 17:20:01 ocv kernel: Oops: [#1] Jul 18 17:20:01 ocv kernel: SMP Jul 18 17:20:01 ocv kernel: Modules linked in: i915 drm nfsd ipv6 vmnet(P) exportfs cifs lockd nfs_acl sunrpc vmmon(P) button battery ac cbc blkcipher twofish twofish_common cryptoloop usbhid ff_memless ohci_hcd sr_mod nls_utf8 ext2 loop dm_mod fuse usb_storage tg3 intel_agp ac97_bus soundcore snd_page_alloc shpchp agpgart ehci_hcd ide_cd cdrom pci_hotplug uhci_hcd usbcore ext3 mbcache jbd edd fan sg ata_piix libata piix thermal processor sd_mod scsi_mod ide_disk ide_core Jul 18 17:20:01 ocv kernel: CPU:0 Jul 18 17:20:01 ocv kernel: EIP:0060:[]Tainted: P VLI Jul 18 17:20:01 ocv kernel: EFLAGS: 00010202 (2.6.22.1-cv #3) Jul 18 17:20:01 ocv kernel: EIP is at smb_init+0x145/0x2a2 [cifs] Jul 18 17:20:01 ocv kernel: eax: 0034 ebx: f71134c0 ecx: dfed2e00 edx: 000f Jul 18 17:20:02 ocv kernel: esi: dfed2e00 edi: f7015960 ebp: 0032 esp: f6d5bd94 Jul 18 17:20:04 ocv kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Jul 18 17:20:05 ocv kernel: Process fuser (pid: 12000, ti=f6d5a000 task=dffd7570 task.ti=f6d5a000) Jul 18 17:20:05 ocv kernel: Stack: 000e 000b 000f c5e14d40 c02b42b8 0573 8000 Jul 18 17:20:05 ocv kernel:f71134c0 fff4 f7015960 f7ede4e0 f94d32be f6d5bde4 f6d5bde0 f7975140 Jul 18 17:20:06 ocv kernel:dfed2e00 020a 51e38bf5 f71134c0 fff4 f7015960 Jul 18 17:20:06 ocv kernel: Call Trace: Jul 18 17:20:07 ocv kernel: [] do_page_fault+0x0/0x516 Jul 18 17:20:09 ocv kernel: [] CIFSSMBQPathInfo+0x43/0x259 [cifs] Jul 18 17:20:09 ocv kernel: [] cifs_get_inode_info+0xcf/0x829 [cifs] Jul 18 17:20:09 ocv kernel: [] __link_path_walk+0xaf2/0xc1a Jul 18 17:20:09 ocv kernel: [] build_path_from_dentry+0x81/0x13e [cifs] Jul 18 17:20:10 ocv kernel: [] cifs_revalidate+0x1e1/0x339 [cifs] Jul 18 17:20:10 ocv kernel: [] cifs_getattr+0xe/0x2b [cifs] Jul 18 17:20:11 ocv kernel: [] cifs_getattr+0x0/0x2b [cifs] Jul 18 17:20:11 ocv kernel: [] vfs_getattr+0x40/0x53 Jul 18 17:20:11 ocv kernel: [] vfs_stat_fd+0x2e/0x40 Jul 18 17:20:11 ocv kernel: [] sys_stat64+0xf/0x23 Jul 18 17:20:11 ocv kernel: [] sysenter_past_esp+0x5f/0x85 Jul 18 17:20:11 ocv kernel: [] wireless_send_event+0x280/0x2f7 Jul 18 17:20:11 ocv kernel: === Jul 18 17:20:11 ocv kernel: Code: 75 23 bb 90 ff ff ff f6 05 00 44 50 f9 01 0f 84 6a 01 00 00 c7 04 24 e1 19 4f f9 e8 a0 35 c5 c6 e9 59 01 00 00 8b 46 24 8b 40 1c <83> b8 94 00 00 00 03 0f 84 28 ff ff ff e8 86 df cd c6 89 c7 8b Jul 18 17:20:11 ocv kernel: EIP: [] smb_init+0x145/0x2a2 [cifs] SS:ESP 0068:f6d5bd94 Jul 18 17:20:11 ocv kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00c8 Jul 18 17:20:11 ocv kernel: printing eip: Jul 18 17:20:11 ocv kernel: f94d0a45 Jul 18 17:20:11 ocv kernel: *pde = Jul 18 17:20:11 ocv kernel: Oops: [#2] Jul 18 17:20:11 ocv kernel: SMP Jul 18 17:20:11 ocv kernel: Modules linked in: i915 drm nfsd ipv6 vmnet(P) exportfs cifs lockd nfs_acl sunrpc vmmon(P) button battery ac cbc blkcipher twofish twofish_common cryptoloop usbhid ff_memless ohci_hcd sr_mod nls_utf8 ext2 loop dm_mod fuse usb_storage tg3 intel_agp ac97_bus soundcore snd_page_alloc shpchp agpgart ehci_hcd ide_cd cdrom pci_hotplug uhci_hcd usbcore ext3 mbcache jbd edd fan sg ata_piix libata piix thermal processor sd_mod scsi_mod ide_disk ide_core Jul 18 17:20:11 ocv kernel: CPU:0 Jul 18 17:20:11 ocv kernel: EIP:0060:[]Tainted: P VLI Jul 18 17:20:11 ocv kernel: EFLAGS: 00010202 (2.6.22.1-cv #3) Jul 18 17:20:11 ocv kernel: EIP is at smb_init+0x145/0x2a2 [cifs] Jul 18 17:20:11 ocv kernel: eax: 0034 ebx: f7b293c0 ecx: dfed2e00 edx: 000f Jul 18 17:20:11 ocv kernel: esi: dfed2e00 edi: f7015960 ebp: 0032 esp: eb517d94 Jul 18 17:20:11 ocv kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Jul 18 17:20:11 ocv kernel: Process fuser (pid: 12005, ti=eb516000 task=f6c58030 task.ti=eb516000) Jul 18 17:20:11 ocv kernel: Stack: dfd28000 f8e0378a 000f 0900 0011 e193c360 8000 Jul 18 17:20:11 ocv kernel:f7b293c0 fff4 f7015960 f73e4d40 f94d32be eb517de4 eb517de0 f7975140 Jul 18 17:20:11 ocv kernel:dfed2e00
Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64
Christian wrote: Hmm, I really think so...: > > May I brought up a wrong reason with the command cmpxchg64. > But disabling CONFIG_X86_CMPXCHG64 helps. > Hi, I found some time to investigate. My resume is: - kernel/verify_cpu.S causes the stop at boot time Cause the required flag for CMPXCHG8B is not set. - boot/setup.S did not print "PANIC: CPU too old for this kernel" ( not visible, also the message did not match ) - VIA C3_2: CMPXCHG8B should work always. Via C3 EBGA Datasheet R1.90 page 30 (3-4) But the bit is not set cause of some early Win NT bugs. - X86_CMPXCHG64 can be set and used. Just verify_cpu.S requires a change to ignore the missing indicator at boot time. My suggestion for the fix is: - kernel/verify_cpu.S should be more tolerant if CONFIG_MVIAC3_2 is set ( see patch below ) - boot/setup.S should be fixed to print out a proper error message ( see below ) - X86_CMPXCHG64 patch(earlier mail in thread ) should not be used. - Important: somebody to check other CPU types if the same behavior happens. - middle term solution already planed: introduce arch/i386/boot/cpucheck.c To be done by somebody with more detail knowledge than me: (never did x86 assembler before) - I add "# missed before: set ds" => somebody should check if I am right with the way to set. => seems to be a generic error in setup.S not to set "ds" for error messages. - other X86-CPU than AMD (?) or Intel => correct verify_cpu.S or set bits if required. Best regards, Christian --- arch/i386/kernel/verify_cpu.S 2007-05-17 05:17:40.0 +0200 +++ arch/i386/kernel/verify_cpu.S 2007-05-17 23:14:18.266679323 +0200 @@ -54,6 +54,12 @@ andl$REQUIRED_MASK1,%edx xorl$REQUIRED_MASK1,%edx +/* VIAC3 does not report the existing CMPXCHG64 by default. So do not go to bad for CMPXCHG64 for this */ +/* via C3 EBGA datasheet R1.9 tells the command works also without shown bit. */ +#if CONFIG_MVIAC3_2 + andl$~NEED_CMPXCHG64,%edx +#endif + jnz bad #endif /* REQUIRED_MASK1 */ --- arch/i386/boot/setup.S 2007-05-17 21:53:08.009226208 +0200 +++ arch/i386/boot/setup.S 2007-05-17 23:12:36.815989168 +0200 @@ -310,12 +310,15 @@ call verify_cpu testl %eax,%eax jz cpu_ok + # missed before: set ds + movw%cs, %ax# aka SETUPSEG + movw%ax, %ds lea cpu_panic_mess,%si callprtstr 1: jmp 1b cpu_panic_mess: - .asciz "PANIC: CPU too old for this kernel." + .asciz "PANIC: CPU too old for this kernel or CPUID function bits are wrong." #include "../kernel/verify_cpu.S" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64
Dave Jones wrote:
> On Thu, May 17, 2007 at 11:28:01PM +0200, Christian Volkmann wrote:
> Though, I've *never* seen or even heard of someone with one of those CPUs,
> so whether we need to care is questionable. The mp6 did actually make it
> to manufacture aparently, but I don't think anyone actually bought one.
> http://en.wikipedia.org/wiki/Rise_Technology for a pic of this mythical beast.
>
> Dave
>
> My VIA C7 has the same problem, boots on 486 but not on C3-2 or C7
>
> --
> Hans
I suppose VIA C7 is another candidate for verify_cpu.S
Maybe something like this in assembler might be useful:
if ( ! Intel && ! AMD )
{
andl$~NEED_CMPXCHG64,%edx
}
This would not really harm anything but avoid this problem.
But I just don't know x86 to do this proper.
Christian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II
Andi Kleen wrote: > Can someone please test if this patch works? > > This preserves the 6 <= model <= 9 logic of the C code; this means > if VIA ever brings out model >= 10 it hopefully sets this bit by default. > Dave, do you have any information to the contrary? > > -Andi > Hi Andi, your patch did not work. See the correction below. The mask should contain 1<<1 instead of 1. Model 10 is now also included. I add also a patch for setup.S. It does not print the CPUID message in case the CPUID is wrong, cause %ds was not set proper. Best regards, Christian Index: linux/arch/i386/kernel/verify_cpu.S === --- linux.orig/arch/i386/kernel/verify_cpu.S +++ linux/arch/i386/kernel/verify_cpu.S @@ -2,6 +2,7 @@ This runs in 16bit mode so that the caller can still use the BIOS to output errors on the screen */ #include +#include verify_cpu: pushfl # Save caller passed flags @@ -45,6 +46,28 @@ cmpl$0x1,%eax jb bad # no cpuid 1 +#if REQUIRED_MASK1 & NEED_CMPXCHG64 + /* Some VIA C3s need magic MSRs to enable CX64. Do this here */ + cmpl$0x746e6543,%ebx# Cent + jne 1f + cmpl$0x48727561,%edx# aurH + jne 1f + cmpl$0x736c7561,%ecx# auls + jne 1f + movl$1,%eax # check model + cpuid + shr $4,%eax + andl$0xf,%eax # get model + cmpl$6,%eax + jb 1f + cmpl$10,%eax # newer vias hopefully don't require + ja 1f # this anymore + movl$MSR_VIA_FCR,%ecx + rdmsr + orl $((1<<1)|(1<<7)),%eax # enable CMPXCHG64 and PGE + wrmsr +1: +#endif movl$0x1,%eax # Does the cpu have what it takes cpuid Index: linux/arch/i386/boot/verify_cpu.S === --- linux.orig/arch/i386/boot/setup.S +++ linux/arch/i386/boot/setup.S @@ -310,12 +310,15 @@ call verify_cpu testl %eax,%eax jz cpu_ok +# missed before: set ds + pushw %cs # CPU too old or CPUID function bits are wrong. + popw%ds # die. lea cpu_panic_mess,%si callprtstr 1: jmp 1b cpu_panic_mess: - .asciz "PANIC: CPU too old for this kernel." +.asciz "PANIC: CPU too old for this kernel or CPUID function bits are wrong." #include "../kernel/verify_cpu.S" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Via C3: other flags possible ?
Hi, Claas asked for the NX flag for the Via C3 (?) processors in another thread. I do not know another synonym for this? Claas Langbehn wrote: > Hello Christian, > > do you know if and how it's possible to enable NX_bit too? > > > Claas > The via C3 documentation is at: http://www.via.com.tw/en/products/processors/c3/ I have seen in c3_ebga.zip that the processor might support 3DNow. But you have to check the registers about this. Inside linux-2.6.22-rc1/arch/i386/kernel/cpu/centaur.c I just see a "fixed type" detection. Does anybody have more information on this ? Otherwise I would play around a little with my C3 Nehemiah and try to change the detection according the Via documentation. Best regards, Christian PS @Andi, did you look for the page above for data sheets? Please see the download section. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via C3: other flags possible ?
Christian Volkmann wrote: > Hi, > > Claas asked for the NX flag for the Via C3 (?) processors > in another thread. > > I do not know another synonym for this? > > Claas Langbehn wrote: >> Hello Christian, >> >> do you know if and how it's possible to enable NX_bit too? >> >> >> Claas >> > C7 Esther: Hmm, I expect the NX-Bit should be detected from linux during the boot. The NX function bit seems to be at the same place where it's located for other CPU. Unfortunately I have no C7 hardware and I am too much a beginner in kernel programming to prepare this "dry". May be a "senior kernel programmer" can easy check if the C7 runs through the regular NX-function detection? Best regards, Christian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via C3/C7: other flags possible ?
Bit 20 in edx is set if NX is available for C7: eax in: 0x8001, eax = ebx = ecx = edx = 0010 ( from your posting "This kernel requires the following..." ) The official VIA Eden datasheet seems to be NDA. I have not found any official download link on the pages: http://www.via.com.tw/en/products/processors/c7/ The /c3/ pages contain the documentation for the C3 family. I do not think the NX feature can be switched on/off by regular registers. May be it helps to play around with the bios ? Load "default settings" => see how the NX flag acts. Load "optimized settings" => see how the NX flags acts. I suppose the bios developer had used one setting to test and work with the NX flag regular. Christian > If you read the other thread properly you'd see that the BIOS has an option > to enable or disable it... when enabled it shows up. PS: @Simon, sorry that I missed the other thread. Too much traffic and not enough time for me to read all. I suppose that's a fulltime job ;-) Claas Langbehn wrote: > Simon Arlott schrieb: >> On 19/05/07 23:36, Christian Volkmann wrote: >>> Christian Volkmann wrote: >>>> Claas asked for the NX flag for the Via C3 (?) processors >>>> in another thread. >> >> If you read the other thread properly you'd see that the BIOS has an >> option to enable or disable it... when enabled it shows up. > > Right, but my bios disables this after each boot-time :( > Therefore it would be great if the kernel would not care > about the BIOS and enable it anyway. > > This seems to be a severe bug in the BIOS, but VIA does not > deliver a new BIOS since months. :( > >> >> I can't reboot that box just to test cx8 detection (which is missing). >> > It works here. > > > > claas > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: This kernel requires the following features not present on the CPU... (on a VIA C7 CPU)
Claas Langbehn wrote: > Could anyone explain to me what CMPXCHG64 / cx8 is and what happens if > the kernel has been compiled to use it but the CPU does not have it? > > Regards, > claas > Hi Claas, the bug is at another place. But it's hidden if X86_CMPXCHG64 is switched of. There are 3 errors. First: Via is capable of CMPXCHG64, but switch the related CPU bit off to work with old Win NT versions. ( So the NT error is the fourth... but who cares about that error. ;-) ) Second: verify_cpu.S This checks during the boot the capability of the CPU. It expected the related bit, but... see first. This error is switched of if X86_CMPXCHG64 is disabled. Third: setup.S "PANIC: CPU too old for this kernel." is not printed cause of a missing set register in setup.S. As I have learned the NX-bit of the C7 is a BIOS issue. The only real required patch is below. It enables the right bits for the C3/C7. The first error is out of scope, and the fix for the "CPU too old.." is for me just a cosmetic print out in case of boot errors. I suppose .rc3 should contain a fix for this bug. Best regards, Christian --- linux.orig/arch/i386/kernel/verify_cpu.S +++ linux/arch/i386/kernel/verify_cpu.S @@ -2,6 +2,7 @@ This runs in 16bit mode so that the caller can still use the BIOS to output errors on the screen */ #include +#include verify_cpu: pushfl # Save caller passed flags @@ -45,6 +46,28 @@ cmpl$0x1,%eax jb bad # no cpuid 1 +#if REQUIRED_MASK1 & NEED_CMPXCHG64 + /* Some VIA C3s need magic MSRs to enable CX64. Do this here */ + cmpl$0x746e6543,%ebx# Cent + jne 1f + cmpl$0x48727561,%edx# aurH + jne 1f + cmpl$0x736c7561,%ecx# auls + jne 1f + movl$1,%eax # check model + cpuid + shr $4,%eax + andl$0xf,%eax # get model + cmpl$6,%eax + jb 1f + cmpl$10,%eax # newer vias hopefully don't require + ja 1f # this anymore + movl$MSR_VIA_FCR,%ecx + rdmsr + orl $((1<<1)|(1<<7)),%eax # enable CMPXCHG64 and PGE + wrmsr +1: +#endif movl$0x1,%eax # Does the cpu have what it takes cpuid - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc6: usb 1-1: device not accepting address 2, error -62
Hi everybody, I have an error message with 2.6.23-rc6. This did not happen with 2.6.22. The kernel reports message like this: <3>usb 1-1: device not accepting address 2, error -62 <3>hub 2-2.1:1.0: hub_port_status failed (err = -71) Does this message harm or is something broken in 2.6.23-rc6 ? I get this kind of messages also with 2.6.23-rc3 Best regards, Christian Please see below for: grep -e hub -e usb boot.msg for a 2.6.23-rc6 boot. (that boot was without (err = -71) grep -e hub -e usb boot.msg for a 2.6.22 boot. lspci -vnn (2.6.22) lsusb -v (2.6.22) 2.6.23-rc6 boot.msg extract ( hub/usb ) <6>usbcore: registered new interface driver usbfs <6>usbcore: registered new interface driver hub <6>usbcore: registered new device driver usb <6>usb usb1: configuration #1 chosen from 1 choice <6>hub 1-0:1.0: USB hub found <6>hub 1-0:1.0: 2 ports detected <6>usb usb2: configuration #1 chosen from 1 choice <6>hub 2-0:1.0: USB hub found <6>hub 2-0:1.0: 2 ports detected <6>usb 1-1: new low speed USB device using ohci_hcd and address 2 <6>usb usb3: configuration #1 chosen from 1 choice <6>hub 3-0:1.0: USB hub found <6>hub 3-0:1.0: 2 ports detected <6>usb usb4: configuration #1 chosen from 1 choice <6>hub 4-0:1.0: USB hub found <6>hub 4-0:1.0: 6 ports detected <6>usb usb5: configuration #1 chosen from 1 choice <6>hub 5-0:1.0: USB hub found <6>hub 5-0:1.0: 2 ports detected <3>usb 1-1: device not accepting address 2, error -62 <6>usb 5-2: new full speed USB device using uhci_hcd and address 2 <6>usb usb6: configuration #1 chosen from 1 choice <6>hub 6-0:1.0: USB hub found <6>hub 6-0:1.0: 4 ports detected <6>usb usb7: configuration #1 chosen from 1 choice <6>hub 7-0:1.0: USB hub found <6>hub 7-0:1.0: 2 ports detected <6>usb 1-1: new low speed USB device using ohci_hcd and address 4 <6>usb 1-1: configuration #1 chosen from 1 choice <6>usb 2-1: new full speed USB device using ohci_hcd and address 2 <6>usb 2-1: configuration #1 chosen from 1 choice <6>usb 6-2: new high speed USB device using ehci_hcd and address 2 <6>usb 6-2: configuration #1 chosen from 1 choice <6>hub 6-2:1.0: USB hub found <6>hub 6-2:1.0: 2 ports detected <6>usbcore: registered new interface driver hiddev <6>input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-:00:03.0-1 <6>usbcore: registered new interface driver usbhid <6>drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver <7>usb-storage: device found at 2 <7>usb-storage: waiting for device to settle before scanning <6>usb 6-2.1: new high speed USB device using ehci_hcd and address 3 <6>usb 6-2.1: configuration #1 chosen from 1 choice <6>hub 6-2.1:1.0: USB hub found <6>hub 6-2.1:1.0: 4 ports detected <6>usb 6-2.1.1: new high speed USB device using ehci_hcd and address 4 <6>usb 6-2.1.1: configuration #1 chosen from 1 choice <7>usb-storage: device found at 4 <7>usb-storage: waiting for device to settle before scanning <6>usbcore: registered new interface driver usb-storage <7>usb-storage: device scan complete <7>usb-storage: device scan complete 2.6.22 boot.msg extract ( hub/usb ) <6>usbcore: registered new interface driver usbfs <6>usbcore: registered new interface driver hub <6>usbcore: registered new device driver usb <6>usb usb1: configuration #1 chosen from 1 choice <6>hub 1-0:1.0: USB hub found <6>hub 1-0:1.0: 2 ports detected <6>usb usb2: configuration #1 chosen from 1 choice <6>hub 2-0:1.0: USB hub found <6>hub 2-0:1.0: 2 ports detected <6>usb 1-1: new low speed USB device using ohci_hcd and address 2 <6>usb usb3: configuration #1 chosen from 1 choice <6>hub 3-0:1.0: USB hub found <6>hub 3-0:1.0: 2 ports detected <6>usb 1-1: configuration #1 chosen from 1 choice <6>usb usb4: configuration #1 chosen from 1 choice <6>hub 4-0:1.0: USB hub found <6>hub 4-0:1.0: 6 ports detected <6>usb 1-1: USB disconnect, address 2 <6>usb usb5: configuration #1 chosen from 1 choice <6>hub 5-0:1.0: USB hub found <6>hub 5-0:1.0: 4 ports detected <6>usb usb6: configuration #1 chosen from 1 choice <6>hub 6-0:1.0: USB hub found <6>hub 6-0:1.0: 2 ports detected <6>usb usb7: configuration #1 chosen from 1 choice <6>hub 7-0:1.0: USB hub found <6>hub 7-0:1.0: 2 ports detected <6>usb 5-2: new high speed USB device using ehci_hcd and address 2 <6>usb 5-2: configuration #1 chosen from 1 choice <6>hub 5-2:1.0: USB hub found <6>hub 5-2:1.0: 2 ports detected <6>usb 1-1: new low speed USB device using ohci_hcd and address 3 <6>usb 1-1: configuration #1 chosen from 1 choice <6>usbcore: registered new interface driver hiddev <6>usb 2-1: new full speed USB device using ohci_hcd and address 2 <6>usb 2-1: configuration #1 chosen from 1 choice <6>usb 5-2.1: new high speed USB device using ehci_hcd and address 3 <6>usb 5-2.1: configuration #1 chosen from 1 choice <6>hub 5-2.1:1.0: USB hub found <6>hub 5-2.1:1.0: 4 ports detected <6>input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-:00:03.0-1 <7>usb-storage: device found at 2 <7>usb-storage: waiting for device to settle before scanning <6>usb 5-2.1.1: new high
Re: 2.6.23-rc6: usb 1-1: device not accepting address 2, error -62
> Does the machine otherwise work OK? > Yes, the USB is working fine for the easy things I do with it. Hmm, so I expect this 2.6.22 message: >> <6>usb 1-1: USB disconnect, address 2 became this 2.6.23rc6 message: >> <3>usb 1-1: device not accepting address 2, error -62 and nothing is harmed. Andrew Morton wrote: > Let's cc the USB mailing list. > > On Fri, 14 Sep 2007 23:28:23 +0200 Christian Volkmann <[EMAIL PROTECTED]> > wrote: > >> Hi everybody, >> >> I have an error message with 2.6.23-rc6. >> This did not happen with 2.6.22. > > Another one for Michal's dirt file. > >> The kernel reports message like this: >> <3>usb 1-1: device not accepting address 2, error -62 >> <3>hub 2-2.1:1.0: hub_port_status failed (err = -71) >> >> Does this message harm or is something broken in 2.6.23-rc6 ? >> I get this kind of messages also with 2.6.23-rc3 > > Does the machine otherwise work OK? > > Even if it does, I don't think we should be (newly) spraying scary messages > like that at people. > >> Best regards, >> >> Christian >> >> >> Please see below for: >> >> grep -e hub -e usb boot.msg for a 2.6.23-rc6 boot. (that boot was without >> (err = -71) >> grep -e hub -e usb boot.msg for a 2.6.22 boot. >> lspci -vnn (2.6.22) >> lsusb -v (2.6.22) >> >> >> 2.6.23-rc6 boot.msg extract ( hub/usb ) >> >> <6>usbcore: registered new interface driver usbfs >> <6>usbcore: registered new interface driver hub >> <6>usbcore: registered new device driver usb >> <6>usb usb1: configuration #1 chosen from 1 choice >> <6>hub 1-0:1.0: USB hub found >> <6>hub 1-0:1.0: 2 ports detected >> <6>usb usb2: configuration #1 chosen from 1 choice >> <6>hub 2-0:1.0: USB hub found >> <6>hub 2-0:1.0: 2 ports detected >> <6>usb 1-1: new low speed USB device using ohci_hcd and address 2 >> <6>usb usb3: configuration #1 chosen from 1 choice >> <6>hub 3-0:1.0: USB hub found >> <6>hub 3-0:1.0: 2 ports detected >> <6>usb usb4: configuration #1 chosen from 1 choice >> <6>hub 4-0:1.0: USB hub found >> <6>hub 4-0:1.0: 6 ports detected >> <6>usb usb5: configuration #1 chosen from 1 choice >> <6>hub 5-0:1.0: USB hub found >> <6>hub 5-0:1.0: 2 ports detected >> <3>usb 1-1: device not accepting address 2, error -62 >> <6>usb 5-2: new full speed USB device using uhci_hcd and address 2 >> <6>usb usb6: configuration #1 chosen from 1 choice >> <6>hub 6-0:1.0: USB hub found >> <6>hub 6-0:1.0: 4 ports detected >> <6>usb usb7: configuration #1 chosen from 1 choice >> <6>hub 7-0:1.0: USB hub found >> <6>hub 7-0:1.0: 2 ports detected >> <6>usb 1-1: new low speed USB device using ohci_hcd and address 4 >> <6>usb 1-1: configuration #1 chosen from 1 choice >> <6>usb 2-1: new full speed USB device using ohci_hcd and address 2 >> <6>usb 2-1: configuration #1 chosen from 1 choice >> <6>usb 6-2: new high speed USB device using ehci_hcd and address 2 >> <6>usb 6-2: configuration #1 chosen from 1 choice >> <6>hub 6-2:1.0: USB hub found >> <6>hub 6-2:1.0: 2 ports detected >> <6>usbcore: registered new interface driver hiddev >> <6>input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-:00:03.0-1 >> <6>usbcore: registered new interface driver usbhid >> <6>drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver >> <7>usb-storage: device found at 2 >> <7>usb-storage: waiting for device to settle before scanning >> <6>usb 6-2.1: new high speed USB device using ehci_hcd and address 3 >> <6>usb 6-2.1: configuration #1 chosen from 1 choice >> <6>hub 6-2.1:1.0: USB hub found >> <6>hub 6-2.1:1.0: 4 ports detected >> <6>usb 6-2.1.1: new high speed USB device using ehci_hcd and address 4 >> <6>usb 6-2.1.1: configuration #1 chosen from 1 choice >> <7>usb-storage: device found at 4 >> <7>usb-storage: waiting for device to settle before scanning >> <6>usbcore: registered new interface driver usb-storage >> <7>usb-storage: device scan complete >> <7>usb-storage: device scan complete >> >> 2.6.22 boot.msg extract ( hub/usb ) >> >> <6>usbcore: registered new interface driver usbfs >> <6>usbcore: registered new interface driver hub >> <6>usbcore: registere
Re: 2.6.23-rc6: usb 1-1: device not accepting address 2, error -62
Second try to send, after I created "postmaster" on my domain. Just to ensure the CC-list works correct. Sorry for this double posting. > 550-Postmaster verification failed while checking <[EMAIL PROTECTED]> > 550-Called: 212.227.15.134 > 550-Sent: RCPT TO:<[EMAIL PROTECTED]> > 550-Response: 550 <[EMAIL PROTECTED]>: invalid address > 550-Several RFCs state that you are required to have a postmaster > 550-mailbox for each mail domain. This host does not accept mail > 550-from domains whose servers reject the postmaster address. >550 Sender verify failed > Does the machine otherwise work OK? > Yes, the USB is working fine for the easy things I do with it. Hmm, so I expect this 2.6.22 message: >> <6>usb 1-1: USB disconnect, address 2 became this 2.6.23rc6 message: >> <3>usb 1-1: device not accepting address 2, error -62 and nothing is harmed. Andrew Morton wrote: > Let's cc the USB mailing list. > > On Fri, 14 Sep 2007 23:28:23 +0200 Christian Volkmann <[EMAIL PROTECTED]> > wrote: > >> Hi everybody, >> >> I have an error message with 2.6.23-rc6. >> This did not happen with 2.6.22. > > Another one for Michal's dirt file. > >> The kernel reports message like this: >> <3>usb 1-1: device not accepting address 2, error -62 >> <3>hub 2-2.1:1.0: hub_port_status failed (err = -71) >> >> Does this message harm or is something broken in 2.6.23-rc6 ? >> I get this kind of messages also with 2.6.23-rc3 > > Does the machine otherwise work OK? > > Even if it does, I don't think we should be (newly) spraying scary messages > like that at people. > >> Best regards, >> >> Christian >> >> >> Please see below for: >> >> grep -e hub -e usb boot.msg for a 2.6.23-rc6 boot. (that boot was without >> (err = -71) >> grep -e hub -e usb boot.msg for a 2.6.22 boot. >> lspci -vnn (2.6.22) >> lsusb -v (2.6.22) >> >> >> 2.6.23-rc6 boot.msg extract ( hub/usb ) >> >> <6>usbcore: registered new interface driver usbfs >> <6>usbcore: registered new interface driver hub >> <6>usbcore: registered new device driver usb >> <6>usb usb1: configuration #1 chosen from 1 choice >> <6>hub 1-0:1.0: USB hub found >> <6>hub 1-0:1.0: 2 ports detected >> <6>usb usb2: configuration #1 chosen from 1 choice >> <6>hub 2-0:1.0: USB hub found >> <6>hub 2-0:1.0: 2 ports detected >> <6>usb 1-1: new low speed USB device using ohci_hcd and address 2 >> <6>usb usb3: configuration #1 chosen from 1 choice >> <6>hub 3-0:1.0: USB hub found >> <6>hub 3-0:1.0: 2 ports detected >> <6>usb usb4: configuration #1 chosen from 1 choice >> <6>hub 4-0:1.0: USB hub found >> <6>hub 4-0:1.0: 6 ports detected >> <6>usb usb5: configuration #1 chosen from 1 choice >> <6>hub 5-0:1.0: USB hub found >> <6>hub 5-0:1.0: 2 ports detected >> <3>usb 1-1: device not accepting address 2, error -62 >> <6>usb 5-2: new full speed USB device using uhci_hcd and address 2 >> <6>usb usb6: configuration #1 chosen from 1 choice >> <6>hub 6-0:1.0: USB hub found >> <6>hub 6-0:1.0: 4 ports detected >> <6>usb usb7: configuration #1 chosen from 1 choice >> <6>hub 7-0:1.0: USB hub found >> <6>hub 7-0:1.0: 2 ports detected >> <6>usb 1-1: new low speed USB device using ohci_hcd and address 4 >> <6>usb 1-1: configuration #1 chosen from 1 choice >> <6>usb 2-1: new full speed USB device using ohci_hcd and address 2 >> <6>usb 2-1: configuration #1 chosen from 1 choice >> <6>usb 6-2: new high speed USB device using ehci_hcd and address 2 >> <6>usb 6-2: configuration #1 chosen from 1 choice >> <6>hub 6-2:1.0: USB hub found >> <6>hub 6-2:1.0: 2 ports detected >> <6>usbcore: registered new interface driver hiddev >> <6>input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-:00:03.0-1 >> <6>usbcore: registered new interface driver usbhid >> <6>drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver >> <7>usb-storage: device found at 2 >> <7>usb-storage: waiting for device to settle before scanning >> <6>usb 6-2.1: new high speed USB device using ehci_hcd and address 3 >> <6>usb 6-2.1: configuration #1 chosen from 1 choice >> <6>hub 6-2.1:1.0: USB hub found >> <6>hub 6-2.1:1.0: 4 ports detected >> <6>usb 6-2.1.1: new high speed USB device using
Re: 2.6.23-rc6: usb 1-1: device not accepting address 2, error -62
Pete Zaitcev wrote: > On Sat, 15 Sep 2007 03:48:19 -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > >>> I have an error message with 2.6.23-rc6. >>> This did not happen with 2.6.22. >> Another one for Michal's dirt file. > > No, I think it's the module ordering again. > >>> 2.6.23-rc6 boot.msg extract ( hub/usb ) > > I wish users stopped this filtering, it's a very bad idea. > Sorry about this. I want to keep the postings shorter. Please see my earlier reply for the complete messages made with CONFIG_PRINTK_TIME and CONFIG_USB_DEBUG > As it is, there's no message showing when ehci_hcd was loaded. > We can try piece together the picture: > >>> <6>usb usb1: configuration #1 chosen from 1 choice >>> <6>hub 1-0:1.0: USB hub found >>> <6>hub 1-0:1.0: 2 ports detected >>> <6>usb usb2: configuration #1 chosen from 1 choice >>> <6>hub 2-0:1.0: USB hub found >>> <6>hub 2-0:1.0: 2 ports detected >>> <6>usb 1-1: new low speed USB device using ohci_hcd and address 2 > > ok this was ohci_hcd > >>> <3>usb 1-1: device not accepting address 2, error -62 >>> <6>usb 5-2: new full speed USB device using uhci_hcd and address 2 > > was ehci here? We don't know but I bet it was, because: > >>> <6>usb 6-2: new high speed USB device using ehci_hcd and address 2 > >>> 2.6.22 boot.msg extract ( hub/usb ) > > This one seems far shorter. The EHCI comes online late here as well, > but not as late as in the "regression" case. I am wondering if we > have some kind of "parallel PCI probing" option in action here. I can send my .config on request. The system itself is a regular suse 10.2. > > -- Pete > Christian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
