Bug 7696
| Summary: | (net b44) driver doesn't work under heavy load | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Charlie Shepherd (masterdriverz) |
| Component: | Network | Assignee: | drivers_network (drivers_network) |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | alan, andreas, anothersillyname, bojan, bug_kernel, holler, kernel, protasnb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.34-rc3 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | bug fix | ||
Created attachment 9844 [details]
bug fix
The attached patch should fix the problem. The b44 chip occasionally needs to
be reset when errors are encountered. The patch will allow the reset to be
done without a PHY reset which will cause link down and several seconds of
interruption. The patch has only been compile-tested.
Sorry for the long delay in replying to this. I've tested with a couple of kernels, and although all of them _seem_ a bit better (this could just be the placebo effect), I still experience the symptons. Latest kernel tested with was 2.6.20_rc2 > I still experience the symptons. That's strange. RH also reported the same bug and the same patch worked for them. Please see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216338 I'm experiencing the same problem with all 2.6 kernels (2.6.0 up to 2.6.20-rc7) on an ACER TM800 laptop. (Tried it with scp remote:knoppix_cd ./) After trying a kernel 2.4 without any problems I've give acpi=off a try and I could transfer the whole 700mb without _any_ reset! So this seems definitely to be a problem with ACPI. Also the resets are much faster with the new patch, this seems not to be the problem (I've never experienced those problems with win xp). I don't know whats the problem with ACPI, but checking /proc/interrupts, the only difference seems to be that irq 9 is used by acpi. iomem is the same and with ACPI I see some more ioports (for the motherboard). I think I don't have to remark that using a laptop without ACPI isn't a solution. ;) Any pointers how this could be solved without disabling ACPI? Here are the two diffs:
laptopahvpn ~ # diff -Naur irqs_acpi_off.txt irqs_acpi_on.txt
--- irqs_acpi_off.txt 2007-02-03 20:46:17.000000000 +0100
+++ irqs_acpi_on.txt 2007-02-03 20:58:37.000000000 +0100
@@ -1,12 +1,13 @@
CPU0
- 0: 94403 XT-PIC-XT timer
- 1: 437 XT-PIC-XT i8042
+ 0: 151641 XT-PIC-XT timer
+ 1: 115 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
- 5: 775845 XT-PIC-XT uhci_hcd:usb2, eth0
+ 5: 0 XT-PIC-XT uhci_hcd:usb2, eth0
8: 2 XT-PIC-XT rtc
- 10: 754 XT-PIC-XT uhci_hcd:usb1, uhci_hcd:usb3,
ehci_hcd:usb4, Intel 82801DB-ICH4, yenta, yenta, fglrx
+ 9: 4572 XT-PIC-XT acpi
+ 10: 32743 XT-PIC-XT uhci_hcd:usb1, uhci_hcd:usb3,
ehci_hcd:usb4, Intel 82801DB-ICH4, yenta, yenta, fglrx
12: 124 XT-PIC-XT i8042
- 14: 23890 XT-PIC-XT ide0
+ 14: 7267 XT-PIC-XT ide0
NMI: 0
LOC: 0
ERR: 0
laptopahvpn ~ # diff -Naur ioports_acpi_off.txt ioports_acpi_on.txt
--- ioports_acpi_off.txt 2007-02-03 20:47:04.000000000 +0100
+++ ioports_acpi_on.txt 2007-02-03 20:58:46.000000000 +0100
@@ -13,7 +13,15 @@
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
+ 1000-107f : motherboard
+ 1000-1003 : ACPI PM1a_EVT_BLK
+ 1004-1005 : ACPI PM1a_CNT_BLK
+ 1008-100b : ACPI PM_TMR
+ 1010-1015 : ACPI CPU throttle
+ 1020-1020 : ACPI PM2_CNT_BLK
+ 1028-102f : ACPI GPE0_BLK
1180-11bf : 0000:00:1f.0
+ 1180-11bf : motherboard
1800-181f : 0000:00:1d.0
1800-181f : uhci_hcd
1820-183f : 0000:00:1d.1
@@ -38,3 +46,4 @@
4400-44ff : PCI CardBus #03
4800-48ff : PCI CardBus #07
4c00-4cff : PCI CardBus #07
+fe00-fe00 : motherboard
Any update on this problem? Thanks. This bug is still valid with 2.6.23.8. (Wouldn't it be reasonable if not only the original reporter could change the kernel-version in the bug-headers?) Bug #11056 seems to be a duplicate. People are also having problems with this at least on 2.6.27 and 2.6.28-rc5 see also: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/279102 This on a Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) above redhat bug was on a (rev 01) I can see this under heavy load, as well as under no load at all, as described here: http://bugzilla.kernel.org/show_bug.cgi?id=11056#c8 Is anyone looking at this? I am having same issue with 2.6.33 and 2.6.34_rc3. I tried to turn acpi off but without any effect. It is especially visible when using cifs. It then restarts once a second or so. 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) *** Bug 14451 has been marked as a duplicate of this bug. *** *** Bug 11056 has been marked as a duplicate of this bug. *** Closing as obsolete, if this is still seen with modern kernels please re-open and update |
First reported as a Gentoo bug[1] I also experience this problem. Under heavy load (ie, downloading tarballs etc as opposed to browsing or irc) dmesg fills up with these messages: b44: eth0: Link is down. b44: eth0: Link is up at 100 Mbps, full duplex. b44: eth0: Flow control is off for TX and off for RX. Also, ssh sessions cut out with 'Connection reset by peer' error, and downloads often fail at this point. lspci -v output:01:09.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01) Subsystem: Dell Unknown device 8127 Flags: bus master, fast devsel, latency 64, IRQ 18 Memory at fe9fe000 (32-bit, non-prefetchable) [size=8K] Expansion ROM at 20080000 [disabled] [size=16K] Capabilities: [40] Power Management version 2 I currently have the b44 driver compiled into my kernel. The earliest kernel I've reproduce this with is 2.6.15, though I can go back further if necessary. This is still reproducible with 2.6.20_rc1. [1] http://bugs.gentoo.org/show_bug.cgi?id=147722