>
> - 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.
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
[email protected]
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.
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.
On Mon, 01 Mar 2004 22:09:22 +1100, Benjamin Herrenschmidt <[email protected]> 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
> >> - 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 <[email protected]>
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
[email protected]
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
[email protected]
On Mon, 01 Mar 2004 22:39:52 +1100, Benjamin Herrenschmidt <[email protected]> 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
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).
On Mon, 01 Mar 2004 13:56:35 +0100, Martin Wickman <[email protected]> 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
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.
>
> 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.
On Mon, 01 Mar 2004 14:47:23 +0100, Arjan van de Ven <[email protected]> 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
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 <[email protected]>
> 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 ;)
> 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 <[email protected]>
> 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.