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 attachment 55657 [details] dmesg from 2.6.11-r5 gentoo-sources boot with skge as module that worked. 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 attachment 55658 [details] 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 attachment 55659 [details] When skge failed to start interface during the first reboot. failed_dmesg.txt is from /var/log/messages
Created attachment 55660 [details] 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
