ThinkPad and ACPI on FreeBSD 7.0

Bob Krzaczek krz at cis.rit.edu
Fri May 16 02:15:43 UTC 2008


Hi there,

I've been investigating why my ThinkPad T42p, with FreeBSD-7.0, only 
successfully resumes from a suspend-to-memory once in a very great 
while.  Most of the time it hangs on a resume, and once in a while it 
panics.

I've seen similar reports to what I'm seeing below in the bug database. 
  The general sequence is this:  Press the sleep key.  /etc/rc.suspend 
runs (see below for a note about this).  The last thing I see on the 
console before the backlight turns off is

     acpi_ec0: warning: EC done before starting event wait

And then the system is down and off in sleep mode.  Upon resuming the 
system, I first see this next message four times in a row.  It's not 
related to this bug, I believe.

     an0: unknown RID: 0

Anyway, ignoring the wireless, here's where it gets interesting.  Next 
we have

     subdisk0: detached
     disk0: detached

Followed by this resulting noise from geom,

     GEOM_LABEL: Label msdosfs/IBM_SERVICE removed.

And then anywhere from 5 to 100's of the following.

     g_vfs_done():ad0s3e[WRITE(offset=1355055104, length=16384)]error = 6

That error, I've seen in the bug database from other notebook users on 
resume.  I'm assuming that it's directly related to the detached drives. 
  ad0s3e is my /var slice.  On a previous install from a few days ago, 
with different drive partitioning, these messages reported a different 
slice that was /var on that configuration, too.  So far, it's always 
/var for me.

At a guess, I'm thinking that something (maybe the logger?) has some 
pending I/O to write before the system has really gotten into a 
quiescent state prior to shutdown.  The reason I'm considering the 
logger is that originally, the system didn't always crash, but then 
again, /etc/rc.suspend didn't get run, either.  I found a one-line patch 
on this mailing list recently for devctl_process_running(); once 
applied, /etc/rc.suspend runs every time.

Or, maybe the "detached" messages were supposed to occur earlier, during 
the suspend?  I'm just making guesses here, because I don't really 
understand the intended ACPI sequence of events.

What's more, I read about hw.acpi.sleep_delay.  I tried adjusting that, 
but it had no effect on my system.  Eventually, I traced it back to 
/usr/src/sys/dev/acpica/acpi.c where it seems the DELAY() has _no_ 
effect.  In fact, I even replaced the DELAY(...sleep_delay * 1000000) 
with a hardcoded 5000000 (five seconds), and the system still goes to 
sleep instantly after /etc/rc.suspend.  This, I'm sure, is at least part 
of the problem; there's no chance for the system to settle when suspending.

I've provided acpi and acpi_ibm dumps from sysctl, the ASL dump, 
device.hints, dmesg, loader.conf, rc.conf, and sysctl.conf information 
at the following URI:

     http://30dor.com/freebsd-acpi/

I'm quite willing to try patches or other things you might suggest.  The 
fact that DELAY() isn't working in acpi_EnterSleepState() has me most 
concerned at the moment.  Alternatively, should I go to APM, or even 
install FreeBSD 6.3 or 6.2?  Would that run better in my particular case?

Looking for advice, willing to be a guinea pig... ;-)

Cheers,
Bob

-- 
Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT
phone +1-585-4757196, email krz at cis.rit.edu, icbm 43.0848N 77.6789W


More information about the freebsd-acpi mailing list