Red Hat Bugzilla – Bug 841119
RX and TX packets, when cable unpugged
Last modified: 2013-05-28 10:37:30 EDT
Description of problem: when ethernet cable unpugged, i have RX and TX packets Version-Release number of selected component (if applicable): Fedora 16, Fedora 17 How reproducible: 100% Steps to Reproduce: 1. Unplug cable 2. Leave PC Actual results: p5p1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 00:26:9e:da:78:6d txqueuelen 1000 (Ethernet) RX packets 4294967156 bytes 4294967156 (3.9 GiB) RX errors 4294966456 dropped 4294967016 overruns 4294967156 frame 4294967295 TX packets 4294967156 bytes 4294967156 (3.9 GiB) TX errors 4294966736 dropped 0 overruns 4294967156 carrier 4294967295 collisions 4294966596 and still grow Expected results: no packets Additional info: lspci -vvv 09:00.0 Ethernet controller: Atheros Communications AR8131 Gigabit Ethernet (rev c0) Subsystem: Acer Incorporated [ALI] Device 0253 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+ Interrupt: pin A routed to IRQ 46 Region 0: Memory at 80900000 (64-bit, non-prefetchable) [disabled] [size=256K] Region 2: I/O ports at 5000 [disabled] [size=128] Capabilities: <access denied> Kernel driver in use: atl1c uname -a Linux kotofos-laptop 3.4.4-5.fc17.i686.PAE #1 SMP Thu Jul 5 20:09:45 UTC 2012 i686 i686 i386 GNU/Linux lsmod | grep atl1c atl1c 36753 0 3.9 GiB per night in fedora 17 some TiB per night in fedora 16 this bug not appears in windows xp, ubuntu 10.04-11.04
When plug cable in nothing happens. To use wired connection i need to reboot.
Looks like a broken driver. Can you post the full /var/log/messages?
This is likely a duplicate of 809706
Created attachment 598984 [details] /var/log//messages
In ifconfig output traffic stop grow at 3.9 GiB and begin slowly decrease. vnstat -i p5p1 -l 1 -ru Monitoring p5p1... (press CTRL-C to stop) rx: 2.05 GiB/s 24.00 GiB tx: 2.05 GiB/s 24.00 GiB
3.5.3-1.fc17.i686.PAE still happens
related to #809706?
This rather looks like it might be a hardware bug. I base that on this line taken from /var/log/messages: Jul 16 22:45:20 kotofos-laptop kernel: [129674.069041] atl1c 0000:09:00.0: MAC state machine can't be idle since disabled for 10ms second That occurs when the driver attempts to reset that MAC (which happens, among other times, when the interface goes down, like it would in response to a cable unplug), but the hardware fails to respond to the request. It looks like it was introduced with commit 5e5c0964d9b93debb040431b5036d28fe8b19136, but I don't think thats the root cause of the issue. The code lives in atl1c_reset_mac, and it looks quite hacked together (a msleep of 10 ms followed by a polling loop with an msleep of 1ms between each check)?! Out of curiosity, the mac gets reset both on ifdown and ifup, if you ifdown/ifup the interface, do the stats start incrementing normally again? Or do they continue to misbehave? And if you remove and reinsmod the module, do the counters get reset to zero properly and increment in a sane way? If so, I wonder if reset operation just needs to be able to wait longer (which I know is a lousy solution, but in the absence of documentation, it may be all we can do).
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.