Bug 103005

Description of problem:
Occasionally mount will get stuck in the "D" state (uninterruptable sleep), and 
there is no way to kill the process. Starting other "mount" or "eject" processes 
referring to the same device will cause these to processes to hang, also. The 
only way out is to reboot.

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

How reproducible:
I haven't tried to reproduce this problem with the same media, but I've seen 
this behavior before and I know it's a long standing problem.

Steps to Reproduce:
1. I bought a new printer today (HP Photosmart 7350). I stuck the Macintosh 
drivers CD into my drive and tried to mount as "vfat" ("hpfs" had already 
failed). My device was an IDE CD-ROM drive controlled with SCSI emulation.
2. mount got stuck in the "D" state. Couldn't kill it.
3. I started other shells and ran both "eject" and "umount" for the same device, 
but these processes also hung in the "D" state.
    
Actual results:
All mount, umount, and eject processes for my CD-ROM drive are hung. The kernel 
created approximately 100 new processes for some reason.

Expected results:
mount should recognize that it either could or could not mount the media and 
eventually stop trying.

Additional info:
I found the following in my kernel message log:

Aug 24 15:49:29 localhost kernel: Unable to identify CD-ROM format.
Aug 24 15:54:38 localhost modprobe: modprobe: Can't locate module hpfs
Aug 24 15:54:38 localhost modprobe: modprobe: Can't locate module freehpfs
Aug 24 15:55:20 localhost kernel: ------------[ cut here ]------------
Aug 24 15:55:20 localhost kernel: kernel BUG at buffer.c:2618!
Aug 24 15:55:20 localhost kernel: invalid operand: 0000
Aug 24 15:55:20 localhost kernel: hfs nls_iso8859-1 printer snd-pcm-oss 
snd-mixer-oss ppp_synctty ppp_async ppp_generic slhc radeon agpgart via686a 
eeprom lm80
i2c-proc i2c-isa i2c-viapro i2c-
Aug 24 15:55:20 localhost kernel: CPU:    0
Aug 24 15:55:20 localhost kernel: EIP:    0060:[<c014bb39>]    Not tainted
Aug 24 15:55:20 localhost kernel: EFLAGS: 00210206
Aug 24 15:55:20 localhost kernel:
Aug 24 15:55:20 localhost kernel: EIP is at grow_buffers [kernel] 0x39 (2.4.
20-19.9)
Aug 24 15:55:20 localhost kernel: eax: 000007ff   ebx: 00000b01   ecx: 00000800
  edx: dfe2d580
Aug 24 15:55:20 localhost kernel: esi: 00000b01   edi: 00000200   ebp: 00000b01
  esp: c50b5d94
Aug 24 15:55:20 localhost kernel: ds: 0068   es: 0068   ss: 0068
Aug 24 15:55:20 localhost kernel: Process mount (pid: 7381, stackpage=c50b5000)
Aug 24 15:55:20 localhost kernel: Stack: e2e3bf11 c5296000 e2e3f19e 00000044 
00000000 00000b01 00000200 00000002
Aug 24 15:55:20 localhost kernel:        c01494d6 00000b01 00000002 00000200 
c50b4000 00000000 00000001 d964ac00
Aug 24 15:55:20 localhost kernel:        00000002 c0149740 00000b01 00000002 
00000200 00000005 e2e3ca2a 00000b01
Aug 24 15:55:20 localhost kernel: Call Trace:   [<e2e3bf11>] parse_options [hfs] 
0xc1 (0xc50b5d94))
Aug 24 15:55:20 localhost kernel: [<e2e3f19e>] .rodata.str1.1 [hfs] 0x12a 
(0xc50b5d9c))
Aug 24 15:55:20 localhost kernel: [<c01494d6>] getblk [kernel] 0x46 (0xc50b5db4)
)
Aug 24 15:55:20 localhost kernel: [<c0149740>] bread [kernel] 0x20 (0xc50b5dd8))
Aug 24 15:55:20 localhost kernel: [<e2e3ca2a>] hfs_buffer_get [hfs] 0x3a 
(0xc50b5dec))
Aug 24 15:55:20 localhost kernel: [<e2e3b0e9>] hfs_mdb_get [hfs] 0x99 
(0xc50b5e0c))
Aug 24 15:55:20 localhost kernel: [<e08b60c1>] scsi_ioctl_R4cb00872 [scsi_mod] 0
x101 (0xc50b5e34))
Aug 24 15:55:20 localhost kernel: [<e2e3c7b5>] hfs_read_super [hfs] 0x85 
(0xc50b5e50))
Aug 24 15:55:20 localhost kernel: [<e08d217b>] sr_media_change [sr_mod] 0x5b 
(0xc50b5e64))
Aug 24 15:55:20 localhost kernel: [<e089eee0>] media_changed [cdrom] 0x60 
(0xc50b5e7c))
Aug 24 15:55:20 localhost kernel: [<c014c72a>] alloc_super [kernel] 0x3a 
(0xc50b5e90))
Aug 24 15:55:20 localhost kernel: [<c014e548>] check_disk_change [kernel] 0x48 
(0xc50b5ea0))
Aug 24 15:55:20 localhost kernel: [<c014d1b3>] get_sb_bdev [kernel] 0x1a3 
(0xc50b5eb4))
Aug 24 15:55:20 localhost kernel: [<e2e42270>] hfs_fs [hfs] 0x0 (0xc50b5ef8))
Aug 24 15:55:20 localhost kernel: [<c014d521>] do_kern_mount [kernel] 0x121 
(0xc50b5f00))
Aug 24 15:55:20 localhost kernel: [<e2e42270>] hfs_fs [hfs] 0x0 (0xc50b5f04))
Aug 24 15:55:20 localhost kernel: [<c0161003>] do_add_mount [kernel] 0x93 
(0xc50b5f24))
Aug 24 15:55:20 localhost kernel: [<c0161330>] do_mount [kernel] 0x160 
(0xc50b5f44))
Aug 24 15:55:20 localhost kernel: [<c0161179>] copy_mount_options [kernel] 0x79
(0xc50b5f74))
Aug 24 15:55:20 localhost kernel: [<c0161751>] sys_mount [kernel] 0xb1 
(0xc50b5f94))
Aug 24 15:55:20 localhost kernel: [<c010953f>] system_call [kernel] 0x33 
(0xc50b5fc0))
Aug 24 15:55:20 localhost kernel:
Aug 24 15:55:20 localhost kernel:
Aug 24 15:55:20 localhost kernel: Code: 0f 0b 3a 0a d7 27 26 c0 8d 87 00 fe ff 
ff 3d 00 0e 00 00 76


Also, lsmod shows the following:
  Module                  Size  Used by    Not tainted
  vfat                   13004   1  (autoclean)
  fat                    38808   0  (autoclean) [vfat]
  hfs                    91168   2  (autoclean)

Yet the hfs mount failed and I do not have any mounted hfs devices -- so what is 
the hfs module used by? rmmod reports that this module is busy. Same with the 
vfat module: it's not used by anything, but I can't unload it.