Date: Sat, 13 Dec 2014 16:48:48 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Colin Percival <cperciva@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ENXIOing non-present battery Message-ID: <20141213154603.L68123@sola.nimnet.asn.au> In-Reply-To: <548B6DE2.10509@freebsd.org> References: <54840781.70603@freebsd.org> <201412111408.50866.jhb@freebsd.org> <548A072D.7090304@freebsd.org> <6449474.BnGsyZAKhP@ralph.baldwin.cx> <548B6DE2.10509@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Dec 2014 14:36:18 -0800, Colin Percival wrote: > On 12/12/14 07:21, John Baldwin wrote: > > On Thursday, December 11, 2014 01:05:49 PM Colin Percival wrote: > >> On 12/11/14 11:08, John Baldwin wrote: > >>> Does setting hint.battery.1.disabled=1 work for you? > >> > >> That fixes the dev.battery sysctls and KDE's battery monitor. The > >> hw.acpi.battery.units sysctl still reports "2", and `acpiconf -i 1` > >> still reports the phantom battery; but I suppose those don't matter > >> much... > > > > Ok. That is the "generic" thing we already have in place to disable devices, > > so I'd probably prefer to use that as the known workaround rather than adding > > another knob. > > OK, I'll stick to using that one. My original thinking was that disabling > "whatever isn't present" would avoid the need for a user to figure out which > number it was; but it's probably safe to assume that batteries will always > be probed in the same order... I believe so, given that they're enumerated that way in the AML, and disassemble to such as BAT0 and BAT1. On my X200 for instance, there's quite a bit of ASL code about whether it's docked or not controlling BATn notifications, as with these and some HPs I've tried to follow that's where a second battery may live. It wouldn't surprise me to find 'DCK' or similar symbols in your ASL, and BAT0 or BAT1 conditionally enabled (or visible) or not, assuming there'd be a dock available for that model, or family? > > That said, it looks like we report the userland state of "not > > present" correctly. I wonder if the bug is in KDE itself and its > > FreeBSD-specific power management bits (rather than hald)? > > The FreeBSD-specific userland bits are in hald. I've yet to update my 9.3-PRE X200 to new Xorg and a later KDE than that installed at 9.2-R, and disabled what I could of KDE's power mgmt stuff, but haven't noticed reports of other laptops having this specific issue. Maybe hald is being misinformed? Care to put up the acpidump somewhere? Not that I could follow it well enough to debug, if that were the issue, but there might be an obvious clue .. Though you may be happy with the workaround and have other stuff to do! cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141213154603.L68123>