ACPI - my observations and question for help
Lars Erdmann
as quite a few people, I am also experiencing problems with ACPI (I am
using version 3.16, unfortunately my software subscription expired). I
quite often experience hangs on boot, sometimes I am able to hit
Ctrl-Alt-Del, sometimes I have to power off and back on.
I have now started to change the ACPI configuration here and there so
see if it has any effect.
Recently, I modified file "acpid.cfg" and deactivated sleep by setting:
SleepState = 0
Additionally, I disabled logging to screen (that should only work with
the debug version of ACPI anyway):
LogScreen = 0
This seems to improve the situation. My suspicion about the Sleep state
stems from XWorkplace's feature to activate sleep from XCenter: when I
increased the SleepState to a high level (S3 or S4) triggering sleep
would lead to a complete shutdown of my system (with a chkdsk on next boot).
Everyone who has hangs on boot: would you please also try and at least
deactivate Sleep and see if that helps and report results here ?
By the way: where is the BEST place to report any
findings/hints/observations about ACPI (apart from reporting a bug) ?
Thanks,
Lars
Allan
> as quite a few people, I am also experiencing problems with ACPI (I am
> using version 3.16, unfortunately my software subscription expired). I
> quite often experience hangs on boot, sometimes I am able to hit
> Ctrl-Alt-Del, sometimes I have to power off and back on.
> I have now started to change the ACPI configuration here and there so
> see if it has any effect.
>
> Recently, I modified file "acpid.cfg" and deactivated sleep by setting:
> SleepState = 0
> Additionally, I disabled logging to screen (that should only work with
> the debug version of ACPI anyway):
> LogScreen = 0
LogScreen has nothing to do ACPI driver output. LogScreen controls
output from ACPIManager.exe
You can see it, if you run it from startup.cmd instead of from config.sys
(and it usually improves stability to do so !)
> This seems to improve the situation. My suspicion about the Sleep state
> stems from XWorkplace's feature to activate sleep from XCenter: when I
> increased the SleepState to a high level (S3 or S4) triggering sleep
> would lead to a complete shutdown of my system (with a chkdsk on next boot).
SleepState = Suspend (and resume). It works on only very few PC's
You can't just select any Sleepstate - your BIOS need to support them
(output from ACPIManager.exe will tell you which). S3 is the only
interesting one - but it works on only very few PC's
> Everyone who has hangs on boot: would you please also try and at least
> deactivate Sleep and see if that helps and report results here ?
The only time 'Sleeptime ' is used, is when you try to call 'Suspend'.
If it is a desktop PC - you could try to not run ACPIManager at all,
that sometimes improves stability.
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Lars Erdmann
> On Sat, 31 Oct 2009 20:00:04 UTC, Lars Erdmann <lars.e...@arcor.de> wrote:
>
>> as quite a few people, I am also experiencing problems with ACPI (I am
>> using version 3.16, unfortunately my software subscription expired). I
>> quite often experience hangs on boot, sometimes I am able to hit
>> Ctrl-Alt-Del, sometimes I have to power off and back on.
>> I have now started to change the ACPI configuration here and there so
>> see if it has any effect.
>>
>> Recently, I modified file "acpid.cfg" and deactivated sleep by setting:
>> SleepState = 0
>> Additionally, I disabled logging to screen (that should only work with
>> the debug version of ACPI anyway):
>> LogScreen = 0
>
> LogScreen has nothing to do ACPI driver output. LogScreen controls
> output from ACPIManager.exe
> You can see it, if you run it from startup.cmd instead of from config.sys
> (and it usually improves stability to do so !)
I have with this box.
I have never run acpimanager.exe neither from config.sys nor from
startup.cmd. Where is it documented that you should do so ? To me it
looks like a diagnosis and stimulation tool and nothing else.
>
>> This seems to improve the situation. My suspicion about the Sleep state
>> stems from XWorkplace's feature to activate sleep from XCenter: when I
>> increased the SleepState to a high level (S3 or S4) triggering sleep
>> would lead to a complete shutdown of my system (with a chkdsk on next boot).
>
> SleepState = Suspend (and resume). It works on only very few PC's
> You can't just select any Sleepstate - your BIOS need to support them
> (output from ACPIManager.exe will tell you which). S3 is the only
> interesting one - but it works on only very few PC's
acpidaemon.log tells me that _S3_,_S4_,_S5_ are supported (whatever
_S5_ means, I cannot correlate it to the states that acpid.cfg lists). I
don't understand where to look for in the acpimanager.exe output.
Any of these (S3,S4) will lead to the problems mentioned. Only if I
completely disable sleep will my PC work reliably.
>
>> Everyone who has hangs on boot: would you please also try and at least
>> deactivate Sleep and see if that helps and report results here ?
>
> The only time 'Sleeptime ' is used, is when you try to call 'Suspend'.
Ok, what I don't see is: when and from where do I call "Suspend" ? Is it
the old APM.SYS programming interface for device drivers and
applications ? I will need to ask the XWorkplace developers what they do
when "Sleep" is activtated via XCenter ...
But yes, when I completely disable Sleep, I no longer seem to have hangs
on boot.
>
> If it is a desktop PC - you could try to not run ACPIManager at all,
> that sometimes improves stability.
I don't run acpimanager.exe, see above.
Lars
Paul Ratcliffe
>> The only time 'Sleeptime ' is used, is when you try to call 'Suspend'.
>
> Ok, what I don't see is: when and from where do I call "Suspend" ? Is it
> the old APM.SYS programming interface for device drivers and
> applications ? I will need to ask the XWorkplace developers what they do
> when "Sleep" is activtated via XCenter ...
It calls method _wpChangePowerstate(6,0,1,2) in the WPPower class. This
resolves to calling the relevant DosDevIOCtl() in APM.SYS
I thought ACPI implemented a replacement APM interface which diverted these
APM calls to ACPI. Am I wrong?
In any case, the rest of XWP calls ACPI directly, so perhaps this should
too?
It is an inelegant way of doing it though. If ACPI is installed it should
completely replace the APM subsystem and the users should carry on without
caring what the lower layers are doing. Then we wouldn't need to rewrite
anything.
Allan
> >
> > LogScreen has nothing to do ACPI driver output. LogScreen controls
> > output from ACPIManager.exe
> > You can see it, if you run it from startup.cmd instead of from config.sys
> > (and it usually improves stability to do so !)
> Ah, ok. In that case, I guess "LogScreen" is irrelevant for the problems
> I have with this box.
> I have never run acpimanager.exe neither from config.sys nor from
> startup.cmd. Where is it documented that you should do so ? To me it
> looks like a diagnosis and stimulation tool and nothing else.
ups, sorry, a typo. I meant AcpiDaemon.exe
> acpidaemon.log tells me that _S3_,_S4_,_S5_ are supported (whatever
> _S5_ means,
S3 = suspend (to RAM)
S4 = hibernate
S5 = power off :-)
> I cannot correlate it to the states that acpid.cfg lists).
You can only use S3. S4 is not implemented in out ACPI driver yet,
and power off makes no sense here. Some BIOS's suports S1 too.
S1 is a 'light' sleep mode, where system still runs, but screen and disks
and some devices are turned off.
> don't understand where to look for in the acpimanager.exe output.
Once again sorry - it was acpidaemon - and you already found it :-)
> Any of these (S3,S4) will lead to the problems mentioned. Only if I
> completely disable sleep will my PC work reliably.
S3 (Suspend) is only called when you specific calls it.
> >> Everyone who has hangs on boot: would you please also try and at least
> >> deactivate Sleep and see if that helps and report results here ?
> >
> > The only time 'Sleeptime ' is used, is when you try to call 'Suspend'.
>
> Ok, what I don't see is: when and from where do I call "Suspend" ? Is it
> the old APM.SYS programming interface for device drivers and
> applications ?
Yes, you can call it from X or from POWER object
Allan
> On Sun, 01 Nov 2009 10:32:44 +0100, Lars Erdmann <lars.e...@arcor.de> wrote:
>
> >> The only time 'Sleeptime ' is used, is when you try to call 'Suspend'.
> >
> > Ok, what I don't see is: when and from where do I call "Suspend" ? Is it
> > the old APM.SYS programming interface for device drivers and
> > applications ? I will need to ask the XWorkplace developers what they do
> > when "Sleep" is activtated via XCenter ...
>
> It calls method _wpChangePowerstate(6,0,1,2) in the WPPower class. This
> resolves to calling the relevant DosDevIOCtl() in APM.SYS
>
> I thought ACPI implemented a replacement APM interface which diverted these
> APM calls to ACPI. Am I wrong?
Not at all - that is what the APM.ADD driver, that comes with ACPI driver does.
Lars Erdmann
Paul Ratcliffe schrieb:
1.) Your understanding was right. Allan seconds what you are saying (I
guess with "ACPI" you meant APM.ADD that comes along with the ACPI
implementation. That is what Allan misinterpreted in his other answer).
2.) I completely agree, it should NOT be necessary to directly "call
into any ACPI.PSD/APM.ADD specifics". APM.ADD should definitely offer
the EXACT same programming interface that APM.SYS used to offer: the
same IDC for device drivers, the same IOCTL for applications. And in
fact it does so.
Thanks for your answer,
Lars
Paul Ratcliffe
>> I thought ACPI implemented a replacement APM interface which diverted these
>> APM calls to ACPI. Am I wrong?
>
> 1.) Your understanding was right. Allan seconds what you are saying (I
> guess with "ACPI" you meant APM.ADD that comes along with the ACPI
> implementation. That is what Allan misinterpreted in his other answer).
Yes, I did mean APM.ADD
> 2.) I completely agree, it should NOT be necessary to directly "call
> into any ACPI.PSD/APM.ADD specifics". APM.ADD should definitely offer
> the EXACT same programming interface that APM.SYS used to offer: the
> same IDC for device drivers, the same IOCTL for applications. And in
> fact it does so.
So why does it not seem to work then? Theoretically using either the
APM code or the ACPI code in XWP ought to produce the same results,
but it clearly does not, given the number of complaints I've had about
people using the APM interface on a machine using ACPI.
Allan
>
> > 2.) I completely agree, it should NOT be necessary to directly "call
> > into any ACPI.PSD/APM.ADD specifics". APM.ADD should definitely offer
> > the EXACT same programming interface that APM.SYS used to offer: the
> > same IDC for device drivers, the same IOCTL for applications. And in
> > fact it does so.
>
> So why does it not seem to work then? Theoretically using either the
> APM code or the ACPI code in XWP ought to produce the same results,
> but it clearly does not, given the number of complaints I've had about
> people using the APM interface on a machine using ACPI.
Are you sure that:
- they actually test both ACPI and APM in same setup ( or
just reported problems with one of them (never testing the other)
- they actually was running a matching pair of ACPI and APM ?
(there is no check for that)
- they have remembered to start acpidaemon (from startup.cmd)
- they do really know what they talk about ;-)
That said, I have sometimes seem differences sometimes.
Anyway - ACPI is betasoftware (at best) and will stay that way for years.
Lars Erdmann
>> into any ACPI.PSD/APM.ADD specifics". APM.ADD should definitely offer
>> the EXACT same programming interface that APM.SYS used to offer: the
>> same IDC for device drivers, the same IOCTL for applications. And in
>> fact it does so.
>
> So why does it not seem to work then? Theoretically using either the
> APM code or the ACPI code in XWP ought to produce the same results,
> but it clearly does not, given the number of complaints I've had about
> people using the APM interface on a machine using ACPI.
Hi Paul,
the reason is: APM.ADD does not support the following UNDOCUMENTED APM
IOCTL functions:
#define APMGIO_ConfirmEvent 0x42 // 0x42 is UNDOCUMENTED.
#define APMGIO_BroadcastEvent 0x43 // 0x43 is UNDOCUMENTED.
#define APMGIO_RegDaemonThread 0x44 // 0x44 is UNDOCUMENTED.
#define APMGIO_OEMFunction 0x45
#define APMGIO_SetResumeTimer 0x46
#define APMGIO_QueryState 0x63
#define APMGIO_QueryCaps 0x64
#define APMGIO_QueryResumeTimer 0x65
#define APMGIO_QuerySettings 0x66
see DDK DDK\base\h\apmioctl.h
Most of these missing calls seem to be the additions APM Version 1.1 ->
APM Version 1.2. I already addressed this to the ACPI developers.
APMGIO_OEMFunction is a nice one: it offers a register interface. You
can pass the exact register values. That allows to invoke ANY APM call
that you can think of (APM Version 1.2 even offers arbitrary calls for
OEM vendors and I guess that is what it is primarily meant for).
Lars
Paul Ratcliffe
>> > 2.) I completely agree, it should NOT be necessary to directly "call
>> > into any ACPI.PSD/APM.ADD specifics". APM.ADD should definitely offer
>> > the EXACT same programming interface that APM.SYS used to offer: the
>> > same IDC for device drivers, the same IOCTL for applications. And in
>> > fact it does so.
>>
>> So why does it not seem to work then? Theoretically using either the
>> APM code or the ACPI code in XWP ought to produce the same results,
>> but it clearly does not, given the number of complaints I've had about
>> people using the APM interface on a machine using ACPI.
>
> Are you sure that:
> - they actually test both ACPI and APM in same setup ( or
> just reported problems with one of them (never testing the other)
They report that APM doesn't work and ACPI does.
> - they actually was running a matching pair of ACPI and APM ?
I have no idea.
> - they have remembered to start acpidaemon (from startup.cmd)
I have no idea.
> - they do really know what they talk about ;-)
Presumably they can tell the difference between a machine powering off
correctly and not.
> That said, I have sometimes seem differences sometimes.
That just adds further weight of evidence that there is something wrong.
Paul Ratcliffe
>>> 2.) I completely agree, it should NOT be necessary to directly "call
>>> into any ACPI.PSD/APM.ADD specifics". APM.ADD should definitely offer
>>> the EXACT same programming interface that APM.SYS used to offer: the
>>> same IDC for device drivers, the same IOCTL for applications. And in
>>> fact it does so.
>>
>> So why does it not seem to work then? Theoretically using either the
>> APM code or the ACPI code in XWP ought to produce the same results,
>> but it clearly does not, given the number of complaints I've had about
>> people using the APM interface on a machine using ACPI.
>
> the reason is: APM.ADD does not support the following UNDOCUMENTED APM
> IOCTL functions:
> #define APMGIO_ConfirmEvent 0x42 // 0x42 is UNDOCUMENTED.
> #define APMGIO_BroadcastEvent 0x43 // 0x43 is UNDOCUMENTED.
> #define APMGIO_RegDaemonThread 0x44 // 0x44 is UNDOCUMENTED.
>
> Most of these missing calls seem to be the additions APM Version 1.1 ->
> APM Version 1.2. I already addressed this to the ACPI developers.
> APMGIO_OEMFunction is a nice one: it offers a register interface. You
> can pass the exact register values. That allows to invoke ANY APM call
> that you can think of (APM Version 1.2 even offers arbitrary calls for
> OEM vendors and I guess that is what it is primarily meant for).
Interesting. Thanks for the info. Maybe it stands some chance of getting
looked at then.
ivan
Don't hold you breath while waiting Paul. The developers seem hell
bent on reinventing the wheel.
ivan
--