Bug 496849 - kernel call trace when removing ultrabay hard drive from Lenovo T60p under F11
kernel call trace when removing ultrabay hard drive from Lenovo T60p under F11
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-21 09:04 EDT by Peter F. Patel-Schneider
Modified: 2009-05-18 19:44 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 19:44:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages with comments on relevant actions (76.34 KB, text/plain)
2009-04-21 09:04 EDT, Peter F. Patel-Schneider
no flags Details

  None (edit)
Description Peter F. Patel-Schneider 2009-04-21 09:04:47 EDT
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?
Comment 1 Peter F. Patel-Schneider 2009-04-21 09:17:42 EDT
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 ]---
Comment 2 Chuck Ebbert 2009-04-22 09:14:02 EDT
I don't think that can be fixed. The system is attempting to unmount the drive but it's already gone.
Comment 3 Chuck Ebbert 2009-04-23 09:36:09 EDT
(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?
Comment 4 Peter F. Patel-Schneider 2009-04-23 19:35:52 EDT
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?
Comment 5 Peter F. Patel-Schneider 2009-05-18 19:44:06 EDT
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.

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