Re: [2.624-rc1 regression] lost battery information
On Friday 26 October 2007, Alexey Starikovskiy wrote:
Your cat's Bad address means -EFAULT, according to man errno.
Please apply this patch to see what exactly failed...
[ 1191.471572] ACPI: element[12]-type = 1, expected string
[ 1196.640065] ACPI: element[12]-type = 1, expected string
[ 1199.479773] ACPI: element[12]-type = 1, expected string
[ 1199.745435] ACPI: element[12]-type = 1, expected string
it is OEM type. For reference here is _BIF from my DSDT:
Method (_BIF, 0, NotSerialized)
{
Name (BUFF, Package (0x0D) {})
Store (0x00, Index (BUFF, 0x00))
Store (\_SB.MEM.BDV2, Local2)
Multiply (\_SB.MEM.BDC2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x01))
Multiply (\_SB.MEM.BLF2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x02))
Store (\_SB.MEM.BTC2, Index (BUFF, 0x03))
Store (\_SB.MEM.BDV2, Index (BUFF, 0x04))
Multiply (\_SB.MEM.BCW2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x05))
Multiply (\_SB.MEM.BCL2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x06))
Multiply (\_SB.MEM.BG12, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x07))
Multiply (\_SB.MEM.BG22, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x08))
Store (\_SB.MEM.BMN2, Index (BUFF, 0x09))
Store (\_SB.MEM.BSN2, Index (BUFF, 0x0A))
Store (\_SB.MEM.BTP2, Index (BUFF, 0x0B))
Store (\_SB.MEM.BOI2, Index (BUFF, 0x0C))
Return (BUFF)
}
This is behaviour change. Previous battery.c used generic acpi_extract_package
which allowed (allows) for object of type integer when string is requested:
case ACPI_TYPE_INTEGER:
switch (format_string[i]) {
case 'N':
size_required += sizeof(acpi_integer);
tail_offset += sizeof(acpi_integer);
break;
case 'S':
size_required +=
sizeof(char *) + sizeof(acpi_integer) +
sizeof(char);
tail_offset += sizeof(char *);
break;
while current battery.c:extract_package fails:
if (offsets[i].mode) {
if (element-type != ACPI_TYPE_STRING
element-type != ACPI_TYPE_BUFFER) {
printk (KERN_ERR PREFIX element[%d]-type = %x, expected string\n, i,
element-type);
return -EFAULT;
}
well, while it could be BIOS fault this happily worked before ... This is
obviously also the reason why I do not have anything in /sys
Fans, could you check whether you have the same issue using test patch?
signature.asc
Description: This is a digitally signed message part.
Re: System hard lock when closing lid(2nd try)
On Fri, 2007-10-26 at 17:41 +0200, Raúl Sánchez Siles wrote: Hello All: Some time ago(2007/09/17) I wrote this e-mail: Raúl Sánchez Siles wrote: Hello all: I've searched for a more user related ML, but this is the closest I've found. I own a Dell inspiron 510m laptop which include the HW listed at [1] As you can see there the graphics card is an intel 855GM. The newer xorg intel driver tries to save power by disabling one of the video output pipes of the card, the one that could drive an external VGA monitor. As a result, someone told me that the system enters in SMM (System Management Mode), leaves the system in such a state that the system ends up locking totally: no ssh connection or sys-rq combination works, just hard power off. More details at https://bugs.freedesktop.org/show_bug.cgi?id=11432 This result is the same no matter what Linux version I use, tried 2.6.20,21 and 22. I have done some research as to know if this could be avoided some way in Linux. I ran the linux firmwarekit, I checked the dsdl table, I upgraded bios, tried different boot parameters but no valuable results I got. This information is available, so feel free to ask for it. I'd like to know if there's anything that could be done with regard to Linux kernel to soothe or solve the issue. Of course, I'm at your disposal to do whatever test is needed. Just in case, I also attach a dmesg output, maybe not the latest stable kernel, but still 2.6.22. Thanks a lot. [1] lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3580] (rev 02) 00:00.1 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3584] (rev 02) 00:00.3 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3585] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 81) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 01) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 01) 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 01) 00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 01) 01:01.0 CardBus bridge [0607]: Texas Instruments PCI4510 PC card Cardbus Controller [104c:ac44] (rev 02) 01:01.1 FireWire (IEEE 1394) [0c00]: Texas Instruments PCI4510 IEEE-1394 Controller [104c:8029] 01:03.0 Network controller [0280]: Intel Corporation PRO/Wireless 2200BG Network Connection [8086:4220] (rev 05) 01:08.0 Ethernet controller [0200]: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller [8086:103d] (rev 81) Maybe by that date there was nobody avaible for considering this issue so I'm trying again. The lid problem stills exist on a current Xorg version, even with intel video driver git version. I'm not surprised since I suspect heavily on a BIOS problem. I'm coming back with more attached info: There is probably a BIOS issue (from reports I've seen on this issue), however the git version of the xserver-xorg-video-intel driver does not address a couple of crashes with 855 hardware which are caused by the X driver writing registers in the card. http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2.diff.gz Shows the diff applied to a (yet unreleased) Ubuntu package for the drivers. (Applies against 2.1.1 release version). You should be able to find the patches in the debian/patches/ dir which the diff creates. It might be worth looking at these, and revisiting the BIOS issue if (as is unfortunately likely) if there remains an issue. Regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) - To unsubscribe from this list: send the line
Re: System hard lock when closing lid(2nd try)
Hello: Peter Clifton wrote: On Fri, 2007-10-26 at 17:41 +0200, Raúl Sánchez Siles wrote: Hello All: Some time ago(2007/09/17) I wrote this e-mail: Raúl Sánchez Siles wrote: Hello all: I've searched for a more user related ML, but this is the closest I've found. I own a Dell inspiron 510m laptop which include the HW listed at [1] As you can see there the graphics card is an intel 855GM. The newer xorg intel driver tries to save power by disabling one of the video output pipes of the card, the one that could drive an external VGA monitor. As a result, someone told me that the system enters in SMM (System Management Mode), leaves the system in such a state that the system ends up locking totally: no ssh connection or sys-rq combination works, just hard power off. More details at https://bugs.freedesktop.org/show_bug.cgi?id=11432 The lid problem stills exist on a current Xorg version, even with intel video driver git version. I'm not surprised since I suspect heavily on a BIOS problem. I'm coming back with more attached info: Thanks a lot for your reply, Peter. :) There is probably a BIOS issue (from reports I've seen on this issue), however the git version of the xserver-xorg-video-intel driver does not address a couple of crashes with 855 hardware which are caused by the X driver writing registers in the card. http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2.diff.gz Shows the diff applied to a (yet unreleased) Ubuntu package for the drivers. (Applies against 2.1.1 release version). You should be able to find the patches in the debian/patches/ dir which the diff creates. I've been following this thread on the xorg-devel ML, and I have those patches queued for testing ;) It might be worth looking at these, and revisiting the BIOS issue if (as is unfortunately likely) if there remains an issue. If you pay attention to https://bugs.freedesktop.org/show_bug.cgi?id=11432 I had published there a patch (comment #23) there that has been happily working for me since I post it (yet it works). But what it does is ugly and has drawbacks as explained there so I still consider it a workaround and not a final solution. That's the reason I came here, to check out wether the Linux kernel could address the issue. Regards, Raúl Sánchez Siles -Proud Debian user- Linux registered user #416098 - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.624-rc1 regression] lost battery information
Andrey,
Please try the attached patch. I choose to do snprintf() instead of direct copy,
as your previous message showed empty OEM type.
Thanks,
Alex.
Andrey Borzenkov wrote:
On Friday 26 October 2007, Alexey Starikovskiy wrote:
Your cat's Bad address means -EFAULT, according to man errno.
Please apply this patch to see what exactly failed...
[ 1191.471572] ACPI: element[12]-type = 1, expected string
[ 1196.640065] ACPI: element[12]-type = 1, expected string
[ 1199.479773] ACPI: element[12]-type = 1, expected string
[ 1199.745435] ACPI: element[12]-type = 1, expected string
it is OEM type. For reference here is _BIF from my DSDT:
Method (_BIF, 0, NotSerialized)
{
Name (BUFF, Package (0x0D) {})
Store (0x00, Index (BUFF, 0x00))
Store (\_SB.MEM.BDV2, Local2)
Multiply (\_SB.MEM.BDC2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x01))
Multiply (\_SB.MEM.BLF2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x02))
Store (\_SB.MEM.BTC2, Index (BUFF, 0x03))
Store (\_SB.MEM.BDV2, Index (BUFF, 0x04))
Multiply (\_SB.MEM.BCW2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x05))
Multiply (\_SB.MEM.BCL2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x06))
Multiply (\_SB.MEM.BG12, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x07))
Multiply (\_SB.MEM.BG22, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x08))
Store (\_SB.MEM.BMN2, Index (BUFF, 0x09))
Store (\_SB.MEM.BSN2, Index (BUFF, 0x0A))
Store (\_SB.MEM.BTP2, Index (BUFF, 0x0B))
Store (\_SB.MEM.BOI2, Index (BUFF, 0x0C))
Return (BUFF)
}
This is behaviour change. Previous battery.c used generic
acpi_extract_package
which allowed (allows) for object of type integer when string is requested:
case ACPI_TYPE_INTEGER:
switch (format_string[i]) {
case 'N':
size_required += sizeof(acpi_integer);
tail_offset += sizeof(acpi_integer);
break;
case 'S':
size_required +=
sizeof(char *) + sizeof(acpi_integer) +
sizeof(char);
tail_offset += sizeof(char *);
break;
while current battery.c:extract_package fails:
if (offsets[i].mode) {
if (element-type != ACPI_TYPE_STRING
element-type != ACPI_TYPE_BUFFER) {
printk (KERN_ERR PREFIX element[%d]-type = %x, expected string\n, i,
element-type);
return -EFAULT;
}
well, while it could be BIOS fault this happily worked before ... This is
obviously also the reason why I do not have anything in /sys
Fans, could you check whether you have the same issue using test patch?
ACPI: Battery: Allow extract string from integer
From: Alexey Starikovskiy [EMAIL PROTECTED]
Some machines return integer instead of expected string.
Signed-off-by: Alexey Starikovskiy [EMAIL PROTECTED]
---
drivers/acpi/battery.c | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 02a396d..6841358 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -260,7 +260,7 @@ static int extract_package(struct acpi_battery *battery,
union acpi_object *package,
struct acpi_offsets *offsets, int num)
{
- int i, *x;
+ int i;
union acpi_object *element;
if (package-type != ACPI_TYPE_PACKAGE)
return -EFAULT;
@@ -269,16 +269,20 @@ static int extract_package(struct acpi_battery *battery,
return -EFAULT;
element = package-package.elements[i];
if (offsets[i].mode) {
- if (element-type != ACPI_TYPE_STRING
- element-type != ACPI_TYPE_BUFFER)
-return -EFAULT;
- strncpy((u8 *)battery + offsets[i].offset,
-element-string.pointer, 32);
+ u8 *ptr = (u8 *)battery + offsets[i].offset;
+ if (element-type == ACPI_TYPE_STRING ||
+ element-type == ACPI_TYPE_BUFFER)
+strncpy(ptr, element-string.pointer, 32);
+ else if (element-type == ACPI_TYPE_INTEGER) {
+
Re: [2.624-rc1 regression] lost battery information
On Saturday 27 October 2007, Alexey Starikovskiy wrote:
Andrey,
Please try the attached patch. I choose to do snprintf() instead of direct
copy, as your previous message showed empty OEM type.
Not quite. Now I get
OEM info:0
while before I got empty string. If I read acpi_extract_package correctly, it
actually interpreted integer as string without any conversion. Which in this
case obviously gave us empty string (integer being 0). I'd prefer to remain
compatible.
also
{pts/1}% cat /sys/class/power_supply/BAT1/manufacturer
0
which is rather weird manufacturer name :)
Thanks,
Alex.
Andrey Borzenkov wrote:
On Friday 26 October 2007, Alexey Starikovskiy wrote:
Your cat's Bad address means -EFAULT, according to man errno.
Please apply this patch to see what exactly failed...
[ 1191.471572] ACPI: element[12]-type = 1, expected string
[ 1196.640065] ACPI: element[12]-type = 1, expected string
[ 1199.479773] ACPI: element[12]-type = 1, expected string
[ 1199.745435] ACPI: element[12]-type = 1, expected string
it is OEM type. For reference here is _BIF from my DSDT:
Method (_BIF, 0, NotSerialized)
{
Name (BUFF, Package (0x0D) {})
Store (0x00, Index (BUFF, 0x00))
Store (\_SB.MEM.BDV2, Local2)
Multiply (\_SB.MEM.BDC2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x01))
Multiply (\_SB.MEM.BLF2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x02))
Store (\_SB.MEM.BTC2, Index (BUFF, 0x03))
Store (\_SB.MEM.BDV2, Index (BUFF, 0x04))
Multiply (\_SB.MEM.BCW2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x05))
Multiply (\_SB.MEM.BCL2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x06))
Multiply (\_SB.MEM.BG12, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x07))
Multiply (\_SB.MEM.BG22, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x08))
Store (\_SB.MEM.BMN2, Index (BUFF, 0x09))
Store (\_SB.MEM.BSN2, Index (BUFF, 0x0A))
Store (\_SB.MEM.BTP2, Index (BUFF, 0x0B))
Store (\_SB.MEM.BOI2, Index (BUFF, 0x0C))
Return (BUFF)
}
This is behaviour change. Previous battery.c used generic
acpi_extract_package which allowed (allows) for object of type integer
when string is requested:
case ACPI_TYPE_INTEGER:
switch (format_string[i]) {
case 'N':
size_required += sizeof(acpi_integer);
tail_offset += sizeof(acpi_integer);
break;
case 'S':
size_required +=
sizeof(char *) + sizeof(acpi_integer)
+ sizeof(char);
tail_offset += sizeof(char *);
break;
while current battery.c:extract_package fails:
if (offsets[i].mode) {
if (element-type != ACPI_TYPE_STRING
element-type != ACPI_TYPE_BUFFER) {
printk (KERN_ERR PREFIX element[%d]-type = %x, expected string\n, i,
element-type);
return -EFAULT;
}
well, while it could be BIOS fault this happily worked before ... This is
obviously also the reason why I do not have anything in /sys
Fans, could you check whether you have the same issue using test patch?
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 0/5] Detect hwmon and i2c bus drivers interfering with ACPI Operation Region resources
On Thu, Oct 25, 2007 at 09:06:22AM -0600, Bjorn Helgaas wrote: But we really *should* reserve things used by opregions, shouldn't we? After all, the whole point of resource reservation is to prevent conflicts. Only if you're happy to lose functionality like IDE, sadly. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.624-rc1 regression] lost battery information
Andrey Borzenkov wrote:
On Saturday 27 October 2007, Alexey Starikovskiy wrote:
Andrey,
Please try the attached patch. I choose to do snprintf() instead of direct
copy, as your previous message showed empty OEM type.
Not quite. Now I get
OEM info:0
Ok, I was hoping to see some number starting with 0, which would be printed
as empty string...
while before I got empty string. If I read acpi_extract_package correctly, it
actually interpreted integer as string without any conversion. Which in this
case obviously gave us empty string (integer being 0). I'd prefer to remain
compatible.
As you wish... :) Please check the attached patch.
also
{pts/1}% cat /sys/class/power_supply/BAT1/manufacturer
0
which is rather weird manufacturer name :)
Thanks,
Alex.
Andrey Borzenkov wrote:
On Friday 26 October 2007, Alexey Starikovskiy wrote:
Your cat's Bad address means -EFAULT, according to man errno.
Please apply this patch to see what exactly failed...
[ 1191.471572] ACPI: element[12]-type = 1, expected string
[ 1196.640065] ACPI: element[12]-type = 1, expected string
[ 1199.479773] ACPI: element[12]-type = 1, expected string
[ 1199.745435] ACPI: element[12]-type = 1, expected string
it is OEM type. For reference here is _BIF from my DSDT:
Method (_BIF, 0, NotSerialized)
{
Name (BUFF, Package (0x0D) {})
Store (0x00, Index (BUFF, 0x00))
Store (\_SB.MEM.BDV2, Local2)
Multiply (\_SB.MEM.BDC2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x01))
Multiply (\_SB.MEM.BLF2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x02))
Store (\_SB.MEM.BTC2, Index (BUFF, 0x03))
Store (\_SB.MEM.BDV2, Index (BUFF, 0x04))
Multiply (\_SB.MEM.BCW2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x05))
Multiply (\_SB.MEM.BCL2, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x06))
Multiply (\_SB.MEM.BG12, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x07))
Multiply (\_SB.MEM.BG22, Local2, Local0)
Divide (Local0, 0x03E8, Local1, Local0)
Store (Local0, Index (BUFF, 0x08))
Store (\_SB.MEM.BMN2, Index (BUFF, 0x09))
Store (\_SB.MEM.BSN2, Index (BUFF, 0x0A))
Store (\_SB.MEM.BTP2, Index (BUFF, 0x0B))
Store (\_SB.MEM.BOI2, Index (BUFF, 0x0C))
Return (BUFF)
}
This is behaviour change. Previous battery.c used generic
acpi_extract_package which allowed (allows) for object of type integer
when string is requested:
case ACPI_TYPE_INTEGER:
switch (format_string[i]) {
case 'N':
size_required += sizeof(acpi_integer);
tail_offset += sizeof(acpi_integer);
break;
case 'S':
size_required +=
sizeof(char *) + sizeof(acpi_integer)
+ sizeof(char);
tail_offset += sizeof(char *);
break;
while current battery.c:extract_package fails:
if (offsets[i].mode) {
if (element-type != ACPI_TYPE_STRING
element-type != ACPI_TYPE_BUFFER) {
printk (KERN_ERR PREFIX element[%d]-type = %x, expected string\n, i,
element-type);
return -EFAULT;
}
well, while it could be BIOS fault this happily worked before ... This is
obviously also the reason why I do not have anything in /sys
Fans, could you check whether you have the same issue using test patch?
ACPI: Battery: Allow extract string from integer
From: Alexey Starikovskiy [EMAIL PROTECTED]
Some machines return integer instead of expected string.
Signed-off-by: Alexey Starikovskiy [EMAIL PROTECTED]
---
drivers/acpi/battery.c | 25 +++--
1 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 02a396d..6c06879 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -260,7 +260,7 @@ static int extract_package(struct acpi_battery *battery,
union acpi_object *package,
struct acpi_offsets *offsets, int num)
{
- int i, *x;
+ int i;
union acpi_object *element;
if (package-type != ACPI_TYPE_PACKAGE)
return
Re: [2.624-rc1 regression] lost battery information
Hmm. Things seem to have progressed since I was last online :-) With Alexey's original patch I also get a number of times: ACPI: element[12]-type = 1, expected string On Saturday 27 October 2007, Alexey Starikovskiy wrote: As you wish... :) Please check the attached patch. With 'battery_allow_extract_string_from_integer.patch' all info in /proc is back and I now also see the new files in /sys/class/power_supply. The OEM info field (line 13 in BAT1/info) is empty, just as it was empty in 2.6.23 too. Tested-by: Frans Pop [EMAIL PROTECTED] Cheers, Frans Pop - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] 2.6.24-rc1: ensure present sysfs attribute even if battery is absent
I am not exactly sure about this one ... what other power_supply class drivers
do? Should I fix HAL instead (but then, I do not know whether HAL is the only
application that is using this interface).
Subject: [PATCH] 2.6.24-rc1: ensure present sysfs attribute even if battery is absent
From: Andrey Borzenkov [EMAIL PROTECTED]
Ensure that we always have present attribute in sysfs. This is compatible
with procfs case where we had present: no if battery was not available.
This fixes HAL battery detection where it does pretend battery is present
but canot provide any value for it.
Signed-off-by: Andrey Borzenkov [EMAIL PROTECTED]
---
drivers/acpi/battery.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 681e26b..6e67fcd 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -187,6 +187,10 @@ static int acpi_battery_get_property(struct power_supply *psy,
return 0;
}
+static enum power_supply_property missing_battery_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+};
+
static enum power_supply_property charge_battery_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_PRESENT,
@@ -389,8 +393,13 @@ static int acpi_battery_update(struct acpi_battery *battery)
{
int saved_present = acpi_battery_present(battery);
int result = acpi_battery_get_status(battery);
- if (result || !acpi_battery_present(battery))
+ if (result)
return result;
+ if (!acpi_battery_present(battery)) {
+ battery-bat.properties = missing_battery_props;
+ battery-bat.num_properties = ARRAY_SIZE(missing_battery_props);
+ return result;
+ }
if (saved_present != acpi_battery_present(battery) ||
!battery-update_time) {
battery-update_time = 0;
signature.asc
Description: This is a digitally signed message part.
Re: [2.624-rc1 regression] lost battery information
Andrey Borzenkov wrote: On Saturday 27 October 2007, Alexey Starikovskiy wrote: As you wish... :) Please check the attached patch. Not sure why you need to reimplement acpi_extract_package, but ... Take a look on memory allocations around it... :) Tested-by: Andrey Borzenkov [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.6.24-rc1: ensure present sysfs attribute even if battery is absent
Andrey Borzenkov wrote: I am not exactly sure about this one ... what other power_supply class drivers do? Should I fix HAL instead (but then, I do not know whether HAL is the only application that is using this interface). Hm, do you need separate set of properties for that? You could register either of existing two, and read function will not allow read of anything but present. IMHO, this is what other modules do (/drivers/power) One remaining trick here, you need to call unregister/register for power_supply if you change attributes -- so please check if your patched driver survives insertion of the battery. Regards, Alex. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc1 acpi battery driver - sysfs interface does not update correctly
Ash Milsted wrote: Hi again, I just thought I'd say that this is still occuring with the current linux-acpi-2.6 git tree on top of Linus' latest.. I don't get (dis)charge uevents and, oddly, the sysfs charge_now value is As I remember, you did not found uevents in 2.6.23 as well? initially wrong on boot-up. For some reason it gives a value of about half the full charge of the battery (no matter what the true value is) until I read it a couple of times, at which point it corrects itself. I attach a few extra details, in case they help. your acpidump output might be usefull at this point. cat /sys/class/power_supply/BAT1/uevent POWER_SUPPLY_NAME=BAT1 POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_STATUS=Charging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Unknown POWER_SUPPLY_VOLTAGE_MIN_DESIGN=1480 POWER_SUPPLY_VOLTAGE_NOW=1480 POWER_SUPPLY_CURRENT_NOW=0 POWER_SUPPLY_CHARGE_FULL_DESIGN=400 POWER_SUPPLY_CHARGE_FULL=400 POWER_SUPPLY_CHARGE_NOW=196 POWER_SUPPLY_MODEL_NAME=PABAS005 POWER_SUPPLY_MANUFACTURER=TOSHIBA One odd thing about this is the TECHNOLOGY field - with the procfs interface it is reported as lion, not Unknown. As before, if I any other info would help, just ask. I check against LION (strcasecmp), so lion should be recognized. Please take a look on dmesg with attached patch Thanks, Alex. diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index 6c06879..bcd489c 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -127,6 +127,7 @@ static int acpi_battery_technology(struct acpi_battery *battery) return POWER_SUPPLY_TECHNOLOGY_LION; if (!strcasecmp(LiP, battery-type)) return POWER_SUPPLY_TECHNOLOGY_LIPO; +printk(KERN_ERR PREFIX unmatched technology '%s'\n, battery-type); return POWER_SUPPLY_TECHNOLOGY_UNKNOWN; }
Re: [PATCH] 2.6.24-rc1: ensure present sysfs attribute even if battery is absent
On Saturday 27 October 2007, Alexey Starikovskiy wrote: Andrey Borzenkov wrote: I am not exactly sure about this one ... what other power_supply class drivers do? Should I fix HAL instead (but then, I do not know whether HAL is the only application that is using this interface). Hm, do you need separate set of properties for that? You could register either of existing two, and read function will not allow read of anything but present. IMHO, this is what other modules do (/drivers/power) Do they have different set of properties depending on underlying hardware that you can't query unless hardware is present? I'd rather avoid adding fake attributes; but I do not actually care so which one do you prefer? :) One remaining trick here, you need to call unregister/register for power_supply if you change attributes -- so please check if your patched driver survives insertion of the battery. Neither does your code (nor kpowersave :) ) Remove battery and set of attributes is stuck instead of being reset to only fixed set of power device attributes (basically info). The only call to power_supply_register is in acpi_battery_add and as far as I can tell this is executed on adding *slot* not when content of this slot changes. signature.asc Description: This is a digitally signed message part.
Re: [PATCH] 2.6.24-rc1: ensure present sysfs attribute even if battery is absent
Andrey Borzenkov wrote: On Saturday 27 October 2007, Alexey Starikovskiy wrote: Andrey Borzenkov wrote: I am not exactly sure about this one ... what other power_supply class drivers do? Should I fix HAL instead (but then, I do not know whether HAL is the only application that is using this interface). Hm, do you need separate set of properties for that? You could register either of existing two, and read function will not allow read of anything but present. IMHO, this is what other modules do (/drivers/power) Do they have different set of properties depending on underlying hardware that you can't query unless hardware is present? I'd rather avoid adding fake attributes; but I do not actually care so which one do you prefer? :) I prefer less code :) One remaining trick here, you need to call unregister/register for power_supply if you change attributes -- so please check if your patched driver survives insertion of the battery. Neither does your code (nor kpowersave :) ) Remove battery and set of attributes is stuck instead of being reset to only fixed set of power device attributes (basically info). The only call to power_supply_register is in acpi_battery_add and as far as I can tell this is executed on adding *slot* not when content of this slot changes. Point is -- it does not break :) If you start to play with shorter length of attributes table and don't call unregister/register, power_supply may go past the end of table. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.6.24-rc1: ensure present sysfs attribute even if battery is absent
On Sat, Oct 27, 2007 at 08:54:30PM +0400, Andrey Borzenkov wrote:
I am not exactly sure about this one ... what other power_supply class
drivers
do? Should I fix HAL instead (but then, I do not know whether HAL is the only
application that is using this interface).
Well, PROP_PRESENT wasn't my idea, currently it's used by pmu and
olpc drivers becuase it's not trivial to register/unregister their
batteries on physical insertion/removal. I have some plans to teach
at least pmu batteries to not use PROP_PRESENT. I don't have any
OLPC, thus I can't convert it.
To sum this: the good way to handle missing batteries is to
unregister them, so they'll not show up in the /sys/class/power_supply.
Is that possible with the ACPI?
The good example is ds2760 batteries:
drivers/power/ds2760_battery.c - is platform device
drivers/w1/slaves/w1_ds2760.c - is w1 slave, which
registers/unregisters pdevs on the detection/removal.
Subject: [PATCH] 2.6.24-rc1: ensure present sysfs attribute even if battery
is absent
Bad idea. Don't use present attribute, if possible.
From: Andrey Borzenkov [EMAIL PROTECTED]
Ensure that we always have present attribute in sysfs. This is compatible
with procfs case where we had present: no if battery was not available.
This fixes HAL battery detection where it does pretend battery is present
but canot provide any value for it.
Signed-off-by: Andrey Borzenkov [EMAIL PROTECTED]
---
drivers/acpi/battery.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 681e26b..6e67fcd 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -187,6 +187,10 @@ static int acpi_battery_get_property(struct power_supply
*psy,
return 0;
}
+static enum power_supply_property missing_battery_props[] = {
+ POWER_SUPPLY_PROP_PRESENT,
+};
+
static enum power_supply_property charge_battery_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_PRESENT,
@@ -389,8 +393,13 @@ static int acpi_battery_update(struct acpi_battery
*battery)
{
int saved_present = acpi_battery_present(battery);
int result = acpi_battery_get_status(battery);
- if (result || !acpi_battery_present(battery))
+ if (result)
return result;
+ if (!acpi_battery_present(battery)) {
+ battery-bat.properties = missing_battery_props;
+ battery-bat.num_properties = ARRAY_SIZE(missing_battery_props);
+ return result;
+ }
if (saved_present != acpi_battery_present(battery) ||
!battery-update_time) {
battery-update_time = 0;
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.6.24-rc1: ensure present sysfs attribute even if battery is absent
On Sat, 2007-10-27 at 22:42 +0400, Anton Vorontsov wrote: Well, PROP_PRESENT wasn't my idea, currently it's used by pmu and olpc drivers becuase it's not trivial to register/unregister their batteries on physical insertion/removal. I have some plans to teach at least pmu batteries to not use PROP_PRESENT. I don't have any OLPC, thus I can't convert it. Actually it's not hard to do that. It was done this way in response to a request from the userspace side. IIRC. -- dwmw2 - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.6.24-rc1: ensure present sysfs attribute even if battery is absent
On Sat, Oct 27, 2007 at 03:32:04PM -0400, David Woodhouse wrote: On Sat, 2007-10-27 at 22:42 +0400, Anton Vorontsov wrote: Well, PROP_PRESENT wasn't my idea, currently it's used by pmu and olpc drivers becuase it's not trivial to register/unregister their batteries on physical insertion/removal. I have some plans to teach at least pmu batteries to not use PROP_PRESENT. I don't have any OLPC, thus I can't convert it. Actually it's not hard to do that. I didn't say it's hard. But we don't have any interrupts for the battery events, thus we have to implement polling. It was done this way in response to a request from the userspace side. IIRC. Oh. Userspace tried to do something weird then, I think. Generally it's just sane to unregister absent hardware. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
acpi problems on a medion 8800 desktop pc
Hi, Currently I'm having two acpi problems on linux. 1. My temperature is reported as -47°C (THRM/temperature). 2. And sometimes the pc is automatically shutdown due to a critical temperature event (not often). I've tried to decompile it with iasl and changed some dsdt logic but I am not able to solve the problem. I've fixed some errors and I also tried to remove the operating system checks in the DSDT so the same logic is executed on linux as on windows, however without success. Any feedback would be very appreciated on how I can solve these problems. In attachment you can see my dsdt.dat. Kind regards, Bart Van Rillaer dsdt.dat Description: Binary data
Re: acpi problems on a medion 8800 desktop pc
Bart wrote: Hi, Currently I'm having two acpi problems on linux. 1. My temperature is reported as -47°C (THRM/temperature). 2. And sometimes the pc is automatically shutdown due to a critical temperature event (not often). First, check if you use lm_sensors. They work with the same hardware as ACPI, and might cause wrong readings. I've tried to decompile it with iasl and changed some dsdt logic but I am not able to solve the problem. I've fixed some errors and I also tried to remove the operating system checks in the DSDT so the same logic is executed on linux as on windows, however without success. Any feedback would be very appreciated on how I can solve these problems. In attachment you can see my dsdt.dat. Kind regards, Bart Van Rillaer - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: acpi problems on a medion 8800 desktop pc
On Sun, 2007-10-28 at 00:00 +0400, Alexey Starikovskiy wrote:
Bart wrote:
Hi,
Currently I'm having two acpi problems on linux.
1. My temperature is reported as -47°C (THRM/temperature).
2. And sometimes the pc is automatically shutdown due to a critical
temperature event (not often).
First, check if you use lm_sensors.
They work with the same hardware as ACPI, and might cause wrong readings.
Yep, it's probably that.
Temperature is read through these ports:
OperationRegion (SEN1, SystemIO, 0x0295, 0x02)
Field (SEN1, ByteAcc, NoLock, Preserve)
{
SEI0, 8,
SED0, 8
}
There was another bug report where these were also accessed via sensor
modules...
This should be caught by the acpi vs native interference checker in
future.
Bart: Those patches will pop up in next -mm release, it would be great
if you can give them a try. You should see a message in your syslog then
that a module failed to load...
Thanks,
Thomas
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
