Re: sata suspend resume ...

[Hugh Dickins <hugh@veritas.com>]

On Wed, 19 Apr 2006, Matt Mackall wrote:
> On Wed, Apr 19, 2006 at 05:13:27PM +0100, Hugh Dickins wrote:
> > On Wed, 19 Apr 2006, Jeff Chua wrote:
> > > 
> > > System suspends ok. Resume ok. but no disk access after that.
> > 
> > Not the same disk model, but I've been having similar trouble on a T43p.

I should have mentioned before, it's suspend to RAM I'm using, by the way.

> > I was delighted to see the MSI suspend/resume fix go into 2.6.17-rc2,
> > but then disappointed.  A bisection found that Matt Mackall's sensible
> > rc1 patch, to speed up get_cmos_time, has removed what often used to be
> > a 2 second delay in resuming: things work well when I reinstate that
> > delay (1 second has proved not enough).  Below is the patch I'm using -
> > where I've failed to resist mucking around to avoid those double calls
> > to get_cmos_time, sorry: really it's just mdelay(2000) needed somewhere
> > (until someone who knows puts in something more scientific).
> 
> That's interesting.
> 
> Just to be clear, with my changes we should never fire timers early.

Yes, the only reservation I have about your patch, entirely unrelated to
this resume issue, is that those systems which "hwclock -w" on shutdown
(do they on suspend too? haven't looked) will slowly tend to lose time.

> Is the problem that we have a timer that didn't get deleted at suspend
> time?

I don't think so, but I don't really know.  On resume, the disk
goes into ata_exec_internal's 30 second timeout which ends with
"ata1: qc timeout (cmd 0xef)": nothing wrong with that timeout, anyway.

I tend to assume that it's not anything subtle, just that something
there needs a delay which it accidentally happened to get (most of
the time) from the CMOS reading, and with that gone now falls over.

I'd be able to test patches from anyone who knows what they're
doing SATA-wise, but probably not until Friday.

Hugh