Messages in this thread | | | From | Marcus Blomenkamp <> | Subject | Re: r8169 GigE driver problem, locks up 2.4.23 NFS subsystem | Date | Mon, 15 Dec 2003 11:24:15 +0100 |
| |
Am Sonntag, 14. Dezember 2003 14:40 schrieben Sie: > > Ok, this one is merged into Jeff Garzik's patchset. If you try it and it > does not work, please report if it does not work in a different manner > (because it is still possible that I have broken something during the > merge).
Hi.
First of all, i did not feel any difference in behaviour for the different ACPI options, so I ran all these tests with acpi=off explicitly. Mainboard is Asus P2B with recent ACPI beta bios.
Ok, from this patchset i extracted and updated the 8169.c diff only. And bad news: With this driver object built-in the kernel does not boot at all - locks up on configuring card 100% reproducible.
I enabled debug options in 8169 and got this output: (manually written...)
r8169 Gigabit Ethernet driver 1.2 loaded mac_version == RTL_GIGA_MAC_VER_E (0002) phy_version == RTL_GIGA_PHY_VER_E (0000) eth0: RTL8169 at 0xd882a00, 00:08:54:d0:e4:70, IRQ 5 mac_version == RTL_GIGA_MAC_VER_E (0002) phy_version == RTL_GIGA_PHY_VER_E (0000) Do final_reg2.cfg
I added more dummy printks and intermediate result: it does not return from function 'rtl8169_hw_phy_config()'
This routine messes up the card itself, as a reset/reboot into 2.4 does not revitalize it. I definitively have to power-cycle the machine.
> > Is it possible to get an ethereal dump for a normal nfs operation as well > as for a failed one on both sides of the link (client + server) ? > The size of the dump should not be an issue on my side.
I tcpdump'ed both sides on transferring 1 Megabyte to the 8139 based machine for both low level transfers (UDP, TCP) and on filesystem level (NFS).
NFS: dd 1M to remote file UDP/TCP: dd 1M trough netcat TCP: scp 1M file
Very interestingly i could not reproduce the NFS lockup during this double monitoring setup. So i ran it twice - once for each machine in promiscious mode. And guess: If the 8169 NIC is in monitoring mode, NFS writes do not lock up. I can even recover the machine from stalling by explicitly entering promiscious mode and SIGINT'ing the writing process.
> > A /proc/interrupts of the working/failing client after the nfs operation > as well as after a normal scp (if possible) could help too.
Everything normal - no interrupt storm visible. On NFS stalling NICs interrupt counter does not increase, however explicit pings work fine and do increment the counter.
> > Some 'ifconfig' output will be welcome too. > > If the problem is more or less trivially related to the length of the > frames, it should be possible to notice a change of behavior while > increasing the size of simple ping (ping -n -c 1 -s _size 192.168.1.254 > where _size ~= 1460...1480). Do you notice something here ?
This one ist interesting too. After having found NFS locking above datagramsize==4k i tried to find the exact boundary in this range. And there is no. First impressions (will do a deeper analysis later):
send 4k OK send 5k -
IIRC there is a region around 4750 bytes at which it seems to works like a Schmitt trigger. If i am coming from below (aka can ping) i can ping with dsize=X but if i am coming from above (aka no ping answer) i can not ping with the same dsize=X.
I'll copy-mail this to lk, so i'll send the logs to you in a separate mail.
Best regards, Marcus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |