Hi,
I think you're right Stefan, this is very possibly a hard disk timeout
issue because even after suspend wakes up I can run a few commands,
even accessing the hard disk, but then after another few seconds if I
try to access the hard-disk the command will block (the machine does
not freeze, just that particular command blocks) for another minute or
so and then finally comes back to life. This happens only on s2ram
not when I suspend to disk. The very strange thing is that it
sometimes takes a few seconds for it to happen. Right when I come
back form suspend I try an 'ls' and it works but if I keep doing it
for a few times then eventually it will hang at some point and I'll
have to wait for the disk to spin up (which I can sometimes here).
This is pretty consistent but there are times when I haven't noticed
it happen.
I've switched back to my old kernel right now (stock SUSE 10.1 -
2.6.16) so I don't have data from the newest kernel (though this
happened on that kernel as well) but here's what I get in dmesg after
this happens:
hda: dma_timer_expiry: dma status == 0x21
hda: DMA timeout error
hda: dma timeout error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hda: status error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE
hda: status error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE
SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC= SRC=192.168.1.35
DST=224.0.0.251 LEN=107 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP
SPT=5353 DPT=5353 LEN=87
hda: lost interrupt
hda: status error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE
hda: status error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE
ide0: reset: success
Any idea how/why this happens and if it can be worked around? Do I
need to change an hdparm setting?
Thanks,
Sheer
On 8/9/06, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 09, 2006 at 11:30:50AM +0200, Sheer El-Showk wrote:
> > Hi Guys,
> >
> > Again, thanks for all the input. Stefan my machine is new. I bought it less
> > than two years ago and it was a very expensive laptop ;-> Its a Sony A190
> > (the ones with the giant screens that are completely unportable) and in
> > Windows resume is pretty fast (its been a while since i tested it but it was
> > < 5 secs I'd say). I'll check later but I also think windows doesn't
> > consume battery nearly as quickly when suspending to ram (this is probably
> > the issue Pavel brought up so I'll try and look into it).
>
> Ok.
>
> > When I wake the machine from a suspend the console comes back up instantly
> > telling me that its "Restarting tasks" but then it sits there for about 30
> > seconds (I've timed it many times and its pretty consistent) before finally
>
> This is strange. It sounds more like suspend to disk usually behaves.
> Pavel, could this be a harddisk timeout issue?
>
> > going to X. I've gone through the logs to try and find out where its
> > spending the time but the log times don't seem reliable to me because I
> > think suspend messages from before and after suspending often get mixed into
> > the log. In any case its not clear to me from the log whether the messages
> > are tasks being restarted after X is already up (such as dhcp, etc...) or
> > while I still see the console. I also modified the 'restore_after_sleep'
> > function in /usr/lib/powersave/scripts to print out the time before each
> > message but it seems like all the things happening in that script happen
> > almost instantaneously. It gets called from restore_after_suspend_to_ram
> > which basically doesn't do anything else.
> >
> > I don't really know how powersave is setup but I presume if I just call
> > s2ram manually from the console that this does not run any scripts or
> > anything on resume right? But when I try s2ram manually it still takes ~30
> > seconds to get me back to X windows. I see the console immediately but it
> > just sits there saying 'Restarting tasks' so it seems to me like whatever is
> > happening is happening in the kernel.
>
> even the powersaved scripts should not take this long :-)
>
> Change to a text console (ctrl-alt-f1), log in as root and suspend with
> "powersave -u", if it gets back on you immediately in this case, try issuing
> "find /" to check if the harddisk is already working. If it is, this is
> most likely a problem with the X server. Then manually switching back to
> X (alt-f7) should take equally long like resuming does now.
> --
> Stefan Seyfried | "Please, just tell people
> QA / R&D Team Mobile Devices | to use KDE."
> SUSE LINUX Products GmbH, Nürnberg | -- Linus Torvalds
>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel
