BIOS Regression on HP/Compaq [d]v6000 series notebooks

Peter Jeremy peterjeremy at
Sat May 17 07:37:21 UTC 2008

On 2008-May-16 20:22:42 +0800, Ariff Abdullah <ariff at> wrote:
>After the recent update, the BIOS decided to force/enable C1E whenever
>it losing main power:

That explains the behaviour I see.

> not their (HP) fault though.

I don't follow this.  HP released a BIOS that is broken.  Either they
did it deliberately, they didn't bother testing it or they don't care.

>Try this patch (against -current, should be OK for other branches
>too). With this patch, whenever AC line state change it will
>disable C1E, hopefully.

Thanks for that.  I've tried it against the latest 6-STABLE and it
applies OK.  The results are mixed though.  If I run top(1) and remove
power, top's clock stops.  When I plug power back in, the clock jumps
to the current time - ntpq shows no time jump so the kernel time-
keeping is still OK.  I've tried this in both single-user and multi-
user within X.  I get the same behaviour with xclock(1) within X.

If I move the mouse, window focus changes appropriately and if I
wave the mouse enough, the clocks will jump to the correct time.

The above is all with kern.timecounter.hardware=ACPI-fast.  I tried
using HPET but the behaviour is the same.

Having the system recover when power is re-applied is a big
improvement over the previous behaviour but I don't understand
the current behaviour - it's far more responsive than it was without
the C1E patch but is still not behaving correctly.

>Hack or no hack, there must be a better / appropriate solution for
>this issue.


Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url :

More information about the freebsd-acpi mailing list