Bug 494844 - nVidia Corporation MCP55 Ethernet card gets disabled for other systems after shut down
Summary: nVidia Corporation MCP55 Ethernet card gets disabled for other systems after ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-08 10:41 UTC by Peeter Puusemp
Modified: 2009-04-08 17:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-08 17:10:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Boot up log of F-10 after normal shut down of F-11 (58.11 KB, text/plain)
2009-04-08 15:08 UTC, Peeter Puusemp
no flags Details

Description Peeter Puusemp 2009-04-08 10:41:44 UTC
Description of problem:
After shutting Fedora 11 Beta down the network card's led doesn't have light any more and the network card doesn't work if to boot into another OS (for example into Fedora 10). If to boot back into Fedora 11 Beta, the network card works again and the led's light is on.

So the network card will work only in Fedora 11 Beta after the first shut down of it.

The same problem is with the installer (DVD version).

Network card (integrated): nVidia Corporation MCP55 Ethernet.

Version-Release number of selected component (if applicable):
I have installed all available updates.

kernel version: 2.6.9.1-52.fc11.x86_64


How reproducible:
Boot into Fedora 11 Beta or into the (installation or rescue mode of) installation media (DVD installer), shut down or exit the installation media, boot into another OS.

Steps to Reproduce:
1. Boot into Fedora 11 Beta or into the (installation or rescue mode of) installation media (DVD installer).
2. Shut down or exit the installation media.
3. Boot into another OS.
  
Actual results:
The network card seems to not exist, it's led doesn't have light.

Expected results:
The network card is recognized and there is internet connection.

Additional info:
Workaround is to force shut down when F11 Beta or the DVD installer with loaded hardware is running.

Comment 1 Neil Horman 2009-04-08 11:43:13 UTC
What is the pci device and vendor id on the card? 

 If you've only tried this with previous versions of Fedora, its entirely possible that the F-10 forcedeth driver simply doesn't support this card.  Does it work if you do a clean install of F-10?

also, can you restate your kernel version? I'm guessing when you wrote 
 kernel version: 2.6.9.1-52.fc11.x86_64
you meant
 kernel version: 2.6.29.1-52.fc11.x86_64

Is that correct?

Please provide that pci vendor/device id set.  As I read your results section above I'm more convinced this is simply a new hardware support issue.

Comment 2 Peeter Puusemp 2009-04-08 13:03:34 UTC
(In reply to comment #1)
> What is the pci device and vendor id on the card? 
> 

> Please provide that pci vendor/device id set.  As I read your results section
> above I'm more convinced this is simply a new hardware support issue.  

It is integrated network "card", so I cannot look it up from the pci card. The motherboard is ASUS M2N-E.

Motherboard specification link:
http://www.asus.com/Product.aspx?P_ID=NFlvt10av3F7ayQ9

>  If you've only tried this with previous versions of Fedora, its entirely
> possible that the F-10 forcedeth driver simply doesn't support this card.  Does
> it work if you do a clean install of F-10?
> 

After I bought the computer in the end of 2006 the network has worked out of the box with all Fedora versions (I always do clean installs).

(PS. I don't know what forcedeth driver means and didn't find any explanations from the internet for it.)

> also, can you restate your kernel version? I'm guessing when you wrote 
>  kernel version: 2.6.9.1-52.fc11.x86_64
> you meant
>  kernel version: 2.6.29.1-52.fc11.x86_64
> 
> Is that correct?
> 

Yes, the kernel version is 2.6.29.1-52.fc11.x86_64.

Comment 3 Peeter Puusemp 2009-04-08 13:15:28 UTC
Additional information: it's the first time to install 64bit system.

Comment 4 John W. Linville 2009-04-08 13:18:46 UTC
Please execute 'lspci -n' and post the output here...thanks!

Comment 5 Neil Horman 2009-04-08 13:19:22 UTC
You don't need to open the box to get the pci dev/vendor id's, just run lspci to find the device, record its bus/dev/fun tuple, then run lspci -n, and find the line with the same bus/dev/fun tuple.  The column with 2 hex numbers separated by a colon are the vendor and device ids (see the man page for details)

If you have an nvidia on board ethernet controller, forcedeth is the name of the driver module that controlls it

Also, when you say, "doesn't exist" in the old kernel, how exactly are you determining that?

Comment 6 Chuck Ebbert 2009-04-08 13:58:07 UTC
I still don't understand the exact problem and the workaround.

First it says to reproduce the problem "shut down or exit the installation media,
boot into another OS".

Then later it says to work around the problem "force shut down when F11 Beta or the DVD installer with loaded hardware is running".

What is the difference between "shut down or exit" and "force shut down"?

To find out the PCI device IDs, just run "lspci -vnn", which will show the names and numbers of the devices, and post the output as an attachment.

Comment 7 Peeter Puusemp 2009-04-08 14:03:39 UTC
(In reply to comment #5)
> Also, when you say, "doesn't exist" in the old kernel, how exactly are you
> determining that?  

* Behind the computer box the network led that usually shines all the time, doesn't shine any more.

* In BIOS I enabled the feature "POST Check LAN Cable" and the cable check fails on restart after normal shut down of F-11. After forcing shut down from the computer box when F-11 is running the cable check doesn't fail.

* F-10 cannot detect the cable.

(In reply to comment #4)
> Please execute 'lspci -n' and post the output here...thanks!  

[peeter@localhost ~]$ lspci -n
00:00.0 0500: 10de:0369 (rev a1)
00:01.0 0601: 10de:0360 (rev a2)
00:01.1 0c05: 10de:0368 (rev a2)
00:01.2 0500: 10de:036a (rev a2)
00:02.0 0c03: 10de:036c (rev a1)
00:02.1 0c03: 10de:036d (rev a2)
00:04.0 0101: 10de:036e (rev a1)
00:05.0 0101: 10de:037f (rev a2)
00:05.1 0101: 10de:037f (rev a2)
00:05.2 0101: 10de:037f (rev a2)
00:06.0 0604: 10de:0370 (rev a2)
00:06.1 0403: 10de:0371 (rev a2)
00:08.0 0680: 10de:0373 (rev a2)
00:0a.0 0604: 10de:0376 (rev a2)
00:0b.0 0604: 10de:0374 (rev a2)
00:0c.0 0604: 10de:0374 (rev a2)
00:0d.0 0604: 10de:0378 (rev a2)
00:0e.0 0604: 10de:0375 (rev a2)
00:0f.0 0604: 10de:0377 (rev a2)
00:18.0 0600: 1022:1100
00:18.1 0600: 1022:1101
00:18.2 0600: 1022:1102
00:18.3 0600: 1022:1103
01:07.0 0400: 109e:036e (rev 11)
01:07.1 0480: 109e:0878 (rev 11)
07:00.0 0300: 10de:0391 (rev a1)

[peeter@localhost ~]$ 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:01.2 RAM memory: nVidia Corporation MCP55 Memory Controller (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:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (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 video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
01:07.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
07:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GT] (rev a1)
[peeter@localhost ~]$

Comment 8 Peeter Puusemp 2009-04-08 14:16:42 UTC
(In reply to comment #6)
> I still don't understand the exact problem and the workaround.
> 
> First it says to reproduce the problem "shut down or exit the installation
> media,
> boot into another OS".
> 
> Then later it says to work around the problem "force shut down when F11 Beta or
> the DVD installer with loaded hardware is running".
> 
> What is the difference between "shut down or exit" and "force shut down"?

Shut down is normal shut down when I shut down from the menu. Force shut down is when I hold the power button on the computer box for some seconds.

The point here should be that kernel does something causing this problem (problem=computer cannot detect the cable any more) when shutting down normally. If forced to shut down, the kernel cannot do usual shutting down procedures (unloading hardware or similar)

Sorry for misunderstandings. Feel free to ask additional questions after reading my last comments.

Comment 9 Neil Horman 2009-04-08 14:34:52 UTC
Ok, so it looks like the latest F-10 kernel supportsthe pci id, thats good.

Regarding the BIOS Check LAN cable test, I have to ask: why?  If thats the only problem plaging this system here ti would seem simple enough to just disable that BIOS test and move on.  I can't imagine what that test is good for, other than for pxe booting, and even then its not overly usefull.  If you disable it, does rebooting to F-10 then work?  If not, what errors do you receive in /var/log/messages during bootup?  Can you attach that from F-10 here?

By way of explination, my first guess would be its the use of the pci shutdown routine.  Looks like F-10 may have just missed some commits that allowed the forcedeth driver to get its pci shutdown routine called on devices supporting MSI interrupts.  Since F-11 has these patches:
d52877c7b1afb8c37ebe17e2005040b79cb618b0
8e149e09f91098fd72bf9ac5b4a77a693abf721e

We all nv_shutdown when we halt, likely placing the device into a power state that the BIOS isn't expecting, in turn causing that test to fail.

Given that that shutdown routine allows other things to work (wake on lan, etc), I'd say just disable the test and get on with it, unless there is a subsequent error.

Comment 10 Peeter Puusemp 2009-04-08 15:08:10 UTC
Created attachment 338721 [details]
Boot up log of F-10 after normal shut down of F-11

(In reply to comment #9)
> Regarding the BIOS Check LAN cable test, I have to ask: why?  If thats the only
> problem plaging this system here ti would seem simple enough to just disable
> that BIOS test and move on.  I can't imagine what that test is good for, other
> than for pxe booting, and even then its not overly usefull.  If you disable it,
> does rebooting to F-10 then work?  If not, what errors do you receive in
> /var/log/messages during bootup?  Can you attach that from F-10 here?
>

I have never used that BIOS check before and I just enabled it now to make some checks and thought that it may be useful information for you. If it's disabled, then there aren't any booting problems.

I attached the boot up log of F-10 when I just did normal shut down of F-11. It means that networking doesn't work in F-10 after that boot up.

Comment 11 Neil Horman 2009-04-08 17:10:06 UTC
Ok, well that would seem to confirm the above theory then.  I'm not sure why on earth you would want to stop a POST if your network card isn't up (perhaps its some aid to pxe booting).  In either case, I'd say its just good cause to turn it off, although you may want to contact your motherboard vendor and ask them to add code to allow that test to operate properly when a card is in D3Hot state (which is the state IIRC that forcedeth leaves the card in on shutdown).

You may also want to explore the use of the reboot= kernel command line parameter.  Its possible that some other reboot method will allow the bios to reset the cards to a state where that test would pass.  I would try:
reboot=cold
reboot=pci
reboot=acpi


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