Bug 8286

http://bugzilla.kernel.org/attachment.cgi?id=10990&action=view
http://bugzilla.kernel.org/attachment.cgi?id=10991&action=view
http://bugzilla.kernel.org/attachment.cgi?id=10996&action=view
http://bugzilla.kernel.org/attachment.cgi?id=10997&action=view

Do you mean it works well with the boot option "acpi=off"?
Please attach the content of /proc/acpi/wakeup.

Here you go:

Device  Sleep state     Status
PCIB       5            disabled
 LAN       5            disabled
PS2K       3            disabled
PSM1       3            disabled
USB0       3            disabled
USB1       3            disabled
USB2       3            disabled
USB7       3            disabled

I just tried.  Neither keyboard button presses or mousepad clicks/touches cause
the machine to resume.  I have to press the laptop lid button to get resume to
start.

I will test with acpi=off.  

Using acpi=off, afaics, doesn't leave me a working suspend.

>Using acpi=off, afaics, doesn't leave me a working suspend.
Sorry, my mistake. :p
>PS2K       3            disabled
>PSM1       3            disabled
#echo PS2K > /proc/acpi/wakeup
#echo PSM1 >/proc/acpi/wakeup
and try again.

Is this the expected outcome?  I see no change:

# echo PS2K > /proc/acpi/wakeup
# echo PSM1 >/proc/acpi/wakeup
# cat /proc/acpi/wakeup
Device  Sleep state     Status
PCIB       5            disabled
 LAN       5            disabled
PS2K       3            disabled
PSM1       3            disabled

This patch looks like it might be helpful:
http://lkml.org/lkml/2007/4/3/359

Oh, I see.
They must share the same GPE.
Change one of them is enough.
So please try:
#echo PS2K >/proc/acpi/wakeup
If you got the following result
    Device  Sleep state     Status
    PS2K       3            enabled
    PSM1       3            enabled
then try to resume the machine by keyboard button presses or mousepad 
clicks/touches.

Thanks.

You are correct that PS2K and PSM1 are linked.
Also, LAN and PCIB are linked, I find.
I tried enabling all the USB entries as well.
THe outcome is not perfect.  I can now get the machine to 
wake by touching the keyboard and by inserting a USB device.
However, touching the synaptics mousepad or pressing the 
mousepad buttons fails to wake up the laptop.

So, is it intended that the user must enable all these wakeup
settings on a per-user basis, or is it desired that the keyboard
and and mouse are enabled for wakeup by default?  This would 
certainly be my desired default.  It is what laptop users are 
used to.  

I don't know whether Gnome or KDE surface these settings in 
their power management configuration apps.  It would be great
if they would.

# cat /proc/acpi/wakeup
Device  Sleep state     Status
PCIB       5             enabled
 LAN       5             enabled
PS2K       3             enabled
PSM1       3             enabled
USB0       3             enabled
USB1       3             enabled
USB2       3             enabled
USB7       3             enabled

Created attachment 11241 [details]
the 1st patch of getting rid of /proc/acpi/wakeup

Created attachment 11242 [details]
the 2nd patch of get rid of /proc/acpi/wakeup

These two patches are written by David Brownell to get rid of
/proc/acpi/wakeup.
Please have a try. :)

Created attachment 11243 [details]
show more information in /proc/acpi/wakeup

Hmmm, you'd better apply this patch as well.
And attach the content of /proc/acpi/wakeup.

Thanks.

Created attachment 11245 [details]
update to "more info in /proc/acpi/wakeup"

I'm going to attach two more patches.  But mostly this is going to all be
informative ... I wouldn't expect anything to change with respect to handling
of those i8042 input devices, but you'll see more info about how ACPI views
things.

The patches "getting rid of" the wakeup file will mostly affect PCI devices on
the motherboard, making it so you don't need to manually enable them in
/proc/acpi/wakeup.

The "more info" patches update /proc/acpi/wakeup to show the device associated
with each wakeup-capable ACPI device ... modulo some glitches in the device
tree support for ACPI.	(This being the second of those two patches.)

The other two patches (a) hook up PNP devices to their ACPI siblings, which
will make /proc/acpi/wakeup show something for the i8042 devices, and (b) set
up cross-links in sysfs so that such hookups, and their PCI analogues, show up
too.  Should help diagnostics, and be more comprehensible than ACPI table
dumps.

You'll likely observe that the touchpad has three (!) sysfs nodes, rather than
the one you'd expect or the two found for most other PNP or PCI nodes.

... but I would really expect the root cause here to be that the i8042 stack
(mouse, touchpad, keyboard, etc) is doing something wrong.

Created attachment 11246 [details]
link PNP and ACPI nodes

I think I submitted these patches in the wrong order; 11245 updates this one.

Created attachment 11247 [details]
crosslink sysfs nodes for acpi and "real" devices

Note that if Gnome or KDE surfaces anything, it should be 
the /sys/devices/.../wakeup entries, not /proc/acpi/wakeup, since not every 
system has ACPI.  Also, that requiring a manual "make the system work right" 
step is kind of the wrong model.  Moving away from that.  :) 

I am doing the build now.  I ran into only one patching quirk:

# patch -p1 --dry-run < /home/miles/11243.patch 
patching file drivers/acpi/sleep/proc.c
Hunk #1 succeeded at 350 (offset -10 lines).

I patched in the order 11241, 11242, 11243, 11246, 11245

It'll be tomorrow when I can get down to testing. 
Thanks for the help!

BTW, David, not sure if you remember me from the Yenta/Hotplug development days.
 I always enjoy working with you.

Cheers,
     Miles

Ah.  I notice I missed 11247.  I've patched with it now and am proceeding.

With patches applied, this is what I get:

# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PCIB      S5     enabled   pci:0000:00:1e.0
LAN       S5     enabled   pci:0000:01:00.0
PS2K      S3     enabled   pnp:00:05
PSM1      S3     enabled   pnp:00:06
USB0      S3     enabled   pci:0000:00:1d.0
USB1      S3     enabled   pci:0000:00:1d.1
USB2      S3     enabled   pci:0000:00:1d.2
USB7      S3     enabled   pci:0000:00:1d.7

Created attachment 11249 [details]
lspci -vv output

This may help you interpret the contents of /proc/acpi/wakeup.

Cool!  This build works correctly.  It resumes when I use the mousepad buttons
or touch the mousepad.  I get the impression that these are not patches you
necessarily want to submit to Linus, but this is a big improvement.

Unfortunately, this build (2.6.21-rc7 + your patches) never suspends when I
press the laptop lid button.

[ 1198.337000] [ACPI Debug]  String: [0x08] "In _Q8A:"
[ 1198.337000] [ACPI Debug]  String: [0x0E] "SW3S and IGDS:"
[ 1198.338000] [ACPI Debug]  Integer: 0x00000000
[ 1198.338000] [ACPI Debug]  Integer: 0x00000001
[ 1210.547000] [ACPI Debug]  String: [0x08] "In _Q8A:"
[ 1210.548000] [ACPI Debug]  String: [0x0E] "SW3S and IGDS:"
[ 1210.548000] [ACPI Debug]  Integer: 0x00000001
[ 1210.548000] [ACPI Debug]  Integer: 0x00000001
[ 1215.116000] [ACPI Debug]  String: [0x08] "In _Q8A:"
[ 1215.117000] [ACPI Debug]  String: [0x0E] "SW3S and IGDS:"
[ 1215.117000] [ACPI Debug]  Integer: 0x00000000
[ 1215.117000] [ACPI Debug]  Integer: 0x00000001
[ 1225.365000] [ACPI Debug]  String: [0x08] "In _Q8A:"
[ 1225.365000] [ACPI Debug]  String: [0x0E] "SW3S and IGDS:"
[ 1225.366000] [ACPI Debug]  Integer: 0x00000001
[ 1225.366000] [ACPI Debug]  Integer: 0x00000001
[ 1229.542000] [ACPI Debug]  String: [0x08] "In _Q8A:"
[ 1229.542000] [ACPI Debug]  String: [0x0E] "SW3S and IGDS:"
[ 1229.543000] [ACPI Debug]  Integer: 0x00000000
[ 1229.543000] [ACPI Debug]  Integer: 0x00000001
[ 1239.170000] [ACPI Debug]  String: [0x08] "In _Q8A:"
[ 1239.170000] [ACPI Debug]  String: [0x0E] "SW3S and IGDS:"
[ 1239.171000] [ACPI Debug]  Integer: 0x00000001
[ 1239.171000] [ACPI Debug]  Integer: 0x00000001

Actually I think all except the "crosslink sysfs nodes" patch are in the MM 
tree and queued for 2.6.22 (possibly via detours through the ACPI or driver 
model queues). 
 
If this resumes correctly from mousepad events ... I can't see why it had 
anything at all to do with these patches. 
 
(Miles, yes I remember you from remote debugging of USB related issues.  The 
reason I got into this ACPI wake stuff was so that USB remote wake could work 
sanely... kind of a detour!) 

Ah.  I have been testing ACPI suspend/resume problems on this laptop.  Since I
was having severe problems with that on the most recent kernel code, I had
dropped back to 2.6.20.  2.6.20 displayed the problem where my machine would
only suspend every other attempt.  Perhaps the resume on mousepad event problem
is fixed in 2.6.21-rc7.  Zhang pointed out the need to tweak settings in
/proc/acpi/wakeup.  So now I'll test that on vanilla 2.6.21-rc7.

Still, tweaking these wakeup values is going to go away, right?  It bugs me to
have to hack initscripts to get devices to do the right thing.  

On this same laptop, I have to tweak settings to get my WIFI activation LED to
light up.  I also have a tweak so that the Audio Mute button LED is operational.
 I have written to developers to see whether these can be made to work by
default, but so far they are ignoring me.  :(

Okay, the "wake on synaptics mousepad event" issue is fixed for me in
2.6.21-rc7-git4.  I just need to enable the right stuff in /proc/acpi/wakeup. 
It would be great to have at least the USB, keyboard and mousepad stuff set to
wake by default.

>Still, tweaking these wakeup values is going to go away, right? 
That's right. :)
>Unfortunately, this build (2.6.21-rc7 + your patches) never suspends when I
>press the laptop lid button.
That's strange.
Anyway, Luming will help you debug this problem. :)

to comment#19:
Hi, Miles,
Did you still manually override /proc/acpi/wakeup after these patches?
If so, you don't need to do it anymore.
The USB, keyboard and mousepad should wake the system even if the 
corresponding status in /proc/acpi/wakeup is disabled. :)

Any notion about how soon these changes will land in a Linus release?
Thanks!

I am still seeing this problem in 2.6.21-rc7-mm2.  

As I commented before, this issue is completely unrelated to these patches.  If 
updating the /proc/acpi/wakeup flags helps, then the root cause of the problem 
is that the i8042 driver stack is wakeup-unaware.

Not ONE of those patches changes behavior for i8042 nodes like a synaptic 
touchpad.

Once the 2.6.22 merges start, it will be possible to make that stack be 
wakeup-aware, but one issue will be that it still has some real stupidities in 
terms of driver model support.  Specifically, that there are *THREE* device 
nodes where there should be just one.  The three nodes are (a) a PNP node, 
which is ignored by the i8042 stack; (b) an ACPI node, which should probably be 
handled by moving the PNP node into the ACPI tree and adding some annotations; 
and (c) an i8042 node, which should not exist given the PNP node.

This patch should probably not have been marked as "resolved", and should 
probably be moved over to the i8042 area ...

I was responding in light of 
http://bugzilla.kernel.org/show_bug.cgi?id=8286#c27

Okay, I'll reopen.

I hope I got this bug moved to the correct component.  I don't see an i8042
selection.

Hi, Dave,
>The three nodes are (a) a PNP node, which is ignored by the i8042 stack;
>(b) an ACPI node, which should probably be handled by moving the PNP node
>into the ACPI tree and adding some annotations;
Do you mean you are planning to merge these two trees?
Well, that's what I'm thinking about at least.
Too many nodes for one device doesn't look good anyway.

to Miles:
at least the USB devices can wakeup the system without 
touching /proc/acpi/wakeup, right?

> Do you mean you are planning to merge these two trees?
> Well, that's what I'm thinking about at least.

I'm hoping someone else resolves those issues!!   I'd hope the ACPI team would 
get rid of duplication between the ACPI and PNPACPI trees, but not necessarily 
between the PNP and i8042 trees.

Re Comment #27, evidently bugzilla discarded my email reply ... that's 
incorrect, none of the patches update the i8042 drivers to make them become 
wakeup-aware.  The only drivers for which a manual update of 
the /proc/acpi/wakeup file is no longer necessary would be wakeup-aware PCI 
drivers, or certain drivers for ACPI buttons.

>I'm hoping someone else resolves those issues!!
>I'd hope the ACPI team would get rid of duplication between the ACPI
>and PNPACPI trees, but not necessarily between the PNP and i8042 trees.
As I said, I'm investigating it. :)

>Re Comment #27, evidently bugzilla discarded my email reply ...
>none of the patches update the i8042 drivers to make them become wakeup-aware.
I know. That's why we move this bug to i8042 area.

zhang, in reply to comment#33, yes, USB connection events do wake up
2.6.21-rc7-mm2.  Thanks.

i8042 doe snot ignore PNP - it attaches to keyboard and/or mouse nodes either 
via PNPBIOS or PNPACPI and retrieves configuration data from there.

Can we adjust PNPACPI to take care of enabling wakeup?

The i8042 code may not ignore PNP, but it doesn't actually use those nodes in a 
normal way.  http://lkml.org/lkml/2007/4/17/357 points out that there are THREE 
(count'em, three!) sysfs nodes for each i8042 device.  (Well, it shows it for 
that touchpad, but I've observed the same on other systems for keyboards and 
mice.  Even on systems where /proc/acpi/wakeup lists the i8042 keyboard and 
mouse nodes.)

The root cause seems to be the device_add() in the serio code:  it's making new 
nodes in /sys/devices/platform/i8042 rather than using the PNP nodes.  (I 
speculate that's because a few years back, having the PNP nodes was the 
exception not the rule ... today it's the other way around, but the driver 
still uses a "legacy with band-aids" driver model structure.  In any case 
the "why" doesn't matter as much as the result.)

ACPI can mark the PNP nodes as wakeup-capable -- and given pending patches, 
does exactly that -- but i8042 uses the node it created instead.  Those are the 
ones associated with the input class devices, /proc/interrupts listings, etc.

The input correctly parents keyboard and mouse to i8042 (keyboard controller) 
as that's where they are physically attached to. PNP and ACPI nodes are 
auxullary and may even go away if disabled (acpi=off).

i8042 could enable wakeup when attaching to PNP nodes in 
drivers/input/serio/i8042-x86ia64io.h but:
1. Will this facuility be available for both PBPBIOS and PNPACPI?
2. Why doesn't PNPACPI enables wakeup automatcally?

You're mixing up various issues here ...

- If PNP nodes don't exist, then just fall back into a legacy mode,
  possibly looking pretty much like what you've got now.  But when
  they do exist, what you're doing is "unclean" from the driver model
  perspective:  don't device_add(), especially when you've been handed
  an appropriate node already!  (In fact, the i8042 stack seems to like
  creating five nodes where two should suffice... only one AUX present.)

- The ACPI nodes ... I'd suggest you don't worry about those (at least
  not yet!); they should eventually not duplicate the PNP nodes.

- Wakeup for i8042 has two aspects.

    * One is device_may_wakeup(), a driver input; once the extra device
      nodes get sorted out, that will just work ... at least for ACPI.
      That's mostly a platform setup issue, other than the way userspace
      can overide the "wakeup enabled by default" setting.

    * The other is the driver awareness, and somewhere in the i8042
      stack will need to be a call_platform_enable_wakeup() call on
      the suspend path when it may_wakeup().  (Then undoing it on the
      resume path.)

- Why doesn't PNPACPI enable wakeup automatically?  I can't answer
  for the "old model".  But the upcoming patches *do* enable it
  automatically.  Thing is, the driver needs to check whether user
  space has disabled it -- i.e. call device_may_wakeup() -- then
  set things up accordingly.

  In the general case, drivers need to do a few special things if
  they're going to be wakeup event sources.  It's possible that
  i8042 is an exception, and doesn't have much to do except call
  the platform hook ... I wouldn't know that.

  On embedded platforms it's more likely that a serio suspend()
  method would enable_irq_wake() if it may_wakeup() and its clock
  can stay enabled, otherwise clk_disable().  (Though I think that
  i8042 clones would mostly just do the irq_wake stuff.)

It looks bugzzilla did not like my reply email...

> You're mixing up various issues here ...
>
> - If PNP nodes don't exist, then just fall back into a legacy mode,
>  possibly looking pretty much like what you've got now.  But when
>  they do exist, what you're doing is "unclean" from the driver model
>  perspective:  don't device_add(), especially when you've been handed
>  an appropriate node already!  (In fact, the i8042 stack seems to like
>  creating five nodes where two should suffice... only one AUX present.)

You are mistaken here - if a box has an active multiplexing controller (which 
many HP's do have) then you have 4 independent AUX ports + 1 KBD port. They 
also physically belong to the keyboard controller (i8042) not ACPI or PNP. 
Therefore I do not think why I would want to use PNP nodes, especially given 
the fact that I am quite often 4 nodes short. You do not suggest that PCI layer 
stop creating device nodes and use ACPI tree instead?

>
> - The ACPI nodes ... I'd suggest you don't worry about those (at least
>  not yet!); they should eventually not duplicate the PNP nodes.
>

And I don't want to.

> - Wakeup for i8042 has two aspects.
>
>    * One is device_may_wakeup(), a driver input; once the extra device
>      nodes get sorted out, that will just work ... at least for ACPI.
>      That's mostly a platform setup issue, other than the way userspace
>      can overide the "wakeup enabled by default" setting.
>
>    * The other is the driver awareness, and somewhere in the i8042
>      stack will need to be a call_platform_enable_wakeup() call on
>      the suspend path when it may_wakeup().  (Then undoing it on the
>      resume path.)
>
> - Why doesn't PNPACPI enable wakeup automatically?  I can't answer
>  for the "old model".  But the upcoming patches *do* enable it
>  automatically.  Thing is, the driver needs to check whether user
>  space has disabled it -- i.e. call device_may_wakeup() -- then
>  set things up accordingly.

Well, if driver needs to check anything then it is not automatic. Anyway, I 
recommend adding this support to drivers/input/serio/i8042-x86ia64io.h where we 
setup PNP driver for AUX and KBD nodes. This will leave core i8042 blissfully 
unaware of PNP/ACPI.

> You are mistaken here - if a box has an active multiplexing controller (which 
> many HP's do have) then you have 4 independent AUX ports + 1 KBD port.

Not mistaken.  There's a difference between ports that are present in silicon
vs those which are actually wired up.  In this case, ACPI reported that only
two ports (KBD, one of the AUX == touchpad) are wired.  Ergo "too many".
As a rule, controllers that aren't usable shouldn't show in sysfs.


> also physically belong to the keyboard controller (i8042) not ACPI or PNP. 
> Therefore I do not think why I would want to use PNP nodes, especially given 
> the fact that I am quite often 4 nodes short.

As above.  The i8042 code is being told how many nodes *really* exist;
it's not a case of being "short", the others aren't wired up/usable.  A
PCI analogy:  sysfs won't show slots, it shows cards plugged into slots.


> Well, if driver needs to check anything then it is not automatic.

And as I explained:  "automatic" is in general not possible.


>    Anyway, I recommend adding this support to
> drivers/input/serio/i8042-x86ia64io.h where we 
> setup PNP driver for AUX and KBD nodes.

That's a reasonable solution on x86 and ia64 ... given the rather
strange driver structure.


> This will leave core i8042 blissfully unaware of PNP/ACPI.

But also:  unfortunately unaware of wakeup.

(And I didn't say a thing about making the core know about PNP.)

> > You are mistaken here - if a box has an active multiplexing controller 
(which
> > many HP's do have) then you have 4 independent AUX ports + 1 KBD port.
>
> Not mistaken.  There's a difference between ports that are present in silicon
> vs those which are actually wired up.

Do you have this laptop? Just for fun please plug an external mouse in it and 
you will be surprised (If it does not have external PS/2 ports you need to get 
a hold of a docking station).

> In this case, ACPI reported that only two ports (KBD, one of the
> AUX == touchpad) are wired.  Ergo "too many".

If I go by this logic I have to immediately pull external mouse from my Compaq 
becauase (oh horror!) it is not mentioned in ACPI and surely it is illusion 
that it is working.

Seriously, ACPI does not care about number of AUX ports present. They share the 
same IRQ and the same IO ports and so look the same to ACPI. There is not a 
single box that I have seen that has a special DSDT because its i8042 supports 
active multiplexing mode.

Also, I would not trust keyboard/mouse data it DSDT - in many cases they report 
either wrong ports or forget about IRQ, etc. If you look in i8042 you will see 
that most of PNP code deals with recovering from bad data provided to it.

> If I go by this logic I have to immediately pull external mouse
> from my Compaq because (oh horror!) it is not mentioned in ACPI
> and surely it is illusion that it is working.

That strange conclusion is entirely your own invention!

I was only remarking on one of the bizarre consequences of what
the i8042 code now does.  A mouse that's actually present should
obviously be usable, and show in sysfs.  It may be that the odd
behavior of muxed AUX ports has some reason attributable to the
hardware ... because in my small sample, non-muxed AUX ports do
not have that problem of showing phantom/non-existent devices.

It's certainly suggestive that the logic creating those phantom
device nodes is *also* discarding platform-provided data which
reports which devices are wakeup-capable, and which does not
have such a "phantom device" problem.  And while it does so, it
also makes a mess in sysfs (one more nodes for each PS2 device).
To someone not versed in the details of i8042 hardware, those
look like facets of one core problem.


> Also, I would not trust keyboard/mouse data it DSDT - in many
> cases they report either wrong ports or forget about IRQ, etc.
> If you look in i8042 you will see that most of PNP code deals
> with recovering from bad data provided to it.

A quick glance at that code shows that the main thing it tests
for is a table not using the "standard" values for any of those
resources.  No wonder the table values are sometimes invalid;
they were never needed, because of hardware standards that
predated PNP or ACPI!

But that's all beside the point.  The core issue is that the
i8042 code isn't wakeup-aware, and it should be.  It'd be good
if it were generic enough to work on non-ACPI systems.

Can anyone please tell me what the current status of this issue is?

Well, I think it's better to close it.