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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
