> > I am having problems getting APM to work on my laptop (a Dell
> > Latitude XPi/CD 150), and I would like to know:
> >
> >  o Is the APM code considered to be stable and/or usable in
> >    1.3_ALPHA?
>
> Well, it works fine on my laptop, as long as I don't run apmd.
> (My laptop, a ThinkPad 760EL, seems to want to deliver _lots_ of
> certain types of APM events, e.g. suspend requests, rather than just
> one, e.g. when the lid is closed.  This ends up confusing the
> kernel+apmd, such that both try to suspend the system...)

Ok.  On my laptop I am currently running apmd.

If I run the GENERIC kernel (which doesn't have APM compiled in),
the hardware-initiated suspend functions (both the "suspend button"
and "close lid") work (!), but my PCMCIA ethernet card appears to
need an "ifconfig down"/"ifconfig up" transition after resume to
work again.  This was what got me to compile in APM support and
start apmd, since I think it's apmd which takes care of running the
"pre-suspend" shell script (which I've set up to ifconfig the
ethernet down before suspend and configure it up again after
resume), and this is what got me into debugging this problem.

> > After autoconf it continues on with printing messages
> > "apmcall: func 11 from line 509 -> 0x1" about once per
> > second.
>
> Right that's "what events do you have waiting?" "none!"

Yep, I guessed that.

> > If I log in and do "zzz", I get "Suspending system..." and the
> > following debug lines:
> >
> > apmcall: func 11 from line 509 -> 0x1
> > apmcall: func 10 from line 676 -> 0x0
>
> This is the APM code (successfully) getting the power status.
> (What version of the driver are you running, BTW?  those line numbers
> ... don't seem right.)

I'm running the version I SUPed Nov 15, and it is the same one
which is available on the 1.3 release branch.

> > apmcall: func  7 from line 604
> >
> > and the cursor just sits behind the "604".  The bell "beeps" at
> > the same time the last line is printed, but the screen is still
> > on, and the power indicator on the PC is also on, but at this
> > point the PC appears to be completely wedged, so I need to power
> > cycle it to get its attention back.
>
> That is theoretically where it's trying to suspend the system.

Yup, that figures.

> > If I press the "suspend" function key, the behaviour is a little
> > different, I get:
> >
> > apmcall func 11 from line 509 -> 0x1
> > apmcall func 11 from line 509 -> 0x0
> > apmev: user suspend request
> > apmcall func  7 from line 604 -> 0x0
> > apmcall func 11 from line 509 -> 0x1
> > apmcall func  7 from line 604 -> 0x0
> > apmcall func 11 from line 509 -> 0x1
> > apmcall func  7 from line 604 -> 0x0
> > apmcall func 11 from line 509 -> 0x1
> > apmcall func  7 from line 604
> >
> > and it freezes (as above) at this point.
>
> Interesting that a number of set power state requests appear to have
> succeeded.  What happens to the system while this is happening?

Well, essentially nothing, the messages come in the "normal"
spacing given by the "func 11" entries.

The "beep" comes a short while (a second?) after the last line
above is printed, but again, it freezes instead of entering the
suspend state.

I will however note that if I type "halt" to my system with APM
compiled in, the power does get switched off automatically, so
apparently it can make *some* use of the APM functions (I guess
switching power completely off is also an APM function).

> > About 6 months ago (?) I used to run NetBSD on this laptop with
> > John Kohl's old PCMCIA patches and the then built-in APM support
> > (I think it was integrated at that time), and I remember APM as
> > working Just Fine on this machine with NetBSD.
>
> The basic operation of the code hasn't changed significantly sense
> then, only the way the APM driver is attached.

Hm.  Strange.  However, considering the above experience with the
GENERIC kernel, it is conceivable that I was running a kernel
without APM support at the time; my memory is too foggy for me to
remember exactly.

> > [autoconf debug output omitted]
>
> I can't see anything there that's obviously wrong.

Ok.  Not sure whether that's good or bad ;-)

> I want to think about it and play around with a few things.
> I'll get back to you.

Ok, that's much appreciated -- I'm looking forward to getting this
problem debugged and (hopefully) resolved.


- H=E5vard