Hello,
since I didn't notice any change about the fact, that since 2.4.14
kernel, after issuing 'halt', the Keyboard Power-ON and Wake-On-LAN
don't work anymore on my ASUS P3B-F, which I reported Thu, 15 Nov 2001
18:43:22 +0100 here on this list, I wrote a small patch to fix
this myself.
The patch does nothing else than suppressing the clearing of the
General Purpose Events (GPEs).
Thanks to Patrick Mochel, who explained me, what was changed
between 2.4.13 and 2.4.14 regarding my problem.
The patch applies to 2.4.14 up to 2.4.18 at least.
With this patch applied and CONFIG_ACPI_NO_GPE_DISABLE #define'd,
Keyboard-Power-ON as well as Wake-On-LAN are working for me,
without this patch or with CONFIG_ACPI_NO_GPE_DISABLE #undef'ined,
both don't work.
Of course, there would be better ways to dynamically change this
behaviour (via some kernel option for example), but the way the
patch goes, was the least invasive one for me.
I have no idea about possible side-effects of suppressing the
execution of acpi_hw_disable_non_wakeup_gpes(), but i'd like
to hear about them, if there are any.
If there are no (relevant) side-effects, I'd be happy, if you'd
consider applying it to 2.4.19 or something like that.
And yes, I did notice, that acpi_hw_disable_non_wakeup_gpes()
should disable *non-wakeup* GPEs, but however - at least for
me it disables more than them :)
PS: I'm not member on the linux-kernel@ list, so please CC me in
replies, thanks.
regards,
Mario
--
[mod_nessus for iauth]
<delta> "scanning your system...found depreciated OS...found
hole...installing new OS...please reboot and reconnect now"
Hi!
> With this patch applied and CONFIG_ACPI_NO_GPE_DISABLE #define'd,
> Keyboard-Power-ON as well as Wake-On-LAN are working for me,
> without this patch or with CONFIG_ACPI_NO_GPE_DISABLE #undef'ined,
> both don't work.
I guess this needs to be runtime-configurable at least. It is probably
bug. Introducing the config option is not right fix.
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
On Mon, Mar 11, 2002 at 09:34:39PM +0100, Pavel Machek wrote:
> I guess this needs to be runtime-configurable at least. It is probably
> bug. Introducing the config option is not right fix.
Yes, you are right.
But as I told: It was the least invasive method for me.
Applying it as a config option, would include adding a MODULE_PARM
section, which doesn't exist yet (not for me, I have ACPI compiled
into the kernel, but to keep it consistent even if compiled as
module). I'm not *that* proof with linux kernel source to guarantee
side-effect-freeness and so on.
This part I'd like to leave for developers knowing better, what
they're doing :)
However, if someone of the ACPI developers or someone of the
patch-acceptors (:)) tells me 'do it, we'll patch it in', I'll do
it.
If it has no chance to get in, I wont do it - for me myself, my
patch is quite enough :)
thanks for your response & regards,
Mario
--
Mario 'BitKoenig' Holbe <[email protected]>
"Why are we hiding from the police, daddy?" | J. E. Guenther
"Because we use SuSE son, they use SYSVR4." | de.alt.sysadmin.recovery
> From: Mario 'BitKoenig' Holbe [mailto:[email protected]]
> However, if someone of the ACPI developers or someone of the
> patch-acceptors (:)) tells me 'do it, we'll patch it in', I'll do
> it.
> If it has no chance to get in, I wont do it - for me myself, my
> patch is quite enough :)
Basically we have to disable non-wake GPEs prior to sleeping - I agree with
Pavel that this should not be a config option. The real problem is that the
keyboard GPE should be flagged as a wake GPE, but it isn't yet.
What needs to happen is, when we are entering a sleep state, we need to
evaluate _PRW and _PSW objects for devices, and take the appropriate action
- I would bet that a result of doing this would be that keyboard (WOL too?
maybe) would be properly flagged as a wake device, so the call to that
function would but turn off its GPE bit.
Regards -- Andy
On Tue, 12 Mar 2002, Grover, Andrew wrote:
> > From: Mario 'BitKoenig' Holbe [mailto:[email protected]]
> > However, if someone of the ACPI developers or someone of the
> > patch-acceptors (:)) tells me 'do it, we'll patch it in', I'll do
> > it.
> > If it has no chance to get in, I wont do it - for me myself, my
> > patch is quite enough :)
>
> Basically we have to disable non-wake GPEs prior to sleeping - I agree with
> Pavel that this should not be a config option. The real problem is that the
> keyboard GPE should be flagged as a wake GPE, but it isn't yet.
>
> What needs to happen is, when we are entering a sleep state, we need to
> evaluate _PRW and _PSW objects for devices, and take the appropriate action
> - I would bet that a result of doing this would be that keyboard (WOL too?
> maybe) would be properly flagged as a wake device, so the call to that
> function would but turn off its GPE bit.
It seems like this would ideally be specified in the config file for the
power management agent. So, before the transition to sleep began, the
agent would enable those devices to wake the system (probably by writing a
value to a driverfs file).
The only thing is that you probably want all devices of a particular class
to wake a system - like all keyboards or all net devices. I don't know
what the config file format for ospmd looks like, but it might articulated
like:
/* devices to wake the system when we go to sleep */
wake {
keyboard
network
mouse
}
Right?
-pat
> From: Patrick Mochel [mailto:[email protected]]
> It seems like this would ideally be specified in the config
> file for the
> power management agent. So, before the transition to sleep began, the
> agent would enable those devices to wake the system (probably
> by writing a
> value to a driverfs file).
Agree.
> The only thing is that you probably want all devices of a
> particular class
> to wake a system - like all keyboards or all net devices. I
> don't know
> what the config file format for ospmd looks like, but it
> might articulated
> like:
>
> /* devices to wake the system when we go to sleep */
> wake {
> keyboard
> network
> mouse
> }
> Right?
Sounds OK to me. Once the wake capability and class of a device are both
visible through driverfs, implementing functionality like this in userspace
is easy.
Regards -- Andy
On Tue, Mar 12, 2002 at 11:57:48AM -0800, Grover, Andrew wrote:
> Pavel that this should not be a config option. The real problem is that the
> keyboard GPE should be flagged as a wake GPE, but it isn't yet.
>
> What needs to happen is, when we are entering a sleep state, we need to
> evaluate _PRW and _PSW objects for devices, and take the appropriate action
Well, as I said a few postings ago, I'm not really proof with
ACPI.
But ... from a users point of view (which I seem to be proof for -
especially in *this* case :)):
I enable in the BIOS, what devices should be considered wake
up devices.
This works very well with Windows (not that I'm going to use that,
I just tested it to validate, if it works there), it did work
very well with 2.4.13 too (yes, I know, there was the TODO: disable
GPEs).
Where is the problem to read those wake up events from the BIOS?
Why should I configure this twice - once in BIOS, once in some
ominous ospmd?
I grepped the ACPI code...
If I understand it right, a call to acpi_hw_enable_gpe_for_wakeup(event)
would mark one specific event as wakeup event.
The only call to this function is in acpi_enable_event(...).
And the only call to acpi_enable_event() is in
acpi_install_fixed_event_handler(...) and is flagged as
ACPI_EVENT_FIXED, so that acpi_hw_enable_gpe_for_wakeup() is
*never* called in the whole ACPI code at the moment, so how
can there be GPEs marked as wakeup events however?
And if there can't be any, why should I'm not be able to work
around this bug?
And yes - I consider this as bug :) There is code, which is never
called, afaics.
regards,
Mario, trying to understand :)
--
Programmieren in C++ haelt die grauen Zellen am Leben. Es schaerft
alle fuenf Sinne: den Schwachsinn, den Bloedsinn, den Wahnsinn, den
Unsinn und den Stumpfsinn.
[Holger Veit in doc]
> From: Mario 'BitKoenig' Holbe [mailto:[email protected]]
[explanation of problem and various code paths snipped]
> And if there can't be any, why should I'm not be able to work
> around this bug?
> And yes - I consider this as bug :) There is code, which is never
> called, afaics.
Well sure, you can work around this bug on your particular machine, but I
can't do the same because then, unlike your machine where not enough devices
are enabled for wake, *too many* devices will be enabled for wake on some
machines. This results in them not turning off properly -- they come right
back on. ;-)
So, there is a general-purpose fix for this, it just is going to take more
than deleting one line.
Regards -- Andy
On Tue, Mar 12, 2002 at 03:05:04PM -0800, Grover, Andrew wrote:
> Well sure, you can work around this bug on your particular machine, but I
> can't do the same because then, unlike your machine where not enough devices
> are enabled for wake, *too many* devices will be enabled for wake on some
> machines. This results in them not turning off properly -- they come right
> back on. ;-)
Okay, I understand this part :)
But what's with the more important one? Isn't that simply readable
from the BIOS somehow?
Doesn't store the BIOS the devices used for ACPI wakeup somewhere
in the ACPI tables?
Can't one read them out there?
And if not - is there actually a syscall interface where i can reach
acpi_hw_enable_gpe_for_wakeup()?
And if so - how can I translate devices to GPE numbers?
thanks & regards,
Mario
--
[mod_nessus for iauth]
<delta> "scanning your system...found depreciated OS...found
hole...installing new OS...please reboot and reconnect now"