Most recent kernel where this bug did not occur: 2.6.12.3 Distribution: Debian Testing Hardware Environment: "ASUS A8N-SLI Premium" Mainboard with on board Marvell Yukon NIC, lspci reports: Ethernet controller: Marvell Technology Group Ltd. Yukon Gigabit Ethernet 10/100/1000Base-T Adapter (rev 13) Software Environment: nothing special here, booting into console Problem Description: After bootup into 2.6.13 kernel, the NIC works fine. However, after reboot into a dual boot alternative OS (e.g. Windows XP), the NIC is no longer detected. The BIOS built in network diagnostics report a lost connection/possible cable failure. Even a hard reset or disconnecting the hardware from the power outlet revives the NIC. Only booting back into linux 2.6.13 kernel brings the NIC back to life and it works like a charm. The only way to get the NIC back to work under Windows is to push the reset button after the successful initialization under 2.6.13. Steps to reproduce: Get a Marvell Yukon on board NIC (ASUS A8N-SLI Premium prefered), configure dual boot WinXP (SP2) and Linux 2.6.13 kernel to use the sk98lin driver, boot, reboot into other OS. Other people seem to have the same problem. See http://www.uwsg.iu.edu/hypermail/linux/kernel/0508.3/1411.html http://www.linuxquestions.org/questions/history/353303 http://www.ussg.iu.edu/hypermail/linux/kernel/0509.0/0217.html http://forums.suselinuxsupport.de/lofiversion/index.php/t18379.html for more reports on this strange behaviour.
-- correction -- The sentence "Even a hard reset or disconnecting the hardware from the power outlet revives the NIC." should of course be "Even a hard reset or disconnecting the hardware from the power outlet DOES NOT revive the NIC."
Update: Could it be related to the following problem from the 2.6.13 changelog? == snip == commit 3f309db33e7868fe11f8fc3a0dd291703df3c662 Author: Stephen Hemminger <shemminger@osdl.org> Date: Mon Jun 27 15:47:25 2005 -0700 [PATCH] sk98lin: fix workaround for yukon-lite chipset (> rev 7) Yukon-Lite chipset needs workaround for revision 7 (or later). Without this patch, chip gets stuck in low power mode and never boots. Newer SysKonnect vendor code already had same patch. Related bug in skge is http://bugs.gentoo.org/87822 Chris, please add for 2.6.12.2 Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Jeff Garzik <jgarzik@pobox.com> == snap == When you follow the gentoo bug, you get reports that indicate towards the same problem I observed.
*** Bug 5451 has been marked as a duplicate of this bug. ***
I agree that this and bug 5451 describe the same problem. I would say that the observed behaviour here that even removing the power connection does not cure the problem might be due to a very well buffered +5Vsb and a very low load on that line. At least in my case (5451) power disconnect cured the problem. Reset does not cure the problem in my case as well.
I again have a new mainboard (the old one went into a server), and I again have a Marvell NIC, with the same problems as before. Observed with kernel 2.6.16.13. Fortunately this board has a second GbE NIC that works. NIC: 0000:05:0c.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) Subsystem: ASUSTeK Computer Inc. Marvell 88E8001 Gigabit Ethernet Controller (Asus) Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at d4000000 (32-bit, non-prefetchable) [size=16K] I/O ports at 9800 [size=256] Expansion ROM at 88000000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data
If windows won't work correctly on reboot but Linux does. Then it means the windows driver is buggy and does not power up the PHY. Why should Linux workaround a buggy windows driver?
I assume you _have_ seen that older Linux drivers cannot initialize the card as well? If not, have a look at bug 5451 again. If you however are willing to say Linux <= 2.6.12.2 and Windows be equally damned, then your decision makes sense....
FWIW I contacted syskonnect when this bug first appeared (a while back). The same bug exists in their own sk98lin driver (from their website, not the in-kernel one): when you boot a new sk98lin, an old sk98lin or old windows driver is not able to power up the PHY and no network transfer is possible. The same bug manifests in other ways too. The newer windows drivers power down the PHY on shutdown, so if you dual boot 2 versions of windows, one with an old driver and one with a new one, one of your windows installs will be unable to use the network after the other one has been used. syskonnect confirmed this is a driver bug both in Windows and Linux drivers and suggested that the only solution is to upgrade your drivers. The most recent windows drivers do work here, as does sk98lin from their website and skge from recent kernels. The decision has already been made to break compatibility with older drivers, regardless of OS.
Ok, then it definitely deserves to be closed. Fine by me.
If that is the verdict, so be it. It might cause some hairloss for people with older kernels/drivers, but I hope they will find this thread using google or Bugzilla. Thanks for the feedback! Cheers Jens