Ok... we'll start with the process table...
monica# ps axl | grep D
UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND
0 0 0 0 -18 0 00 sched DLs ??0:00.81 (swapper)
0 2 0 0 -18 0 00 psleep DL??1:10.93 (pagedae
Ah!... ok, it is an NFS bug. I've been trying to track this down
for a while ever since you reported the 3.4 lockup bug. This is probably
related to a similar problem.
There is a bug somewhere related to NFS locking up while doing a
pagein from the executable image. It ca
> Ah!... ok, it is an NFS bug. I've been trying to track this down
> for a while ever since you reported the 3.4 lockup bug. This is probably
> related to a similar problem.
>
> There is a bug somewhere related to NFS locking up while doing a
> pagein from the executable im
I just ran a tcpdump -s1500 for 5 minutes, gathered ~21k of data over that
time, no mentions of stale NFS handles from the NFS server... it would
appear the NFS client is not asking for those pages (it makes sense, since if
it asked and got the 'stale' error one would expect the SEGV).
--
David
Ok, I've reproduced the NFS problem:
server> cp /usr/bin/vi vi1
client> ./vi1
server> echo > vi1
client> (try to do somtehing in vi, like 'o')
I'm tracking it down now. I should be able to work up a fix quickly
and get an approved commit in for 4.0.
(Reply-To se
Hmm... would this address the specific instances of our problems as well?
The two problems that we saw were a hard-locked machine, and the emacs
process in forever disk-wait. The emacs binary would never have been in a
position to be truncated or modified at all when this problem happened.
--
Da
:Hmm... would this address the specific instances of our problems as well?
:The two problems that we saw were a hard-locked machine, and the emacs
:process in forever disk-wait. The emacs binary would never have been in a
:position to be truncated or modified at all when this problem happened.
:
7 matches
Mail list logo
