Subject: Re: Call for testers: power management branch
To: Jared D. McNeill <jmcneill@invisible.ca>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: current-users
Date: 08/04/2007 11:15:24
On Fri, 3 Aug 2007 18:34:12 -0400 (EDT)
"Jared D. McNeill" <jmcneill@invisible.ca> wrote:

> Heyas folks --
> As some of you may know, I've spent the past few weeks plugging away
> at our power management support code. I'm now at the point where I
> need help with testing various hardware combinations. Testing is
> easy! -- boot the following kernel single-user and run 'apm -d -z' on
> an ACPI-capable machine:
> ftp://ftp.netbsd.org/pub/NetBSD/misc/jmcneill/pm/netbsd The code is
> available on the jmcneill-pm branch if you're feeling up to sending
> patches for your hardware also :-) Ok, now for the bad news:
>    * Only i386 is supported (I lack an amd64 laptop to work on this)
>    * MULTIPROCESSOR kernels probably won't resume properly.
>    * If a device driver spits out a 'WARNING: powerhook_establish is
>      deprecated' message when it attaches, the powerhook will not be
> run. You will need to convert it to the new API; see
> sys/dev/ic/hpet.c for a simple example, and sys/dev/usb/ehci_pci.c
> for a typical PCI power handler.
>    * You can't suspend from X yet.
> Now, what I need are reports containing the following information:
>    1. Output from 'dmidecode', found in pkgsrc/sysutils/dmidecode
>    2. Did NetBSD support ACPI suspend/resume before?
>    3. Does suspend/resume work with this new kernel?
>    4. If the system resumed, do any device drivers stop working?
>    5. Any other quirks after resume?
> One final note: For debugging power handlers for PCI devices,
> remember that pcictl's dump command is your friend :-) Cheers,

I tried your new kernel on a Thinkpad T42 (and I thank you for doing
this work!). Results were mixed but encouraging.  Unfortunately, I
didn't run dmidecode because this note was on the laptop I was testing,
so I didn't see that I was supposed to...

Anyway -- suspend/resume itself worked.  It did before these changes,
too.  The disk and CD worked after resume; I was able to keep a CD
mounted across a suspend/resume.

USB worked after a suspend/resume; it had not worked after an ACPI
resume before.  If, however, I had a flash disk mounted at suspend
time, it didn't work after resume unless I unmounted and mounted it
again.  A USB keyboard worked perfectly across a suspend/resume.
Plugging in my iPod indicates that the USB slots are powered down
properly.

ath0 works after suspend/resume (well, to the extent that it works at
all on 4.99.26, per another thread....).  I don't recall what it did
before.

wm0 does *not* work after resume.  Here's some relevant dmesg output:

wm0 at pci2 dev 1 function 0: Intel i82540EP 1000BASE-T Ethernet, rev. 3
wm0: interrupting at irq 11
wm0: 32-bit 33MHz PCI bus
wm0: 64 word (6 address bits) MicroWire EEPROM
wm0: Ethernet address 00:0d:60:b2:06:7e
makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 4
wm0: WARNING: powerhook_establish is deprecated; please see devpm(4)
wm0: WARNING: power management not supported
wm0: reset failed to complete
wm0: MDIC write error: phy 1 reg 4
wm0: MDIC write error: phy 1 reg 9
wm0: MDIC write error: phy 1 reg 0
wm0: device timeout (txfree 4091 txsfree 61 txnext 5)
wm0: reset failed to complete
wm0: MDIC write error: phy 1 reg 4
wm0: MDIC write error: phy 1 reg 9
wm0: MDIC write error: phy 1 reg 0
wm0: MDIC write error: phy 1 reg 16
wm0: MDIC write error: phy 1 reg 0
wm0: MDIC write error: phy 1 reg 4
wm0: MDIC write error: phy 1 reg 9
wm0: MDIC write error: phy 1 reg 0
wm0: device timeout (txfree 4089 txsfree 59 txnext 7)
wm0: reset failed to complete
wm0: MDIC write error: phy 1 reg 4
wm0: MDIC write error: phy 1 reg 9
wm0: MDIC write error: phy 1 reg 0
wm0: MDIC write error: phy 1 reg 16
wm0: MDIC write error: phy 1 reg 0
wm0: MDIC write error: phy 1 reg 4
wm0: MDIC write error: phy 1 reg 9
wm0: MDIC write error: phy 1 reg 0

The MDIC errors persist until if ifconfig the device down.  Doing
ifconfig down/up does not restore functionality, it just causes the
errors to resume...

Audio was mixed.  After a resume, *something* was working, in that
echoing ^g to the console produced a beep.  However, mpg123 did not
work afterwards.  It's possible that some relevant setting wasn't
restored; however, outputs.master's value (which I have to set to
255,255 at boot time) was restored properly.  Here is the only dmesg
about it:

auich0 at pci0 dev 31 function 5: i82801DB/DBM (ICH4/ICH4M) AC-97 Audio
auich0: interrupting at irq 11
auich0: ac97: Analog Devices AD1981B codec; headphone, 20 bit DAC, no
3D stereo auich0: ac97: ext id 601<AC97_22,AMAP,VRA>
auich0: WARNING: powerhook_establish is deprecated; please see devpm(4)
auich0: WARNING: power management not supported
auich0: measured ac97 link rate at 48000 Hz
audio0 at auich0: full duplex, mmap, independent
audio0: audio device class power management enabled
audio0: supported states: D0 D3

A CF disk in a cbb slot worked properly after resume, even if it was
mounted at suspend time.  The blinkenlights on an EVDO card (which
shows up as umodem0 attached to ohci attached to cbb) indicate that the
slot was not powered down by a suspend.  (No surprise, since the driver
for cbb warns that it doesn't support powerhooks.)  Leaving the EVDO
card in across suspend/resume had mixed results.  Once, it worked after
resume (though it took a few seconds); once, it didn't, and I couldn't
even get out of cu.  

The VGA display was cleared by the resume process, a minor nuisance.  

Sometimes -- I'm not certain how often -- I got two 'resume' messages
on the console.  I'm not sure if that's real or if it's some artifact
of syslogd not running.  (All tests were done in single-user mode with
the disk mounted read-only.)

dmesg output available on request.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb