apm_emulation regression

apm_emulation regression

[Benjamin Herrenschmidt]

I only just noticed a huge regression that was introduced when we moved
PowerPC to the generic APM emulation code instead of our own. I'm in
large part to blame since I acked the patch...

Basically, what we lost is the mechanism for notifying user applications
and waiting for their ACK before proceeding to system suspend. The new
generic code will still do that ... only when the actual suspend request
initiates from an APM suspend ioctl.

For any other suspend (via our private PMU ioctl or via the sysfs
interface), userspace will -not- be notified.

That basically means X will break. That's why X broke on the latest
ubuntu until I whacked some new scripts in them to force console
switching, among other things. Possibly other apps that relied
on /dev/apm_bios to be notified of system suspend/resume broke as well.

Now the question is that is it still work trying to fix it ? That would
probably require APM emulation hooking at a fairly high level into the
generic PM code to trigger the signaling & waiting of processes before
freeze & device suspend among others...

Cheers,
Ben.

Re: apm_emulation regression

[Johannes Berg]

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


On Wed, 2007-12-12 at 13:45 +1100, Benjamin Herrenschmidt wrote:
> I only just noticed a huge regression that was introduced when we moved
> PowerPC to the generic APM emulation code instead of our own. I'm in
> large part to blame since I acked the patch...
> 
> Basically, what we lost is the mechanism for notifying user applications
> and waiting for their ACK before proceeding to system suspend. The new
> generic code will still do that ... only when the actual suspend request
> initiates from an APM suspend ioctl.

Indeed.

> For any other suspend (via our private PMU ioctl or via the sysfs
> interface), userspace will -not- be notified.

Right.

> That basically means X will break. That's why X broke on the latest
> ubuntu until I whacked some new scripts in them to force console
> switching, among other things. Possibly other apps that relied
> on /dev/apm_bios to be notified of system suspend/resume broke as well.

Ah. I guess I never noticed because I had the scripts to do console
switching all along.

> Now the question is that is it still work trying to fix it ? That would
> probably require APM emulation hooking at a fairly high level into the
> generic PM code to trigger the signaling & waiting of processes before
> freeze & device suspend among others...

Yeah, bit icky... but doable. Rafael, any ideas?

johannes

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

Re: apm_emulation regression

[Johannes Berg]

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


> > That basically means X will break. That's why X broke on the latest
> > ubuntu until I whacked some new scripts in them to force console
> > switching, among other things. Possibly other apps that relied
> > on /dev/apm_bios to be notified of system suspend/resume broke as well.
> 
> Ah. I guess I never noticed because I had the scripts to do console
> switching all along.

Actually, it just occurred to me that the *kernel* does a console switch
when we use /sys/power/state, so maybe that is why I never had a problem
rather than userspace doing a console switch (which it only started
doing very recently)

johannes

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

Re: apm_emulation regression

[Benjamin Herrenschmidt]

On Thu, 2007-12-13 at 12:40 +0100, Johannes Berg wrote:
> > > That basically means X will break. That's why X broke on the latest
> > > ubuntu until I whacked some new scripts in them to force console
> > > switching, among other things. Possibly other apps that relied
> > > on /dev/apm_bios to be notified of system suspend/resume broke as well.
> > 
> > Ah. I guess I never noticed because I had the scripts to do console
> > switching all along.
> 
> Actually, it just occurred to me that the *kernel* does a console switch
> when we use /sys/power/state, so maybe that is why I never had a problem
> rather than userspace doing a console switch (which it only started
> doing very recently)

The kernel console switching can be disabled and -is- by some distros.
For example, the problem I was having was when testing Gutsy before it
was final, the script to console switch wasn't in the right place for
powermac and didn't work. X wouldn't be suspended properly and the
machine would lockup.

In general, we should try to fix that, as other things might rely
on /dev/apm_bios doing the right thing.

Ben.

Re: apm_emulation regression

[Rafael J. Wysocki]

On Wednesday, 12 of December 2007, Johannes Berg wrote:
> 
> On Wed, 2007-12-12 at 13:45 +1100, Benjamin Herrenschmidt wrote:
> > I only just noticed a huge regression that was introduced when we moved
> > PowerPC to the generic APM emulation code instead of our own. I'm in
> > large part to blame since I acked the patch...
> > 
> > Basically, what we lost is the mechanism for notifying user applications
> > and waiting for their ACK before proceeding to system suspend. The new
> > generic code will still do that ... only when the actual suspend request
> > initiates from an APM suspend ioctl.
> 
> Indeed.
> 
> > For any other suspend (via our private PMU ioctl or via the sysfs
> > interface), userspace will -not- be notified.
> 
> Right.
> 
> > That basically means X will break. That's why X broke on the latest
> > ubuntu until I whacked some new scripts in them to force console
> > switching, among other things. Possibly other apps that relied
> > on /dev/apm_bios to be notified of system suspend/resume broke as well.
> 
> Ah. I guess I never noticed because I had the scripts to do console
> switching all along.
> 
> > Now the question is that is it still work trying to fix it ? That would
> > probably require APM emulation hooking at a fairly high level into the
> > generic PM code to trigger the signaling & waiting of processes before
> > freeze & device suspend among others...
> 
> Yeah, bit icky... but doable. Rafael, any ideas?

Hmm.

I'm not that familiar with the APM emulation code, but the description of the
problem above suggests that the APM emulation can install a suspend
notifier for this purpose.

Greetings,
Rafael

Re: apm_emulation regression

[Benjamin Herrenschmidt]

On Fri, 2007-12-14 at 01:10 +0100, Rafael J. Wysocki wrote:
> 
> Hmm.
> 
> I'm not that familiar with the APM emulation code, but the description
> of the
> problem above suggests that the APM emulation can install a suspend
> notifier for this purpose.

It can use the new notifier that happens before freezing yes. Johannes,
I think that's pretty much what my old powermac implementation did
(using my private notifier scheme I had there), might be worth reviving
that bit and sticking it into the generic apm_emu ...

Ben.

Re: apm_emulation regression

[Benjamin Herrenschmidt]

On Fri, 2007-12-14 at 11:04 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2007-12-14 at 01:10 +0100, Rafael J. Wysocki wrote:
> > 
> > Hmm.
> > 
> > I'm not that familiar with the APM emulation code, but the description
> > of the
> > problem above suggests that the APM emulation can install a suspend
> > notifier for this purpose.
> 
> It can use the new notifier that happens before freezing yes. Johannes,
> I think that's pretty much what my old powermac implementation did
> (using my private notifier scheme I had there), might be worth reviving
> that bit and sticking it into the generic apm_emu ...

Note that you may want to improve on it with a timeout in case userspace
doesn't ack...

Ben.

Re: apm_emulation regression

[Johannes Berg]

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


> > It can use the new notifier that happens before freezing yes. Johannes,
> > I think that's pretty much what my old powermac implementation did
> > (using my private notifier scheme I had there), might be worth reviving
> > that bit and sticking it into the generic apm_emu ...
> 
> Note that you may want to improve on it with a timeout in case userspace
> doesn't ack...

Yeah heh. I'll take a look, shouldn't be too hard. Except I'm not
exactly sure how to test it.

johannes

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

Re: apm_emulation regression

[Rafael J. Wysocki]

On Friday, 14 of December 2007, Johannes Berg wrote:
> 
> > > It can use the new notifier that happens before freezing yes. Johannes,
> > > I think that's pretty much what my old powermac implementation did
> > > (using my private notifier scheme I had there), might be worth reviving
> > > that bit and sticking it into the generic apm_emu ...
> > 
> > Note that you may want to improve on it with a timeout in case userspace
> > doesn't ack...
> 
> Yeah heh. I'll take a look, shouldn't be too hard. Except I'm not
> exactly sure how to test it.

Create an artificially malicious application? ;-)

Rafael