ACPI parser error

[nopper]

I got this while using acpi_thermal driver (cat /dev/power/acpi_thermal/0):

KERN: acpi_thermal: read()
KERN: acpi_thermal: GetThermalType()
KERN: ACPI Error (evregion-0426): No handler for Region [EC__] (0x90afa320) [EmbeddedControl] [20080701]
KERN: ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20080701]
KERN: ACPI Error (psparse-0627): Method parse/execution failed [\_TZ_.THRM._TMP] (Node 0x90af9820), AE_NOT_EXIST
KERN: acpi_thermal: GotBasicTemperatures()

I think that's a problem relative to the bus manager in general (evaluate_method?)

[nopper]

I got these errors also using my driver that manages the battery. I need this function to test and then to release the code.

[nopper]

This is a first attempt to port the linux acpi_battery module to haiku.

[stippi]

Pretty cool. But you have some left-overs in your code, like turning on ACPI unconditionally (you need to change your "kernel" settings file instead) and also there are coding style violations/inconsistencies. If you could go over your patch again and look for coding style issues, that would be great! Thanks a lot for your work! BTW, Is there a userland application already which can work with this driver, or is this something that would need to be done yet?

[ithamar]

I've just started to look at this, but I get reasonable values with the current acpi_thermal driver on my EeePC 900, doing a cat /dev/power/acpi_thermal/0.... I'll try this patch and see if the battery driver gives me reasonable values too.

@nopper, could you attach the output of /dev/acpi/namespace here, just to see if we might be looking at an ACPI Table issue here?

[ithamar]

ok, after installing the battery driver it is unable to find the battery device, whilst there are multiple listed in the /dev/acpi/namespace output. One device is found without a name. I'm going to dive into the enumeration code, as that seems to fail, as the tables contain the battery device (see /dev/acpi/namespace output), but no acpi device node is generated for it.

I guess the bug that is causing this _might_ also cause the problem you're seeing. Will report back when I find this bugger ;)

[axeld]

BTW the PowerStatus application should be extended to work with this driver once it's ready :-)

I also wouldn't mind to have a userland API for it that's part of a power management framework that figures out the details itself. But that's something for R2 (we need something to improve upon, right? ;-)).

[ithamar]

ok, some more status here.... It seems (using dm_tree from KDL) that the device nodes for _all_ ACPI devices are actually being created, and with the appropriate paths/hids. The main problem seems to be that the *_support() functions in the drivers only get to see a subset of these, and therefore don't get to see the battery.

Will start looking into why this is this weekend. Expect a fix soon ;)

@Axel: Will take a look at the PowerStatus application, didn't even know we had it :P And yeah, lets get the basic tech working for R1, and leave R2 to use it intelligently ;)

[axeld]

There are a number of rules how the devices are iterated, and when supports_device() is being called. Either ACPI does not use the right flags for the nodes, or the device manager is at fault.

PowerStatus is currently not on the image, as APM is problematic, and ACPI is not only turned off by default, but also does not deliver the information yet :-)

[ithamar]

ok, got further now. ACPI sets B_FIND_CHILD_ON_DEMAND | B_FIND_MULTIPLE_CHILDREN as flags on the nodes, and when removing ON_DEMAND, the device manager actually calls supports_device() for all ACPI devices. Going to have a look at the device manager code what ON_DEMAND _exactly_ does, and try to figure out if this is a bug in acpi or the device manager ;)

[nopper]

Tested on my PC seems working. Someone please test it :)

[monni]

There's a typo in the diff:

rechareable -> rechargeable

[nopper]

Typo fix

[nopper]

Thanks for the notice monni. Fixed

[tqh]

Our ACPI is updated quite a bit since your latest work. Would mind retrying.

[tqh]

Would you mind...

[scottmc]

can you recheck this with a recent Haiku build and let us know the current status?

[nopper]

Sorry I am a little busy these days. By the way I will test it as soon as possible.

[nopper]

Actually the output produced is messed up with hrev42149. I've also attached the syslog file also so you can take a deeper look.

[tqh]

Could you attach the output of more -f /dev/acpi/namespace?

[nopper]

Ok I am attaching the log. By the way when I try to cat the file I get this message printed on the stderr also:

cat: /dev/acpi/namespace: Bad semaphore ID

[nopper]

This is instead what I get by reading the acpi_battery file:

~> cat /dev/power/acpi_battery/0 
Battery Status:
 State 402890752, Current Rate -2145965088, Capacity -2070331884, Voltage -2147064566

Battery Info:
 Power Unit -2133007292, Design Capacity -2070332052, Last Full Charge 12870, Technology -2133007292
 Design Voltage -2133092560, Design Capacity Warning -2070331988, Design Capacity Low -2133088960, Capacity Granularity1 0, Capacity Granularity1 0
 Model Number =P<>, Serial Number =P<>, Type >ü<>, OEM Info B

[waddlesplash]

Still an issue?

[nopper]

I don't own the hardware anymore and don't have the time to test this. Not sure if ithamar@ has any updates on this. Otherwise you can mark this as obsolete given that more than 10 years have passed.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed