Bug 5204 - sk98lin driver blocks NIC for BIOS/dual boot OS after reboot
Summary: sk98lin driver blocks NIC for BIOS/dual boot OS after reboot
Alias: None
Product: Drivers
Classification: Unclassified
Component: Network (show other bugs)
Hardware: i386 Linux
: P2 blocking
Assignee: Stephen Hemminger
: 5451 (view as bug list)
Depends on:
Reported: 2005-09-07 16:44 UTC by Jens Pruefer
Modified: 2007-01-25 13:09 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.13
Tree: Mainline
Regression: ---


Description Jens Pruefer 2005-09-07 16:44:04 UTC
Most recent kernel where this bug did not occur:

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


for more reports on this strange behaviour.
Comment 1 Jens Pruefer 2005-09-07 16:49:03 UTC
-- 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."
Comment 2 Jens Pruefer 2005-09-08 11:30:48 UTC
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
    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.
Comment 3 Stephen Hemminger 2006-04-03 15:02:08 UTC
*** Bug 5451 has been marked as a duplicate of this bug. ***
Comment 4 Arno Wagner 2006-04-04 06:23:43 UTC
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.
Comment 5 Arno Wagner 2006-05-19 11:25:30 UTC
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 
Fortunately this board has a second GbE NIC that works.


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
Comment 6 Stephen Hemminger 2006-11-28 10:21:28 UTC
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?
Comment 7 Arno Wagner 2006-11-28 11:42:08 UTC
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 <= and Windows be equally 
damned, then your decision makes sense....
Comment 8 Daniel Drake 2006-11-28 11:55:19 UTC
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.
Comment 9 Arno Wagner 2006-11-28 13:57:13 UTC
Ok, then it definitely deserves to be closed. Fine by me.
Comment 10 Jens Pruefer 2007-01-25 13:09:55 UTC
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 

Thanks for the feedback!



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