Bug 743270 - e100 ethernet card does not work
Summary: e100 ethernet card does not work
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-04 12:58 UTC by Alexey Kurnosov
Modified: 2012-07-23 20:57 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-11 17:52:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg (78.97 KB, application/octet-stream)
2011-11-30 14:27 UTC, Alexey Kurnosov
no flags Details

Description Alexey Kurnosov 2011-10-04 12:58:55 UTC
Description of problem:

After upgrade f14->f15 the one of ethernet cards does not work:
# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	Supports auto-negotiation: Yes
	Advertised link modes:  100baseT/Full 
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: g
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: no

The link is present of course.
Other cards(both e1000) work just fine.
Then boot to old 2.6.35.14-96.fc14.x86_64 kernel the card is working perfectly.


Version-Release number of selected component (if applicable):

# uname -rvs
Linux 2.6.40.4-5.fc15.x86_64 #1 SMP Thu Sep 1 11:59:56 UTC 2011

# lspci -v -s 03:01.0
03:01.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 08)
	Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter with Alert On LAN*
	Flags: bus master, medium devsel, latency 32, IRQ 31
	Memory at e3200000 (32-bit, non-prefetchable) [size=4K]
	I/O ports at 2000 [size=64]
	Memory at e3100000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at e3400000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 2
	Kernel driver in use: e100
	Kernel modules: e100

#dmesg | grep 'e100\>'
[    0.351925] pci 0000:03:01.0: Firmware left e100 interrupts enabled; disabling
[    6.412954] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[    6.413202] e100: Copyright(c) 1999-2006 Intel Corporation
[    6.413483] e100 0000:03:01.0: PCI INT A -> GSI 31 (level, low) -> IRQ 31
[    6.516732] e100 0000:03:01.0: PME# disabled
[    6.517070] e100 0000:03:01.0: eth0: addr 0xe3200000, irq 31, MAC addr 00:d0:b7:ca:86:36

How reproducible:
Boot the kernel.


Additional info:
dmesg for other cards:
#dmesg | grep 'e1000'
[    6.398213] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
[    6.398501] e1000: Copyright (c) 1999-2006 Intel Corporation.
[    6.398859] e1000 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[    6.537848] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
[    6.538115] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[    6.538423] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[    6.538689] e1000e 0000:00:19.0: setting latency timer to 64
[    6.538830] e1000e 0000:00:19.0: irq 75 for MSI/MSI-X
[    6.605150] e1000 0000:05:02.0: eth1: (PCI:33MHz:32-bit) 00:15:17:b2:97:1c
[    6.605394] e1000 0000:05:02.0: eth1: Intel(R) PRO/1000 Network Connection
[    6.837034] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width x1) 00:15:17:b2:97:1e
[    6.837459] e1000e 0000:00:19.0: eth2: Intel(R) PRO/1000 Network Connection
[    6.837711] e1000e 0000:00:19.0: eth2: MAC: 7, PHY: 6, PBA No: 0070FF-0FF
[   15.662184] e1000e 0000:00:19.0: irq 75 for MSI/MSI-X
[   15.713051] e1000e 0000:00:19.0: irq 75 for MSI/MSI-X
[   15.794410] e1000: eth2 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

dmesg for 2.6.35.14-96.fc14.x86_64:
[    0.358525] pci 0000:03:01.0: Firmware left e100 interrupts enabled; disabling
[    9.033980] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[    9.034227] e100: Copyright(c) 1999-2006 Intel Corporation
[    9.034549] e100 0000:03:01.0: PCI INT A -> GSI 31 (level, low) -> IRQ 31
[    9.134475] e100 0000:03:01.0: PME# disabled
[    9.134741] e100 0000:03:01.0: eth2: addr 0xe3200000, irq 31, MAC addr 00:d0:b7:ca:86:36
[   17.891396] e100 0000:03:01.0: eth0: NIC Link is Up 100 Mbps Full Duplex

#cat  /etc/udev/rules.d/70-persistent-net.rules

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# Intel Corporation 82541GI Gigabit Ethernet Controller (rule written by anaconda)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:b2:97:1c", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
# Intel Corporation 82566DM-2 Gigabit Network Connection (rule written by anaconda)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:17:b2:97:1e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:d0:b7:ca:86:36", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x0b05:0x1723 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:23:54:07:18:61", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

Comment 1 Josh Boyer 2011-10-05 17:24:37 UTC
Do you have active links to all 3 ethernet cards?  It seems like the .35 kernel is doing some kind of rename from eth2 -> eth0.  Perhaps that isn't getting applied on F15 since it shows eth2 actually coming up with the link.

Comment 2 Alexey Kurnosov 2011-10-06 11:46:10 UTC
During the booting the link on eth1(00:15:17:b2:97:1e) was inactive. But it  works perfectly when the link is up. 

>It seems like the .35 kernel is doing some kind of rename from eth2 -> eth0.

That is correct. When boot 2.6.35 eth0 (e100, 00:d0:b7:ca:86:36) up as eth2 and had been renamed by udev:
dmesg | grep eth[02] 
[    9.094577] e1000 0000:05:02.0: eth0: (PCI:33MHz:32-bit) 00:15:17:b2:97:1c
[    9.094815] e1000 0000:05:02.0: eth0: Intel(R) PRO/1000 Network Connection
[    9.218161] e100 0000:03:01.0: eth2: addr 0xe3200000, irq 31, MAC addr 00:d0:b7:ca:86:36
[    9.315243] <30>udev[718]: renamed network interface eth0 to eth0-eth2
[    9.336355] <30>udev[714]: renamed network interface eth2 to eth0
[    9.366217] <30>udev[718]: renamed network interface eth0-eth2 to eth2
[   17.932789] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   17.933394] e100 0000:03:01.0: eth0: NIC Link is Up 100 Mbps Full Duplex
[   17.943513] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   20.661524] ADDRCONF(NETDEV_UP): eth2: link is not ready
[   20.662661] e1000: eth2 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[   20.663418] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[   28.338006] eth0: no IPv6 routers present
[   31.138254] eth2: no IPv6 routers present

When booting 2.6.40 eth0 up as eth0 and had not been renamed:
#  grep eth[02] dmesg.2.6.40
[    6.517070] e100 0000:03:01.0: eth0: addr 0xe3200000, irq 31, MAC addr 00:d0:b7:ca:86:36
[    6.837034] e1000e 0000:00:19.0: eth2: (PCI Express:2.5GT/s:Width x1) 00:15:17:b2:97:1e
[    6.837459] e1000e 0000:00:19.0: eth2: Intel(R) PRO/1000 Network Connection
[    6.837711] e1000e 0000:00:19.0: eth2: MAC: 7, PHY: 6, PBA No: 0070FF-0FF
[    6.921115] udev[735]: renamed network interface eth1 to eth1-eth2
[    6.956122] udev[666]: renamed network interface eth2 to eth1
[    6.980154] udev[735]: renamed network interface eth1-eth2 to eth2
[   15.794410] e1000: eth2 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[   15.795265] ADDRCONF(NETDEV_UP): eth2: link is not ready
[   15.795997] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[   25.954006] eth2: no IPv6 routers present

So there is no mistake. Exactly eth0 does not work. 

If I do:
# rmmod eth0
# modprobe e100 debug=16
dmesg got:
[  433.818192] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
[  433.818479] e100: Copyright(c) 1999-2006 Intel Corporation
[  433.818841] e100 0000:03:01.0: PCI INT A -> GSI 31 (level, low) -> IRQ 31
[  433.918489] e100 0000:03:01.0: (unregistered net_device): READ:addr=1, reg=0, data_in=0x0000, data_out=0x18203000
[  433.918538] e100 0000:03:01.0: (unregistered net_device): READ:addr=1, reg=1, data_in=0x0000, data_out=0x1821782D
[  433.918586] e100 0000:03:01.0: (unregistered net_device): READ:addr=1, reg=1, data_in=0x0000, data_out=0x1821782D
[  433.918590] e100 0000:03:01.0: (unregistered net_device): phy_addr = 1
[  433.918638] e100 0000:03:01.0: (unregistered net_device): READ:addr=1, reg=2, data_in=0x0000, data_out=0x182202A8
[  433.918686] e100 0000:03:01.0: (unregistered net_device): READ:addr=1, reg=3, data_in=0x0000, data_out=0x18230154
[  433.918691] e100 0000:03:01.0: (unregistered net_device): phy ID = 0x015402A8
[  433.918738] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=0, reg=0, data_in=0x0400, data_out=0x14000400
[  433.918786] e100 0000:03:01.0: (unregistered net_device): READ:addr=1, reg=0, data_in=0x0000, data_out=0x18203000
[  433.918835] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=1, reg=0, data_in=0x3000, data_out=0x14203000
[  433.918883] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=2, reg=0, data_in=0x0400, data_out=0x14400400
[  433.918931] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=3, reg=0, data_in=0x0400, data_out=0x14600400
[  433.918979] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=4, reg=0, data_in=0x0400, data_out=0x14800400
[  433.919036] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=5, reg=0, data_in=0x0400, data_out=0x14A00400
[  433.919085] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=6, reg=0, data_in=0x0400, data_out=0x14C00400
[  433.919135] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=7, reg=0, data_in=0x0400, data_out=0x14E00400
[  433.919183] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=8, reg=0, data_in=0x0400, data_out=0x15000400
[  433.919232] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=9, reg=0, data_in=0x0400, data_out=0x15200400
[  433.919281] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=10, reg=0, data_in=0x0400, data_out=0x15400400
[  433.919330] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=11, reg=0, data_in=0x0400, data_out=0x15600400
[  433.919378] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=12, reg=0, data_in=0x0400, data_out=0x15800400
[  433.919426] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=13, reg=0, data_in=0x0400, data_out=0x15A00400
[  433.919474] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=14, reg=0, data_in=0x0400, data_out=0x15C00400
[  433.919522] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=15, reg=0, data_in=0x0400, data_out=0x15E00400
[  433.919571] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=16, reg=0, data_in=0x0400, data_out=0x16000400
[  433.919619] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=17, reg=0, data_in=0x0400, data_out=0x16200400
[  433.919668] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=18, reg=0, data_in=0x0400, data_out=0x16400400
[  433.919717] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=19, reg=0, data_in=0x0400, data_out=0x16600400
[  433.919766] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=20, reg=0, data_in=0x0400, data_out=0x16800400
[  433.919814] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=21, reg=0, data_in=0x0400, data_out=0x16A00400
[  433.919862] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=22, reg=0, data_in=0x0400, data_out=0x16C00400
[  433.919911] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=23, reg=0, data_in=0x0400, data_out=0x16E00400
[  433.919959] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=24, reg=0, data_in=0x0400, data_out=0x17000400
[  433.920030] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=25, reg=0, data_in=0x0400, data_out=0x17200400
[  433.920079] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=26, reg=0, data_in=0x0400, data_out=0x17400400
[  433.920127] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=27, reg=0, data_in=0x0400, data_out=0x17600400
[  433.920176] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=28, reg=0, data_in=0x0400, data_out=0x17800400
[  433.920225] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=29, reg=0, data_in=0x0400, data_out=0x17A00400
[  433.920273] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=30, reg=0, data_in=0x0400, data_out=0x17C00400
[  433.920321] e100 0000:03:01.0: (unregistered net_device): WRITE:addr=31, reg=0, data_in=0x0400, data_out=0x17E00400
[  433.932036] e100 0000:03:01.0: PME# disabled
[  433.932452] e100 0000:03:01.0: eth0: addr 0xe3200000, irq 31, MAC addr 00:d0:b7:ca:86:36
[  434.045701] e100 0000:03:01.0: eth0: e100_hw_init
[  434.056013] e100 0000:03:01.0: eth0: Self-test failed: result=0xFFFFFFFF
[  434.056594] e100 0000:03:01.0: eth0: Cannot open interface, aborting

So I believe this is a driver related issue.

Same things happened if boot "native" 2.6.38.6-26.rc1 kernel.

Comment 3 Alexey Kurnosov 2011-10-06 12:05:12 UTC
* rmmod e100

Comment 4 Josh Boyer 2011-10-06 15:28:22 UTC
Basically, the card is attempting to do a self-test 

There were only two changes between 2.6.35 and 2.6.38 to e100.c, and neither of them really look related to this at all.

807540baae406c84dcb9c1c8ef07a56d2d2ae84a and 
2d0bb1c1f4524befe9f0fcf0d0cd3081a451223f

Would it be possible for you to try a .36 and .37 kernel build as well, to see if the issue hits there?

http://koji.fedoraproject.org/koji/buildinfo?buildID=207513
http://koji.fedoraproject.org/koji/buildinfo?buildID=213137

Perhaps if we narrow it down to which release hits this first, we might be able to come up with an idea of which change introduced the new behaviour.

Comment 5 Alexey Kurnosov 2011-10-07 11:09:28 UTC
2.6.36.1-11.fc15.x86_64 is affected. I'll try vanilla later.

Comment 6 Josh Boyer 2011-10-07 11:21:13 UTC
(In reply to comment #5)
> 2.6.36.1-11.fc15.x86_64 is affected. I'll try vanilla later.

Well, that is somewhat good news.  If 2.6.36 is broken for you in this area, then doing a git bisect between 2.6.35 and 2.6.36 should be relatively simple to narrow down what caused it.

Comment 7 Josh Boyer 2011-10-10 14:17:26 UTC
Going to put this back into needinfo until Alexey can let us know how the vanilla kernel and/or git bisect went per comment #5 and comment #6

Comment 8 Alexey Kurnosov 2011-10-18 14:20:42 UTC
Vanilla 2.6.36.1-15 (from src.rpm built on f14) has the bug.

Comment 9 Josh Boyer 2011-11-29 20:06:53 UTC
Alexey, did you ever git bisect this to a specific commit?

Comment 10 Alexey Kurnosov 2011-11-30 14:27:56 UTC
Created attachment 538583 [details]
dmesg

Comment 11 Alexey Kurnosov 2011-11-30 14:37:19 UTC
The problem is in using ACPI CRS by default for newer kernels, which is
obviously broken for my Intel S3210SH motherboard with 06.2009 firmware.
Append pci=nocrs to kernel command line solve the issue. Sorry for late
answer.

But when I install 2.6.41.1-1.fc15.x86_64 another bug appear.
And e100 still does not work.:)
The entire dmesg output in attachment.
The main lines there:

[   17.056340] irq 17: nobody cared (try booting with the "irqpoll" option)
[   17.056576] Pid: 0, comm: swapper Not tainted 2.6.41.1-1.fc15.x86_64 #1
[   17.056807] Call Trace:
[   17.057032]  <IRQ>  [<ffffffff810b2222>] __report_bad_irq+0x38/0xc3
[   17.057317]  [<ffffffff810b24bc>] note_interrupt+0x176/0x1fa
[   17.057337]  [<ffffffff810b0a0f>] handle_irq_event_percpu+0x15d/0x1a5
[   17.057337]  [<ffffffff810b0a92>] handle_irq_event+0x3b/0x59
[   17.057337]  [<ffffffff810782e9>] ? sched_clock_cpu+0xbb/0xc6
[   17.057337]  [<ffffffff810b2c7c>] handle_fasteoi_irq+0x80/0xa4
[   17.057337]  [<ffffffff81010af9>] handle_irq+0x88/0x8e
[   17.057337]  [<ffffffff814a5c0d>] do_IRQ+0x4d/0xa5
[   17.057337]  [<ffffffff8149cd6e>] common_interrupt+0x6e/0x6e
[   17.057337]  <EOI>  [<ffffffff81015d21>] ? mwait_idle+0x87/0xb4
[   17.057337]  [<ffffffff81015d14>] ? mwait_idle+0x7a/0xb4
[   17.057337]  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
[   17.057337]  [<ffffffff8147b0be>] rest_init+0x72/0x74
[   17.057337]  [<ffffffff81b71b7d>] start_kernel+0x3ab/0x3b6
[   17.057337]  [<ffffffff81b712c4>] x86_64_start_reservations+0xaf/0xb3
[   17.057337]  [<ffffffff81b71140>] ? early_idt_handlers+0x140/0x140
[   17.057337]  [<ffffffff81b713ca>] x86_64_start_kernel+0x102/0x111
[   17.057337] handlers:

Comment 12 Josh Boyer 2012-06-07 14:48:50 UTC
Are you still seeing this with 2.6.43/3.3?

Comment 13 Josh Boyer 2012-07-11 17:52:37 UTC
Fedora 15 has reached it's end of life as of June 26, 2012.  As a result, we will not be fixing any remaining bugs found in Fedora 15.

In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with.  Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered.

Thank you for taking the time to file a report.  We hope newer versions of Fedora suit your needs.

Comment 14 Alexey Kurnosov 2012-07-21 19:26:25 UTC
(In reply to comment #12)
> Are you still seeing this with 2.6.43/3.3?

Why are you asking? Something had been done?:) No, it's still does not work.
If I would upgrade to F16/17 I will end up with not working ISP net card.
Looks like time to hardware upgrade.

Comment 15 Stuart D Gathman 2012-07-23 20:32:40 UTC
This is fixed on F16, but broken again on F17.

Comment 16 Stuart D Gathman 2012-07-23 20:57:15 UTC
Actually works on F17 also.  My problem was installer booting wrong kernel by default.


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