Re: SATA suspend-to-ram patch - merge?

Re: SATA suspend-to-ram patch - merge?

[Jeff Garzik]

Joshua Kwan wrote:
> Is Jens' patch still relevant? If so, should it be rediffed and merged
> into mainline? It doesn't seem to cause any weird side-effects.
> 
> More importantly, I would be inclined to properly rediff Jens' patch and
> merge it into Debian 2.6.12 kernel sources if there aren't any such
> side-effects, since it benefits everyone using SATA and suspend-to-ram
> (that is, users of relatively modern laptops.)

Jens' patch is technical correct for SATA, but really we want to do more 
stuff at the SCSI layer (see James Bottomley's response to Jens' patch).

Unfortunately, this also implies that we have to figure out which SCSI 
devices are available to be power-managed, and which SCSI devices are on 
a shared bus that should never be suspended.

So currently we are in limbo...

	Jeff

Re: SATA suspend-to-ram patch - merge?

[Jens Axboe]

On Wed, Sep 21 2005, Jeff Garzik wrote:
> Joshua Kwan wrote:
> >Is Jens' patch still relevant? If so, should it be rediffed and merged
> >into mainline? It doesn't seem to cause any weird side-effects.
> >
> >More importantly, I would be inclined to properly rediff Jens' patch and
> >merge it into Debian 2.6.12 kernel sources if there aren't any such
> >side-effects, since it benefits everyone using SATA and suspend-to-ram
> >(that is, users of relatively modern laptops.)
> 
> Jens' patch is technical correct for SATA, but really we want to do more 
> stuff at the SCSI layer (see James Bottomley's response to Jens' patch).
> 
> Unfortunately, this also implies that we have to figure out which SCSI 
> devices are available to be power-managed, and which SCSI devices are on 
> a shared bus that should never be suspended.
> 
> So currently we are in limbo...

Which is a shame, since it means that software suspend on sata is
basically impossible :)

-- 
Jens Axboe

Re: SATA suspend-to-ram patch - merge?

[Mark Lord]

>>So currently we are in limbo...
> 
> Which is a shame, since it means that software suspend on sata is
> basically impossible :)

Except that it actually does work, with Jen's patch.

Rather than sitting around for another six months hoping the problem
will go away (it won't), perhaps we should just update/merge Jen's
patch as a sorely needed interim fix.

This might then prod James et al into looking more at the SCSI side of
things, and some year we might see this get replaced with a better scheme.

This is a real problem, and an immediate solution is needed last spring.

Cheers

Re: SATA suspend-to-ram patch - merge?

[Matthew Garrett]

Mark Lord <liml@rtr.ca> wrote:

> Rather than sitting around for another six months hoping the problem
> will go away (it won't), perhaps we should just update/merge Jen's
> patch as a sorely needed interim fix.

As a datapoint, we've been shipping it in Ubuntu for a month or so now
and we haven't had any reported problems.
-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: SATA suspend-to-ram patch - merge?

[Jens Axboe]

On Thu, Sep 22 2005, Matthew Garrett wrote:
> Mark Lord <liml@rtr.ca> wrote:
> 
> > Rather than sitting around for another six months hoping the problem
> > will go away (it won't), perhaps we should just update/merge Jen's
> > patch as a sorely needed interim fix.
> 
> As a datapoint, we've been shipping it in Ubuntu for a month or so now
> and we haven't had any reported problems.

(dunno why I was trimmed from the reply?)

SUSE has shipped it in 9.3 and now in 10.0 as well.

-- 
Jens Axboe

Re: SATA suspend-to-ram patch - merge?

[Jens Axboe]

On Thu, Sep 22 2005, Mark Lord wrote:
> >>So currently we are in limbo...
> >
> >Which is a shame, since it means that software suspend on sata is
> >basically impossible :)
> 
> Except that it actually does work, with Jen's patch.

(Jens's, not Jen's!)

Yes, I'm very aware of that. The above note refers to what is currently
shipping in Linus's tree, and sata suspend definitely does not work
there.

> Rather than sitting around for another six months hoping the problem
> will go away (it won't), perhaps we should just update/merge Jen's
> patch as a sorely needed interim fix.
> 
> This might then prod James et al into looking more at the SCSI side of
> things, and some year we might see this get replaced with a better scheme.
> 
> This is a real problem, and an immediate solution is needed last spring.

Could not have said it better myself. It's not like the patch is hack
either.

-- 
Jens Axboe

Re: SATA suspend-to-ram patch - merge?

[Christoph Hellwig]

On Thu, Sep 22, 2005 at 09:04:28AM -0400, Mark Lord wrote:
> Rather than sitting around for another six months hoping the problem
> will go away (it won't), perhaps we should just update/merge Jen's
> patch as a sorely needed interim fix.
> 
> This might then prod James et al into looking more at the SCSI side of
> things, and some year we might see this get replaced with a better scheme.
> 
> This is a real problem, and an immediate solution is needed last spring.

Folks, bitching around on lkml on this won't get you far.  Send the
patch to linux-scsi again, and explain what's the current stance on the
disk synchronize cache and spindown issues.

Re: SATA suspend-to-ram patch - merge?

[Alan Cox]

On Iau, 2005-09-22 at 08:18 +0200, Jens Axboe wrote:
> > So currently we are in limbo...
> 
> Which is a shame, since it means that software suspend on sata is
> basically impossible :)

Not really, everyone on the planet who cares is using the existing patch
and that just works. If the SCSI folks can't fix the SCSI layer to do
power management then the scsi drivers just need to not provide pm
methods until they catch up.

Blocking SATA suspend which people need for SCSI suspend which is
utterly obscure and weird is pointless, as pretty much ever vendor
except Red Hat has already decided.

Alan

Re: SATA suspend-to-ram patch - merge?

[Jens Axboe]

On Thu, Sep 22 2005, Alan Cox wrote:
> On Iau, 2005-09-22 at 08:18 +0200, Jens Axboe wrote:
> > > So currently we are in limbo...
> > 
> > Which is a shame, since it means that software suspend on sata is
> > basically impossible :)
> 
> Not really, everyone on the planet who cares is using the existing patch
> and that just works. If the SCSI folks can't fix the SCSI layer to do
> power management then the scsi drivers just need to not provide pm
> methods until they catch up.

It's a shame for the people not using distros, since they need to first
experience the suspend failure, then google around for a solution, find
the patch, etc. That is a shame, since it could have worked out of the
box since 2.6.12 at least.

And it's a shame because it causes extra work for me everytime we update
the SUSE kernel :-)

-- 
Jens Axboe

Re: SATA suspend-to-ram patch - merge?

[Alan Cox]

On Iau, 2005-09-22 at 15:56 +0200, Jens Axboe wrote:
> It's a shame for the people not using distros, since they need to first
> experience the suspend failure, then google around for a solution, find
> the patch, etc. That is a shame, since it could have worked out of the
> box since 2.6.12 at least.

Its a symptom of general problems in this area. To get a sane kernel you
have to not only pick a distro kernel right now but then add several
other patches only found in other distributions.

SCSI suspend should not be blocking SATA suspend. If SCSI isn't with the
program yet then SCSI should just not support suspend while allowing
SATA to do so.

Alan

Re: SATA suspend-to-ram patch - merge?

[Luben Tuikov]

On 09/22/05 10:30, Alan Cox wrote:
> On Iau, 2005-09-22 at 15:56 +0200, Jens Axboe wrote:
> 
>>It's a shame for the people not using distros, since they need to first
>>experience the suspend failure, then google around for a solution, find
>>the patch, etc. That is a shame, since it could have worked out of the
>>box since 2.6.12 at least.
> 
> 
> Its a symptom of general problems in this area. To get a sane kernel you
> have to not only pick a distro kernel right now but then add several
> other patches only found in other distributions.
> 
> SCSI suspend should not be blocking SATA suspend. If SCSI isn't with the
> program yet then SCSI should just not support suspend while allowing
> SATA to do so.

I agree with Alan, Mark and Jens -- indeded, one should do
what makes sense.

	Luben

Re: SATA suspend-to-ram patch - merge?

[Jeff Garzik]

Alan Cox wrote:
> SCSI suspend should not be blocking SATA suspend. If SCSI isn't with the
> program yet then SCSI should just not support suspend while allowing
> SATA to do so.

Jens' patch updates the SCSI layer -- as is proper and needed.

Someone needs to take Jens patch to linux-scsi as Christoph mentioned, 
maybe there is a change in the wind...

	Jeff

Re: SATA suspend-to-ram patch - merge?

[Linus Torvalds]

On Thu, 22 Sep 2005, Jeff Garzik wrote:

> Alan Cox wrote:
> > SCSI suspend should not be blocking SATA suspend. If SCSI isn't with the
> > program yet then SCSI should just not support suspend while allowing
> > SATA to do so.
> 
> Jens' patch updates the SCSI layer -- as is proper and needed.
> 
> Someone needs to take Jens patch to linux-scsi as Christoph mentioned, 
> maybe there is a change in the wind...

Why not just send it to me and Andrew and get it merged.

The way we keep everybody honest (me, maintainers, and random developers) 
is with this concept called "open source", which means that anybody can 
fix a problem, and you don't need to wait for the "vendor". 

Yes, it's good to go through channels, but when that doesn't work, it's 
good to go _past_ them too.

			Linus

Re: SATA suspend-to-ram patch - merge?

[Christoph Hellwig]

On Thu, Sep 22, 2005 at 11:04:58AM -0700, Linus Torvalds wrote:
> Why not just send it to me and Andrew and get it merged.
> 
> The way we keep everybody honest (me, maintainers, and random developers) 
> is with this concept called "open source", which means that anybody can 
> fix a problem, and you don't need to wait for the "vendor". 
> 
> Yes, it's good to go through channels, but when that doesn't work, it's 
> good to go _past_ them too.

Umm, no one tried.  The last time it came up there was a healthy
discussion, but it stopped somewhere and no one followed up.  There
were two sets of patches from Jens and James and we need to arrive
somewhere in the middle.

That's exactly what I said above, people should stop bitching and bring
the patch up again - I'm pretty sure we'll find an acceptable variant
real soon.

Re: SATA suspend-to-ram patch - merge?

[Jens Axboe]

On Thu, Sep 22 2005, Christoph Hellwig wrote:
> On Thu, Sep 22, 2005 at 11:04:58AM -0700, Linus Torvalds wrote:
> > Why not just send it to me and Andrew and get it merged.
> > 
> > The way we keep everybody honest (me, maintainers, and random developers) 
> > is with this concept called "open source", which means that anybody can 
> > fix a problem, and you don't need to wait for the "vendor". 
> > 
> > Yes, it's good to go through channels, but when that doesn't work, it's 
> > good to go _past_ them too.
> 
> Umm, no one tried.  The last time it came up there was a healthy
> discussion, but it stopped somewhere and no one followed up.  There
> were two sets of patches from Jens and James and we need to arrive
> somewhere in the middle.
> 
> That's exactly what I said above, people should stop bitching and bring
> the patch up again - I'm pretty sure we'll find an acceptable variant
> real soon.

Sure, I'll brush up a version and post it tomorrow.

-- 
Jens Axboe

Re: SATA suspend-to-ram patch - merge?

[Randy.Dunlap]

On Thu, 22 Sep 2005, Jens Axboe wrote:

> On Wed, Sep 21 2005, Jeff Garzik wrote:
> > Joshua Kwan wrote:
> > >Is Jens' patch still relevant? If so, should it be rediffed and merged
> > >into mainline? It doesn't seem to cause any weird side-effects.
> > >
> > >More importantly, I would be inclined to properly rediff Jens' patch and
> > >merge it into Debian 2.6.12 kernel sources if there aren't any such
> > >side-effects, since it benefits everyone using SATA and suspend-to-ram
> > >(that is, users of relatively modern laptops.)
> >
> > Jens' patch is technical correct for SATA, but really we want to do more
> > stuff at the SCSI layer (see James Bottomley's response to Jens' patch).
> >
> > Unfortunately, this also implies that we have to figure out which SCSI
> > devices are available to be power-managed, and which SCSI devices are on
> > a shared bus that should never be suspended.
> >
> > So currently we are in limbo...
>
> Which is a shame, since it means that software suspend on sata is
> basically impossible :)

so just go with Jens's patch for SATA until SCSI knows more
about power management??

-- 
~Randy

Re: SATA suspend-to-ram patch - merge?

[Pavel Machek]

Hi!

> >Is Jens' patch still relevant? If so, should it be rediffed and 
> >merged
> >into mainline? It doesn't seem to cause any weird side-effects.
> >
> >More importantly, I would be inclined to properly rediff Jens' patch 
> >and
> >merge it into Debian 2.6.12 kernel sources if there aren't any such
> >side-effects, since it benefits everyone using SATA and 
> >suspend-to-ram
> >(that is, users of relatively modern laptops.)
> 
> Jens' patch is technical correct for SATA, but really we want to do 
> more stuff at the SCSI layer (see James Bottomley's response to Jens' 
> patch).
> 
> Unfortunately, this also implies that we have to figure out which 
> SCSI devices are available to be power-managed, and which SCSI 
> devices are on a shared bus that should never be suspended.

I think that shared buses are rare enough to be safely ignored.
We could simply say "never ever suspend machine with some
disks on shared bus".

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: SATA suspend-to-ram patch - merge?

[Jeff Garzik]

Pavel Machek wrote:
> I think that shared buses are rare enough to be safely ignored.

Hardly.  This potentially covers many enterprise installations that use 
fibre channel, iSCSI, plus the upcoming SAS device networks.

Desktop != the entire universe.


> We could simply say "never ever suspend machine with some
> disks on shared bus".

This is indeed a fair statement, at least in the short term.

	Jeff