Enabled ACPI , but cant install Battery Bar Replicant in tray.

[streak]

On hrev36511 i Enabled ACPI , but cant install Battery Bar Replicant in tray.

My Laptop -> MSI Wind.

[anevilyak]

Can you provide a syslog?

[streak]

Ill add a syslog soon.

btw. Running CPU Freq gives me trip to KDL without keyboard debugging possibility ..

[tqh]

Can you please update your tree and rebuild Haiku and try again?

To me it looks like you are using something before hrev36511 or that the build isn't correct. Also check that 'svn status' don't mention anything with acp_embedded_controller.

[streak]

The hrev36511 build was taken from haiku-files official site..

[streak]

New syslog from hrev36601 , still the same. Battery bar not installing info tray, acpi not work..

[tqh]

Does it power off on shutdown?

Could you also attach the output of 'more -f /dev/acpi/namespace' if it works?

[tqh]

If CPU freq gives you kdl, could try grab a photo of what is there?

[streak]

Yes. Im getting a KDL after entering into CPU Freq: here's the image. I didnt add it as an attachment because it was too big > 1.5mb

link to imageshack -> ​http://img16.imageshack.us/img16/4811/cpufreqerror.jpg

"Does it power off on shutdown?" Yes it does.

[tqh]

This seems to be a problem with CPU Frequency driver. It crashes here: source:/haiku/trunk/src/add-ons/kernel/drivers/power/enhanced_speedstep/frequency.cpp#L34

[phoudoin]

Currently the driver supports only EIST control & status registers addresses and freq/states values hardcoded.

But here it sounds like EIST set and get state MSR registers are not located/setup by MSI bios at default addresses 0x198 and 0x199. These locations should probably be retrieved from _PCT ACPI object instead, as the supported freq/states pairs, in _PSS ACPI object. In particular when ACPI 2.0 is in used, like with this MSI Wind.

[bonefish]

Replying to phoudoin:

Currently the driver supports only EIST control & status registers addresses and freq/states values hardcoded.

But here it sounds like EIST set and get state MSR registers are not located/setup by MSI bios at default addresses 0x198 and 0x199. These locations should probably be retrieved from _PCT ACPI object instead, as the supported freq/states pairs, in _PSS ACPI object. In particular when ACPI 2.0 is in used, like with this MSI Wind.

Not sure what you're talking about here. My knowledge regarding ACPI is close to non-existent. I do, however, have the "Intel® 64 and IA-32 Architectures, Software Developer’s Manual, Volume 3A: System Programming Guide, Part 1, June 2009" at hand, which in chapter 14 details on Power and Thermal Management. To my knowledge MSRs always have fixed indexes. For the three concerned ones the following table gives the names of the registers as per spec, the corresponding macro names in the driver (unfortunately not matching the spec name), the register indexes, and specification sections of definition for the indexes:

Name (Spec)	Name (Driver)	Register Index	Defined in Spec Section
IA32_PERF_STATUS	MSR_GET_FREQ_STATE	0x198	14.3.2.2
IA32_PERF_CTL	MSR_SET_FREQ_STATE	0x199	14.3.2.2
IA32_MISC_ENABLE	MSR_MISC	0x1a0	8.7.8

After a quick look at the driver I see at least two issues:

• est_open() enables SpeedStep only on the current logical CPU, not on all CPUs. At least after a quick scan of the specs I find no indication that this has not to be done for all CPUs. That would at least explain an exception (probably #GP; the panic message is unfortunately missing in the screen shot) -- when writing to IA32_PERF_CTL on a CPU that doesn't have the feature enabled.
• The driver seems to be ignorant where multi-threading is concerned. I see no locking at all, and I have the feeling that e.g. est_set_id16() should really not be executed by two threads at the same time. Since interrupts are enabled a thread might even change the CPU while executing the function, which definitely is a problem, if the MSRs are really per-CPU.

[czeidler]

Yes only one cpu is assumed in the driver. I think also the threading point is an issue. The problem is that I don't have the cpu any more, I have an AMD now. When I checked some points on my todo list, like make ACPI working on my machine, I may start to take a look at an ACPI implementation of this driver... So feel free to step into it!

[tqh]

Have you checked if it starts booting with ACPI now. I've fixed some issues that prevented booting on some machines (i.e don't use condvars and sleep that early in the boot process).

[czeidler]

Yes tried it but it still hangs at the disk icon. Can't even enter KDL. Maybe its some hardware quirk at least mmlr assumed it with regard to my also buggy usb. Will debug it after I implement the radeon_hd mode setting correctly...

[phoudoin]

Not sure what you're talking about here.

Me neither, anymore :-)

To my knowledge MSRs always have fixed indexes.

True. But on multi-CPUs, the driver should read & write the good registers, hence why ACPI 2.0 introduced the possibility to publish via _PCT object table memory mapped or IO addresses for these performance control & status registers, which allow a driver to modify them without having to run on the CPU. FreeBSD's acpi_perf.c and Linux's processor_perflib.c uses them when they're available.

I suspect the enhanced_speedstep driver, assuming only one CPU, read or write perf MSRs on the wrong CPU, while only the one who ran est_open() have EST enabled, without any warranty they're the same one...

[axeld]

What about disabling the driver when it runs on an SMP system for now?

[phoudoin]

Replying to axeld:

What about disabling the driver when it runs on an SMP system for now?

+1

Except if it could be fixed for r1a2, aka... yesterday :-)

[bonefish]

Replying to axeld:

What about disabling the driver when it runs on an SMP system for now?

Done in hrev36726 (trunk).

[scottmc]

Any updates on this one?

[scottmc]

Is this related to #1492?

[czeidler]

Does the main battery problem still exist? will close it for now. Hopefully fixed with the latest acpi updates...