Re: ENXIOing non-present battery
On Thursday, December 11, 2014 01:05:49 PM Colin Percival wrote: On 12/11/14 11:08, John Baldwin wrote: On Sunday, December 07, 2014 2:53:37 am Colin Percival wrote: On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First the battery which exists; and second, a Not Present battery with zeroed statistics. FreeBSD, not realizing that this second battery is a complete myth -- the E7440 only has one battery, and there is nowhere to add another -- faithfully reports the data from ACPI to userland. 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. 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)? -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
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... 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. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
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 ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
Just remember, batteries can come and go, so we can't just ignore a battery because the status says not present. So I think it's a bug in hald. -adrian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On Sunday, December 07, 2014 2:53:37 am Colin Percival wrote: Hi ACPI people, On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First the battery which exists; and second, a Not Present battery with zeroed statistics. FreeBSD, not realizing that this second battery is a complete myth -- the E7440 only has one battery, and there is nowhere to add another -- faithfully reports the data from ACPI to userland. Unfortunately it causes some problems there; in particular, KDE interprets it as meaning that the system should have two batteries, and when it sees that the second battery has 0% power remaining it kicks off the battery is low, turn the laptop off code. If that code is disabled, it still displays the wrong battery-charge-remaining status icons. For dealing with such broken ACPIs, it seems like not attaching a non-present battery would be a good idea. This shouldn't be the default behaviour, since there are plenty of systems where a non-present battery might be inserted at a later time; but I see nothing wrong with adding an option. The attached patch adds a acpi.cmbat.hide_not_present loader tunable which, as the name suggests, hides non-present batteries; this is done in the probe code by returning ENXIO if the tunable is set to a nonzero value and acpi_BatteryIsPresent returns zero. With this patch and the tunable set my laptop behaves appropriately; and (aside from wasting a few bytes of memory) there should be no effect on systems where the tunable is not set. Any objections to me committing this? Does setting hint.battery.1.disabled=1 work for you? -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On 12/11/14 11:08, John Baldwin wrote: On Sunday, December 07, 2014 2:53:37 am Colin Percival wrote: On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First the battery which exists; and second, a Not Present battery with zeroed statistics. FreeBSD, not realizing that this second battery is a complete myth -- the E7440 only has one battery, and there is nowhere to add another -- faithfully reports the data from ACPI to userland. 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... -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On Tue, 9 Dec 2014 10:42:39 +0100, Dan Lukes wrote:
On 12/09/14 06:33, Ian Smith:
Normally with 2 batteries catered for and only one fitted you'd expect to
see
battery1: ACPI Control Method Battery on acpi0
battery1: battery initialization start
battery1: battery initialization failed, giving up
Just for the completeness ...
... it is expected behavior for non-present battery. Relevant part of code
(sys/dev/acpica/acpi_cmbat.c):
ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),
battery initialization start\n);
...
for (retry = 0; retry ACPI_CMBAT_RETRY_MAX; retry++,
AcpiOsSleep(1)) {
...
if (!acpi_BatteryIsPresent(dev))
continue;
...
}
if (retry == ACPI_CMBAT_RETRY_MAX) {
ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),
battery initialization failed, giving up\n);
Yes, I just wanted to eliminate the battery being erroneously detected
as being present on initialisation.
So this problem seems likely to be down to (at least) one of:
a) a bug in our ACPI code;
b) a bug in this machine's AML (which we haven't seen);
c) a bug in hald.
.. which is hardly helpful, I know. I had a quick browse of the scripts
and FreeBSD backend bits of sysutils/hal, and was frankly too horrified
to consider trying to browse its full sources.
cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On 12/09/14 06:33, Ian Smith:
Normally with 2 batteries catered for and only one fitted you'd expect to see
battery1: ACPI Control Method Battery on acpi0
battery1: battery initialization start
battery1: battery initialization failed, giving up
Just for the completeness ...
... it is expected behavior for non-present battery. Relevant part of
code (sys/dev/acpica/acpi_cmbat.c):
ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),
battery initialization start\n);
...
for (retry = 0; retry ACPI_CMBAT_RETRY_MAX; retry++, AcpiOsSleep(1)) {
...
if (!acpi_BatteryIsPresent(dev))
continue;
...
}
if (retry == ACPI_CMBAT_RETRY_MAX) {
ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),
battery initialization failed, giving up\n);
Dan
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On 12/08/14 15:27, Adrian Chadd wrote: What's the output of acpiconf -i0 and acpiconf -i1? acpiconf -i0 is exactly what you'd expect. acpiconf -i1 shows blank for the model/serial/type/OEM info strings, and 0 mAh/mV for the rest except State which is not present. I wonder if changing 'state' to something else would keep everything happy. I can't see how it would. The hald code uses hw.acpi.battery.units to see how many batteries there are, then reads the _BIF data via ioctl; the state isn't even in _BIF. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On 12/08/14 21:33, Ian Smith wrote: And what does 'grep battery /var/run/dmesg.boot' have to say? Normally with 2 batteries catered for and only one fitted you'd expect to see eg: ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0: ACPI Control Method Battery on acpi0 ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery1: ACPI Control Method Battery on acpi0 ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0: battery initialization start ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery1: battery initialization start ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0: battery initialization done, tried 1 times ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery1: battery initialization failed, giving up Yes, that's exactly what I see. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On 12/07/14 08:03, Adrian Chadd wrote: How's this work on other systems? KDE on Linux doesn't lose its mind if the second battery is totally flat. I just booted Ubuntu 14.04, and both batteries appear in /proc/acpi/battery; but BAT1 just shows present: no without any statistics, and the GUI shows the correct state for the single present battery. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
What's the output of acpiconf -i0 and acpiconf -i1? I wonder if changing 'state' to something else would keep everything happy. -adrian On 8 December 2014 at 15:08, Colin Percival cperc...@freebsd.org wrote: On 12/07/14 08:03, Adrian Chadd wrote: How's this work on other systems? KDE on Linux doesn't lose its mind if the second battery is totally flat. I just booted Ubuntu 14.04, and both batteries appear in /proc/acpi/battery; but BAT1 just shows present: no without any statistics, and the GUI shows the correct state for the single present battery. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On Mon, 8 Dec 2014 15:27:10 -0800, Adrian Chadd wrote: What's the output of acpiconf -i0 and acpiconf -i1? I wonder if changing 'state' to something else would keep everything happy. On 8 December 2014 at 15:08, Colin Percival cperc...@freebsd.org wrote: On 12/07/14 08:03, Adrian Chadd wrote: How's this work on other systems? KDE on Linux doesn't lose its mind if the second battery is totally flat. I just booted Ubuntu 14.04, and both batteries appear in /proc/acpi/battery; but BAT1 just shows present: no without any statistics, and the GUI shows the correct state for the single present battery. And what does 'grep battery /var/run/dmesg.boot' have to say? Normally with 2 batteries catered for and only one fitted you'd expect to see eg: ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0: ACPI Control Method Battery on acpi0 ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery1: ACPI Control Method Battery on acpi0 ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0: battery initialization start ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery1: battery initialization start ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery0: battery initialization done, tried 1 times ./nicks_acpi/dmesg-bootwithacpi-2-part.txt:battery1: battery initialization failed, giving up cheers, Ian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
Colin Percival wrote: it seems like not attaching a non-present battery would be a good idea. This shouldn't be the default behaviour, since there are plenty of systems where a non-present battery might be inserted at a later time; but I see nothing wrong with adding an option. The attached patch adds a acpi.cmbat.hide_not_present loader tunable which, as the name suggests, hides non-present batteries; this is done in the probe code by returning ENXIO Any objections to me committing this? No, but it may be more useful to create more generalized interface. A remember broken ACPI with issues related to ghost floppy drive when no real floppy drive has been present. Not only battery, but any device should be considered non-attachable upon administrator request. Just my $0.02 Dan ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On 12/07/14 00:28, Dan Lukes wrote: Colin Percival wrote: it seems like not attaching a non-present battery would be a good idea. This shouldn't be the default behaviour, since there are plenty of systems where a non-present battery might be inserted at a later time; but I see nothing wrong with adding an option. The attached patch adds a acpi.cmbat.hide_not_present loader tunable which, as the name suggests, hides non-present batteries; this is done in the probe code by returning ENXIO Any objections to me committing this? No, but it may be more useful to create more generalized interface. I agree in theory, but do you have any idea how to do this? A remember broken ACPI with issues related to ghost floppy drive when no real floppy drive has been present. Not only battery, but any device should be considered non-attachable upon administrator request. In the case of my laptop, the only way I can see to distinguish between the real battery and the ghost battery is that the latter returns zero from acpi_BatteryIsPresent; and that won't work for non-battery devices. There is, of course, the option of using debug.apci.disabled to disable complete subsystems, but I only want to hide the ghost battery, not the real one. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
Colin Percival wrote: The attached patch adds a acpi.cmbat.hide_not_present loader tunable which, as the name suggests, hides non-present batteries; this is done in the probe code by returning ENXIO No, but it may be more useful to create more generalized interface. I agree in theory, but do you have any idea how to do this? Well, may be I'm not the best expert on the matter, but I assume there is an device enumerator which invoke probe function of device drivers. Such enumerator should skip the devices listen in don't probe list. I'm aware there is no single enumerator in the kernel. All those enumerators needs to be patched to honor such list. Other solutions: No enumerator needs to be patched. There needs to be device driver module which will claim high priority ownership of all devices on the disabled device list. So particular device will be attached to such special driver, not to the standard one. In the case of my laptop, the only way I can see to distinguish between the real battery and the ghost battery is that the latter returns zero from acpi_BatteryIsPresent; In case of your particular laptop you can claim second battery to be ghost battery as you know there is no second battery now and will not be even in the future. So no battery device driver needs to be attached to such device. It will hide such battery from applications. By the way, as long as your ACPI claim non-existent battery as non existent, it seems not to be broken. If KDE read remaining capacity of battery claimed to be non-present, then it seems to be KDE who have broken logic ... There is, of course, the option of using debug.apci.disabled to disable complete subsystems, but I only want to hide the ghost battery, not the real one. I asked for more generic mechanism, but not as generic as you described. It would eb nice if we can disable enumeration of broken devices only (despite they are enumerated trough ACPI, PNP, PCI, USB or so enumerator), not the just ACPI at all. Dan ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
Hi, Wait - so it reports a battery with 0% in it, but not that it's not present? How's this work on other systems? KDE on Linux doesn't lose its mind if the second battery is totally flat. -adrian On 6 December 2014 at 23:53, Colin Percival cperc...@freebsd.org wrote: Hi ACPI people, On my Dell Latitude E7440 laptop, the ACPI reports two batteries: First the battery which exists; and second, a Not Present battery with zeroed statistics. FreeBSD, not realizing that this second battery is a complete myth -- the E7440 only has one battery, and there is nowhere to add another -- faithfully reports the data from ACPI to userland. Unfortunately it causes some problems there; in particular, KDE interprets it as meaning that the system should have two batteries, and when it sees that the second battery has 0% power remaining it kicks off the battery is low, turn the laptop off code. If that code is disabled, it still displays the wrong battery-charge-remaining status icons. For dealing with such broken ACPIs, it seems like not attaching a non-present battery would be a good idea. This shouldn't be the default behaviour, since there are plenty of systems where a non-present battery might be inserted at a later time; but I see nothing wrong with adding an option. The attached patch adds a acpi.cmbat.hide_not_present loader tunable which, as the name suggests, hides non-present batteries; this is done in the probe code by returning ENXIO if the tunable is set to a nonzero value and acpi_BatteryIsPresent returns zero. With this patch and the tunable set my laptop behaves appropriately; and (aside from wasting a few bytes of memory) there should be no effect on systems where the tunable is not set. Any objections to me committing this? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On 12/07/14 08:03, Adrian Chadd wrote: Wait - so it reports a battery with 0% in it, but not that it's not present? It reports all zeroes: Not Present, 0% power, 0V, 0mA design capacity, etc. How's this work on other systems? KDE on Linux doesn't lose its mind if the second battery is totally flat. Good question. I'll download an Ubuntu image and find out. Given that KDE gets this information via hald, it's possible that hald's linux code has a workaround for this though -- the battery-status-reading code is entirely separate between FreeBSD and Linux. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: ENXIOing non-present battery
On 07/12/2014 22:49, Colin Percival wrote: On 12/07/14 08:03, Adrian Chadd wrote: Wait - so it reports a battery with 0% in it, but not that it's not present? It reports all zeroes: Not Present, 0% power, 0V, 0mA design capacity, etc. How's this work on other systems? KDE on Linux doesn't lose its mind if the second battery is totally flat. Good question. I'll download an Ubuntu image and find out. Given that KDE gets this information via hald, it's possible that hald's linux code has a workaround for this though -- the battery-status-reading code is entirely separate between FreeBSD and Linux. Or that HAL is no longer used at all in most Linux-based OSes... -- Andriy Gapon ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
