Bug 497052 - forcedeth driver makes the network card unusable after reboot/halt
forcedeth driver makes the network card unusable after reboot/halt
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-22 03:27 EDT by Edouard Bourguignon
Modified: 2009-06-02 03:09 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-02 03:09:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg (40.11 KB, text/plain)
2009-04-22 03:37 EDT, Edouard Bourguignon
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 13072 None None None Never

  None (edit)
Description Edouard Bourguignon 2009-04-22 03:27:54 EDT
Description of problem:

When using the forcedeth driver everything works, network link is accessible and performance seems good. 
But after a reboot or a poweroff, the network card become unusable for other OS (fedora10, ubuntu, etc). Seems something is not enought cleaned at shutdown (I presume). Only the media link detection fails, the card is still detected, forcedeth driver is loaded, everything seems fine except that link is unavailable. So network doesn't work.

I found an annoying workaround that is to unplug the power cord, wait few seconds, and start again the computer.

Manually unloading the forcedeth driver correctly shut the power off on the ethernet link, then manually loading it again still works, media link is accessible again. So what the difference between unloading/loading at hand, and a reboot?

This problem only occurs when using fedora rawhide. On other OS I can reboot at will.

Not sure if it's related, I also got the Free DMA errors at boot (cf bug #484494), but since the messages have disappeared I open this new bug.

Version-Release number of selected component (if applicable):
all kernels since rawhide.
kernel-2.6.29.1-68.fc11.x86_64
kernel-2.6.29.1-70.fc11.x86_64
kernel-2.6.29.1-100.fc11.x86_64


How reproducible:
static

Steps to Reproduce:
1. boot
2. network is working
3. reboot
4. ethernet media link has gone
  
Actual results:
network doesn't work after reboot.


Expected results:
network should work even after reboot

Additional info:
lspci
------------------------------------------------------------------------
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:07.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value
01:08.0 Network controller: RaLink RT2561/RT61 802.11g PCI
02:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
02:00.1 Audio device: ATI Technologies Inc HD48x0 audio
------------------------------------------------------------------------
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
	Subsystem: ASUSTeK Computer Inc. Device 8239
	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-
	Latency: 0 (250ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 25
	Region 0: Memory at fe02a000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at b000 [size=8]
	Region 2: Memory at fe029000 (32-bit, non-prefetchable) [size=256]
	Region 3: Memory at fe028000 (32-bit, non-prefetchable) [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
	Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
		Vector table: BAR=2 offset=00000000
		PBA: BAR=3 offset=00000000
	Capabilities: [50] MSI: Mask+ 64bit+ Count=1/8 Enable+
		Address: 00000000fee0100c  Data: 4189
		Masking: 000000fe  Pending: 00000000
	Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+
	Kernel driver in use: forcedeth
	Kernel modules: forcedeth
------------------------------------------------------------------------

Motherboard is an Asus M2N-E, pretty common.
Comment 1 Edouard Bourguignon 2009-04-22 03:37:35 EDT
Created attachment 340684 [details]
dmesg
Comment 2 Edouard Bourguignon 2009-05-12 03:45:49 EDT
still having the problem on kernel 2.6.29.2-126.fc11.x86_64
Comment 3 Edouard Bourguignon 2009-05-13 15:44:12 EDT
seems this is a duplicate of bug #484505
Comment 4 John Hawkes 2009-05-28 14:08:31 EDT
I'm also seeing this with the forcedeth.c included in rhel4.8 (the 2.6.9-89 kernel).  The forcedeth in rhel4.7 (2.6.9-78.0.22) worked fine (at least for this particular problem).  The forcedeth drivers are significantly different, even though both identify themselves as "0.61".

The particular hardware that shows the problem (from lspci):
 00:08.0 Ethernet controller: nVidia Corporation MCP55 Ethernet (rev a3)
 00:09.0 Ethernet controller: nVidia Corporation MCP55 Ethernet (rev a3)

When the Ethernet controller becomes unresponsive, even IPMI accesses fail.

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