Bug 841119

Summary: RX and TX packets, when cable unpugged
Product: [Fedora] Fedora Reporter: kotofos <ibelkov>
Component: kernelAssignee: Neil Horman <nhorman>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: b.m.kast, dennis, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, nhorman
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-28 14:37:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/var/log//messages none

Description kotofos 2012-07-18 08:21:51 UTC
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

Comment 1 kotofos 2012-07-18 08:23:30 UTC
When plug cable in nothing happens. To use wired connection i need to reboot.

Comment 2 Bill Nottingham 2012-07-18 14:07:20 UTC
Looks like a broken driver. Can you post the full /var/log/messages?

Comment 3 Josh Boyer 2012-07-18 14:29:57 UTC
This is likely a duplicate of 809706

Comment 4 kotofos 2012-07-18 19:07:53 UTC
Created attachment 598984 [details]
/var/log//messages

Comment 5 kotofos 2012-07-18 20:43:57 UTC
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 15:52:20 UTC
3.5.3-1.fc17.i686.PAE still happens

Comment 7 b.m.kast 2013-01-20 23:07:00 UTC
related to #809706?

Comment 8 Neil Horman 2013-04-19 16:47:06 UTC
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 14:37:30 UTC
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.