Bug 99589

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.