Bug 841119 - RX and TX packets, when cable unpugged
RX and TX packets, when cable unpugged
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-07-18 04:21 EDT by kotofos
Modified: 2013-05-28 10:37 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-28 10:37:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log//messages (4.46 MB, text/plain)
2012-07-18 15:07 EDT, kotofos
no flags Details

  None (edit)
Description kotofos 2012-07-18 04:21:51 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:
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
Comment 1 kotofos 2012-07-18 04:23:30 EDT
When plug cable in nothing happens. To use wired connection i need to reboot.
Comment 2 Bill Nottingham 2012-07-18 10:07:20 EDT
Looks like a broken driver. Can you post the full /var/log/messages?
Comment 3 Josh Boyer 2012-07-18 10:29:57 EDT
This is likely a duplicate of 809706
Comment 4 kotofos 2012-07-18 15:07:53 EDT
Created attachment 598984 [details]
Comment 5 kotofos 2012-07-18 16:43:57 EDT
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
Comment 6 kotofos 2012-09-18 11:52:20 EDT
3.5.3-1.fc17.i686.PAE still happens
Comment 7 b.m.kast 2013-01-20 18:07:00 EST
related to #809706?
Comment 8 Neil Horman 2013-04-19 12:47:06 EDT
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).
Comment 9 Josh Boyer 2013-05-28 10:37:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.