I can replicate this readily on my home 8.0 box. It fails making the initrd
after kernel installation. I can generally trigger it just by making an initrd. 
Here's a bit of diagnostic info from the system exhibiting this:

Jan  7 23:29:16 localhost kernel: su            S 00000000     0  7966   7779 
7969               (NOTLB)
Jan  7 23:29:16 localhost kernel: Call Trace: [<c0125b52>] sys_rt_sigaction
[kernel] 0x82 (0xd587df64))
Jan  7 23:29:16 localhost kernel: [<c011e280>] sys_wait4 [kernel] 0x100
(0xd587df80))
Jan  7 23:29:16 localhost kernel: [<c0109117>] system_call [kernel] 0x33
(0xd587dfc0))
Jan  7 23:29:16 localhost kernel: 
Jan  7 23:29:16 localhost kernel: bash          S 00000000     0  7969   7966 
8010               (NOTLB)
Jan  7 23:29:16 localhost kernel: Call Trace: [<c011e280>] sys_wait4 [kernel]
0x100 (0xd188ff80))
Jan  7 23:29:16 localhost kernel: [<c0109117>] system_call [kernel] 0x33
(0xd188ffc0))
Jan  7 23:29:16 localhost kernel: 
Jan  7 23:29:16 localhost kernel: loop0         S 00000002     0  8191      1  
             7949 (L-TLB)
Jan  7 23:29:16 localhost kernel: Call Trace: [<c0107d31>] __down_interruptible
[kernel] 0x71 (0xd1985f84))
Jan  7 23:29:16 localhost kernel: [<c0107ddf>] __down_failed_interruptible
[kernel] 0x7 (0xd1985fac))
Jan  7 23:29:16 localhost kernel: [<e0ca8100>] .text.lock.loop [loop] 0x55
(0xd1985fb8))
Jan  7 23:29:16 localhost kernel: [<e0ca6bf0>] loop_thread [loop] 0x0 (0xd1985fc8))
Jan  7 23:29:16 localhost kernel: [<c010745e>] kernel_thread [kernel] 0x2e
(0xd1985ff0))
Jan  7 23:29:16 localhost kernel: [<e0ca6bf0>] loop_thread [loop] 0x0 (0xd1985ff8))
Jan  7 23:29:16 localhost kernel: 
Jan  7 23:29:16 localhost kernel: umount        R current      4  8237   8010  
                  (NOTLB)
Jan  7 23:29:16 localhost kernel: Call Trace: [<c0140fbe>] invalidate_bdev
[kernel] 0x5e (0xd028ff04))
Jan  7 23:29:16 localhost kernel: [<c014585b>] kill_bdev [kernel] 0x1b (0xd028ff38))
Jan  7 23:29:16 localhost kernel: [<c01466dd>] blkdev_put [kernel] 0xad
(0xd028ff4c))
Jan  7 23:29:16 localhost kernel: [<c01447aa>] remove_super [kernel] 0x6a
(0xd028ff68))
Jan  7 23:29:16 localhost kernel: [<c015762f>] sys_umount [kernel] 0x3f
(0xd028ff80))
Jan  7 23:29:16 localhost kernel: [<c01576a7>] sys_oldumount [kernel] 0x17
(0xd028ffb4))
Jan  7 23:29:16 localhost kernel: [<c0109117>] system_call [kernel] 0x33
(0xd028ffc0))
Jan  7 23:29:16 localhost kernel: 
<snip>
Jan  7 23:37:08 localhost kernel: SysRq : Show Regs
Jan  7 23:37:08 localhost kernel: 
Jan  7 23:37:08 localhost kernel: Pid: 8237, comm:               umount
Jan  7 23:37:08 localhost kernel: EIP: 0010:[<c0140fba>] CPU: 0
Jan  7 23:37:08 localhost kernel: EIP is at invalidate_bdev [kernel] 0x5a
(2.4.18-18.8.0)
Jan  7 23:37:08 localhost kernel:  EFLAGS: 00000206    Tainted: P 
Jan  7 23:37:08 localhost kernel: EAX: 00000700 EBX: caa02140 ECX: 00000001 EDX:
d028e000
Jan  7 23:37:08 localhost kernel: ESI: 0000429c EDI: caa021c0 EBP: 00000000 DS:
0018 ES: 0018
Jan  7 23:37:08 localhost kernel: CR0: 8005003b CR2: 40018000 CR3: 07901000 CR4:
000002d0
Jan  7 23:37:08 localhost kernel: Call Trace: [<c014585b>] kill_bdev [kernel]
0x1b (0xd028ff38))
Jan  7 23:37:08 localhost kernel: [<c01466dd>] blkdev_put [kernel] 0xad
(0xd028ff4c))
Jan  7 23:37:08 localhost kernel: [<c01447aa>] remove_super [kernel] 0x6a
(0xd028ff68))
Jan  7 23:37:08 localhost kernel: [<c015762f>] sys_umount [kernel] 0x3f
(0xd028ff80))
Jan  7 23:37:08 localhost kernel: [<c01576a7>] sys_oldumount [kernel] 0x17
(0xd028ffb4))
Jan  7 23:37:08 localhost kernel: [<c0109117>] system_call [kernel] 0x33
(0xd028ffc0))
Jan  7 23:37:08 localhost kernel: 


root      7966  0.0  0.1  3832 1012 pts/7    S    23:17   0:00 su -
root      7969  0.0  0.2  4212 1512 pts/7    S    23:17   0:00 -bash
root      8191  0.0  0.0     0    0 ?        SW   23:18   0:00 [loop0]
root      8237 87.8  0.0  3136  484 pts/7    R    23:18  13:09 umount
/tmp/initrd.mnt.qtKWbl
root      8244  0.0  0.1  3832 1012 pts/6    S    23:21   0:00 su -
root      8247  0.0  0.2  4212 1512 pts/6    S    23:21   0:00 -bash
root      8010  0.0  0.2  3896 1156 pts/7    S    23:18   0:00 /bin/bash
/sbin/mkinitrd initrd-2.4

I also get this on my home machine.

I'm also seeing this under Red Hat 7.3, but just on Dell PowerEdge 2550's.  I
have a number of Dell PowerEdge 4400's that I'm not seeing this on and I haven't
nailed down what the exact cause of the hang is.  The symptoms I'm seeing are
consistent with what you're reporting (hung loop0 and umount process).  All
other errata are applied on these boxes.

I'm seeing this on my system too (Xeon-2.4, gdth, mirrored ultra320 drives, 1G 
ram, running original 2.4.18-14 kernel).  To troubleshoot it, I 
modified /sbin/new-kernel-pkg to run mkinitrd under strace -
o /tmp/mkinitrd.out -f.  This caused all hell to break loose in mkinitrd:

VFS: Can't find ext2 filesystem on dev loop(7,0).
tune2fs: Bad magic number in super-block while trying to open /dev/loop0
Couldn't find valid filesystem superblock.
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       or too many mounted file systems
umount: /tmp/initrd.mnt.XpHPy0: not mounted

Adding a 'sync' after the 'dd if=/dev/zero of=$IMAGE' line in mkinitrd seems to 
help considerably, but tune2fs still pukes sometimes:

tune2fs: Bad magic number in super-block while trying to open /dev/loop0
Couldn't find valid filesystem superblock.

So it looks like it's doing the tune2fs before the mke2fs has completed.  
Adding a 'sleep 5' after the mke2fs appears to make it work reliably for me.

The work around Jon Lusky describes works for me too. Thanks Jon for sorting this out. 
Now we can upgrade the kernel of our Dell PE 1650's.

Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/