Bug 5451
| Summary: | 2.6.13.x ''locks'' network card. | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Arno Wagner (wagner) |
| Component: | Network | Assignee: | Stephen Hemminger (stephen) |
| Status: | REJECTED DUPLICATE | ||
| Severity: | normal | CC: | bunk, romieu, stephen |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.13.3 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
I tested this again with 2.6.14. The problem is still present. I have confirmed that turning of standby power (+5V_SB) is needed to reset this behaviour, i.e. pulling the plug or switching the PSU off with the switch on that back of the PSU. Alternatively booting 2.6.12.2 also resets this behaviour. Here is a work-around for 2.6.14: Replace drivers/net/sk98lin from 2.6.14 with the same directory from 2.6.12.2. Seems to work without problem. Can you give the skge module a try and report if it exhibits the same behavior ? If so it will possible to add its maintainer to the Cc: list :o) -- Ueimor skge behaves similarly. In fact skge is worse: When booting with skge from 2.6.14, neither Windows XP nor sk98lin from 2.6.12.2 are able to get the card up and the LEDs remain off, i.e. the physical link stays down. At least with sk98lin the version from 2.6.12.2 can revitalize the card after it has been booted with sk98lin from 2.6.14. As before only completely turning power off helps. BTW, there is a bug in the config infor for skge in 2.6.14: The "help" page does not give the module name. Small update: Problem still present in 2.6.15-rc5. Just to document it. Stephen, can you look at the skge part of this bug? I need to know the chip version and revision, from the kernel console output (dmesg). Something like: skge 1.2 addr 0xf2000000 irq 17 chip Yukon rev 1 skge eth0: addr 00:0c:41:1a:a5:1f skge 1.2 addr 0xfe200000 irq 16 chip Yukon-Lite rev 9 skge eth0: addr 00:11:d8:54:6d:60 Is this sufficient? Stephen, what is the status of this issue? No new progress, I couldn't reproduce it on the one dual boot system I tried. It may depend on hardware and windows driver version. Well, I cannot help you, since I don't have the mainboard anymore. Sorry. Still, It is not a windows driver issue. Don't forget that 2.6.12.2 was not able to bring the card up as well. So unless there are Windows drivers in 2.6.12.2..... This matches symptoms of other bug. So mark as duplicate *** This bug has been marked as a duplicate of 5204 *** |
Most recent kernel where this bug did not occur: none that I know of Distribution: Debian etch Hardware Environment: VIA KT880 (Asus A7V880), Athlon XP 3000+, affected component: On-board Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) Problem Description: The Card works fine under Linux. However when I (warm) reboot to Windows XP, it does not detect that a link is present. It is neccessary to turn off the computer, and, I think disconnect the PSU from power to restore functionality for Windows. Now, I realise that this is probably the MS driver not doing proper initialisation, but the problem first turned up with 2.6.13.1 for me and 2.6.12.2 (last one I used before) works fine, so there was some driver change that causes this new behaviour. Steps to reproduce: Boot to 2.6.13.3, bring up NIC, reboot to Windows, see NIC fail. Card description from 'lspci': 0000:00:09.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 64, IRQ 18 Memory at fe200000 (32-bit, non-prefetchable) [size=16K] I/O ports at ed00 [size=256] Expansion ROM at fe100000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data