Re: sata suspend resume ...

[Matt Mackall <mpm@selenic.com>]

On Wed, Apr 19, 2006 at 11:50:55PM +0100, Hugh Dickins wrote:
> 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.

If they weren't already using NTP, they were losing time anyway.
 
> > 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.

I'm puzzled by 1 second not being enough. The former code should have
taken between 1+e and 2 seconds, so I'd think mdelay(1000) would work.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/