Solved (Re: FYI: acpi | boot hangs when Laptop not connected to AC | NEC Versa FM320)

[Matthew Dillon]

:This is because we lack devd framework that acpica5 relies on. I think you
:didn't see it throttle up/down when you plugged/unplugged the AC to your
:machine just before your fix. The acpi_cpu.c from FreeBSD-4.x installed an
:eventhandler power_profile_change so that a call to power_profile_set_state()
:called acpi_cpu_power_profile(). In FreeBSD-5.x, throttling on transition of
:power profile is handled via devd, so they don't have to install the
:eventhandler anymore. And this was why `economy' and 'performance' knobs
:were removed from hw.acpi.cpu. Bringing the eventhandler hook from 4.x code
:is probably the right fix at the moment, but it's less flexible than devd.

    Ok, I've fixed this, but there is still something that we are not doing.
    Let me demonstrate through the syscall1 sysperf:

LAPTOP: Sony TR3A.

(1) LAPTOP BOOTED WITH POWER CONNECTED:

    (throttle setting is 8)
    timing standard getuid() syscall
    getuid()  0.937s 1667100 loops =  0.562uS/loop

    disconnect power:

    (throttle setting is 4)
    timing standard getuid() syscall
    getuid()  0.938s 793800 loops =  1.182uS/loop

    reconnect power:

    (throttle setting is 8)
    timing standard getuid() syscall
    getuid()  0.937s 1667100 loops =  0.562uS/loop

(2) LAPTOP BOOTED WITH POWER DISCONNECTED:

    (throttle setting is 4)
    timing standard getuid() syscall
    getuid()  0.954s 468500 loops =  2.036uS/loop

    reconnect power:

    (throttle setting is 8)
    timing standard getuid() syscall
    getuid()  0.955s 992600 loops =  0.962uS/loop

You see the problem?  There seems to be a permanent skew when the
laptop is booted with power disconnected.  The cpu states are updated
properly, but the laptop is still only half as fast when power is reconnected,
and a quarter as fast (instead of half as fast) when power is disconnected.

I have no idea what is causing this.  I assume its some sort of ACPI event
or state setting that we are not handling.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>