Re: 2.6.22-rc3 hibernate(?) fails totally - regression

From: Tejun Heo <htejun@gmail.com>
To: David Greaves <david@dgreaves.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	xfs@oss.sgi.com,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	netdev@oss.sgi.com, linux-pm <linux-pm@lists.osdl.org>,
	Neil Brown <neilb@suse.de>
Subject: Re: 2.6.22-rc3 hibernate(?) fails totally - regression
Date: Wed, 06 Jun 2007 17:33:36 +0900	[thread overview]
Message-ID: <46667160.80905@gmail.com> (raw)
In-Reply-To: <4662D852.4000005@dgreaves.com>

Hello,

David Greaves wrote:
> Linus Torvalds wrote:
>> It would be interesting to see what triggered it, since it apparently 
>> worked before. So yes, a bisection would be great.
> 
> Tejun, all the problematic patches are yours - so adding you.

Ouch....

> given the first patch identified is
> 9666f4009c22f6520ac3fb8a19c9e32ab973e828: "libata: reimplement suspend/resume
> support using sdev->manage_start_stop"
> That seems a good candidate...

9ce3075c20d458040138690edfdf6446664ec3ee works, right?  Can you test
9666f4009c22f6520ac3fb8a19c9e32ab973e828 by removing
ata_scsi_device_suspend/resume callbacks from sata_via.c?  Just delete
all lines referencing those two functions.  There were one or two
fallouts from the conversion.

How many drives do you have?  Behavior difference introduced by the
reimplementation is serialization of resume sequence, so it takes more
time.  My test machine had problems resuming if resume took too long
even with the previous implementation.  It didn't matter whether the
long resuming sequence is caused by too many controllers or explicit
ssleep().  If time needed for resume sequence is over certain threshold,
machine hangs while resuming.  I thought it was a BIOS glitch and didn't
dig into it but you might be seeing the same issue.

Please post dmesg too.  Thanks.

-- 
tejun