Summary: | NFS client returns input/output error when reading certain directories | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gabe Martin-Dempesy <gabe> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Gabe Martin-Dempesy
2005-12-07 16:46:56 UTC
This occurs with both linux-2.6.14-gentoo-r2 linux-2.6.14-hardened-r1 kernels. Please try and reproduce this on the latest development kernel (currently vanilla-sources-2.6.15_rc5) Bug still occurs on vanilla-sources-2.6.15_rc5 Other interesting note -- I've just tried to duplicate this behavior on another Gentoo server we have, with the same hardened toolchain, profile, and kernel (version, not configuration) as the broken machine. Both are Dell Power edges, but the one with the buggy behavior is more high end. The hardware differences are: Broken Machine: * e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection * Dual Xeon * Hardware AAC Raid Working Machine: * Broadcom Tigon3 * Single Celeron * SATA hard drives The problematic machine had this issue in its previous install. Due to this issue, I reinstalled it from scratch (just as I had with the working machine), and still have the same issue. This makes me lean towards a software issue that is related to the hardware. Can the ethernet drivers play a role in this? Yeah, maybe. Do you use the network heavily in other ways? Might be worth testing some FTP transfers of large files (or similar) to see if it is a 'generic' networking problem. Is it possible to temporarily swap the network cards in these two machines for testing purposes? You should also check the "dmesg" output after these problems occur if you have not done so already. This is *VERY* interesting. Ignore anything said previously about this being hardware related -- that was incidental. 1> The 2005.1 Gentoo installation CD has this problem off the bat. If I boot from the CD and issue *JUST* these commands, I get the error, on any machine I try: ifconfig eth0 10.10.10.15 /etc/init.d/portmap start mkdir /sack mount -t nfs 10.10.10.10:/Volumes/Sack /sack find /Volumes/Sack/HCMG 1>/dev/null So whatever this problem is, its in the Gentoo installer too. 2> Because of this weird behavior, I took the config file from the known working machine (after rebooting out of the installer), copied it to the broken machine, flipped on RAIDAAC and my ethernet driver, and reinstalled. It worked. I did a few builds based on kernel diffs trying to target what to change. Disabling NFS Version 3 client will prevent this behavior from occurring. This means that the issue is most likely related to OSX's 64 bit NFS behavior, which could honestly be the culprit here. Do note that this behavior occurs regardless of the -32bitclients flag for OSX's NFS. I'm nominating this bug to be INVALID because of this. Interesting. If you have time, can I suggest that you write a summary of this and post it to the NFS mailing list? It's a good place for this problem and workaround to be archived, and may prompt the NFS developers to fix it if they regard it as a bug (generally kernel developers work towards maximum compatibility). Just send a mail to nfs@lists.sourceforge.net (no subscription necessary). |