to my knowledge, the directory listings were fine -- just generating the
message. I'll ignore them for the time being.
| Not sure what this could be -- is it repeatable with certain files or random? Are
| all of the cases with one type of network card?
The network cards are different (one using the de4x5 driver (a Umax card I
believe) and one using the tulip driver (kingston card)).
Before I go into details, I should note that one of the problems I saw
yesterday (text log files being written (via NFS) would have whole sections
missing) is apparently a problem with sockets in 2.1.x (it works fine in
2.0.35), and not NFS (the same thing happens when writing the log file to a
local disk). I'll be poking around trying to narrow down what the problem is.
As for these 2 added/removed characters, here's the full situation as I know
it:
The Solaris box (server) is running ClearCase. We export one of the views via
NFS and mount it on the Linux box (this is standard to access views on hosts
not running ClearCase). Everything works fine, except for one file. This
file is generated "on the fly" (see below) via a Makefile and is corrupted
when using the 2.1.x series kernels. The commands that create the file are:
rm -rf Obj-linux/decomp_body
echo "/* This file is automatically generated, edits will be lost */" >
Obj-linux/decomp_body
echo "/* It is included in the case statement in chry_decomp.c
*/" >> Obj-linux/decomp_body
echo " " >> Obj-linux/decomp_body
sed -n '/--BEGIN_STAXI_E--/,/STAX_E/p' include/csd_level5.h | awk '/^[
]*stax/{print $1}' | sed -e 's/,//' -e 's/.*/CaseCodeToName( &, "&" );/' >>
Obj-linux/decomp_body
Here's the odd part. If I comment out the echos and just leave the sed part,
the file is created without any problem. If I leave any of the echos, I get
the corruption. If I take the above and change the output to any other
directory (NFS or not) on a different mount point, it works fine.
The reason I think this is Linux NFS related is because this file is good if
created locally on the Solaris box, or if it's created via NFS on a non-Linux
(or non-2.1.x kernel) box (SGI IRIX 5.4, and Linux 2.0.35 work fine). The
only system that doesn't work is a Linux box running 2.1.x. (and it works
sometimes (no echos) but not all the time).
| FWIW, I'm using 2.1.115 NFS every day in network-intensive operations with no
| problems.
yeah, that's the odd thing about this problem. I use 2.1.115 on my personal
workstation (home directory is via NFS), and I've had no issues, it's only
this one file/mount that has the problem.
BTW: I found another problem today:
lockd: failed to monitor 199.172.48.251
lockd: failed to monitor 199.172.48.251
lockd: failed to monitor 199.172.48.251
lockd: failed to monitor 199.172.48.251
lockd: failed to monitor 199.172.48.251
the other system in question is a Network Appliance dedicated NFS server.
Thanks for the quick response!
-- Randomly Generated Tagline: I'd love to, but I'm observing National Apathy Week.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html