Subject: Re: Debugging apm
To: None <port-i386@netbsd.org>
From: Peter Seebach <seebs@plethora.net>
List: port-i386
Date: 08/10/2001 00:27:20
Peter Seebach writes:
>So, the new notebook won't sleep.  It says:

>Aug  9 17:01:09 ged /netbsd: APM set power state <1,2>: unable to enter reques
>ted state (0x6007)

>How do I interpret 0x6007?  The last time I had a similar problem, it was
>because I had an active PCMCIA interface card.  This time, I don't.  I tried
>adding "ifconfig tlp0 down" to /etc/apm/suspend, but it still doesn't like
>me.  So... how do I interpret this?  Anyone seen that particular magic cookie
>before?

I made a sort of indirect progress on this.  If instead of trying to
sleep APM_DEV_ALLDEVS, I go through a bunch of devices individually, the
laptop actually appears to go all the way to sleep.

Hmm.  Actually, I may have found a likely explanation:  There was some
discussion some time ago about a change to the npx0 handling (somewhere after
1.4Y, or around the introduction of npx_isa.c), which apparently broke this
on some thinkpads, and apparently also on my laptop.

Kevin Sullivan isolated it to:
	P arch/i386/conf/DR-EVIL (1.20 to 1.21)
	P arch/i386/conf/files.i386 (1.162 to 1.163)
	P arch/i386/isa/npx.c (1.71 to 1.72)
	U arch/i386/isa/npx_isa.c (created 1.1)
	U arch/i386/isa/npxvar.h (created 1.1)
	P arch/i386/pnpbios/files.pnpbios (1.7 to 1.8)
	U arch/i386/pnpbios/npx_pnpbios.c (created 1.1)

Anyone know more than me about why a change to the numeric coprocessor code
could cause this?  I don't see any references either in the APM code to the
coprocessor code, or in the coprocessor code to the APM code.

On an unrelated note, is there any interest in per-device suspend settings?
e.g., something like
	apm -z usb
I think this could probably be done.

-s