Re: Dropping CONFIG_PM_DISK?

Re: Dropping CONFIG_PM_DISK?

[Karol Kozimor]

Thus wrote Pavel Machek:
> Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> It seems noone is maintaining it, equivalent functionality is provided
> by swsusp, and it is confusing users...

It may be ugly, it may be unmaintained, but I get the impression that it
works for some people for whom swsusp doesn't. So unless swsusp works for
everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> > It seems noone is maintaining it, equivalent functionality is provided
> > by swsusp, and it is confusing users...
> 
> It may be ugly, it may be unmaintained, but I get the impression that it
> works for some people for whom swsusp doesn't. So unless swsusp works for
> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.

Do you have example when pmdisk works and swsusp does not? I'm not
aware of any in recent history...
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

> Hi!
>
>> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
>> > It seems noone is maintaining it, equivalent functionality is provided
>> > by swsusp, and it is confusing users...
>> 
>> It may be ugly, it may be unmaintained, but I get the impression that it
>> works for some people for whom swsusp doesn't. So unless swsusp works for
>> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
>
> Do you have example when pmdisk works and swsusp does not? I'm not
> aware of any in recent history...

For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
to get pmdisk to resume once, and swsusp2 makes it half-way through
the resume.  The old swsusp doesn't even get that far.

-- 
Måns Rullgård
mru@kth.se

Re: Dropping CONFIG_PM_DISK?

[Michael Frank]

On Sun, 29 Feb 2004 18:32:21 +0100, Måns Rullgård <mru@kth.se> wrote:

> Pavel Machek <pavel@ucw.cz> writes:
>
>> Hi!
>>
>>> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
>>> > It seems noone is maintaining it, equivalent functionality is provided
>>> > by swsusp, and it is confusing users...
>>>
>>> It may be ugly, it may be unmaintained, but I get the impression that it
>>> works for some people for whom swsusp doesn't. So unless swsusp works for
>>> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
>>
>> Do you have example when pmdisk works and swsusp does not? I'm not
>> aware of any in recent history...
>
> For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
> to get pmdisk to resume once, and swsusp2 makes it half-way through
> the resume.

Hate to hear this - 2.0 is said to work _flawlessly_ on 2.4.24 and
on 2.6.2 within the bounds of more complex PM/driver issues.

2.4.25 and 2.6.3 patches are undergoing testing.

If you like to try again, please have a look at http://swsusp.sf.net.

There is also comprehensive FAQ and Howto on the site.

You also will find a lot of user support wrt specific HW.

Myself is running 2.0 on 2.4.2[345] without any stability issues
whatsoever this year.

In short, I am confident we can make it work for you!

Regards
Michael

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Micha Feigin]

On Mon, Mar 01, 2004 at 02:10:09AM +0800, Michael Frank wrote:
> On Sun, 29 Feb 2004 18:32:21 +0100, M?ns Rullg?rd <mru@kth.se> wrote:
> 
> >Pavel Machek <pavel@ucw.cz> writes:
> >
> >>Hi!
> >>
> >>>> Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> >>>> It seems noone is maintaining it, equivalent functionality is provided
> >>>> by swsusp, and it is confusing users...
> >>>
> >>>It may be ugly, it may be unmaintained, but I get the impression that it
> >>>works for some people for whom swsusp doesn't. So unless swsusp works for
> >>>everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
> >>
> >>Do you have example when pmdisk works and swsusp does not? I'm not
> >>aware of any in recent history...
> >
> >For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
> >to get pmdisk to resume once, and swsusp2 makes it half-way through
> >the resume.
> 
> Hate to hear this - 2.0 is said to work _flawlessly_ on 2.4.24 and
> on 2.6.2 within the bounds of more complex PM/driver issues.
> 
> 2.4.25 and 2.6.3 patches are undergoing testing.
> 
> If you like to try again, please have a look at http://swsusp.sf.net.
> 
> There is also comprehensive FAQ and Howto on the site.
> 
> You also will find a lot of user support wrt specific HW.
> 
> Myself is running 2.0 on 2.4.2[345] without any stability issues
> whatsoever this year.
> 
> In short, I am confident we can make it work for you!
> 

Same for me. No problems with 2.4.[345] and also works nicely on
2.6.[123] as long as dri is not running (PM problems).

Only one problem that is not caused by swsusp but is a bit of a head
ache. X will ocationaly crash when changing VT to the console. I
originally thought it was a problem with my dri resume patch for
mach64, but the resume kicks in only when entering X and not when
leaving so its got to be something else.

> Regards Michael
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id\x1356&alloc_id438&op=click
> _______________________________________________
> swsusp-devel mailing list
> swsusp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/swsusp-devel
> 

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Michael Frank]

On Sun, 29 Feb 2004 23:33:02 +0200, Micha Feigin <michf@post.tau.ac.il> wrote:

> On Mon, Mar 01, 2004 at 02:10:09AM +0800, Michael Frank wrote:
>> On Sun, 29 Feb 2004 18:32:21 +0100, M?ns Rullg?rd <mru@kth.se> wrote:
>>
>> >Pavel Machek <pavel@ucw.cz> writes:
>> >
>> >>Hi!
>> >>
>> >>>> Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
>> >>>> It seems noone is maintaining it, equivalent functionality is provided
>> >>>> by swsusp, and it is confusing users...
>> >>>
>> >>>It may be ugly, it may be unmaintained, but I get the impression that it
>> >>>works for some people for whom swsusp doesn't. So unless swsusp works for
>> >>>everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
>> >>
>> >>Do you have example when pmdisk works and swsusp does not? I'm not
>> >>aware of any in recent history...
>> >
>> >For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
>> >to get pmdisk to resume once, and swsusp2 makes it half-way through
>> >the resume.
>>
>> Hate to hear this - 2.0 is said to work _flawlessly_ on 2.4.24 and
>> on 2.6.2 within the bounds of more complex PM/driver issues.
>>
>> 2.4.25 and 2.6.3 patches are undergoing testing.
>>
>> If you like to try again, please have a look at http://swsusp.sf.net.
>>
>> There is also comprehensive FAQ and Howto on the site.
>>
>> You also will find a lot of user support wrt specific HW.
>>
>> Myself is running 2.0 on 2.4.2[345] without any stability issues
>> whatsoever this year.
>>
>> In short, I am confident we can make it work for you!
>>
>
> Same for me. No problems with 2.4.[345] and also works nicely on
> 2.6.[123] as long as dri is not running (PM problems).
>
> Only one problem that is not caused by swsusp but is a bit of a head
> ache. X will ocationaly crash when changing VT to the console. I
> originally thought it was a problem with my dri resume patch for
> mach64, but the resume kicks in only when entering X and not when
> leaving so its got to be something else.

Yeah, too bad

- that 2.4 style PM got depreciated and let die before the
   "new-driver-model" PM is working
- that perfectly good drivers were rewritten from scratch,
   but without functioning PM support

:-(

Regards Michael

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Benjamin Herrenschmidt]

> 
> - that 2.4 style PM got depreciated and let die before the
>    "new-driver-model" PM is workin

Except that it never worked

> - that perfectly good drivers were rewritten from scratch,
>    but without functioning PM support

Please, give names.

Ben.

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Karol Kozimor]

Thus wrote Benjamin Herrenschmidt:
> > - that 2.4 style PM got depreciated and let die before the
> >    "new-driver-model" PM is workin
> Except that it never worked
> > - that perfectly good drivers were rewritten from scratch,
> >    but without functioning PM support
> Please, give names.

USB UHCI driver could be a fine example of a regression -- it could survive
suspend in 2.4 under certain conditions, this is no longer true for 2.6.

There's also a great deal of people, who can't resume when AGP is being 
used -- that is again a regression over 2.4.

The above are major showstoppers for most laptop users that already got
used to stable and reliable swsusp and hence prefer to stick with 2.4.

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Benjamin Herrenschmidt]

On Mon, 2004-03-01 at 22:35, Karol Kozimor wrote:
> Thus wrote Benjamin Herrenschmidt:
> > > - that 2.4 style PM got depreciated and let die before the
> > >    "new-driver-model" PM is workin
> > Except that it never worked
> > > - that perfectly good drivers were rewritten from scratch,
> > >    but without functioning PM support
> > Please, give names.
> 
> USB UHCI driver could be a fine example of a regression -- it could survive
> suspend in 2.4 under certain conditions, this is no longer true for 2.6.

Well, it may have survived by mere luck... the fact is that 2.4 never
had an infrastructure allowing anything remotely safe for
suspend/resume.

> There's also a great deal of people, who can't resume when AGP is being 
> used -- that is again a regression over 2.4.
>
> The above are major showstoppers for most laptop users that already got
> used to stable and reliable swsusp and hence prefer to stick with 2.4.

There haven't been a regression in the AGP drivers themselves afaik.

Ben.

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Karol Kozimor]

Thus wrote Benjamin Herrenschmidt:
> > USB UHCI driver could be a fine example of a regression -- it could survive
> > suspend in 2.4 under certain conditions, this is no longer true for 2.6.
> Well, it may have survived by mere luck... the fact is that 2.4 never

That's very likely. Anyway, pure luck is still better than no luck
whatsoever...

> had an infrastructure allowing anything remotely safe for
> suspend/resume.

Right, but the point is that while 2.6 has such an infrastructure, its
introduction actually completely broke UHCI suspend / resume.

> > There's also a great deal of people, who can't resume when AGP is being 
> > used -- that is again a regression over 2.4.
> There haven't been a regression in the AGP drivers themselves afaik.

Which, again, leads us to conclusion that it was the driver model change
that broke that.

I'm not trying to criticize the driver model itself (I'm sure others have
already done enough), but merely to emphasize that 2.6 is not yet ready for
laptop users.

Enough of that, this is becoming off-topic. :)
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Martin Wickman]

Karol Kozimor wrote:
> Thus wrote Benjamin Herrenschmidt:
> Right, but the point is that while 2.6 has such an infrastructure, its
> introduction actually completely broke UHCI suspend / resume.
> 
>>>There's also a great deal of people, who can't resume when AGP is being 
>>>used -- that is again a regression over 2.4.
>>
>>There haven't been a regression in the AGP drivers themselves afaik.
> 
> Which, again, leads us to conclusion that it was the driver model change
> that broke that.
> 
> I'm not trying to criticize the driver model itself (I'm sure others have
> already done enough), but merely to emphasize that 2.6 is not yet ready for
> laptop users.

...and it's pretty obvious that it'll never be unless it's
fixed. Its kinda frustrating this agp resume thing keeps holding swsusp2 
back -- everything else works (on my laptop at least).

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Michael Frank]

On Mon, 01 Mar 2004 13:56:35 +0100, Martin Wickman <martin.wickman@xms.se> wrote:

> Karol Kozimor wrote:
>> Thus wrote Benjamin Herrenschmidt:
>> Right, but the point is that while 2.6 has such an infrastructure, its
>> introduction actually completely broke UHCI suspend / resume.
>>
>>>> There's also a great deal of people, who can't resume when AGP is being
>>>> used -- that is again a regression over 2.4.
>>>
>>> There haven't been a regression in the AGP drivers themselves afaik.
>>
>> Which, again, leads us to conclusion that it was the driver model change
>> that broke that.
>>
>> I'm not trying to criticize the driver model itself (I'm sure others have
>> already done enough), but merely to emphasize that 2.6 is not yet ready for
>> laptop users.
>
> ...and it's pretty obvious that it'll never be unless it's
> fixed. Its kinda frustrating this agp resume thing keeps holding swsusp2
> back -- everything else works (on my laptop at least).
> -

PM and driver issues are holding back many non-server applications moving
 from 2.4 to 2.6, and to a substantial extend prevent people moving away
 from XP...

Regards
Michael

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Micha Feigin]

On Mon, Mar 01, 2004 at 10:28:36PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2004-03-01 at 22:35, Karol Kozimor wrote:
> > Thus wrote Benjamin Herrenschmidt:
> > > > - that 2.4 style PM got depreciated and let die before the
> > > >    "new-driver-model" PM is workin
> > > Except that it never worked
> > > > - that perfectly good drivers were rewritten from scratch,
> > > >    but without functioning PM support
> > > Please, give names.
> > 
> > USB UHCI driver could be a fine example of a regression -- it could survive
> > suspend in 2.4 under certain conditions, this is no longer true for 2.6.
> 
> Well, it may have survived by mere luck... the fact is that 2.4 never
> had an infrastructure allowing anything remotely safe for
> suspend/resume.
> 
> > There's also a great deal of people, who can't resume when AGP is being 
> > used -- that is again a regression over 2.4.
> >
> > The above are major showstoppers for most laptop users that already got
> > used to stable and reliable swsusp and hence prefer to stick with 2.4.
> 
> There haven't been a regression in the AGP drivers themselves afaik.

The suspend/resume calls have been removed from the drm drivers and
returning them doesn't solve the resume problems (I guess either agp
isn't woken up properly or something is happening in the wrong order. I
haven't had time to investigate further). And I have a simple mach64
(rage mobility m1) card which is relatively easy to wake up since not
much needs to be done (the agp bus is via).

> 
> Ben.
> 

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Benjamin Herrenschmidt]

On Mon, 2004-03-01 at 22:35, Karol Kozimor wrote:
> Thus wrote Benjamin Herrenschmidt:
> > > - that 2.4 style PM got depreciated and let die before the
> > >    "new-driver-model" PM is workin
> > Except that it never worked
> > > - that perfectly good drivers were rewritten from scratch,
> > >    but without functioning PM support
> > Please, give names.
> 
> USB UHCI driver could be a fine example of a regression -- it could survive
> suspend in 2.4 under certain conditions, this is no longer true for 2.6.
> 
> There's also a great deal of people, who can't resume when AGP is being 
> used -- that is again a regression over 2.4.
> 
> The above are major showstoppers for most laptop users that already got
> used to stable and reliable swsusp and hence prefer to stick with 2.4.

Oh... and what about looking into the problem instead and adding/fixing
the necessary stuff ? It's not _that_ rocket science (and I have no
UHCI hardware to do it myself, thanks).

Ben.

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Karol Kozimor]

Thus wrote Benjamin Herrenschmidt:
> > USB UHCI driver could be a fine example of a regression -- it could survive
> > suspend in 2.4 under certain conditions, this is no longer true for 2.6.
> > 
> > There's also a great deal of people, who can't resume when AGP is being 
> > used -- that is again a regression over 2.4.
> > 
> > The above are major showstoppers for most laptop users that already got
> > used to stable and reliable swsusp and hence prefer to stick with 2.4.
> Oh... and what about looking into the problem instead and adding/fixing
> the necessary stuff ? It's not _that_ rocket science (and I have no
> UHCI hardware to do it myself, thanks).

Well, the AGP problem is black magic to me. Those hangs / reboots happen
during the copying of the original kernel back (when S4 is concerned) and
that's completely beyond me, sorry.

I did try to look into the USB problem back then, but again, I couldn't
find anything significantly different between 2.4 and 2.6, so I backed out.
Anyway, you're still right about that one should fix it instead of
complaining...
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Benjamin Herrenschmidt]

> Well, the AGP problem is black magic to me. Those hangs / reboots happen
> during the copying of the original kernel back (when S4 is concerned) and
> that's completely beyond me, sorry.

Where, the whole swsusp thing is very fragile by design... I'd say you
probably need to disable the AGP bridge & release all AGP memory when
doing that copying, and re-enable it on wakeup. The list of pages used
for AGP have changed between both of those...

> I did try to look into the USB problem back then, but again, I couldn't
> find anything significantly different between 2.4 and 2.6, so I backed out.
> Anyway, you're still right about that one should fix it instead of
> complaining...
> Best regards,
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Michael Frank]

On Mon, 01 Mar 2004 22:09:22 +1100, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

>
>>
>> - that 2.4 style PM got depreciated and let die before the
>>    "new-driver-model" PM is workin
>
> Except that it never worked

It is actively used for ide, network, serial drivers with swsusp2.

>
>> - that perfectly good drivers were rewritten from scratch,
>>    but without functioning PM support
>
> Please, give names.
>

A few I tested:

AGP (sis, savage)
trident (Ali153x)
Serial (82x50)
Yenta (Toshiba Topic95)

Regards
Michael

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Benjamin Herrenschmidt]

> >> - that 2.4 style PM got depreciated and let die before the
> >>    "new-driver-model" PM is workin
> >
> > Except that it never worked
> 
> It is actively used for ide, network, serial drivers with swsusp2.

Without any proper ordering guarantee, IDE could take requests
after beeing suspended, which could be fatal (and cause data loss)
etc... 

Moving to the new model is easy. I don't see why we should have had
such a "compatibility" path on a major kernel version, that makes
no sense, just help fixing the drivers that need more fixing instead.

> >
> >> - that perfectly good drivers were rewritten from scratch,
> >>    but without functioning PM support
> >
> > Please, give names.
> >
> 
> A few I tested:
> 
> AGP (sis, savage)
> trident (Ali153x)
> Serial (82x50)
> Yenta (Toshiba Topic95)
> 
> Regards
> Michael
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Michael Frank]

On Mon, 01 Mar 2004 22:39:52 +1100, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

>
>> >> - that 2.4 style PM got depreciated and let die before the
>> >>    "new-driver-model" PM is workin
>> >
>> > Except that it never worked
>>
>> It is actively used for ide, network, serial drivers with swsusp2.
>
> Without any proper ordering guarantee, IDE could take requests
> after beeing suspended, which could be fatal (and cause data loss)
> etc...

Appreciated, suspending a driver like sending XOFF to a tty is ideal,
but not neccessary for _most_ drivers (software suspend) purpose.

Wrt IDE, in practice all processes get frozen well before
suspending drivers. Tested and no issues were ever reported with 2.4.

>
> Moving to the new model is easy. I don't see why we should have had
> such a "compatibility" path on a major kernel version, that makes
> no sense, just help fixing the drivers that need more fixing instead.

What for write new drivers for (fast obsoleting) hardware?.

- Developer time is the most precious resource
- Testing of drivers is in practice very difficult due to lack of
     several variations of HW (one can't really test anything in one box)
- It will take _years_ for drivers to become available and reach the
   stability of 2.4 drivers.
- Many drivers will die for lack of overall resources to port them.

So, why burn resources on reinventing wheels, which end up poorly
tested and run like a disk sliced of a tree...

What is needed is a  _compatible_ infrastructure to _any_ 2.4 driver
in existence and also provideing rudimentary centralized suspend and
resume capability.

This infrastructure could even be a config option
	CONFIG_24_DRIVER_SUPPORT
and be independent of the new model.

Then one could just drop in a driver from 2.4 and use it.

People having time to make new "pretty" drivers could
also use this facility for cross checking.

>
>> >
>> >> - that perfectly good drivers were rewritten from scratch,
>> >>    but without functioning PM support
>> >
>> > Please, give names.
>> >
>>
>> A few I tested:
>>
>> AGP (sis, savage)
>> trident (Ali153x)
>> Serial (82x50)
>> Yenta (Toshiba Topic95)
>>
>> Regards
>> Michael

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]


> Then one could just drop in a driver from 2.4 and use it.
> 
> People having time to make new "pretty" drivers could
> also use this facility for cross checking.

I'm sorry but this is a load of bull ;)
New kernel revisions come with a new API. If we keep the old one around
forever that achieves two things
1) The kernel bloats up 
2) Nobody puts effort into using the new (better) API

A proof of 2 is the scsi error handling; the old one was kept around as
compat for the last 5 years and only 2 or 3 drivers bothered to use the
new one.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Michael Frank]

On Mon, 01 Mar 2004 14:47:23 +0100, Arjan van de Ven <arjanv@redhat.com> wrote:

>
>> Then one could just drop in a driver from 2.4 and use it.
>>
>> People having time to make new "pretty" drivers could
>> also use this facility for cross checking.
>
> I'm sorry but this is a load of bull ;)

Thank you, I do fully concur with you from an ideal scientific perspective
where resources are not constrained. Applying the same perspective I might
like to craft lots of drivers in assembler or even reinvent whatever...,
but I do not live an ideal world.

> New kernel revisions come with a new API. If we keep the old one around
> forever that achieves two things
> 1) The kernel bloats up

By a few %, only when old API is used, the benefits far outweighs the cost.

The old API should be an independent glue layer where incompatible.
Performance is not a concern here, functionality is.

> 2) Nobody puts effort into using the new (better) API

Could be fixed by the simple policy that drivers which did not exist before
must use new API.

>
> A proof of 2 is the scsi error handling; the old one was kept around as
> compat for the last 5 years and only 2 or 3 drivers bothered to use the
> new one.

I am not around here that long, but if those drivers were added after the
API was finalized, it would have been a policy issue which does not have to
be repeated.

At least, (hopefully not from an ideal perspective), the new API is good
enough to last and will not have to be trown away in 2.7 or even 2.9 :)

Regards
Michael

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Mon, Mar 01, 2004 at 10:33:43PM +0800, Michael Frank wrote:
> On Mon, 01 Mar 2004 14:47:23 +0100, Arjan van de Ven <arjanv@redhat.com> 
> wrote:
> 
> >
> >>Then one could just drop in a driver from 2.4 and use it.
> >>
> >>People having time to make new "pretty" drivers could
> >>also use this facility for cross checking.
> >
> >I'm sorry but this is a load of bull ;)
> 
> Thank you, I do fully concur with you from an ideal scientific perspective
> where resources are not constrained. Applying the same perspective I might
> like to craft lots of drivers in assembler or even reinvent whatever...,
> but I do not live an ideal world.

I do not live an ideal world, However I do live in a practical world of
having to put distribution kernels together. 
> 
> >New kernel revisions come with a new API. If we keep the old one around
> >forever that achieves two things
> >1) The kernel bloats up
> 
> By a few %, only when old API is used, the benefits far outweighs the cost.

Ehm no. You entirely forget the cost where the new API and old API need to
work together, which is a significant complexity explosion. When linux grows
a new API that touches so many drivers, there's a good reason for that, eg
the API improves something or makes something possible.
Making powermanagement work is hard, even with 1 API to worry about. With 2
interfering API's it becomes outright impossible and untrackable. 
That's not a scientific perspective, that's a practical perspective where
the scientific theory maybe says you can have 2 parallel api's that never
interact ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[Benjamin Herrenschmidt]

> Appreciated, suspending a driver like sending XOFF to a tty is ideal,
> but not neccessary for _most_ drivers (software suspend) purpose.
> 
> Wrt IDE, in practice all processes get frozen well before
> suspending drivers. Tested and no issues were ever reported with 2.4.

It is still fragile. I have seen IDE requests slipping in anyway.

But IDE isn't a problem, I wrote a working PM implementation for
IDE in 2.6. 

> > Moving to the new model is easy. I don't see why we should have had
> > such a "compatibility" path on a major kernel version, that makes
> > no sense, just help fixing the drivers that need more fixing instead.
> 
> What for write new drivers for (fast obsoleting) hardware?.

Ok, you are at troll, no need to argue more.

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> >> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> >> > It seems noone is maintaining it, equivalent functionality is provided
> >> > by swsusp, and it is confusing users...
> >> 
> >> It may be ugly, it may be unmaintained, but I get the impression that it
> >> works for some people for whom swsusp doesn't. So unless swsusp works for
> >> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
> >
> > Do you have example when pmdisk works and swsusp does not? I'm not
> > aware of any in recent history...
> 
> For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
> to get pmdisk to resume once, and swsusp2 makes it half-way through
> the resume.  The old swsusp doesn't even get that far.

Try current swsusp with minimal drivers, init=/bin/bash.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Måns Rullgård]

Pavel Machek <pavel@suse.cz> writes:

> Hi!
>
>> >> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
>> >> > It seems noone is maintaining it, equivalent functionality is provided
>> >> > by swsusp, and it is confusing users...
>> >> 
>> >> It may be ugly, it may be unmaintained, but I get the impression that it
>> >> works for some people for whom swsusp doesn't. So unless swsusp works for
>> >> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
>> >
>> > Do you have example when pmdisk works and swsusp does not? I'm not
>> > aware of any in recent history...
>> 
>> For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
>> to get pmdisk to resume once, and swsusp2 makes it half-way through
>> the resume.  The old swsusp doesn't even get that far.
>
> Try current swsusp with minimal drivers, init=/bin/bash.

Well, if I do that it works.  Or at least some old version did, I
assume the later ones would too.  However, that sort of removes the
whole point.  Taking down the system enough to be able to unload
almost everything is as close as rebooting you'll get.

BTW, is there some easier way to track the development than using the
patches from the web page?  Unpatching after a couple of BK merges
isn't the easiest thing.  Is there a BK tree somewhere I can pull
from?

-- 
Måns Rullgård
mru@kth.se

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> >> >> > Would there be any major screaming if I tried to drop CONFIG_PM_DISK?
> >> >> > It seems noone is maintaining it, equivalent functionality is provided
> >> >> > by swsusp, and it is confusing users...
> >> >> 
> >> >> It may be ugly, it may be unmaintained, but I get the impression that it
> >> >> works for some people for whom swsusp doesn't. So unless swsusp works for
> >> >> everyone or Nigel's swsusp2 is merged, I'd suggest leaving that in.
> >> >
> >> > Do you have example when pmdisk works and swsusp does not? I'm not
> >> > aware of any in recent history...
> >> 
> >> For me, none of them (pmdisk, swsusp and swsusp2) work.  I did manage
> >> to get pmdisk to resume once, and swsusp2 makes it half-way through
> >> the resume.  The old swsusp doesn't even get that far.
> >
> > Try current swsusp with minimal drivers, init=/bin/bash.
> 
> Well, if I do that it works.  Or at least some old version did, I
> assume the later ones would too.  However, that sort of removes the
> whole point.  Taking down the system enough to be able to unload
> almost everything is as close as rebooting you'll get.

Well, now do a search for "which module/application causes failure".

> BTW, is there some easier way to track the development than using the
> patches from the web page?  Unpatching after a couple of BK merges
> isn't the easiest thing.  Is there a BK tree somewhere I can pull
> from?

Are you using swsusp2? That's _not_ what I'm talking about. swsusp is
in mainline.
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Måns Rullgård]

Pavel Machek <pavel@ucw.cz> writes:

>> > Try current swsusp with minimal drivers, init=/bin/bash.
>> 
>> Well, if I do that it works.  Or at least some old version did, I
>> assume the later ones would too.  However, that sort of removes the
>> whole point.  Taking down the system enough to be able to unload
>> almost everything is as close as rebooting you'll get.
>
> Well, now do a search for "which module/application causes failure".

I know, it just takes an awful time.

>> BTW, is there some easier way to track the development than using the
>> patches from the web page?  Unpatching after a couple of BK merges
>> isn't the easiest thing.  Is there a BK tree somewhere I can pull
>> from?
>
> Are you using swsusp2?

Well, trying to.  Isn't it supposed to be the latest and greatest?

> That's _not_ what I'm talking about. swsusp is in mainline.

It would still be the same module(s) that caused it to fail, right?

-- 
Måns Rullgård
mru@kth.se

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> >> > Try current swsusp with minimal drivers, init=/bin/bash.
> >> 
> >> Well, if I do that it works.  Or at least some old version did, I
> >> assume the later ones would too.  However, that sort of removes the
> >> whole point.  Taking down the system enough to be able to unload
> >> almost everything is as close as rebooting you'll get.
> >
> > Well, now do a search for "which module/application causes failure".
> 
> I know, it just takes an awful time.

Binary search should be pretty fast.

> >> BTW, is there some easier way to track the development than using the
> >> patches from the web page?  Unpatching after a couple of BK merges
> >> isn't the easiest thing.  Is there a BK tree somewhere I can pull
> >> from?
> >
> > Are you using swsusp2?
> 
> Well, trying to.  Isn't it supposed to be the latest and greatest?

It is latest, but not most stable.

								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: Dropping CONFIG_PM_DISK?

[Nigel Cunningham]

Can you provide specific examples? I can fix bugs if I'm given
reproducible issues instead of hand waving :>

Nigel

On Mon, 2004-03-01 at 23:39, Pavel Machek wrote:
> It is latest, but not most stable.

-- 
My work on Software Suspend was graciously brought to you between
October and January by LinuxFund.org.

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> Can you provide specific examples? I can fix bugs if I'm given
> reproducible issues instead of hand waving :>
> 

Try compiling with regparm=3; you are likely to find some
missing asmlinkages.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Dropping CONFIG_PM_DISK?

[Nigel Cunningham]

Forgive my ignorance, but I don't see how that could be something that
makes suspend2 less stable than the already-merged versions. They have
the same problem (assuming your patch hasn't been merged yet).

Regards,

Nigel

On Tue, 2004-03-02 at 01:46, Pavel Machek wrote:
> Hi!
> 
> > Can you provide specific examples? I can fix bugs if I'm given
> > reproducible issues instead of hand waving :>
> > 
> 
> Try compiling with regparm=3; you are likely to find some
> missing asmlinkages.
> 				Pavel
-- 
My work on Software Suspend was graciously brought to you between
October and January by LinuxFund.org.

Re: Dropping CONFIG_PM_DISK?

[Pavel Machek]

Hi!

> Forgive my ignorance, but I don't see how that could be something that
> makes suspend2 less stable than the already-merged versions. They have
> the same problem (assuming your patch hasn't been merged yet).

Okay... well...

swsusp2 is meant to be feature-full. in kernel swsusp is meant to be
stable. Perhaps swsusp2 manages to be both feature-full and stable at
same time; at that point I'm obviously doing not-too-good job.

								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Dropping CONFIG_PM_DISK?

[Michael Frank]

On Mon, 01 Mar 2004 11:08:01 +0100, Måns Rullgård <mru@kth.se> wrote:

> Pavel Machek <pavel@ucw.cz> writes:
>
>>> > Try current swsusp with minimal drivers, init=/bin/bash.
>>>
>>> Well, if I do that it works.  Or at least some old version did, I
>>> assume the later ones would too.  However, that sort of removes the
>>> whole point.  Taking down the system enough to be able to unload
>>> almost everything is as close as rebooting you'll get.
>>
>> Well, now do a search for "which module/application causes failure".
>
> I know, it just takes an awful time.
>
>>> BTW, is there some easier way to track the development than using the
>>> patches from the web page?  Unpatching after a couple of BK merges
>>> isn't the easiest thing.  Is there a BK tree somewhere I can pull
>>> from?
>>
>> Are you using swsusp2?
>
> Well, trying to.  Isn't it supposed to be the latest and greatest?
>
>> That's _not_ what I'm talking about. swsusp is in mainline.
>
> It would still be the same module(s) that caused it to fail, right?
>

Further to my post yesterday, here is a short article which may be of interest.

http://lwn.net/Articles/68747/

So, to make it work better lets get PM usable :)

swsusp2 mailing list: swsusp-devel@lists.sourceforge.net

Regards
Michael

Re: [Swsusp-devel] Re: Dropping CONFIG_PM_DISK?

[John Mock]

    USB UHCI driver could be a fine example of a regression -- it could survive
    suspend in 2.4 under certain conditions, this is no longer true for 2.6.

I would agree with you about the UHCI for 2.6.0, but i've seen improvement 
since then.  At this point (vanilla 2.6.3), the non-module version of the 
UHCI is not only able to suspend, but it can even resume a digital camera'
('usb-storage'), which was something that i didn't expect.  I tried to make 
the module version work under 2.6.1-rc1, but i didn't get very far.  I could
get it to come up without major complaints, but could not get it to retain 
any connections.  That may be fine for an HID device, but not much good for 
a file-oriented device.  It really isn't much better than rmmod'ing just
before suspending (as the effect is the same).

Surprisingly enough, under 2.6.3, even the PCMCIA IDE card came back up
after hibernation, albeit with a few minor complaints.  So in some ways,
the current version may be better if one doesn't need certain modules to 
work.

As far as CONFIG_PM_DISK vs. CONFIG_SOFTWARE_SUSPEND, i'm not sure what to
say, except that 'echo 4b > /proc/acpi/sleep' mostly works for me, while
'echo -n disk > /sys/power/state' returns without successfully hibernating
(and has done that for the last several kernel versions i've tried).

I have not had much luck with X, as the only thing that manages to survive
suspend is VESA running 256 colors (and the version under 2.6.3 doesn't end
up with enough left over to run a web browser effectively).  With a 2.4.22
kernel and recent software suspend patch (2.0-rc2), the native driver for 
a Sony R505EL almost works, but again, only if i use 256 colors and switch
away to suspend (and then i still need to restart 'gpm' after suspending).
I need to have it suspend when it's running on batteries and i've left the
room (or otherwise forgotten about things), so this isn't very acceptable.

So software suspend under 2.4 might be better, it doesn't really answer my
problems.  So i still feel stuck with Windows when i'm not at home.

				-- JM