Created attachment 20841 [details] Kernel logs right after loading b44 driver: modprobe b44 b44_debug=31 After a fresh reboot everything works just fine. The problems appear after resuming from suspend to ram at least once. Both network interfaces (ethernet and wireless) keep dropping continuously. Dropping frequency seems to depend on traffic. BTW suspend to ram seems to work perfectly fine. This problem happens in a Dell Inspiron 600m laptop. The ethernet card uses driver b44 and the wireless ipw2200. The problem occurs with kernels 2.6.29 and 2.6.29.1, but not with 2.6.28 or less. I'll attach some kernel logs showing what happens from the moment I load the network drivers. The interface drops happen within seconds after the connection is established. One more thing, while using the wireless card the connection drops happen much more frequently when using encrypted networks (both WEP and WPA).
Created attachment 20842 [details] Kernel logs after loading ipw2200 driver: modprobe ipw2200
Created attachment 20843 [details] Kernel logs after loading ipw2200 driver: modprobe ipw2200 debug=0x43fff
Not sure what would account for drops on both wired and wireless interfaces.
I have some new info on this issue. I noticed that the problems don't appear if I have a USB optical mouse plugged in. I played around with plugging and unplugging the mouse and this is what I get: After fresh reboot: - USB mouse plugged in: no drops - USB mouse unplugged: no drops After a suspend/resume: - USB mouse plugged in: no drops - USB mouse unplugged: lots of drops I can also confirm that this happens with 2.6.29.1 and not with 2.6.28.9 (both vanilla kernels). Just in case the kind of mouse matters, this is what shows in the kernel logs when I plug it: Apr 8 13:17:48 flux generic-usb 0003:0461:4D03.0003: input: USB HID v1.00 Mouse [ARROW STRONG USB 3D Mouse] on usb-0000:00:1d.0-1/input0
Could there be something going on with the system power saving? As the ipw2200 errors do not help much here (all we have is fw sysassert) can you perhaps dig into the b44 errors? Perhaps adding a "dump_stack" into b44_halt() will give us an idea of why the system is bringing device down at that time.
Created attachment 20912 [details] Messages after adding "dump_stack" to b44_halt() I inserted a call to dump_stack at the bottom of b44_halt: diff --git a/drivers/net/b44.c b/drivers/net/b44.c index dc5f051..1e066c0 100644 --- a/drivers/net/b44.c +++ b/drivers/net/b44.c @@ -1337,6 +1337,7 @@ static void b44_halt(struct b44 *bp) /* now reset the chip, but without enabling the MAC&PHY * part of it. This has to be done _after_ we shut down the PHY */ b44_chip_reset(bp, B44_CHIP_RESET_PARTIAL); + dump_stack(); } /* bp->lock is held. */ Find attached the kernel messages showing 3 consecutive network drops. The messages show from the time I unplug the USB mouse to the time I plug it back in (and the drops stop).
That stack dump shows that the reset is triggered after the device reports an error to the driver via an interrupt. In the ipw2200 case there is also a hardware error, but the hardware resets itself (no need for driver intervention). So, something is going on in the lower levels of your platform. Unfortunately I do not know how to debug this further.
Jose, can you test commit 0db29af1e767464d71b89410d61a1e5b668d0370, please?
Commit 0db29af1e767464d71b89410d61a1e5b668d0370 refers to MSI stuff: "PCI/MSI: bugfix/utilize for msi_capability_init()". I don't seem to have MSI enabled in my config: CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set I went ahead anyway and undid the commit which made no difference. Make told me my build was up to date.
Sorry, I didn't mean to revert the commit, but to try the kernel where this commit is a head.
The kernel at that commit does not have the problem. I've been testing with both wired and wireless for quite a while and everything works fine. Not a single drop.
OK, now please test the kernel where the head is commit 8efb8c76fcdccf5050c0ea059dac392789baaff2 .
Sorry, comment #12 is wrong, please discard it.
Please test the kernel where the head is commit aa8c6c93747f7b55fa11e1624fec8ca33763a805 .
After trying the first commit you suggested I got curious and started a bisect. Here's the bisect log at this point: git bisect start # good: [0db29af1e767464d71b89410d61a1e5b668d0370] PCI/MSI: bugfix/utilize for msi_capability_init() git bisect good 0db29af1e767464d71b89410d61a1e5b668d0370 # bad: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29 git bisect bad 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 # bad: [1db8508cf483dc1ecf66141f90a7c03659d69512] hugetlbfs: fix build failure with !CONFIG_HUGETLBFS git bisect bad 1db8508cf483dc1ecf66141f90a7c03659d69512 # good: [8b1e3a2f7f84484a8c208671adac39eb148c7d61] headers_check fix: linux/video_decoder.h git bisect good 8b1e3a2f7f84484a8c208671adac39eb148c7d61 So right now I'm between: 8b1e3a2f7f84484a8c208671adac39eb148c7d61 (good) and 1db8508cf483dc1ecf66141f90a7c03659d69512 (bad) I believe the commit you suggest in comment #14 is before my current good bisect point. Do you want me to test it anyway?
No, thanks, please continue the bisection.
After 12 rebuilds and reboots I finally finished the bisection. Here's the result: 31878dd86b7df9a147f5e6cc6e07092b4308782b is first bad commit commit 31878dd86b7df9a147f5e6cc6e07092b4308782b Author: Len Brown <len.brown@intel.com> Date: Wed Jan 28 18:28:09 2009 -0500 ACPI: remove BM_RLD access from idle entry path It is true that BM_RLD needs to be set to enable bus master activity to wake an older chipset (eg PIIX4) from C3. This is contrary to the erroneous wording the ACPI 2.0, 3.0 specifications that suggests that BM_RLD is an indicator rather than a control bit. ACPI 1.0's correct wording should be restored in ACPI 4.0: http://www.acpica.org/bugzilla/show_bug.cgi?id=689 But the kernel should not have to clear BM_RLD when entering a non C3-type state just to set it again when entering a C3-type C-state. We should be able to set BM_RLD at boot time and leave it alone -- removing the overhead of accessing this IO register from the idle entry path. Signed-off-by: Len Brown <len.brown@intel.com> :040000 040000 999629a2940ce92d1b2022fe510eecd2f57599ee 892206507142af444079b2329eeecf1d86f54d19 M drivers
Thanks for bisecting it! First-Bad-Commit : 31878dd86b7df9a147f5e6cc6e07092b4308782b
To trigger this bug all I had to do is create some network traffic. By downloading something or by ssh to a remote machine and running "find .". While bisecting the bug I noticed that I could not trigger the bug while the kernel was compiling (cpu at 100%) or when I ssh to a machine in the local network. With powertop I checked the Cn state of the cpu: **** network drops **** -- USB mouse unplugged, traffic with distant machine Cn Avg residency P-states (frequencies) C0 (cpu running) (10.2%) 2.00 Ghz 9.0% polling 0.0ms ( 0.0%) 1.80 Ghz 1.1% C1 halt 0.0ms ( 0.0%) 1.60 Ghz 0.1% C2 4.2ms (15.6%) 800 Mhz 1.0% C3 0.3ms ( 0.1%) 600 Mhz 88.7% C4 3.8ms (74.1%) **** NO network drops **** -- USB mouse unplugged, traffic with machine in local network Cn Avg residency P-states (frequencies) C0 (cpu running) (99.9%) 2.00 Ghz 42.4% polling 0.0ms ( 0.0%) 1.80 Ghz 0.0% C1 halt 0.0ms ( 0.0%) 1.60 Ghz 0.0% C2 0.9ms ( 0.1%) 800 Mhz 2.5% C3 0.0ms ( 0.0%) 600 Mhz 55.0% C4 0.0ms ( 0.0%) -- Mouse plugged in Cn Avg residency P-states (frequencies) C0 (cpu running) ( 2.8%) 2.00 Ghz 6.2% polling 0.0ms ( 0.0%) 1.80 Ghz 0.0% C1 halt 0.0ms ( 0.0%) 1.60 Ghz 0.0% C2 5.1ms (97.2%) 1400 Mhz 0.0% C3 0.0ms ( 0.0%) 600 Mhz 93.8% C4 0.0ms ( 0.0%) It seems that the network drops only happen whenever the cpu is allowed to go lower than C2. Somehow plugging in the USB mouse is preventing this.
Notify-Also : ACPI Bugzilla <acpi-bugzilla@lists.sourceforge.net>
please attach the output from lspci -vv
Created attachment 21164 [details] Output from lspci -vv
Created attachment 21271 [details] patch vs 2.6.30-rc4 to restore BM_RLD on resume please apply this patch, suspend, resume, and show the output of "dmesg | grep BM_RLD" and report if the patch fixes the regression.
Created attachment 21272 [details] patch vs 2.6.30-rc4 to restore BM_RLD on resume fixed printk typo in previous version, please test this one instead.
This patch fixes the regression here. Yay. The output of "dmesg | grep BM_RLD" after one suspend/resume: ACPI: saved: BM_RLD 1 ACPI: resumed: BM_RLD 0 ACPI: restored BM_RLD 1 Thanks :)
*** Bug 13277 has been marked as a duplicate of this bug. ***
Fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=815ab0fd40579ad2aa42058298073503648762b9