Bugzilla Bug 87822

Been having quite a few problems with the sk98lin driver in the kernel, in both
my x86 and amd64 system. Module has always loaded correctly and with no
errors,...

Just quite often it will shut off for some reason during a reboot and not come
back up. Found the only way was to boot to Win2k and run the diagnostics for
the Marvell Ethernet Controller. Then reboot. That worked, most of the time.

Ahorn's AMD64 LiveCD always worked, not when rebooting to another OS, but
always started the Controller and could access internet, ssh,...

Found he was using the sk98lin ver. 8.13.1.3(01) driver. Couldn't find that,
the newest one from syskonnect.com is 8.15.1.3 version. Put that on mine x86
system (amd64 is borked for other reasons) and after done modprobed the driver
and came right up! Nothing has worked like that before. 

The amd64 system was built using the Gentoo stage1 and gentoo-sources kernel,
just so you know I wasn't using a exotic kernel. 

Feel that updating this driver in the gentoo-sources kernels and maybe others
will solve a lot of peoples problems been having with the sk98lin. 
I see that it is depreciated in the kernel, but the skge driver isn't working
for me or others. See some that have but no many. 

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Please try the new version 0.6 of the skge driver, included in
gentoo-sources-2.6.11-r5

Thanks for the quick reply. Unfortunetly it didn't work. Even took the sk98lin
out of kernel with only the skge in there. Got some errors during kernel
compile of module. Could try later as in kernel if you think warranted.

Errors got during compile:

  CC [M]  drivers/net/skge.o
drivers/net/skge.c: In function `skge_xmit_frame':
drivers/net/skge.c:2379: warning: int format, different type arg (arg 3)
drivers/net/skge.c: In function `skge_poll':
drivers/net/skge.c:2610: warning: int format, different type arg (arg 3)
drivers/net/skge.c: In function `skge_tx_intr':
drivers/net/skge.c:2670: warning: int format, different type arg (arg 3)

So no interface came up. 

Can you please attach dmesg output from the failed kernel, and also attach the
"lspci -v" output

Created an attachment (id=55657) [edit]
dmesg from 2.6.11-r5 gentoo-sources boot with skge as module.

Weird, few difference in console dmesg output and what is in /var/log/dmesg.
So going to attach a diff file so don't have to post both.
This one is from the console dmesg output.

Created an attachment (id=55658) [edit]
diff from the /var/log/dmesg output

this is the:
diff -uN dmesg_skge.txt dmesg_skge2.txt

dmesg_skge2.txt is the actual /var/log/dmesg file. Just putting the diffs in
here.

Created an attachment (id=55659) [edit]
When skge failed to start interface during the first reboot.

failed_dmesg.txt is from /var/log/messages

Created an attachment (id=55660) [edit]
lspci -v -v output

Finally found a problem with the new 'skge' driver. 

Little background: Had trouble with Gentoo and Win2k until got the right drivers in place. Sometimes the Marvell Ethernet Controller wouldn't come up at all, Nothing. Gentoo: When put the one from syskonnect.com is 8.15.1.3 version, all problems gone. When put the 8.20.10.3 version from Marvell on the Win2k all problems gone with that one also. Always came up, no matter how tested, at least so far.

Noticed the other day when put the RR4 Gentoo LiveCd in that when my Marvell Ethernet (sk98lin) wasn't detected, it didn't come up, which isn't bad since didn't detect it correctly. But, when rebooted to system with the 'skge' driver it didn't come back up either. Did on the other systems. Rebooted before that several times to the one with the 'skge' driver and Nothing. That is when rebooted to another system and came up.

Then today, trying to get gensplash working (works when shutting down, not when booting up), so tried what one guy had in grub kernel line: noapic
Did this on the system with the 'skge' driver. Nothing, Ethernet failed to come up. So did same thing, rebooted back to my normal (working) grub line to same kernel and didn't come up again. So did same thing as last time, rebooted to another system (this time same system, but with the kernel with the sk98lin version 8.15.1.3 I patched the kernel with). It came back up again and using it right now.

So, the skge driver, though works, still has the same problem as was happening with the older drivers. IF the Marvell Ethernet Controller doesn't come up, the skge won't wake it up. So, for the time being, sticking with the 8.15.1.3 sk98lin version.

Any further instructions?

I've asked the skge author to have a look. He is busy for the next 2 weeks but
hopefully he'll come up with something after.

Thanks, maybe make a note to him that during my observations with this problem.
That anytime one of the drivers didn't work, Rebooting doesn't wake it back up! 
The only thing that consistently worked was to run the SysKonnect Diagnostics
from Win2k. Sometime would have to run it a couple times, always passed, but
when rebooted (to Win2k or Gentoo) it would start working again. 
Just running diagnostics by itself and not rebooting 99% of the time didn't
work, would have to reboot. Not too bad if in Windows all the time, but if run
Linux most of the time or don't have Windows, then problem.

skge doesn't work with SK-9E21D cards. So you should patch the kernel with the
syskonnect drivers:
http://www.syskonnect.com/syskonnect/support/driver/htm/sk9elin.htm

And please do this fast, because the livecd doesn't recognise my card..

Nuno

That's a big ugly patch which was rejected by the kernel maintainers, and one
of the reasons why skge came about (I think), so we aren't going to be applying
that. It would be helpful if you could define "doesnt work" by posting things
like dmesg, lspci -vv output, etc. Then hopefully the skge author will be able
to have a look.

I have the same marvell controller (11ab:4320), and it's working without
problems with the 0.6 skge driver. I haven't understood if the 0.6 skge driver
fails to compile on your machine. Those errors you're talking about are just
warnings, which should be addressed to the use in those three printk calls of
the "%d" conversion specifier for the argument (e - ring->start), which is a
pointer.

lspci -vv:
0000:02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 Gigabit Ethernet Controller (rev 15)
        Subsystem: Toshiba America Info Systems Marvell 88E8053 Gigabit Ethernet Controller (Toshiba)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR-
        Latency: 0, cache line size 08
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at cdffc000 (64-bit, non-prefetchable)
        Region 2: I/O ports at ce00 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [e0] #10 [0011]

Ignore the warnings, they are noise about wrong type (ptr diff is long long on
x86_64) and will go away in next version.

Here is what is happening:
1.   skge driver comes up okay and finds the board and that version of chip
should work okay
2.   device is brought up and the skge driver trys to bring up the PHY interface
and start autonegotiation
3.   it looks like negotiation never completes.

The next step in debugging this would be to add
#define DEBUG 1
to start of skge.c so that all the pr_debug() stuff gets compiled in.
Also loading with:
  modprobe skge debug=16
will spew more stuff as well.

Most likely the PHY interrupt as result of auto-negotiation isn't happening,
or there is a bug in the decode of the result.  Or maybe you are connecting
to an old box that doesn't do autonegotiation correctly (driver should still
be fixed).

I decided to try the debug. Must have done something wrong.
Put the #define DEBUG 1 in /usr/src/linux-2.6.11-gentoo-r5/drivers/net/skge.c file.
Recompiled the kernel with skge as a module. Actually still had it in there,
just stopped letting it load.
First tried this:
1) change net driver from the patched sk98lin to 'skge debug=16' in
/etc/modules.autoload.d/kernel-2.6

Says loaded fine when rebooted, but no net, router lights out. Did a grep on
/var/log and only found this:
***************
kern.log:May 19 23:40:15 decibels skge addr 0xfc000000 irq 19 chip Yukon-Lite rev 9
kern.log:May 19 23:40:15 decibels skge eth0: addr 00:0f:ea:7a:8e:53
kern.log:May 19 23:40:15 decibels skge eth0: enabling interface
**************

2) Then thought, maybe the 'debug=16' in kernel-2.6 file screwed it up. So
'rmmod skge' then 'modprobe skge debug=16' in commandline. 

rechecked the /var/log files and only got this:
**************
kern.log:May 19 23:40:15 decibels skge addr 0xfc000000 irq 19 chip Yukon-Lite rev 9
kern.log:May 19 23:40:15 decibels skge eth0: addr 00:0f:ea:7a:8e:53
kern.log:May 19 23:40:15 decibels skge eth0: enabling interface
kern.log:May 19 23:44:08 decibels skge eth0: disabling interface
**************

Same results and not net, connection never established.

3) Rmmod skge and modprobed the patched sk98lin and interface comes right up,
came here and filed report, no reboot necessary or manually restarting the
interface.

Went back and tried stopping/starting/restarting the network after
rmmod/modprobing skge and still nogo. sk98lin though still brings interface
right up.

Thanks for the testing. I'm not sure if module autoload files will obey
parameters like that, so for now, make sure you are modprobing it manually with
the debug param.

The two log excerpts that you pasted show the exact same lines (according to the
timestamps) suggesting that no output was produced the second time you loaded
the module (maybe the hardware was hung or something..?)

For more accurate results, it may be best to fresh reboot, and then *without*
loading sk98lin beforehand, run "modprobe skge debug=16". Then check the debug
stuff in the logs.

(In reply to comment #18)
> I'm not sure if module autoload files will obey parameters like that, so for 
> now, make sure you are modprobing it manually with the debug param.

That is why did it the other way also and got the second results in the other post.
 
> The two log excerpts that you pasted show the exact same lines (according to
the timestamps)

Ya, sorry, caught that after posted. Oops. :(
 
> For more accurate results, it may be best to fresh reboot, and then *without*
> loading sk98lin beforehand, run "modprobe skge debug=16". Then check the debug
> stuff in the logs.

I did that last time also. I removed the sk98lin from loading and only had the
skge in the /etc/../kernel-2.6 file.

This time I tried it again (fresh reboot), with both skge and sk98lin commented
out, removed net.eth0 from default runlevel and tried again.

Same results. It appears to load and nothing (ie. no router lights, no
connection,...). No debug output. Had to put the sk98lin back to get net working.

Just to show you I did put the debug in the correct kernel.

1) decibels david # uname -r
2.6.11-gentoo-r5

2) decibels net # pwd
/usr/src/linux-2.6.11-gentoo-r5/drivers/net

3) decibels net # grep -i 'define d' skge.c
#define DEBUG 1
#define DRV_NAME                "skge"
#define DRV_VERSION             "0.6"
#define DEFAULT_TX_RING_SIZE    128
#define DEFAULT_RX_RING_SIZE    512

Oh, didn't mention, incase you were wondering. Yes, after fresh reboot with
net.eth0 out of default. I modprobed the skge, then '/etc/init.d/net.eth0 start'

Patch posted to netdev@vger.kernel.org

Basically, comparison for YUKON_LITE_A3(rev 7) needs to be extended
to include greater than or equal to rev 7.

Thanks Stephen. Fixed in gentoo-sources-2.6.12-r2