BIOS Regression on HP/Compaq [d]v6000 series notebooks
ariff at FreeBSD.org
Sat May 17 11:43:44 UTC 2008
On Sat, 17 May 2008 17:37:17 +1000
Peter Jeremy <peterjeremy at optushome.com.au> wrote:
> On 2008-May-16 20:22:42 +0800, Ariff Abdullah <ariff at freebsd.org>
> >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.
It is not their fault, really. It is expected to lower down
everything, either forcefully or not whenever you loose main power
connection to conserve power usages. The problem is with FreeBSD own
timer which relies on local APIC timer that went dead whenever it
enter lowest power state (and lapic timer is _mandatory_ for
APIC/SMP as in FreeBSD case). If you manage to boot without apic (thus
using old/legacy i8254 timer, SMP disabled), you'll find that
everything runs normally. Booting without apic is quite tricky
especially on modern hardwares.
> >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.
Install sysutils/devcpu from ports, load cpu.ko, and grab / compile
http://people.freebsd.org/~ariff/misc/k8c1e/ . Try playing with it
(enable, disable, status)
... Recording in stereo is obviously too advanced
and confusing for us idiot ***** users :P ........
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080517/018c33c3/attachment.pgp
More information about the freebsd-acpi