Re: rtl8192cu: slow path warning
Hello Larry, On Tue, 23 Jul 2013 10:05:26 -0500 Larry Finger wrote: > The reason that patch is not in mainline is that it takes time. If you > want to have it, you can get the official patch from > http://marc.info/?l=linux-wireless=137242880222442=2, or you need to > implement kernels from the wireless-testing git tree, where it was added > on June 28 as commit bcfb879. My original patch included the following > note for John Linville: > > "Ideally, this patch should be pushed to the 3.10 stream; however, at > this late time that is not possible. Please push it for 3.11 and the Cc > to stable will get it into 3.10.X." > > As you see, it was marked with a Cc for Stable, and it will be propagated > to 3.10 when it gets incorporated by Linus. I think I have done all that > I can do for now. > > If you want to lobby Linus to get stuff accepted faster, that is your > prerogative; however, I could not recommend that action, and I certainly > will never do anything like that. Neither will I... I was just wondering and asking, nothing else, as I'm also facing this warning. I'm glad to see the link you sent is presenting a patch that is the same as the one I prepared. I'm going to use that while waiting for the patch to hit mainline ! Thanks for replying, Best, Paul signature.asc Description: PGP signature
Re: rtl8192cu: slow path warning
Hello Richard, If you still have the required HW and still would like a patch to remove that warning on your machine, could you please try the attached one ? I slightly reworked the original patch by moving the function rtl_lps_change_work_callback from pci.c to ps.c. I've successfully compiled that on my machine, but I have PCI set in my .config, so I'd like your feedback. Best, Paul On Tue, 23 Jul 2013 14:29:07 +0200 Paul Rolland (ポール・ロラン) wrote: > Hello, > > On Thu, 27 Jun 2013 09:33:20 +0200 > Richard Genoud wrote: > > > Yes, of course, you can add my > > Reported-by: Richard Genoud > > > > But the patch doesn't compile on my platform ( since I'm on ARM, I > > haven't got a PCI bus, so rtlwifi/pci.c is not compiled ) : > > > > ERROR: "rtl_lps_change_work_callback" > > [drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined! > > Is that the reason why this patch is not yet in 3.10.x or 3.11-rcY ? > I'm running a 3.10.1 with USB dongle including 8192CU, and I can see this > warning when the machine starts. > I've check 3.10.1, 3.10.2 and 3.11-rc3 source code, but this fix is not > there. Is there a different fix that went in in 3.10.2 or 3.11-rc? > > Best, > Paul patch Description: Binary data signature.asc Description: PGP signature
Re: rtl8192cu: slow path warning
Hello, On Thu, 27 Jun 2013 09:33:20 +0200 Richard Genoud wrote: > Yes, of course, you can add my > Reported-by: Richard Genoud > > But the patch doesn't compile on my platform ( since I'm on ARM, I > haven't got a PCI bus, so rtlwifi/pci.c is not compiled ) : > > ERROR: "rtl_lps_change_work_callback" > [drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined! Is that the reason why this patch is not yet in 3.10.x or 3.11-rcY ? I'm running a 3.10.1 with USB dongle including 8192CU, and I can see this warning when the machine starts. I've check 3.10.1, 3.10.2 and 3.11-rc3 source code, but this fix is not there. Is there a different fix that went in in 3.10.2 or 3.11-rc? Best, Paul signature.asc Description: PGP signature
Re: rtl8192cu: slow path warning
Hello, On Thu, 27 Jun 2013 09:33:20 +0200 Richard Genoud richard.gen...@gmail.com wrote: Yes, of course, you can add my Reported-by: Richard Genoud richard.gen...@gmail.com But the patch doesn't compile on my platform ( since I'm on ARM, I haven't got a PCI bus, so rtlwifi/pci.c is not compiled ) : ERROR: rtl_lps_change_work_callback [drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined! Is that the reason why this patch is not yet in 3.10.x or 3.11-rcY ? I'm running a 3.10.1 with USB dongle including 8192CU, and I can see this warning when the machine starts. I've check 3.10.1, 3.10.2 and 3.11-rc3 source code, but this fix is not there. Is there a different fix that went in in 3.10.2 or 3.11-rc? Best, Paul signature.asc Description: PGP signature
Re: rtl8192cu: slow path warning
Hello Richard, If you still have the required HW and still would like a patch to remove that warning on your machine, could you please try the attached one ? I slightly reworked the original patch by moving the function rtl_lps_change_work_callback from pci.c to ps.c. I've successfully compiled that on my machine, but I have PCI set in my .config, so I'd like your feedback. Best, Paul On Tue, 23 Jul 2013 14:29:07 +0200 Paul Rolland (ポール・ロラン) r...@witbe.net wrote: Hello, On Thu, 27 Jun 2013 09:33:20 +0200 Richard Genoud richard.gen...@gmail.com wrote: Yes, of course, you can add my Reported-by: Richard Genoud richard.gen...@gmail.com But the patch doesn't compile on my platform ( since I'm on ARM, I haven't got a PCI bus, so rtlwifi/pci.c is not compiled ) : ERROR: rtl_lps_change_work_callback [drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined! Is that the reason why this patch is not yet in 3.10.x or 3.11-rcY ? I'm running a 3.10.1 with USB dongle including 8192CU, and I can see this warning when the machine starts. I've check 3.10.1, 3.10.2 and 3.11-rc3 source code, but this fix is not there. Is there a different fix that went in in 3.10.2 or 3.11-rc? Best, Paul patch Description: Binary data signature.asc Description: PGP signature
Re: rtl8192cu: slow path warning
Hello Larry, On Tue, 23 Jul 2013 10:05:26 -0500 Larry Finger larry.fin...@lwfinger.net wrote: The reason that patch is not in mainline is that it takes time. If you want to have it, you can get the official patch from http://marc.info/?l=linux-wirelessm=137242880222442w=2, or you need to implement kernels from the wireless-testing git tree, where it was added on June 28 as commit bcfb879. My original patch included the following note for John Linville: Ideally, this patch should be pushed to the 3.10 stream; however, at this late time that is not possible. Please push it for 3.11 and the Cc to stable will get it into 3.10.X. As you see, it was marked with a Cc for Stable, and it will be propagated to 3.10 when it gets incorporated by Linus. I think I have done all that I can do for now. If you want to lobby Linus to get stuff accepted faster, that is your prerogative; however, I could not recommend that action, and I certainly will never do anything like that. Neither will I... I was just wondering and asking, nothing else, as I'm also facing this warning. I'm glad to see the link you sent is presenting a patch that is the same as the one I prepared. I'm going to use that while waiting for the patch to hit mainline ! Thanks for replying, Best, Paul signature.asc Description: PGP signature
Re: PROBLEM: Can ping address, but traceroute gets ENETDOWN
Hello,
On Tue, 17 Jul 2012 09:41:27 -0400
Terry Phelps wrote:
> On Tue, Jul 17, 2012 at 9:30 AM, Eric Dumazet
> wrote:
> > On Tue, 2012-07-17 at 09:04 -0400, Terry Phelps wrote:
> >> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
> >> setsockopt(3, SOL_IP, IP_MTU_DISCOVER, [0], 4) = 0
> >> setsockopt(3, SOL_SOCKET, SO_TIMESTAMP, [1], 4) = 0
> >> fcntl(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
> >> setsockopt(3, SOL_IP, IP_TTL, [1], 4) = 0
> >> setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
> >> connect(3, {sa_family=AF_INET, sin_port=htons(33434),
> >> sin_addr=inet_addr("192.168.118.22")}, 28) = 0
> >> sendto(3, "@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = -1
> >> ENETDOWN (Network is down)
ENETDOWN should mean your interface is no more in the UP status.
Could it be you have some processes running that could turn down and up
your interfaces ? Anything in /var/log/messages about eth0 ?
Paul
signature.asc
Description: PGP signature
Re: PROBLEM: Can ping address, but traceroute gets ENETDOWN
Hello,
On Tue, 17 Jul 2012 09:41:27 -0400
Terry Phelps tgphelp...@gmail.com wrote:
On Tue, Jul 17, 2012 at 9:30 AM, Eric Dumazet eric.duma...@gmail.com
wrote:
On Tue, 2012-07-17 at 09:04 -0400, Terry Phelps wrote:
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
setsockopt(3, SOL_IP, IP_MTU_DISCOVER, [0], 4) = 0
setsockopt(3, SOL_SOCKET, SO_TIMESTAMP, [1], 4) = 0
fcntl(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
setsockopt(3, SOL_IP, IP_TTL, [1], 4) = 0
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(33434),
sin_addr=inet_addr(192.168.118.22)}, 28) = 0
sendto(3, @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_..., 40, 0, NULL, 0) = -1
ENETDOWN (Network is down)
ENETDOWN should mean your interface is no more in the UP status.
Could it be you have some processes running that could turn down and up
your interfaces ? Anything in /var/log/messages about eth0 ?
Paul
signature.asc
Description: PGP signature
Re: constant_tsc and TSC unstable
Hello, On Fri, 30 Nov 2007 00:26:47 +0300 Michael Tokarev <[EMAIL PROTECTED]> wrote: > H. Peter Anvin wrote: > > Paul Rolland (ポール・ロラン) wrote: > [] > >> Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock. > >> Marking TSC unstable due to: check_tsc_sync_source failed. > [] > >> but I was wondering if this is a bug or a feature ;) > > > The problem you're having is that the TSCs of your two cores are > > completely different, over a second apart. This is a bug, unrelated to > > constant_tsc. > > A bug in where - in the CPU or in kernel? Good question ! > The thing is that all our dual-core machines shows something like > that. > > (not that huge difference as Paul reported, but still "unstable". > The same happens with 2.6.23) I've been checking my logs, and the difference is quite constant and huge : [EMAIL PROTECTED] log]# grep 'cycles TSC warp' messages* messages:Nov 26 08:27:56 tux kernel: Measured 4078687691 cycles TSC warp between C PUs, turning off TSC clock. messages:Nov 26 17:21:21 tux kernel: Measured 3978592228 cycles TSC warp between C PUs, turning off TSC clock. messages.1:Nov 18 22:52:23 tux kernel: Measured 4063102940 cycles TSC warp between CPUs, turning off TSC clock. messages.1:Nov 19 07:19:02 tux kernel: Measured 4057192061 cycles TSC warp between CPUs, turning off TSC clock. messages.1:Nov 23 20:50:12 tux kernel: Measured 4064589321 cycles TSC warp between CPUs, turning off TSC clock. messages.2:Nov 12 08:06:44 tux kernel: Measured 4072130361 cycles TSC warp between CPUs, turning off TSC clock. messages.2:Nov 13 19:42:47 tux kernel: Measured 4049899451 cycles TSC warp between CPUs, turning off TSC clock. messages.2:Nov 17 09:27:22 tux kernel: Measured 4066629060 cycles TSC warp between CPUs, turning off TSC clock. messages.3:Nov 5 08:25:08 tux kernel: Measured 4086386109 cycles TSC warp between CPUs, turning off TSC clock. messages.3:Nov 8 13:07:08 tux kernel: Measured 4041945934 cycles TSC warp between CPUs, turning off TSC clock. messages.3:Nov 9 23:31:24 tux kernel: Measured 4092303059 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Oct 29 07:28:23 tux kernel: Measured 4096946373 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Oct 31 17:07:21 tux kernel: Measured 4046765372 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Oct 31 17:15:09 tux kernel: Measured 4039328228 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Oct 31 23:19:00 tux kernel: Measured 4069714246 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 1 20:33:02 tux kernel: Measured 4088199726 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 2 11:53:17 tux kernel: Measured 4079927527 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 3 09:37:16 tux kernel: Measured 4071112656 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 3 10:51:29 tux kernel: Measured 3986266219 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 4 18:14:56 tux kernel: Measured 4074214144 cycles TSC warp between CPUs, turning off TSC clock. > Note that once TSC is disabled (it's using "jiffies" as far > as I can see), ntpd constantly speeds up and slows down the > clock, it jumps +/- 0.5sec every several minutes or hours - > I guess that's when ntpd process gets moved from one core > to another for whatever reason. And an interesting thing > is that with 64bits kernel this TSC problem does not occur > on this very machine. H That could make it a problem related to kernel rather than CPU. > Something similar is reported on AMD X2 64 machines as well -- > can't check right now. If I recall correctly, issues with AMD X2 where related to TSC being independant for each core and not constant (speed depending of C state). But the reason I raise the issue is that the Core2 reports constant TSC, so there is (IMHO) no reason for that. Paul - 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: constant_tsc and TSC unstable
Hello, On Thu, 29 Nov 2007 15:29:49 -0800 "Pallipadi, Venkatesh" <[EMAIL PROTECTED]> wrote: > TSCs on Core 2 Duo are supposed to be in sync unless CPU supports deep idle > states like C2, C3. Can you send the full /proc/cpuinfo and full dmesg. > Sure I can... [EMAIL PROTECTED] log]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz stepping: 2 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat ps e36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmo n pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3461.13 clflush size: 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz stepping: 2 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat ps e36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmo n pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3458.02 clflush size: 64 Regards, Paul dmesg Description: Binary data
constant_tsc and TSC unstable
Hello, I've a machine with a Core2Duo CPU. /proc/cpuinfo reports the flag constant_tsc, but at boot time, I have the log : ... Total of 2 processors activated (6919.15 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 checking TSC synchronization [CPU#0 -> CPU#1]: Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock. Marking TSC unstable due to: check_tsc_sync_source failed. Brought up 2 CPUs ... This machine is running 2.6.23.1-21.fc7. I know I should report to Fedora, but I was wondering if this is a bug or a feature ;) Regards, Paul - 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/
constant_tsc and TSC unstable
Hello, I've a machine with a Core2Duo CPU. /proc/cpuinfo reports the flag constant_tsc, but at boot time, I have the log : ... Total of 2 processors activated (6919.15 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 checking TSC synchronization [CPU#0 - CPU#1]: Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock. Marking TSC unstable due to: check_tsc_sync_source failed. Brought up 2 CPUs ... This machine is running 2.6.23.1-21.fc7. I know I should report to Fedora, but I was wondering if this is a bug or a feature ;) Regards, Paul - 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: constant_tsc and TSC unstable
Hello, On Thu, 29 Nov 2007 15:29:49 -0800 Pallipadi, Venkatesh [EMAIL PROTECTED] wrote: TSCs on Core 2 Duo are supposed to be in sync unless CPU supports deep idle states like C2, C3. Can you send the full /proc/cpuinfo and full dmesg. Sure I can... [EMAIL PROTECTED] log]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz stepping: 2 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat ps e36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmo n pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3461.13 clflush size: 64 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU T5300 @ 1.73GHz stepping: 2 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat ps e36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmo n pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 3458.02 clflush size: 64 Regards, Paul dmesg Description: Binary data
Re: constant_tsc and TSC unstable
Hello, On Fri, 30 Nov 2007 00:26:47 +0300 Michael Tokarev [EMAIL PROTECTED] wrote: H. Peter Anvin wrote: Paul Rolland (ポール・ロラン) wrote: [] Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock. Marking TSC unstable due to: check_tsc_sync_source failed. [] but I was wondering if this is a bug or a feature ;) The problem you're having is that the TSCs of your two cores are completely different, over a second apart. This is a bug, unrelated to constant_tsc. A bug in where - in the CPU or in kernel? Good question ! The thing is that all our dual-core machines shows something like that. (not that huge difference as Paul reported, but still unstable. The same happens with 2.6.23) I've been checking my logs, and the difference is quite constant and huge : [EMAIL PROTECTED] log]# grep 'cycles TSC warp' messages* messages:Nov 26 08:27:56 tux kernel: Measured 4078687691 cycles TSC warp between C PUs, turning off TSC clock. messages:Nov 26 17:21:21 tux kernel: Measured 3978592228 cycles TSC warp between C PUs, turning off TSC clock. messages.1:Nov 18 22:52:23 tux kernel: Measured 4063102940 cycles TSC warp between CPUs, turning off TSC clock. messages.1:Nov 19 07:19:02 tux kernel: Measured 4057192061 cycles TSC warp between CPUs, turning off TSC clock. messages.1:Nov 23 20:50:12 tux kernel: Measured 4064589321 cycles TSC warp between CPUs, turning off TSC clock. messages.2:Nov 12 08:06:44 tux kernel: Measured 4072130361 cycles TSC warp between CPUs, turning off TSC clock. messages.2:Nov 13 19:42:47 tux kernel: Measured 4049899451 cycles TSC warp between CPUs, turning off TSC clock. messages.2:Nov 17 09:27:22 tux kernel: Measured 4066629060 cycles TSC warp between CPUs, turning off TSC clock. messages.3:Nov 5 08:25:08 tux kernel: Measured 4086386109 cycles TSC warp between CPUs, turning off TSC clock. messages.3:Nov 8 13:07:08 tux kernel: Measured 4041945934 cycles TSC warp between CPUs, turning off TSC clock. messages.3:Nov 9 23:31:24 tux kernel: Measured 4092303059 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Oct 29 07:28:23 tux kernel: Measured 4096946373 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Oct 31 17:07:21 tux kernel: Measured 4046765372 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Oct 31 17:15:09 tux kernel: Measured 4039328228 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Oct 31 23:19:00 tux kernel: Measured 4069714246 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 1 20:33:02 tux kernel: Measured 4088199726 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 2 11:53:17 tux kernel: Measured 4079927527 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 3 09:37:16 tux kernel: Measured 4071112656 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 3 10:51:29 tux kernel: Measured 3986266219 cycles TSC warp between CPUs, turning off TSC clock. messages.4:Nov 4 18:14:56 tux kernel: Measured 4074214144 cycles TSC warp between CPUs, turning off TSC clock. Note that once TSC is disabled (it's using jiffies as far as I can see), ntpd constantly speeds up and slows down the clock, it jumps +/- 0.5sec every several minutes or hours - I guess that's when ntpd process gets moved from one core to another for whatever reason. And an interesting thing is that with 64bits kernel this TSC problem does not occur on this very machine. H That could make it a problem related to kernel rather than CPU. Something similar is reported on AMD X2 64 machines as well -- can't check right now. If I recall correctly, issues with AMD X2 where related to TSC being independant for each core and not constant (speed depending of C state). But the reason I raise the issue is that the Core2 reports constant TSC, so there is (IMHO) no reason for that. Paul - 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-rc7 - _random_ IRQ23 : nobody cared
Hello, I already reported kernel 2.6.23-rcX warning about irq X : nobody cared, and it seemed to have been fixed in 2.6.23-rc6... Unfortunately, just rebooting with my 2.6.23-rc7, I got it appearing again, though the previous boot was just fine, and I didn't change/recompile my kernel in between. So, what changed ? I've compiled two modules : qc-usb-messenger, and hsf-modem, to make sure all my hardware is fully supported. And now, I have : scsi 3:0:1:0: Direct-Access ATA ST3500641AS 3.AA PQ: 0 ANSI: 5 sd 3:0:1:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) sd 3:0:1:0: [sdd] Write Protect is off sd 3:0:1:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:0:1:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) sd 3:0:1:0: [sdd] Write Protect is off sd 3:0:1:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA irq 23: nobody cared (try booting with the "irqpoll" option) Call Trace: [] __report_bad_irq+0x30/0x72 [] note_interrupt+0x20f/0x253 [] handle_fasteoi_irq+0xa9/0xd1 [] do_IRQ+0xf1/0x160 [] mwait_idle+0x0/0x45 [] ret_from_intr+0x0/0xa [] mwait_idle+0x42/0x45 [] cpu_idle+0xbd/0xe0 [] start_kernel+0x2bb/0x2c7 [] _sinittext+0x140/0x144 handlers: [] (ata_interrupt+0x0/0x1d3) Disabling IRQ #23 sdd:<3>ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata4.01: cmd c8/00:08:00:00:00/00:00:00:00:00/f0 tag 0 cdb 0x0 data 4096 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata4: soft resetting port ata4.01: qc timeout (cmd 0x27) ata4.01: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (976773168) ata4.00: failed to IDENTIFY (I/O error, err_mask=0x40) ata4: failed to recover some devices, retrying in 5 secs ata4: soft resetting port ata4.01: qc timeout (cmd 0x27) Booting with irqpoll is Ok, and I have : 2 [14:55] [EMAIL PROTECTED]:~> cat /proc/interrupts CPU0 CPU1 0: 31263 0 IO-APIC-edge timer 1:201 0 IO-APIC-edge i8042 4:219 0 IO-APIC-edge serial 6: 5 0 IO-APIC-edge floppy 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12:129 1124 IO-APIC-edge i8042 14: 7010 1235 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 4250 0 IO-APIC-fasteoi uhci_hcd:usb5, HDA Intel 20: 1251 44 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21:422640 IO-APIC-fasteoi pata_pdc2027x, firewire_ohci 23: 24023 0 IO-APIC-fasteoi libata, hsfpcibasic2 378: 93108 PCI-MSI-edge eth0 379: 1 0 PCI-MSI-edge eth1 NMI: 0 0 LOC: 31000 30803 ERR: 0 Hell, IRQ 23 is shared between libata and my modem !!! OK, just reboot, and see what happens Cool, now it is booting fine, no more complaint, even without irqpoll, IRQ 23 still shared... Another one, and Ok again... So, this looks really random :( Anything I could do to try to collect usefull traces ? Paul - 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-rc7 - _random_ IRQ23 : nobody cared
Hello, I already reported kernel 2.6.23-rcX warning about irq X : nobody cared, and it seemed to have been fixed in 2.6.23-rc6... Unfortunately, just rebooting with my 2.6.23-rc7, I got it appearing again, though the previous boot was just fine, and I didn't change/recompile my kernel in between. So, what changed ? I've compiled two modules : qc-usb-messenger, and hsf-modem, to make sure all my hardware is fully supported. And now, I have : scsi 3:0:1:0: Direct-Access ATA ST3500641AS 3.AA PQ: 0 ANSI: 5 sd 3:0:1:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) sd 3:0:1:0: [sdd] Write Protect is off sd 3:0:1:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:0:1:0: [sdd] 976773168 512-byte hardware sectors (500108 MB) sd 3:0:1:0: [sdd] Write Protect is off sd 3:0:1:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA irq 23: nobody cared (try booting with the irqpoll option) Call Trace: IRQ [8105d21b] __report_bad_irq+0x30/0x72 [8105d46c] note_interrupt+0x20f/0x253 [8105dd38] handle_fasteoi_irq+0xa9/0xd1 [8100ec65] do_IRQ+0xf1/0x160 [8100b25b] mwait_idle+0x0/0x45 [8100c431] ret_from_intr+0x0/0xa EOI [8100b29d] mwait_idle+0x42/0x45 [8100b1f3] cpu_idle+0xbd/0xe0 [8175ca8e] start_kernel+0x2bb/0x2c7 [8175c140] _sinittext+0x140/0x144 handlers: [81307485] (ata_interrupt+0x0/0x1d3) Disabling IRQ #23 sdd:3ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata4.01: cmd c8/00:08:00:00:00/00:00:00:00:00/f0 tag 0 cdb 0x0 data 4096 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata4: soft resetting port ata4.01: qc timeout (cmd 0x27) ata4.01: ata_hpa_resize 1: hpa sectors (0) is smaller than sectors (976773168) ata4.00: failed to IDENTIFY (I/O error, err_mask=0x40) ata4: failed to recover some devices, retrying in 5 secs ata4: soft resetting port ata4.01: qc timeout (cmd 0x27) Booting with irqpoll is Ok, and I have : 2 [14:55] [EMAIL PROTECTED]:~ cat /proc/interrupts CPU0 CPU1 0: 31263 0 IO-APIC-edge timer 1:201 0 IO-APIC-edge i8042 4:219 0 IO-APIC-edge serial 6: 5 0 IO-APIC-edge floppy 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12:129 1124 IO-APIC-edge i8042 14: 7010 1235 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 4250 0 IO-APIC-fasteoi uhci_hcd:usb5, HDA Intel 20: 1251 44 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21:422640 IO-APIC-fasteoi pata_pdc2027x, firewire_ohci 23: 24023 0 IO-APIC-fasteoi libata, hsfpcibasic2 378: 93108 PCI-MSI-edge eth0 379: 1 0 PCI-MSI-edge eth1 NMI: 0 0 LOC: 31000 30803 ERR: 0 Hell, IRQ 23 is shared between libata and my modem !!! OK, just reboot, and see what happens Cool, now it is booting fine, no more complaint, even without irqpoll, IRQ 23 still shared... Another one, and Ok again... So, this looks really random :( Anything I could do to try to collect usefull traces ? Paul - 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.23-rc6 : crash with RTL8187 USB
Hello, > [PATCH] mac80211: fix initialisation when built-in > http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation > > [PATCH] cfg80211: fix initialisation if built-in > http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation This is not present in 2.6.23-rc7 ! :((( Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" Volley Theory: It is better to have lobbed and lost than never to have lobbed at all. - 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.23-rc6 : crash with RTL8187 USB
Hello, [PATCH] mac80211: fix initialisation when built-in http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation [PATCH] cfg80211: fix initialisation if built-in http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation This is not present in 2.6.23-rc7 ! :((( Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it Volley Theory: It is better to have lobbed and lost than never to have lobbed at all. - 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: rtl8187 driver in 2.6.23-rc6-git5: kernel panic if not used as a module. Works as a module.
Hi Eric, On Sat, 15 Sep 2007 20:30:14 +0200 Eric Valette <[EMAIL PROTECTED]> wrote: > Rob Hussey wrote: > > On 9/15/07, Eric Valette <[EMAIL PROTECTED]> wrote: > >> Eric Valette wrote: > >> > > Thanks for your help: it does indeed fix the problem. Nice it works for you too ! > Now I have two side questions: > - the code is no more symetric "subsys_initcall" -> "module_exit". > Do not know if it is "normal" but I love symmetry in code :-). Did not test > it still works as a module... Symmetry is not broken, as we have : #define subsys_initcall(fn) module_init(fn) in include/linux/init.h where compiling as a module, and when not compiling as a module, I doubt the exit function is called unless you are shuting down your machine... > - Who takes the responsability to push a patch to Linus? I guess it > is urgent unless he plans a rc7 Good point ! I expect the patches to be already in some queue waiting to be pulled ! - 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: rtl8187 driver in 2.6.23-rc6-git5: kernel panic if not used as a module. Works as a module.
Hi Rob, On Sat, 15 Sep 2007 12:28:36 -0400 "Rob Hussey" <[EMAIL PROTECTED]> wrote: > On 9/15/07, Eric Valette <[EMAIL PROTECTED]> wrote: > > Eric Valette wrote: > > > > > I can probably take a picture of the backtrace if you want. > > > > Just saw that just above my message in the LKML web interface, someone > > posted a backtrace. Mine is different but at least, we are at least two > > to have the crash. > > This is the same thing I said to Paul Rolland, since I think your > problems are the same: > I had this problem as well. It has to do with mac80211, cfg80211 and > the rate control algorithm not initializing early enough in the boot > process. These two patches should fix it: > > [PATCH] mac80211: fix initialisation when built-in > http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation > > [PATCH] cfg80211: fix initialisation if built-in > http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation > Too bad gmane patches can't be applied directly, they seems to contain very strange inside However, manually patching seems to be Ok. Kernel is now booting correctly, and I have : ... 802.1Q VLAN Support v1.8 Ben Greear <[EMAIL PROTECTED]> All bugs added by David S. Miller <[EMAIL PROTECTED]> ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <[EMAIL PROTECTED]> ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' ieee80211_crypt: registered algorithm 'CCMP' ieee80211_crypt: registered algorithm 'TKIP' ... and after some iwconfig configuration steps, I have : wlan0 Link encap:Ethernet HWaddr 00:15:AF:0F:D7:90 inet addr:192.168.1.34 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::215:afff:fe0f:d790/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15 errors:0 dropped:0 overruns:0 frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4798 (4.6 KiB) TX bytes:4566 (4.4 KiB) These two patches are a "must be" for 2.6.23 !!! Eric, feel confident, it seems really to do the trick, and the changes are subtle and mostly harmless. Regards, Paul - 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 : crash with RTL8187 USB
Hello, Each time I add the support for this piece of hardware, I have a crash during the boot process. Serial console gives the attached boot message... Linux version 2.6.23-rc6 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Sat Sep 15 15:02:47 CEST 2007 Command line: ro root=LABEL=/1 rhgb irqpoll vga=extended console=ttyS0,38400 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - c7f8 (usable) BIOS-e820: c7f8 - c7f8e000 (ACPI data) BIOS-e820: c7f8e000 - c7fe (ACPI NVS) BIOS-e820: c7fe - c800 (reserved) BIOS-e820: ffb0 - 0001 (reserved) end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP 000FAF20, 0014 (r0 ACPIAM) ACPI: RSDT C7F8, 0040 (r1 A_M_I_ OEMRSDT 7000724 MSFT 97) ACPI: FACP C7F80200, 0081 (r1 A_M_I_ OEMFACP 7000724 MSFT 97) ACPI: DSDT C7F80590, 9560 (r1 A0543 A05430000 INTL 20060113) ACPI: FACS C7F8E000, 0040 ACPI: APIC C7F80390, 0080 (r1 A_M_I_ OEMAPIC 7000724 MSFT 97) ACPI: OEMB C7F8E040, 0066 (r1 A_M_I_ AMI_OEM 7000724 MSFT 97) ACPI: HPET C7F89AF0, 0038 (r1 A_M_I_ OEMHPET 7000724 MSFT 97) ACPI: MCFG C7F89B30, 003C (r1 A_M_I_ OEMMCFG 7000724 MSFT 97) ACPI: SSDT C7F8E0B0, 01C6 (r1AMI CPU1PM1 INTL 20060113) ACPI: SSDT C7F8E280, 013A (r1AMI CPU2PM1 INTL 20060113) Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 819072 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Setting APIC routing to flat ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at cc00 (gap: c800:37b0) SMP: Allowing 4 CPUs, 2 hotplug CPUs PERCPU: Allocating 31320 bytes of per cpu data Built 1 zonelists in Zone order. Total pages: 805591 Kernel command line: ro root=LABEL=/1 rhgb irqpoll vga=extended console=ttyS0,38400 Misrouted IRQ fixup and polling support enabled This may significantly impact system performance Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) time.c: Detected 2404.112 MHz processor. Console: colour VGA+ 80x50 console [ttyS0] enabled Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking aperture... Memory: 3212620k/3276288k available (4864k kernel code, 62832k reserved, 2733k data, 276k init) SLUB: Genslabs=22, HWalign=64, Order=0-1, MinObjects=4, CPUs=4, Nodes=1 Calibrating delay using timer specific routine.. 4823.96 BogoMIPS (lpj=9647923) Mount-cache hash table entries: 256 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU0: Thermal monitoring enabled (TM2) SMP alternatives: switching to UP code ACPI: Core revision 20070126 Using local APIC timer interrupts. result 16695222 Detected 16.695 MHz APIC timer. SMP alternatives: switching to SMP code Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 4808.32 BogoMIPS (lpj=9616640) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 CPU1: Thermal monitoring enabled (TM2) Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06 checking TSC synchronization [CPU#0 -> CPU#1]: passed. Brought up 2 CPUs xor: automatically using best checksumming function: generic_sse generic_sse: 8757.000 MB/sec xor: using function: generic_sse (8757.000 MB/sec) NET: Registered protocol family 16 ACPI: bus type pci registered PCI: BIOS Bug: MCFG area at f000 is not E820-reserved PCI: Not using MMCONFIG. PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: (supports S0 S1 S3) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO PCI quirk: region 0480-04bf claimed by ICH6 GPIO PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Link
Re: [2.6.22.5] irq X: nobody cared but X is successfully used by libata
Hello, Just to let you know that this seems to be over in 2.6.23-rc6. Don't know exactly what fixed it, but it is no more present in my bootlog, with or without the irqpoll option. Nice job, Regards, Paul On Sun, 9 Sep 2007 08:59:23 +0200 Paul Rolland <[EMAIL PROTECTED]> wrote: > Hello Tejun, > > On Sat, 08 Sep 2007 16:23:20 +0900 > Tejun Heo <[EMAIL PROTECTED]> wrote: > > > Paul Rolland wrote: > > > Hello, > > > > > > My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is > > > reporting a : > > > irq 23: nobody cared (try booting with the "irqpoll" option) > > > together with a Call Trace, but : > > > - irqpoll is present on the command line, > > > - the irq is reported to be used by libata, > > > - the irqpoll option is mandatory if I want _some_ of my SATA disks to > > > be accessible. > > > > So, if you don't add the 'irqpoll' option, IO to disks don't work at all > > after nobody cared message, right? > > IO to disks don't work for SOME disks, but some others are still Ok (I've > three SATA and two IDE). > > Also, what is weird is the content of dmesg : after the nobody care, it > looks as if IRQ 23 is reuse for another device (SMBus), > but /proc/interrupts still reports it being used by libata. > > I've been trying 2.6.23-rc5, and I'm still having this IRQ 23 nobody cared > message. > > Regards, > Paul > > > -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" So much depends upon a red wheel barrow glazed with rain water beside the white chickens. -- William Carlos Williams, "The Red Wheel Barrow" - 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.5] irq X: nobody cared but X is successfully used by libata
Hello, Just to let you know that this seems to be over in 2.6.23-rc6. Don't know exactly what fixed it, but it is no more present in my bootlog, with or without the irqpoll option. Nice job, Regards, Paul On Sun, 9 Sep 2007 08:59:23 +0200 Paul Rolland [EMAIL PROTECTED] wrote: Hello Tejun, On Sat, 08 Sep 2007 16:23:20 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Paul Rolland wrote: Hello, My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is reporting a : irq 23: nobody cared (try booting with the irqpoll option) together with a Call Trace, but : - irqpoll is present on the command line, - the irq is reported to be used by libata, - the irqpoll option is mandatory if I want _some_ of my SATA disks to be accessible. So, if you don't add the 'irqpoll' option, IO to disks don't work at all after nobody cared message, right? IO to disks don't work for SOME disks, but some others are still Ok (I've three SATA and two IDE). Also, what is weird is the content of dmesg : after the nobody care, it looks as if IRQ 23 is reuse for another device (SMBus), but /proc/interrupts still reports it being used by libata. I've been trying 2.6.23-rc5, and I'm still having this IRQ 23 nobody cared message. Regards, Paul -- Paul RollandE-Mail : rol(at)witbe.net Witbe.net SATel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La DefenseRIPE : PR12-RIPE Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur Some people dream of success... while others wake up and work hard at it So much depends upon a red wheel barrow glazed with rain water beside the white chickens. -- William Carlos Williams, The Red Wheel Barrow - 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 : crash with RTL8187 USB
Hello, Each time I add the support for this piece of hardware, I have a crash during the boot process. Serial console gives the attached boot message... Linux version 2.6.23-rc6 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Sat Sep 15 15:02:47 CEST 2007 Command line: ro root=LABEL=/1 rhgb irqpoll vga=extended console=ttyS0,38400 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - c7f8 (usable) BIOS-e820: c7f8 - c7f8e000 (ACPI data) BIOS-e820: c7f8e000 - c7fe (ACPI NVS) BIOS-e820: c7fe - c800 (reserved) BIOS-e820: ffb0 - 0001 (reserved) end_pfn_map = 1048576 DMI 2.4 present. ACPI: RSDP 000FAF20, 0014 (r0 ACPIAM) ACPI: RSDT C7F8, 0040 (r1 A_M_I_ OEMRSDT 7000724 MSFT 97) ACPI: FACP C7F80200, 0081 (r1 A_M_I_ OEMFACP 7000724 MSFT 97) ACPI: DSDT C7F80590, 9560 (r1 A0543 A05430000 INTL 20060113) ACPI: FACS C7F8E000, 0040 ACPI: APIC C7F80390, 0080 (r1 A_M_I_ OEMAPIC 7000724 MSFT 97) ACPI: OEMB C7F8E040, 0066 (r1 A_M_I_ AMI_OEM 7000724 MSFT 97) ACPI: HPET C7F89AF0, 0038 (r1 A_M_I_ OEMHPET 7000724 MSFT 97) ACPI: MCFG C7F89B30, 003C (r1 A_M_I_ OEMMCFG 7000724 MSFT 97) ACPI: SSDT C7F8E0B0, 01C6 (r1AMI CPU1PM1 INTL 20060113) ACPI: SSDT C7F8E280, 013A (r1AMI CPU2PM1 INTL 20060113) Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 819072 ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Setting APIC routing to flat ACPI: HPET id: 0x8086a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at cc00 (gap: c800:37b0) SMP: Allowing 4 CPUs, 2 hotplug CPUs PERCPU: Allocating 31320 bytes of per cpu data Built 1 zonelists in Zone order. Total pages: 805591 Kernel command line: ro root=LABEL=/1 rhgb irqpoll vga=extended console=ttyS0,38400 Misrouted IRQ fixup and polling support enabled This may significantly impact system performance Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) time.c: Detected 2404.112 MHz processor. Console: colour VGA+ 80x50 console [ttyS0] enabled Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking aperture... Memory: 3212620k/3276288k available (4864k kernel code, 62832k reserved, 2733k data, 276k init) SLUB: Genslabs=22, HWalign=64, Order=0-1, MinObjects=4, CPUs=4, Nodes=1 Calibrating delay using timer specific routine.. 4823.96 BogoMIPS (lpj=9647923) Mount-cache hash table entries: 256 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU0: Thermal monitoring enabled (TM2) SMP alternatives: switching to UP code ACPI: Core revision 20070126 Using local APIC timer interrupts. result 16695222 Detected 16.695 MHz APIC timer. SMP alternatives: switching to SMP code Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 4808.32 BogoMIPS (lpj=9616640) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 CPU1: Thermal monitoring enabled (TM2) Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06 checking TSC synchronization [CPU#0 - CPU#1]: passed. Brought up 2 CPUs xor: automatically using best checksumming function: generic_sse generic_sse: 8757.000 MB/sec xor: using function: generic_sse (8757.000 MB/sec) NET: Registered protocol family 16 ACPI: bus type pci registered PCI: BIOS Bug: MCFG area at f000 is not E820-reserved PCI: Not using MMCONFIG. PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: (supports S0 S1 S3) ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO PCI quirk: region 0480-04bf claimed by ICH6 GPIO PCI: Transparent bridge - :00:1e.0 ACPI: PCI Interrupt Link [LNKA]
Re: rtl8187 driver in 2.6.23-rc6-git5: kernel panic if not used as a module. Works as a module.
Hi Rob, On Sat, 15 Sep 2007 12:28:36 -0400 Rob Hussey [EMAIL PROTECTED] wrote: On 9/15/07, Eric Valette [EMAIL PROTECTED] wrote: Eric Valette wrote: I can probably take a picture of the backtrace if you want. Just saw that just above my message in the LKML web interface, someone posted a backtrace. Mine is different but at least, we are at least two to have the crash. This is the same thing I said to Paul Rolland, since I think your problems are the same: I had this problem as well. It has to do with mac80211, cfg80211 and the rate control algorithm not initializing early enough in the boot process. These two patches should fix it: [PATCH] mac80211: fix initialisation when built-in http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation [PATCH] cfg80211: fix initialisation if built-in http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation Too bad gmane patches can't be applied directly, they seems to contain very strange at inside However, manually patching seems to be Ok. Kernel is now booting correctly, and I have : ... 802.1Q VLAN Support v1.8 Ben Greear [EMAIL PROTECTED] All bugs added by David S. Miller [EMAIL PROTECTED] ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED] ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' ieee80211_crypt: registered algorithm 'CCMP' ieee80211_crypt: registered algorithm 'TKIP' ... and after some iwconfig configuration steps, I have : wlan0 Link encap:Ethernet HWaddr 00:15:AF:0F:D7:90 inet addr:192.168.1.34 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::215:afff:fe0f:d790/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:15 errors:0 dropped:0 overruns:0 frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4798 (4.6 KiB) TX bytes:4566 (4.4 KiB) These two patches are a must be for 2.6.23 !!! Eric, feel confident, it seems really to do the trick, and the changes are subtle and mostly harmless. Regards, Paul - 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: rtl8187 driver in 2.6.23-rc6-git5: kernel panic if not used as a module. Works as a module.
Hi Eric, On Sat, 15 Sep 2007 20:30:14 +0200 Eric Valette [EMAIL PROTECTED] wrote: Rob Hussey wrote: On 9/15/07, Eric Valette [EMAIL PROTECTED] wrote: Eric Valette wrote: Thanks for your help: it does indeed fix the problem. Nice it works for you too ! Now I have two side questions: - the code is no more symetric subsys_initcall - module_exit. Do not know if it is normal but I love symmetry in code :-). Did not test it still works as a module... Symmetry is not broken, as we have : #define subsys_initcall(fn) module_init(fn) in include/linux/init.h where compiling as a module, and when not compiling as a module, I doubt the exit function is called unless you are shuting down your machine... - Who takes the responsability to push a patch to Linus? I guess it is urgent unless he plans a rc7 Good point ! I expect the patches to be already in some queue waiting to be pulled ! - 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/
