Bug 4566

Summary: (net B44) Randomly driver starts sending garbage and stops receiving
Product: Drivers Reporter: Bruno Prémont (bonbons)
Component: NetworkAssignee: Jeff Garzik (jgarzik)
Status: REJECTED UNREPRODUCIBLE    
Severity: high CC: masterdriverz, protasnb
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.11 Subsystem:
Regression: --- Bisected commit-id:

Description Bruno Prémont 2005-04-30 14:04:11 UTC
Distribution: Gentoo 
Hardware Environment: Acer TM66x 
    0000:02:02.0 Class 0200: 14e4:4401 (rev 01)  
        Subsystem: 1025:0035  
        Flags: bus master, fast devsel, latency 64, IRQ 10  
        Memory at e0204000 (32-bit, non-prefetchable)  
        Capabilities: [40] Power Management version 2  
    Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)  
        Subsystem: Acer Incorporated [ALI]: Unknown device 0035  
        Flags: bus master, fast devsel, latency 64, IRQ 10  
        Memory at e0204000 (32-bit, non-prefetchable)  
        Capabilities: [40] Power Management version 2  
Software Environment: GCC 3.3.5-20050130  
Problem Description:  
After some time of normal network communication, suddenly incoming traffic   
stops to be received and only outgoing traffic remains.  
Looking at the traffic sent from another machine in the network with tcpdump I   
get following output (repeating at a high rate): 
22:33:01.018523 00:40:05:43:5e:fe > 01:80:c2:00:00:01, ethertype Unknown 
(0x8808), length 60: 
    0x0000: 0001 ffff 0000 0000 0000 0000 0000 0000 
    0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 
    0x0020: 0000 0000 0000 0000 0000 0000 0000 
dmesg does not produce any useful output about this. 
 
ifconfig eth0 down 
ifconfig eth0 up 
Restores the communications and stops the garbage traffic. 
 
 
Steps to reproduce: 
Happens randomly, some days very often some days not at all 
 
 
I have not yet tried to disable ACPI (as suggesed in bug #3050)
Comment 1 Pekka Pietikainen 2005-06-04 11:29:42 UTC
Could you try disabling ACPI? It certainly seems to make the driver unhappy for
some people.
Comment 2 Bruno Prémont 2005-06-05 13:38:18 UTC
Today I disabled ACPI (acpi=off boot parameter) and the B44 driver stopped 
receiving a few minutes ago after about 12 hours uptime. No kernel message 
during over 1 hour before the driver "stopped". 
 
Next thing I will try is forcing the kernel to enable the local apic which is 
by default disabled by the BIOS. 
 
Probably unrelated, but who knows: 
I currently get one spurious 8259A interrupt: IRQ7 per session. How may I find 
out where it comes from? 
Here the kernel's interrupt table: 
           CPU0 
  0:   32749592          XT-PIC  timer 
  1:      50740          XT-PIC  i8042 
  2:          0          XT-PIC  cascade 
  8:          2          XT-PIC  rtc 
 10:    1394293          XT-PIC  ehci_hcd, uhci_hcd, Intel 82801DB-ICH4 
 11:    1764954          XT-PIC  uhci_hcd, uhci_hcd, i915@pci:0000:00:02.0, 
eth0 
 12:       3404          XT-PIC  i8042 
 14:     442096          XT-PIC  ide0 
 15:       7787          XT-PIC  ide1 
NMI:          0 
LOC:          0 
ERR:          1 
MIS:          0 
Comment 3 Bruno Prémont 2005-06-23 03:52:41 UTC
Lately the communication broke down completely, or was extremly slow, and 
activity LED was flashing very much (hi activity). 
 
This happened as well under Windows or under BIOS control. Any 100MBit speed 
triggered this behavior. 10MBit was fine though. 
 
Looks like the card does not Like the port of my DLink DES1005D switch it is 
connected to. For a few days now it's running all right connected to another 
Port of the Switch, and was working fine on another switch as well. 
Some Realtec cards work just fine on the give port of the switch though. 
Comment 4 Natalie Protasevich 2007-11-18 00:02:58 UTC
Any status on this, has the problem been resolved or still there with newer kernels?
Thanks.
Comment 5 Bruno Prémont 2008-01-01 03:56:56 UTC
I connected my laptop to the switch in question (2.6.24-rc kernel) but couldn't reproduct the issue (could not reproduce under Windows either)

I didn't try all ports on the D-Link switch so might be the "bad" one is one of those I did not try again, unless it's a symptom that builds up over time

As I don't connect the laptop to that switch very often (connecting to Cisco Router switchports right now) it's hard to test with randomness in apearance.

Note that I got no issue fir a different D-Link switch and the Cisco router I'm connecting to now.