Messages in this thread | | | Date | Wed, 19 Apr 2006 17:57:59 -0500 | From | Matt Mackall <> | Subject | Re: sata suspend resume ... |
| |
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/
| |