+++ This bug was initially created as a clone of Bug #155021 +++
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323
Description of problem:
An up to date Fedora Core 3 machine mounts my home directory from a
NFSv4-server. When "draging and drop"-copying 100 files at the same time from a
file /tmp/r/a.tar.gz opened in file-roller to a nfs-directory ~/nfscrash10
opened in nautilus, the copying stops after about half of the files showing a
pop-up window with a progress bar.
"Files copied: 43 of 100
and there is a cancel push-button.
Pressing cancel just makes the window not being repainted.
Any process accesing my nfs home directory hangs from now on. For instance
typing "ls ~" on the command line will just leave the ls-process hanging.
Executing the command "ps auxw", I found out that many of the processes with my
uid are in the "D"-state ( uninterruptible sleep ).
The only way to get out of the situation tend to be to reboot the machine.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. login with kde
2. on the command line type:
3. on the command line type:
4. on the command line type:
You now see that file-roller expands the a.tar.gz file. File-roller
will show you the directory "a" which resides in a.tar.gz.
5. open the directory "a" in file-roller. Now the 100 files from a.tar.gz is
visible in file-roller.
6. ctrl-a (select all)
7. press left mouse button and drag the files to the nautilus window.
8. release left mouse button
A pop up window shows you the progress of the copying. After copying about
half of the files, the copying seems to stop.
9. Because nothing seems to happen I press cancel in the pop up window.
Actual Results: Processes accessing nfs home directory now hangs. Some
processes are in the
"D" running state ( uninterruptible sleep ).
Expected Results: Processes should not hang.
Oxygen is the hostname of my machine ( the nfs client ).
[esjolund@oxygen ~]$ grep nfs /etc/auto.nfs
home -rw,fstype=nfs4,hard,intr,nosuid,tcp nfs.sbc.su.se:/home
[esjolund@oxygen ~]$ uname -a
Linux oxygen 2.6.11-1.14_FC3 #1 Thu Apr 7 19:23:49 EDT 2005 i686 i686 i386 GNU/Linux
I also did
echo t > /proc/sysrq-trigger
The resulting log from /var/log/messages will be attached to the bug report.
It appears we are not recovering from NFS4ERR_DELAY errors.
This will need more investigation...
PID: 10093 TASK: f3695110 CPU: 0 COMMAND: "nautilus"
#0 [f5ebad44] schedule at c02e2fcd
#1 [f5ebada0] schedule_timeout at c02e3bfa
#2 [f5ebaddc] nfs4_delay at f8b781b4
#3 [f5ebadf8] nfs4_handle_exception at f8b782a7
#4 [f5ebae04] nfs4_do_setattr at f8b7609d
#5 [f5ebae20] nfs4_proc_setattr at f8b768f3
#6 [f5ebae48] nfs_setattr at f8b67f1a
#7 [f5ebaef0] notify_change at c0173b9c
#8 [f5ebaf10] chown_common at c015adf0
#9 [f5ebaf64] sys_chown at c015ae48
#10 [f5ebafc0] system_call at c02e5554
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
*** This bug has been marked as a duplicate of 184549 ***