Bug 77548 - umount hang during kernel rpm upgrade
umount hang during kernel rpm upgrade
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-08 15:57 EST by Need Real Name
Modified: 2007-04-18 12:48 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-11-08 15:57:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-11-08 15:57:07 EST
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 15:47:32 EST
Without reproduction, doesn't seem something that can be fixed.
Comment 2 Jeremy Sanders 2003-02-18 05:18:22 EST
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 05:20:49 EST
PS the umount eventually dies (took ~30 minutes here, but the time is variable).
Comment 4 István Tóth 2004-01-10 04:41:23 EST
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@localhost.localdomain)
(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

Note You need to log in before you can comment on or make changes to this bug.