sky2 was compiled as the only gigabit net driver into gentoo-sources-2.6.16-r9. The NIC is integrated into an MSI K8N nVidia 4 Platinum motherboard: 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 15) Subsystem: Micro-Star International Co., Ltd. Marvell 88E8053 Gigabit Ethernet Controller (MSI) sky2 fails to drive the above NIC. Reproducibility: every time Steps to reproduce: 1. Compile sky2 as only gigabit Ethernet driver (i.e. not as module) into gentoo-sources-2.6.16-r9 2. Boot 2.6.16-r9 Actual results: sky2 binds to eth0 as expected. dhcp "appears" to work normally for eth0. All remaining boot net services fail (e.g. iptables, ntp-client). Cannot ping ISP's router, yahoo.com, or any other IP address. Expected results: Boot services should work. Ping should work for ISP's router, yahoo.com, etc. I've had this problem since 2.6.16-r1. I'm currently running 2.6.15-r7 using sk98lin with Syskonnect patch. emerge --info from 2.6.16-r9: Gentoo Base System version 1.12.1 Portage 2.1 (default-linux/amd64/2005.0, gcc-3.4.6, glibc-2.3.6-r3, 2.6.16-gentoo-r9 x86_64) ================================================================= System uname: 2.6.16-gentoo-r9 x86_64 AMD Athlon(tm) 64 Processor 3800+ dev-lang/python: 2.3.5-r2, 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.16 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=k8 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://mirror.mcs.anl.gov/pub/gentoo/ " MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="amd64 X alsa also apache2 arts avi berkdb bitmap-fonts cdr cli crypt cups dri dvd eds emboss encode foomaticdb fortran gif gpm gstreamer gtk gtk2 imap imlib ipv6 isdnlog jpeg kde kdeenablefinal lzw lzw-tiff mp3 mpeg ncurses nls opengl pam pcre pdflib perl png ppds pppd python qt quicktime readline reflection sdl session spell spl ssl symlink tcpd tiff truetype-fonts type1-fonts usb xorg xpm xv zlib elibc_glibc kernel_linux userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY As suggested by dsd, dmesg and /proc/interrupts will be attached after this is filed.
Created attachment 88954 [details] dmesg from 2.6.16-r9 boot
Created attachment 88955 [details] /proc/interrupts from 2.6.16-r9 boot
does the nforce chip work with the forcedeth driver work on the same setup? Did you try the sk98lin driver from syskonnect? It work better for me.
(In reply to comment #3) > does the nforce chip work with the forcedeth driver work on the same setup? Yes, the forcedeth driver has worked with the nforce chip in all kernels that I've run. > Did you try the sk98lin driver from syskonnect? It work better for me. The current patch from Syskonnect, Version: 8.32.2.3, System: Linux, Date: 27.04.2006, will not compile with gentoo-sources-2.6.16-r9. It *will* compile with gentoo-sources-2.6.15-r7, so that's what I'm using.
Did you have success with sky2 on older kernels?
(In reply to comment #5) > Did you have success with sky2 on older kernels? Since sk98lin with Syskonnect patch had worked for the 2.6.15-r7 kernel, I never tried sky2 with 2.6.15 kernels. When sk98lin with Syskonnect patch failed to compile with 2.6.16-r1, I tried sky2 and it has not worked for 2.6.16-r1 through 2.6.16-r9. Following your suggestion, I compiled sky2 into 2.6.15-r7 and it works! I'll keep it for a while to see if it times out.
I have the same board, I'll see if I can debug sky2...
If sky2 is built into your kernel, boot with the sky2.disable_msi=1 parameter. If sky2 is built as a module, load it with modprobe sky2 disable_msi=1 See if that helps.
(In reply to comment #6) > Following your suggestion, I compiled sky2 into 2.6.15-r7 and it works! I'll > keep it for a while to see if it times out. It worked for about 8 hours and then died.
(In reply to comment #8) > If sky2 is built into your kernel, boot with the sky2.disable_msi=1 parameter. > If sky2 is built as a module, load it with modprobe sky2 disable_msi=1 It's built into the 2.6.16-r9 kernel. I booted with kernel /kernel-2.6.16-gentoo-r9 root=/dev/hda4 sky2.disable_msi=1 and had the same problems as if I booted *without* that last parameter.
I have the same controller but a different revision (and different motherboard, Asus P5LD2), and I've also been using the 2.6.15-r7 kernel with sk98lin Syskonnect patch since I haven't got the newer kernel modules for sk98lin, skge or sky2 to work. However, a while ago I made a fresh install of Gentoo, using this time new versions of compilers and the new kernel. And with those, the sky2 driver has been working fine for a couple of days. Since the whole system is new it's hard to know what actually made the driver work (and hopefully it won't fail later), but here are the most important differences in my system to the original report, in case it helps: 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 19) Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet controller PCIe (Asus) Portage 2.1 (default-linux/amd64/2006.0, gcc-4.1.1/amd64-vanilla, glibc-2.4-r3, 2.6.16-gentoo-r9 x86_64) dmesg | grep sky2: sky2 v1.4 addr 0xd2efc000 irq 177 Yukon-EC (0xb6) rev 2 # the original had rev 1 sky2 eth0: addr 00:13:d4:45:20:e6 sky2 eth0: enabling interface sky2 eth0: Link is up at 100 Mbps, full duplex, flow control none Also, I built sky2 as a module. But maybe the problem I had was a different one since the rev. is different? http://www.ussg.iu.edu/hypermail/linux/kernel/0601.3/0082.html
(In reply to comment #11) > ...Portage 2.1 (default-linux/amd64/2006.0, gcc-4.1.1/amd64-vanilla, glibc-2.4-r3, > 2.6.16-gentoo-r9 x86_64) > ...Also, I built sky2 as a module. But maybe the problem I had was a different one > since the rev. is different? I tried sky2 as a module with the same results. I then used gcc-config to set my gcc-profile to 4.1.1 and recompiled the kernel. That didn't help. My glibc is 2.3.6-r2. Do I need to change it to 2.4-r3? > http://www.ussg.iu.edu/hypermail/linux/kernel/0601.3/0082.html Is this a patch for 2.6.15 kernels or should I apply this to 2.6.16-r9?
(In reply to comment #12) > Is this a patch for 2.6.15 kernels or should I apply this to 2.6.16-r9? I just mentioned that patch because I thought that might be relevant in considering where the problem is. It should already be in the current (2.6.16-gentoo-r9) sky2.c., and it's listed in the kernel 2.6.16-rc3 patches. In the same set there was also another patch that might be relevant since one difference we had was that you had the link up at 10Mbps/half where I have 100/full duplex. From the patch description: "Users report problems w/ auto-negotiation disabled and the link set to 100/Half or 10/Half. Problems range from poor performance to no link at all. The current sky2 code does not set things properly on link up if autonegotiation is disabled. Plus it does not contemplate a 10Mbit setting at all. This patch corrects that." http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc3/2.6.16-rc3-mm1/broken-out/sky2-speed-setting-fix.patch However, that should also already be in the current driver so it should be fixed. But perhaps the problem is related.
(In reply to comment #13) > "Users report problems w/ auto-negotiation disabled and the link set to > 100/Half or 10/Half. Problems range from poor performance to no link at > all. Agreed. This sounds like my problem. >http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc3/2.6.16-rc3-mm1/broken-out/sky2-speed-setting-fix.patch > However, that should also already be in the current driver so it should be > fixed. But perhaps the problem is related. I checked and this patch appears to already be in sky2.c.
I get the same behavior with gentoo-sources-2.6.17. A diff of sky2.c in gentoo-sources-2.6.16-r9 and gentoo-sources-2.6.17 didn't show any differences so it's not surprising that the behavior is the same.
(In reply to comment #11) > Portage 2.1 (default-linux/amd64/2006.0, gcc-4.1.1/amd64-vanilla, glibc-2.4-r3, > 2.6.16-gentoo-r9 x86_64) I've got gcc-4.1.1 and could switch to it with gcc-config. I also have glibc-2.3.6-r4 (stable) but could quickpkg it and emerge glibc-2.4-r3 (testing). If I switched to a new gcc and glibc, could I simply compile a new kernel for a test or would I have to completely wipe out my entire gentoo and compile *everything* with the new gcc and glibc? I've tested every kernel up to 2.6.17-gentoo-r2 with the same results.
Changing gcc/glibc will not help Testing 2.6.18-rc1 would be a good move
(In reply to comment #17) > Changing gcc/glibc will not help > Testing 2.6.18-rc1 would be a good move I grabbed a vanilla 2.6.17 kernel from kernel.org and applied the prepatch 2.6.18-rc1. It patched with no problems but I still have the same behavior with sky2. Thanks.
Just waiting for the developer to come back from holiday :)
Ok, he's back, I just need a little more info before I send this report on. Attach the output of "lspci -vvvxxxs 03:00.0" For the info I ask for below, you need to make sure your kernel is completely untainted. So make sure the nvidia module does not get loaded. Boot 2.6.18-rc1 without the sky2.disable_msi=1 parameter. Attach dmesg and /proc/interrupts output. Observe the networking failure. Keep an eye on the sky2 interrupt count (that's the column labelled CPU0), and see if it is stuck at a certain value or if it is increasing. Boot 2.6.18-rc1 *with* the sky2.disable_msi=1 parameter. Attach dmesg and /proc/interrupts output. Observe the networking failure. Keep an eye on the sky2 interrupt count (that's the column labelled CPU0), and see if it is stuck at a certain value or if it is increasing.
Make that 2.6.18-rc2, there have been some sky2 changes
Make that 2.6.18-rc2 with this patch on top: http://marc.theaimsgroup.com/?l=linux-netdev&m=115314452123184&q=raw
(In reply to comment #20) > For the info I ask for below, you need to make sure your kernel is completely > untainted. So make sure the nvidia module does not get loaded. I commented out the nvidia line in /etc/modules.autoload.d/kernel-2.6 and booted softlevel=single but it still loaded. I can start services manually and rmmod nvidia before starting any network services. Will that work?
(In reply to comment #22) > Make that 2.6.18-rc2 with this patch on top: > http://marc.theaimsgroup.com/?l=linux-netdev&m=115314452123184&q=raw The patch failed with an error message that it stopped in the middle of a line. Perhaps I don't understand the extent of the patch. I used as patch --- sky2.orig/drivers/net/sky2.c 2006-07-17 06:02:27.000000000 -0700 +++ sky2/drivers/net/sky2.c 2006-07-17 06:06:56.000000000 -0700 @@ -50,7 +50,7 @@ #include "sky2.h" #define DRV_NAME "sky2" -#define DRV_VERSION "1.4" +#define DRV_VERSION "1.5" #define PFX DRV_NAME " " /* @@ -2204,9 +2204,6 @@ int work_done = 0; u32 status = sky2_read32(hw, B0_Y2_SP_EISR); - if (!~status) - goto out; - if (status & Y2_IS_HW_ERR) sky2_hw_intr(hw); @@ -2243,7 +2240,7 @@ if (sky2_more_work(hw)) return 1; -out: + netif_rx_complete(dev0); sky2_read32(hw, B0_Y2_SP_LISR); -
No, you must ensure that nvidia does not load at all, even if that means deleting the module from /lib/modules I think you'll find the patch applied OK even despite that error (check this manually). The message footer starts with a "-" which patch tries to interpret...
Created attachment 92181 [details] lspci -vvvxxxs 03:00.0
Created attachment 92182 [details] dmesg from 2.6.18-rc2 boot without sky2.disable_msi parameter 2.6.18-rc2 has sky2 patch. nvidia not loaded.
Created attachment 92183 [details] /proc/interrupts from 2.6.18-rc2 boot without sky2.disable_msi parameter 2.6.18-rc2 has sky2 patch. nvidia not loaded. /proc/interrupts showed sky2 incrementing "normally."
Created attachment 92184 [details] dmesg from 2.6.18-rc2 boot with sky2.disable_msi=1 parameter 2.6.18-rc2 with sky2 patch. nvidia not loaded.
Created attachment 92185 [details] /proc/interrupts from 2.6.18-rc2 boot with sky2.disable_msi=1 parameter 2.6.18-rc2 with sky2 patch. nvidia not loaded. /proc/interrupts showed sky2 incrementing "normally."
Created attachment 92243 [details] /proc/net/sky2/eth0 under 2.6.18-rc2 with debug patch This is 2.6.18-rc2 with sky2 patch and http://developer.osdl.org/shemminger/prototypes/sky2-proc-debug.patch. No nvidia and no sky2.disable_msi parameter. Status and tx rings are always empty. The rx ring rotates with time.
The TX ring stays empty even when you are trying to transmit something?
(In reply to comment #32) > The TX ring stays empty even when you are trying to transmit something? I booted in single-user mode and started /etc/init.d/eth0 with very few other services. Here's the tail of dmesg: sky2 eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready sky2 eth0: Link is up at 10 Mbps, half duplex, flow control none ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present sky2 worked. Then I started /etc/init.d/iptables and it gave an error. dmesg then contained an error to the effect that sky2 had a null pointer exception. I then stopped iptables and sky2 worked again. I rebooted and tried to replicate this. Exactly the same thing happened except that dmesg was "normal" and didn't contain the sky2 null pointer exception. Evidently iptables somehow is linked to sky2. My iptables has a "normal" list of rules: NAT, restrict ssh to certain hosts, etc.
Please temporarily try and shrink your iptables config to something really simple. Confirm the bug still exists, and post your iptables config so that we can try and get others to reproduce.
And please do the above tests on gentoo-sources-2.6.17-r6 or newer.
Created attachment 95694 [details] iptables rules with gentooo-sources-2.6.17-r6 I have sky2 compiled into the kernel of gentoo-sources-2.6.17-r6. When I boot into single-user mode and start net.eth0 but not iptables, I can ping. When I start iptables, it generates error messages and I cannot ping. When I then stop iptables I can ping again. The last line in the attachment is the first line in iptables which generates an iptables error message: iptables: Unknown error 18446744073709551615 The actual iptables is longer than the attachment. I determined this was the first line which generated an error by a linear search, commenting out the remaining lines.
As suggested by email, please apply this patch: http://marc.theaimsgroup.com/?l=linux-netdev&m=115678927930918&q=raw
(In reply to comment #37) > As suggested by email, please apply this patch: > http://marc.theaimsgroup.com/?l=linux-netdev&m=115678927930918&q=raw The patch applied correctly in both gentoo-sources-2.6.17-r7 and a vanilla 2.6.18-rc2 but I get this make error in both: drivers/built-in.o: In function `sky2_rx_start': sky2.c:(.text+0x6d32a): undefined reference to `__netdev_alloc_skb' drivers/built-in.o: In function `sky2_poll': sky2.c:(.text+0x6fa9f): undefined reference to `netdev_alloc_skb' sky2.c:(.text+0x6fbc4): undefined reference to `__netdev_alloc_skb' make: *** [.tmp_vmlinux1] Error 1
A working version of this patch is included in gentoo-sources-2.6.17-r8 -- please test that kernel.
(In reply to comment #39) > A working version of this patch is included in gentoo-sources-2.6.17-r8 -- > please test that kernel. I compiled sky2 into that kernel and get the same behavior. When I start iptables I lose the connection. When I stop iptables, the connection comes back.
Created attachment 97810 [details] iptables rules with gentoo-sources-2.6.18 that cause sky2 to malfunction I compiled sky2 into the gentoo-sources-2.6.18 kernel and booted into single-user mode. I started eth0 and sky2 functioned normally. I started iptables and sky2 stopped working. I then stopped iptables and sky2 began working again. Then I did a linear search to find out which iptables rule caused the problem. The very *first* iptables rule /sbin/iptables -P INPUT DROP causes sky2 to malfunction and does not print any IPTABLES error to the console.
When you say malfunction, do you mean it actually crashes, or do you just mean that you can't receive data through it? That rule sets the default policy to drop incoming data so it's no surprise that you don't receive anything after running it...
(In reply to comment #42) > When you say malfunction, do you mean it actually crashes, or do you just mean > that you can't receive data through it? > > That rule sets the default policy to drop incoming data so it's no surprise > that you don't receive anything after running it... The problem is solved. iptables doesn't function without "Loadable module support-> Automatic kernel module loading" turned on in the kernel. Older kernels had this automatically turned on while newer ones don't. This is explained in https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=467 I am ecstatically running sky2 with 2.6.18! Thank you for your help. I have made (yet another) contribution to the Gentoo Linux Foundation.
(In reply to comment #43) > (In reply to comment #42) > > When you say malfunction, do you mean it actually crashes, or do you just mean > > that you can't receive data through it? > > > > That rule sets the default policy to drop incoming data so it's no surprise > > that you don't receive anything after running it... > > The problem is solved. iptables doesn't function without "Loadable module > support-> Automatic kernel module loading" turned on in the kernel. Older > kernels had this automatically turned on while newer ones don't. This is > explained in > > https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=467 > > I am ecstatically running sky2 with 2.6.18! Thank you for your help. I have > made (yet another) contribution to the Gentoo Linux Foundation. > I incorrectly marked this as FIXED rather than INVALID.
