Bug 497052

Summary: forcedeth driver makes the network card unusable after reboot/halt
Product: [Fedora] Fedora Reporter: Edouard Bourguignon <madko>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: itamar, jhawkes, kernel-maint, quintela
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-02 07:09:47 UTC Type: ---
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
dmesg none

Description Edouard Bourguignon 2009-04-22 07:27:54 UTC 
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 07:37:35 UTC 
Created attachment 340684 [details]
dmesg
Comment 2 Edouard Bourguignon 2009-05-12 07:45:49 UTC 
still having the problem on kernel 2.6.29.2-126.fc11.x86_64
Comment 3 Edouard Bourguignon 2009-05-13 19:44:12 UTC 
seems this is a duplicate of bug #484505
Comment 4 John Hawkes 2009-05-28 18:08:31 UTC 
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.