Bugzilla – Bug 99589
hald-addon-storage hangs in ide_do_drive_cmd after wakeup
Last modified: 2006-09-28 13:26:24 UTC
When the iBook wakes up from suspend to RAM the hald-addon-storage hangs in ide_do_drive_cmd, and subsequently other processes will hang there or in other parts of the kernel (mostly filesystem).
add 'echo t > /proc/sysrq-trigger ; dmesg ' output
Created attachment 44217 [details] sysrq-t output
I see '*cdrom*' in the backtrace so I pass it on to Jens. I assume that is current 2.6.13-rc4+?
It's (almost) vanilla 2.6.13-rc4.
Andreas, how long did you wait? Just curious what happened when the commands timed out. What kernel exactly are you running? Is this a regression or did you never test suspend/resume on this laptop before? IOW, please fill out some more details about this :)
I didn't see any timeout happening, not even after several minutes. See comment #4 for the exact kernel. It only happens when hald is running, nothing else is ever running in this kind of lockup. Other than that suspend to ram is working almost perfectly. How can I know what details do you need???
Is this a regression? Could you strace hald and see exactly what it is up to at this point? Probably that wont get us the actual command, but at least it should help... Also, "(almost) vanilla 2.6.13-rc4" isn't exactly an exact kernel version. It seems to me that both the cdrom and hard drive are hanging waiting for response, not just the cdrom.
It happens exactly since hal exists. Nothing else has this problem. For the purpose of this bug this is exactly vanilla 2.6.13-rc4.
hald-addon-storage does nothing else but open /dev/hdb.
So if you disable cdrom checking, it works fine for hda? What do you mean it happens since hal exists? What did you run on this ibook before? Please just explain if this is a regression or not wrt the kernel, this is now my 3rd time asking. Even if you can't be bothered to say what patches are applied (I can't count the number of times people have told me exactly this. You are probably right, but I always like to double check).
How do you disable cdrom checking? hal didn't exist in SLES9. How can I know whether this is a regression? SLES9 surely didn't have this problem.
Olaf should know all about hal and this sort of thing, Olaf, see comment #11, how can Andreas easiest test that?
I dont know how to disable hal stuff, Danny may know.
I never tried this, but I think you must comment out the related code and comile a new HAL package.
Huh, is this a joke? Surely there must be some way to tell hald to stay away from a device?
you can also try this: add to: /usr/share/fdi/policy/10osvendor/10-storage-policy.fdi behind this block: !-- Handle drives with non-partitioned media --> <match key="storage.no_partitions_hint" bool="true"> <!-- optical drives --> <match key="storage.drive_type" string="cdrom"> <merge key="storage.policy.mount_filesystem" type="string">auto</merge> the line: mergematch key="storage.media_check_enabled" type="bool">false</merge> and restart hal
Disabling cdrom polling makes wakeup work again, but of course this is just a workaround since the file will be overwritten on each update.
can you try plain 2.6.12?
Same bug.
I did a fresh isntall and suspend to ram (closing the lid) works ok for me.
On what system?
300MHz ibook1.
Try a more recent one.
try with kernel-default and load ide-cd. or attach the used .config of your custom kernel.
I'm not stupid, your prachtkernel has exactly the same bug, as expected.
Does it still happen with beta4? Does it also happen if no cd is in the cd-rom drive? I see a similar problem on i386 with beta4: suspend-to-disk hangs while suspending IFF I have a data cd in my cd-rom drive. Since suspend-to-disk does suspend all devices and then resume the disk to write out the image during suspend, the pattern looks similar.
2.6.13 is still broken.
Maybe related to bug 115095.
It seems hald accesses the cdrom drive every two seconds. If the drive gets opened/closed/activated/deactivated, hald will hang in state D until the cdrom drive responds. So if the cdrom does not respond after resume, hald will hang and with it everything else accessing the disks. It may be hard to reproduce for some people because we are talking about a race condition with hald here.
*** Bug 120344 has been marked as a duplicate of this bug. ***
http://marc.theaimsgroup.com/?l=linux-kernel&m=112856076700240&w=2
Yeah, it looks like the case that benh diagnosed. We just need to find an appropriate solution.
Ben's workaround is working for me.
This patch is now in 2.6.14-rc4.
Lets just stick with it for the SL10 base at least, I've added the patch.