Bug 77548

Summary:	umount hang during kernel rpm upgrade
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <aander07>
Component:	util-linux	Assignee:	Elliot Lee <sopwith>
Status:	CLOSED WORKSFORME	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	jss
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:	2002-11-08 20:57:13 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 Need Real Name 2002-11-08 20:57:07 UTC

Description of Problem:

While /sbin/new-kernel-pkg was running in the %post of the kernel RPM,
umount hung, consuming 100% CPU time.  Top showed that the the CPU usage
was in system, strace to the process did not product any output, and gdb
only gave this:

(gdb) attach 19284
Attaching to program: /bin/umount, process 19284
ptrace: Operation not permitted.

Version-Release number of selected component (if applicable):

util-linux-2.11f-17.7.2
The machine was running a 2.4.18-17.7.x kernel at the time of installation.

How Reproducible:

I have only seen this once, and was not able to reproduce after rebooting.

Comment 1 Elliot Lee 2002-12-10 20:47:32 UTC

Without reproduction, doesn't seem something that can be fixed.

Comment 2 Jeremy Sanders 2003-02-18 10:18:22 UTC

I'm seeing this quite often on a particular machine. This one is hanging on
installing kernel-2.4.18-24.7.x.athlon.rpm 

Feb 18 10:09:50 xpc3 kernel: new-kernel-pk S DE6C0000     0 10428  10411 10431 
             (NOTLB)
Feb 18 10:09:50 xpc3 kernel: Call Trace: [<c011b531>] sys_wait4 [kernel] 0x371
(0xde6c1f8c))
Feb 18 10:09:50 xpc3 kernel: [<c0108933>] system_call [kernel] 0x33 (0xde6c1fc0))
Feb 18 10:09:50 xpc3 kernel: 
Feb 18 10:09:50 xpc3 kernel: mkinitrd      S EA6A2000     0 10431  10428 10651 
             (NOTLB)
Feb 18 10:09:50 xpc3 kernel: Call Trace: [<c011b531>] sys_wait4 [kernel] 0x371
(0xea6a3f8c))
Feb 18 10:09:50 xpc3 kernel: [<c0108933>] system_call [kernel] 0x33 (0xea6a3fc0))

Feb 18 10:09:50 xpc3 kernel: umount        R EF138000     0 10651  10431       
             (NOTLB)
Feb 18 10:09:50 xpc3 kernel: Call Trace: [<c013a80f>] invalidate_bdev [kernel]
0x8f (0xef139eec))
Feb 18 10:09:50 xpc3 kernel: [<c013e81d>] kill_bdev [kernel] 0xd (0xef139f20))
Feb 18 10:09:50 xpc3 kernel: [<c013f3d0>] blkdev_put [kernel] 0x50 (0xef139f30))
Feb 18 10:09:50 xpc3 kernel: [<c013da72>] remove_super [kernel] 0x62 (0xef139f44))
Feb 18 10:09:50 xpc3 kernel: [<c013e53a>] kill_super [kernel] 0xca (0xef139f54))
Feb 18 10:09:50 xpc3 kernel: [<c0141ff8>] path_release [kernel] 0x28 (0xef139f6c))
Feb 18 10:09:50 xpc3 kernel: [<c014e0d8>] sys_umount [kernel] 0x78 (0xef139f88))
Feb 18 10:09:50 xpc3 kernel: [<c01282d4>] sys_munmap [kernel] 0x34 (0xef139fa0))
Feb 18 10:09:50 xpc3 kernel: [<c014e0ec>] sys_oldumount [kernel] 0xc (0xef139fb4))
Feb 18 10:09:50 xpc3 kernel: [<c0108933>] system_call [kernel] 0x33 (0xef139fc0))

Feb 18 10:09:50 xpc3 kernel: loop0         S CB7CA000     0 10605      1       
        7442 (L-TLB)
Feb 18 10:09:50 xpc3 kernel: Call Trace: [<c010775d>] __down_interruptible
[kernel] 0x5d (0xcb7cbf90))
Feb 18 10:09:50 xpc3 kernel: [<c010780b>] __down_failed_interruptible [kernel]
0x7 (0xcb7cbfb4))
Feb 18 10:09:50 xpc3 kernel: [<fa43ac16>] .text.lock.loop [loop] 0x5f (0xcb7cbfc0))
Feb 18 10:09:50 xpc3 kernel: [<fa439ab0>] loop_thread [loop] 0x0 (0xcb7cbfc8))
Feb 18 10:09:50 xpc3 kernel: [<c0107146>] kernel_thread [kernel] 0x26 (0xcb7cbff0))
Feb 18 10:09:50 xpc3 kernel: [<fa439ab0>] loop_thread [loop] 0x0 (0xcb7cbff8))

At the time of installation 2.4.18-17.7.x was running on an athlon. I've seen
this on previous kernel versions a few times, but not on 24.7.x yet (I haven't
had the opportunity to upgrade that one!).

Comment 3 Jeremy Sanders 2003-02-18 10:20:49 UTC

PS the umount eventually dies (took ~30 minutes here, but the time is variable).

Comment 4 István Tóth 2004-01-10 09:41:23 UTC

I have the same problem in Fedora Core 1 when installing a recompiled
kernel
(2.4.22-1.2140.nptl), and issuing "make install"

CPU utilization goes to 100%, and stays there, but the system is
operational otherwise.

The umount process cannot be killed even with kill -9, only a reboot
makes it go away.

[root@localhost stoty]# cat /proc/version
Linux version 2.4.22-1.2135.nptlcustom (root)
(gcc version 3.2.3 20030422 (Red Hat Linux 3.2.3-6)) #3 Sat Jan 3
17:19:05 CET 2004

(this is the stock Fedora kernel, but recompiled to include the NTFS
driver)

[root@localhost stoty]# rpm -q util-linux
util-linux-2.11y-29

The output from make install:

warning: kernel is too big for standalone boot from floppy
sh -x ./install.sh 2.4.22-1.2140.nptlcustom bzImage
/usr/src/linux-2.4.22-1.2140.nptl/System.map ""
+ '[' -x /root/bin/installkernel ']'
+ '[' -x /sbin/installkernel ']'
+ exec /sbin/installkernel 2.4.22-1.2140.nptlcustom bzImage
/usr/src/linux-2.4.22-1.2140.nptl/System.map ''
-> the install hangs here


top output:
 10:39:45  up  1:37,  4 users,  load average: 3.49, 3.56, 3.48
86 processes: 83 sleeping, 3 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total    6.9%    0.0%   93.0%   0.0%     0.0%    0.0%    0.0%
Mem:   514656k av,  510292k used,    4364k free,       0k shrd,  
78996k buff
       252520k active,             190180k inactive
Swap: 1052216k av,   40232k used, 1011984k free                 
227520k cached
                                                                     
          
  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
14964 root      25   0   436  436   376 R    89.8  0.0   5:39   0 umount
 4119 root      15   0  119M  37M  5924 S     5.9  7.4  10:59   0 X