Re: [SoftwareSuspend-devel] 2.6 Suspend PM issues

Re: [SoftwareSuspend-devel] 2.6 Suspend PM issues

[Nigel Cunningham]

Hi Michael.

On Fri, 2004-12-17 at 16:15, Michael Frank wrote:
> Hi Nigel,
> 
> By what was discussed wrt ALSA issue I gather that you still resume _all_ 
> drivers after doing the atomic copy?
> 
> As explained earlier this year, if this is the case, it is firstly 
> unacceptable as it will result in loss of data in many applications and 
> secondly very clumsy.
> 
> Example With 2.4 OK, with 2.6 It would fail:
> A datalogger connected to a seral port of a notebook in the field. Data 
> transfer in progress which can be put on hold bo lowering RTS (HW handshake) 
> but _cannot_ be restarted. Battery low, must suspend to change battery, upon 
> resume transfer can continue.
> 
> Will this be taken care of?

Until 2.1.5.8, I had put in support ('device trees') for handling the
devices we're using in writing the image separately. Unused devices were
suspending prior to beginning to write the image and not resumed before
powerdown. At resume time, they were suspended and not resumed until the
whole image had been re-read. In short, it did what you're asking.

>From what I understand, though, work on the driver model and individual
drivers should be making this unnecessary. If that's not true, I'll
happily put the device tree code back in. For now, though, I've been
seeking to implement changes that will help with getting the code
merged, and this was one of them.

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

You see, at just the right time, when we were still powerless, Christ
died for the ungodly.		-- Romans 5:6

Re: [SoftwareSuspend-devel] 2.6 Suspend PM issues

[Pavel Machek]

Hi!

> > By what was discussed wrt ALSA issue I gather that you still resume _all_ 
> > drivers after doing the atomic copy?
> > 
> > As explained earlier this year, if this is the case, it is firstly 
> > unacceptable as it will result in loss of data in many applications and 
> > secondly very clumsy.
> > 
> > Example With 2.4 OK, with 2.6 It would fail:
> > A datalogger connected to a seral port of a notebook in the field. Data 
> > transfer in progress which can be put on hold bo lowering RTS (HW handshake) 
> > but _cannot_ be restarted. Battery low, must suspend to change battery, upon 
> > resume transfer can continue.
> > 
> > Will this be taken care of?

Driver will get enough info in its resume routine ("hey, it is resume,
but it is only resume after atomic copy"), so it can ignore the resume
if it really needs to.

But this is 2.6.11 material.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [SoftwareSuspend-devel] 2.6 Suspend PM issues

[Michael Frank]

On Friday 17 December 2004 17:26, Pavel Machek wrote:
> Hi!
>
> > > By what was discussed wrt ALSA issue I gather that you still resume
> > > _all_ drivers after doing the atomic copy?
> > >
> > > As explained earlier this year, if this is the case, it is firstly
> > > unacceptable as it will result in loss of data in many applications and
> > > secondly very clumsy.
> > >
> > > Example With 2.4 OK, with 2.6 It would fail:
> > > A datalogger connected to a seral port of a notebook in the field. Data
> > > transfer in progress which can be put on hold bo lowering RTS (HW
> > > handshake) but _cannot_ be restarted. Battery low, must suspend to
> > > change battery, upon resume transfer can continue.
> > >
> > > Will this be taken care of?
>
> Driver will get enough info in its resume routine ("hey, it is resume,
> but it is only resume after atomic copy"), so it can ignore the resume
> if it really needs to.

Each driver has to make the decision when to ignore resume? that would add a 
lot of bloat as well as lots of work to implement and test the changes for 
100s of drivers...

Please consider the practical implications of your proposal and you may find 
that this really should be handled in a centralized manner.

>
> But this is 2.6.11 material.

Fine.

 Michael

Re: [SoftwareSuspend-devel] 2.6 Suspend PM issues

[Pavel Machek]

Hi!

> > > > By what was discussed wrt ALSA issue I gather that you still resume
> > > > _all_ drivers after doing the atomic copy?
> > > >
> > > > As explained earlier this year, if this is the case, it is firstly
> > > > unacceptable as it will result in loss of data in many applications and
> > > > secondly very clumsy.
> > > >
> > > > Example With 2.4 OK, with 2.6 It would fail:
> > > > A datalogger connected to a seral port of a notebook in the field. Data
> > > > transfer in progress which can be put on hold bo lowering RTS (HW
> > > > handshake) but _cannot_ be restarted. Battery low, must suspend to
> > > > change battery, upon resume transfer can continue.
> > > >
> > > > Will this be taken care of?
> >
> > Driver will get enough info in its resume routine ("hey, it is resume,
> > but it is only resume after atomic copy"), so it can ignore the resume
> > if it really needs to.
> 
> Each driver has to make the decision when to ignore resume? that would add a 
> lot of bloat as well as lots of work to implement and test the changes for 
> 100s of drivers...

No, only those drivers where extra resume does some damage. So far I
know about one, and that's your data logging device.
									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [SoftwareSuspend-devel] 2.6 Suspend PM issues

[Pavel Machek]

Hi!

> > > > > By what was discussed wrt ALSA issue I gather that you still resume
> > > > > _all_ drivers after doing the atomic copy?
> > > > >
> > > > > As explained earlier this year, if this is the case, it is firstly
> > > > > unacceptable as it will result in loss of data in many applications and
> > > > > secondly very clumsy.
> > > > >
> > > > > Example With 2.4 OK, with 2.6 It would fail:
> > > > > A datalogger connected to a seral port of a notebook in the field. Data
> > > > > transfer in progress which can be put on hold bo lowering RTS (HW
> > > > > handshake) but _cannot_ be restarted. Battery low, must suspend to
> > > > > change battery, upon resume transfer can continue.
> > > > >
> > > > > Will this be taken care of?
> > >
> > > Driver will get enough info in its resume routine ("hey, it is resume,
> > > but it is only resume after atomic copy"), so it can ignore the resume
> > > if it really needs to.
> > 
> > Each driver has to make the decision when to ignore resume? that would add a 
> > lot of bloat as well as lots of work to implement and test the changes for 
> > 100s of drivers...
> 
> No, only those drivers where extra resume does some damage. So far I
> know about one, and that's your data logging device.

...which will not work anyway, swsusp1 or swsusp2. Have you actually
tried it?

During boot, BIOS is probably going to play with RTS anyway. So no
matter what you do during suspend, you are probably going to screw it
up anyway on the boot just before resume.

So there are currently 0 examples where extra resume hurts.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [SoftwareSuspend-devel] 2.6 Suspend PM issues

[Michael Frank]

On Saturday 18 December 2004 15:50, Pavel Machek wrote:
> Hi!
>
> > > > > > By what was discussed wrt ALSA issue I gather that you still
> > > > > > resume _all_ drivers after doing the atomic copy?
> > > > > >
> > > > > > As explained earlier this year, if this is the case, it is
> > > > > > firstly unacceptable as it will result in loss of data in many
> > > > > > applications and secondly very clumsy.
> > > > > >
> > > > > > Example With 2.4 OK, with 2.6 It would fail:
> > > > > > A datalogger connected to a seral port of a notebook in the
> > > > > > field. Data transfer in progress which can be put on hold bo
> > > > > > lowering RTS (HW handshake) but _cannot_ be restarted. Battery
> > > > > > low, must suspend to change battery, upon resume transfer can
> > > > > > continue.
> > > > > >
> > > > > > Will this be taken care of?
> > > >
> > > > Driver will get enough info in its resume routine ("hey, it is
> > > > resume, but it is only resume after atomic copy"), so it can ignore
> > > > the resume if it really needs to.
> > >
> > > Each driver has to make the decision when to ignore resume? that would
> > > add a lot of bloat as well as lots of work to implement and test the
> > > changes for 100s of drivers...
> >
> > No, only those drivers where extra resume does some damage. So far I
> > know about one, and that's your data logging device.
>
> ...which will not work anyway, swsusp1 or swsusp2. Have you actually
> tried it?

I put suspend support into 2.4 serial driver and use it. It does work.

2.6 serial driver suspend was not working a year ago, have not tried since.

>
> During boot, BIOS is probably going to play with RTS anyway. So no
> matter what you do during suspend, you are probably going to screw it
> up anyway on the boot just before resume.

Luckily not on several of my machines and the linux 2.4 driver at least 
does not turn the lines on until resume tells it to do so...

>
> So there are currently 0 examples where extra resume hurts.

still 1 ;) and the same thing would apply to using an USB dongle and 
there will be many applications were it hurts as well.

Then, extra resume is not required, it's bad when it causes strain on the 
power source (notebook battery low), is a clumsy implementation and slows 
suspend process down.

Michael

Re: [SoftwareSuspend-devel] 2.6 Suspend PM issues

[Pavel Machek]

Hi!

> > ...which will not work anyway, swsusp1 or swsusp2. Have you actually
> > tried it?
> 
> I put suspend support into 2.4 serial driver and use it. It does work.
> 
> 2.6 serial driver suspend was not working a year ago, have not tried since.
> 
> > During boot, BIOS is probably going to play with RTS anyway. So no
> > matter what you do during suspend, you are probably going to screw it
> > up anyway on the boot just before resume.
> 
> Luckily not on several of my machines and the linux 2.4 driver at least 
> does not turn the lines on until resume tells it to do so...

If 2.6 serial does not turn it on boot, there's no reason it should
turn it on during resume() [and it would be a bug].

Find out what 2.6 serial does, and fix the bug...
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!