Bug 161446

Summary: uninterruptible sleep processes when copying from file-roller to nautilus
Product: Red Hat Enterprise Linux 4 Reporter: Marty Wesley <mwesley>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED DUPLICATE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-12 14:01:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marty Wesley 2005-06-23 14:35:24 UTC
+++ 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
Firefox/1.0.2 Fedora/1.0.2-1.3.1

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.

windows title:

"Copying files."

window content:

"Files copied: 43 of 100
Copying: a47
From: /tmp/fr-XzJiHU/a
To: /nfs/home/others/esjolund/nfscrash10
"
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):
nfs-utils-1.0.6-52

How reproducible:
Always

Steps to Reproduce:
1. login with kde
2. on the command line type: 
   mkdir ~/nfscrash10
3. on the command line type:
   nautilus ~/nfscrash10
4. on the command line type:
   file-roller /tmp/r/a.tar.gz 
 
  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.



Additional info:

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.

Comment 3 Steve Dickson 2005-07-27 12:20:13 UTC
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


Comment 9 RHEL Program Management 2006-08-18 17:37:56 UTC
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
release.

Comment 10 Steve Dickson 2006-09-12 14:01:08 UTC

*** This bug has been marked as a duplicate of 184549 ***