http://bugzilla.suse.com/show_bug.cgi?id=1095821
http://bugzilla.suse.com/show_bug.cgi?id=1095821#c9
--- Comment #9 from Neil Brown ---
(In reply to Ruediger Meier from comment #5)
Created attachment 772969 [details]
strace, firefox on NFS using 4.4.132-53-default
The freeze happened between 13:51:50 and 13:52:27 (I guess my visually
stopped times may be inexact about +-5 seconds at least).
(sorry I haven't had much time for this).
Whenever there are problems with firefox and NFS, it is almost always related
to locking.
So I grepped for 'fcntl()' in the strace, and looked at the times you
mentioned.
7345 13:51:39.904059 fcntl(40, F_SETLK, {type=F_UNLCK, whence=SEEK_SET,
start=124, len=1}
....
7345 13:52:23.104823 <... fcntl resumed> ) = 0
So that unlock request took over 40 seconds, and is almost exactly the time
range you reported.
Unlock requests shouldn't take more than a few milliseconds.
Network packet loss could cause a delay like this, but seems unlikely as other
threads are still doing locking and unlocking, and tcp is normally resilient to
some packet loss.
What would help most is kernel stack traces while the hang happens.
As netscape has so many thread it would be error-prone to try to get
/proc/$PID/stack for each for them.
Instead, try
echo t > /proc/sysrq-trigger
while the hang is happening, then collect the output of "dmesg"
dmesg > /tmp/somefile
Hopefully the stack traces won't be too big to overflow the kernel message
buffer.
--
You are receiving this mail because:
You are on the CC list for the bug.