From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751315AbWDSXAq (ORCPT ); Wed, 19 Apr 2006 19:00:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751317AbWDSXAq (ORCPT ); Wed, 19 Apr 2006 19:00:46 -0400 Received: from waste.org ([64.81.244.121]:8356 "EHLO waste.org") by vger.kernel.org with ESMTP id S1751315AbWDSXAp (ORCPT ); Wed, 19 Apr 2006 19:00:45 -0400 Date: Wed, 19 Apr 2006 17:57:59 -0500 From: Matt Mackall To: Hugh Dickins Cc: Jeff Chua , Jeff Garzik , Jens Axboe , Linux Kernel Subject: Re: sata suspend resume ... Message-ID: <20060419225759.GV15445@waste.org> References: <20060419214959.GR15445@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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.