Date: Sat, 17 May 2008 17:37:17 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Ariff Abdullah <ariff@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: BIOS Regression on HP/Compaq [d]v6000 series notebooks Message-ID: <20080517073716.GF80125@server.vk2pj.dyndns.org> In-Reply-To: <20080516202242.3992b284.ariff@FreeBSD.org> References: <20080428112623.GA99757@server.vk2pj.dyndns.org> <20080516202242.3992b284.ariff@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-May-16 20:22:42 +0800, Ariff Abdullah <ariff@freebsd.org> 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=3DACPI-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. Agreed. --=20 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. --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkguiywACgkQ/opHv/APuIe35gCeMJZZ6xAWf57r1gZnXV9fJozq MywAnRQ9coEtsiic4YDWL6TffqgJgK1x =ZvL/ -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080517073716.GF80125>