NIC Stops Working With Current Huge Kernel
 

Recently I started playing with Current (13.0). Seems that every time I boot with the 2.6.29.2 huge kernel, I lose my NIC. The LEDs stop working too. I have to power down the box to reinitialize the NIC.

The NIC is on-board with a Asus M2NPV-VM motherboard. The on-board 1 Gbps NIC is part of the Nvidia MCP51 chip set (Nvidia nForce 430 MCP51 controller, Marvell PHY).

Any ideas what might be causing this?

Okay, a slightly modified generic kernel (enabled ext2/3/4 support direct into the kernel and disabled the boot logo) causes this too.

This is weird. I'm not paranoid --- yet.

Any ideas?

There have been a few times in the last month or two that I've noticed the NIC being disconnected. Kind of surprising but I just restarted it via rc.inet1. I almost wondered if the NIC was sleeping but then thought it was related to one of the upgrades. Maybe wicd or ntp. I don't use wicd on this machine but notice on "top" that it pops up every once in a while. Suppose it could also be related to mysql and mythtv.

What happens if you just unload and reload the NIC module. Only ask as I had similar problems, albeit with the wireless interface using the same kernel so decided to go back to the kernel provided by 12.2, though still running everything else current.

I again fiddled with this today. When I use the 2.6.27.7 kernel with Current I have no problems. When I use the 2.6.29.2 kernel from Current then the NIC stops working.

I can watch the NIC LEDs and as soon as the udev script starts running the LEDs extinguish. They do not do that with 12.2 when the udev script runs.

Removing the NIC kernel module (rmmod forcedeth) and reloading (modprobe forcedeth) does nothing.

I compiled a new kernel using the generic config as a basis. I built in ext3 support, removed the logos, added 64GB support.

With the newly compiled kernel the NIC LEDs again extinguished when the udev script ran, but reappeared when the inet1 script ran.

Everything seemed okay.

I then noticed that something happened during shutdown/rebooting that disabled the NIC. During shutdown/reboot I noticed when the inet1 script is run (stopped), the NIC LEDs extinguished and upon reboot, the NIC failed to initialize under Current. Therefore something in the way the NIC is started/stopped is triggering this behavior. That would seem to imply the ifconfig command.

Stranger, I have to shutdown my Linksys WRT54GL router too. Seems that whatever causes the NIC to hang latches the router port too. :scratch:

I'll keep testing, but this is weird. :scratch: And unsettling. :(

Like I said earlier I'm sure It's a kernel bug.

http://www.nvnews.net/vbulletin/showthread.php?t=130438


I wonder if wicd would be a work-around for this.

Ah, sorry, I must have missed that report somewhere. :) Thanks for the link and info. I won't bother troubleshooting further. Looks like a patch was submitted. I hope the kernel gets updated officially before the next official Slackware release.

As one person in the linked thread stated:

Pretty much sums up what I reported.

Kernel bug. Fixed in 2.6.29.3

Hmm. I can't confirm. I downloaded the 2.6.29.3 sources and compiled the kernel using my 2.6.29.2 config file. The NIC functions fine until I warm reboot (Ctrl-Alt-Del). Then the same thing happens when the inet1 service script is run (stopped). The NIC LEDs extinguish and the NIC fails to initialize thereafter. :(

I ran out of time to test the generic or huge config files or 2.6.29.4.

I didn't see anything in the .4 changelog for forcedeth. I have an older nic that uses this module, fixed it for that, perhaps a different issue directly effecting your model. Though that fix was tested and on (a DFI board with an nVidia MCP55) and signed off.

Reading through LKML, it goes from blaming the patch (too aggressive), user error, bad bios tables ...........

2.6.27.23 has this http://kernel.org/pub/linux/kernel/v...eLog-2.6.27.23

Then there's this
Might have to stick with the 12.2 kernel, or get another NIC. I went through a similar ordeal with one of my onboard reltek NICs. It's finally fixed in the kernel now, but my $8 dedicated nic works much better.

I remember I used to have the most trouble with the "forcedeth" driver for my NIC's back in the day, I eventually threw in a old 3com I had to fix the problem, not the way I like to fix things but it worked ;)

Well I wish I knew what to do. Without hard numbers, the 2.6.29.x kernel seems faster than 2.6.27.7 and the KDE 3.5.10 desktop seems a tad snappier too. Could be my imagination. Regardless, I'd like to find a remedy for this regression. :(

I just compiled a 2.6.29.4 kernel and tested Current. Same results. The NIC locks upon a reboot, which is unacceptable. Sure, under typical usage I don't reboot all day, but when I'm testing, such as now with testing Current, I reboot often. Annoying. :(

I'm going to try to copy the 2.6.27.7 forcedeth source files to 2.9.29.2 and compile again. I have no idea whether that will work.

I'm open to ideas how to resolve the problem without buying a new NIC.

Will you post back to let us know how the above works?

I hope it does solve your issue. Nvidia does offer drivers. These have not been updated since 2007. MCP51 is defined in the source code.
http://www.nvidia.com/object/linux_nforce_1.23.html

The kernel failed to compile properly. All of the network related modules, that is. I'm no kernel expert and won't pretend to be. I only copied the forcedeth.c file. I might try again but be more selective about copying only sections of code. I diffed the files. Seems only a few spots might relate to my problem. As I'm no kernel guru I could be way off target with all of this.

I'm trying to surf to learn more about this problem. At this moment I'm compiling the 2.6.28.10 kernel and will report on that effort. If that kernel succeeds then the problem would seem to have occurred in the 2.6.29 series. There are many discussions online about forcedeth regressions but I haven't yet figured out which regression is the one affecting me.

I see Pat today updated Current to 2.6.29.4.