Created attachment 340516 [details] /var/log/messages with comments on relevant actions Description of problem: WHen removing the ultrabay with hard drive without first unmounting the drive, I got a kernel call trace. Version-Release number of selected component (if applicable): rawhide as of 21 April 2009 How reproducible: unknown (happened when trying to investigate a lockup when removing ultrabay device) Steps to Reproduce: 1. Boot F11 on Thinkpad T60p with Ultrabay CD drive in 2. Remove Ultrabay, insert HDD bay, unmount, reinsert 3. Remove HDD ultrabay (without unmounting) Actual results: Kernel trace (see attached dump of /var/log/messages), but no lockup. Expected results: No trace. (I guess.) Additional info: Maybe this is expected behaviour?
This seems to be easily reproducible. I just got it again using the following sequence - boot with HDD Ultrabay in then eject without unmounting. Here is the call trace and associated messages: Apr 21 09:13:01 idefix kernel: ata5.00: disabled Apr 21 09:13:01 idefix kernel: ata5.00: detaching (SCSI 4:0:0:0) Apr 21 09:13:01 idefix kernel: ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR - undocking Apr 21 09:13:01 idefix kernel: sd 4:0:0:0: [sdb] Synchronizing SCSI cache Apr 21 09:13:01 idefix kernel: sd 4:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK Apr 21 09:13:01 idefix kernel: sd 4:0:0:0: [sdb] Stopping disk Apr 21 09:13:01 idefix kernel: sd 4:0:0:0: [sdb] START_STOP FAILED Apr 21 09:13:01 idefix kernel: sd 4:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK Apr 21 09:13:01 idefix kernel: ------------[ cut here ]------------ Apr 21 09:13:01 idefix kernel: WARNING: at fs/buffer.c:1247 mark_buffer_dirty+0x2a/0x76() (Not tainted) Apr 21 09:13:01 idefix kernel: Hardware name: Apr 21 09:13:01 idefix kernel: Modules linked in: ext2 fuse bridge stp llc bnep sco l2cap bluetooth autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput thinkpad_acpi arc4 hwmon snd_hda_codec_analog ecb snd_hda_intel snd_hda_codec snd_hwdep iwl3945 iTCO_wdt snd_pcm mac80211 snd_timer pcspkr i2c_i801 joydev iTCO_vendor_support snd nsc_ircc soundcore lib80211 yenta_socket irda video snd_page_alloc rsrc_nonstatic e1000e cfg80211 crc_ccitt output radeon drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] Apr 21 09:13:01 idefix kernel: Pid: 2904, comm: umount Not tainted 2.6.29.1-100.fc11.i586 #1 Apr 21 09:13:01 idefix kernel: Call Trace: Apr 21 09:13:01 idefix kernel: [<c042f342>] warn_slowpath+0x7c/0xa4 Apr 21 09:13:01 idefix kernel: [<c0478fdb>] ? find_get_pages+0x2d/0x88 Apr 21 09:13:01 idefix kernel: [<c047fec4>] ? pagevec_lookup+0x1b/0x22 Apr 21 09:13:01 idefix kernel: [<c0480e85>] ? truncate_inode_pages_range+0x1cd/0x26c Apr 21 09:13:01 idefix kernel: [<c0499767>] ? add_partial+0x3b/0x41 Apr 21 09:13:01 idefix kernel: [<c049acec>] ? __slab_free+0x62/0x21b Apr 21 09:13:01 idefix kernel: [<c049b0fb>] ? kmem_cache_free+0x86/0xbf Apr 21 09:13:01 idefix kernel: [<c053597b>] ? selinux_inode_free_security+0x5b/0x60 Apr 21 09:13:01 idefix kernel: [<c04cdbd3>] ? __mb_cache_entry_forget+0x49/0x54 Apr 21 09:13:01 idefix kernel: [<c04cdbd3>] ? __mb_cache_entry_forget+0x49/0x54 Apr 21 09:13:01 idefix kernel: [<c04bb054>] mark_buffer_dirty+0x2a/0x76 Apr 21 09:13:01 idefix kernel: [<f89552c2>] ext2_sync_super+0x36/0x4c [ext2] Apr 21 09:13:01 idefix kernel: [<f89559ef>] ext2_put_super+0x32/0xa6 [ext2] Apr 21 09:13:01 idefix kernel: [<c04a28b4>] generic_shutdown_super+0x62/0xca Apr 21 09:13:01 idefix kernel: [<c04a293e>] kill_block_super+0x22/0x36 Apr 21 09:13:01 idefix kernel: [<c04d0dba>] ? vfs_quota_off+0x0/0x17 Apr 21 09:13:01 idefix kernel: [<c04a2a05>] deactivate_super+0x57/0x6a Apr 21 09:13:01 idefix kernel: [<c04b2ba6>] mntput_no_expire+0xd8/0x106 Apr 21 09:13:01 idefix kernel: [<c04b3090>] sys_umount+0x288/0x2ad Apr 21 09:13:01 idefix kernel: [<c0403ff2>] syscall_call+0x7/0xb Apr 21 09:13:01 idefix kernel: ---[ end trace b97fe21eae04d999 ]---
I don't think that can be fixed. The system is attempting to unmount the drive but it's already gone.
(In reply to comment #1) > This seems to be easily reproducible. I just got it again using the following > sequence - boot with HDD Ultrabay in then eject without unmounting. Bye "eject" do you mean physically removing the drive or just pushing the button to prepare for ejection?
This is a hard eject. I first clicked the slide which pops out the removal tab (but appears to do nothing useful with respect to mounting) and then physically removed the bay and its drive (without unmounting beforehand). There is no button push. This is not a CD bay, it is a special Ultrabay hard drive holder. It may well indeed be that the trace is simply saying that the kernel is trying to write to the device but that it can't. I reported the trace because it is in F11 beta and I hadn't experienced it before. Of course, I hadn't tried to do this before now, as I didn't have this hardware before now. On a related note, I would be very happy to find out how to hook the slide click to something that tries to do a graceful unmount. I see that udev events are generated, but it appears that nothing is listening to them. I posted a query on Fedora forum on how to do this, but haven't seen any response yet. I don't even know what should be used to do this - ACPI, udev, HAL, DeviceKit?
I agree that this is just the kernel doing the best that it can, and the trace is actually a good thing, so I'm closing this as not a bug. Of course, getting bay eject to work right would be best, but that is a different story.