HP nc6400 v.03 or v.05 laptop ACPI fails after reboot, works again after booting windows

Hi everyone, I recently tried to install gentoo linux on my HP nc6400 laptop, and everything works fine except for the following issues.

This may be related to:
http://marc.theaimsgroup.com/?l=linux-acpi&m=115583434909936&w=2

Here are the problems:
1. After booting gentoo, when I reboot, I can no longer enter the BIOS
setup screen by pressing F10.
2. After booting gentoo, when I reboot, the ACPI battery file does not
update the power status / events.

Here's how they happen:
1. Boot windows: everything works fine.
2. Reboot from windows: I can get into setup by pressing F10.
3. Boot Gentoo after having booted windows first: power status meter
works, files are updated, etc.
4. Reboot into Gentoo: I can no longer enter setup via F10.
5. Reboot into windows: Everything works again. On next bootup, F10
works fine.

Sometimes the keyboard will refuse to work until the system has booted into the OS. (This doesn't seem to consistently occur.)

Any ideas on how to go about fixing this?

My DSDT generates the following errors on compiling:

------------------------------------------------------------------------------------------------------
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20060912 [Dec 11 2006] Copyright (C) 2000 - 2006 Intel Corporation Supports ACPI Specification Revision 3.0a

dsdt.dsl 3275: And (Local1, 0xFFFF)
Warning 1104 - Result is not used, operator has no effect ^

dsdt.dsl 4672: Method (_DSM, 4, NotSerialized)
Warning 1086 - ^ Not all control paths return a value (_DSM)

dsdt.dsl 4672: Method (_DSM, 4, NotSerialized)
Warning 1079 - ^ Reserved method must return a value (_DSM)

dsdt.dsl 12767: CreateByteField (C1D3, \_SB.C002.C003._Y0F._LEN, C08F)
Error 4062 - Object does not exist ^ (\_SB.C002.C003._Y0F._LEN)

ASL Input: dsdt.dsl - 13280 lines, 491767 bytes, 6207 keywords Compilation complete. 1 Errors, 3 Warnings, 0 Remarks, 2052 Optimizations

Crazy as it seems, add an init script to rmmod psmouse before you shutdown or reboot linux. Somehow having it loaded when the machine shuts down causes the BIOS to get upset.

Works on my nc6320 as a workaround, although I've got a few odd issues still:

Critically, when the lid-switch is pressed, the backlight extinguishes, but if the touchpad senses any movement, a key is pressed, or for some random reason, the backlight fires back up again, then doesn't switch off.

This leaves the laptop very toasty if you shut the lid and it does this.

Does yours do this?

Suspend doesn't work out of box, I've not really tried to diagnose.

Regards,

Peter Clifton

Wow. You're completely right... so this isn't an ACPI issue (directly.)

I don't seem to experience any of the other problems you describe, but I do have a different model. I don't have an external lid-switch sensor. Hm.. Suspend doesn't quite work for me either, I'll look into this farther and get back to you.

The battery meters and other ACPI functionality is working now with your workaround. Should this be a bug report? Which group should get the report if this is the case?

Thanks so much!
Lincoln

It was suggested to me to open a kernel bug (possibly starting under ACPI), however I never got to it.. I don't know where kernel bugs are reported officially, and was busy at the time. (still am). I do try and reply to others with the same problems though... finding the webpage which suggested that fix was not trivial!

My lid switch is just above the keyboard, on the right hand side of the left hand screen hinge. It is just a tiny piece of plastic protruding from the case. Push it, and the screen goes off. Hold it, and wiggle the mouse (touchpad), and the naughty screen comes back on.

Most importantly for me, the workaround brings the max CPU speed available with speed step back to what it is supposed to be on my laptop, and the BIOS actually boots much faster.

Peter C.

Well. I just tested the lid, and I don't seem to have that problem.
I also don't think I have an external lid-switch, because I really can't find it anywhere... anyway.

Your workaround got me past the buggy/slow booting; however, there's another problem that I've found that is just about as annoying. And I'm hoping that someone will have an idea.

When I boot the computer with ACPI support, there's an audible hum that comes from the CPU whenever the processor is idle. This hum does not occur in windows, and when I boot with "noapic pci=noapic acpi=off" in the kernel options, the sound is gone.

Does anyone have any ideas how I can fix this? Is it possible to load ACPI as a module? Should I play around with which ACPI features are compiled in, and see which one, if it is just one, is the kicker?

Thanks again for all of your help,
Lincoln

I saw this on my old desktop computer (Nforce2 chipset, AMD XP+2800). Not ACPI related perhaps, but definatly CPU load related. When the CPU was "thinking", the humming stops. When it was idle, it would humm.

My presumption was that the CPU was bouncing the power rails to the sound chip at a given frequency which was coming through. (Sound was on the mobo, and I wasn't bothered enough to get the oscilloscope and probe it).

It is possible that since ACPI is related to power-saving of your CPU, removing ACPI - (and hence the power saving) stops the CPU powering up and down / changing clock speed so much, removing the fluctuation on the power rails.

All of this is a bit of a guess, but do see if the humming quietens under load.

(Try the following C program...)

spinloop.c

int main( int argc, char **argv )

{
	while( 1 );
}

(Compile with gcc spinloop.c -o spinloop)

Run ./spinloop

Ctrl-C will break out of it.

(Run multiple times for each CPU core you have!)

Peter C.

Yes. I definitely noticed that it's load based, however, here's the kicker.
When I power up the system with the AC adapter plugged in, and then proceed to remove the adapter after ACPI has done its initial checks at bootup, there is no humming sound.

Also, this hum does not occur unlesss the specific ACPI module, which is what I expected... the processor, is loaded into the kernel.

Is there a way to attempt to load this as a module after boot time?

ACPI Support
<y> Processor

Thanks again!

Update:

Kernel 2.6.18-r4

I've done some more testing, and I've narrowed the problem down to the "processor" cpu driver.
I disabled all power management features in the kernel, and compiled ACPI as modules so that they would not be loaded until I wanted them to be.

APM is off.
CPU Frequency Scaling is off.
ACPI is compiled entirely as modules to be loaded by the user.

While running on the battery:
As soon as I "modprobe processor" the humming begins, and as soon as I "rmmod processor" the humming stops.

While running on AC, if I "modprobe processor" there is no buzzing. I can remove the AC adapter and the computer remains silent.

It seems to be something related to the way that the processor driver is handling power to the CPU. Ideas?

Hi!

Try the following:
cat /proc/acpi/processor/*/power in the following situations:
1) After loading the processor module being on the battery,
2) After loading the processor module being on AC,
3) After disconnecting the AC,
and compare the results. I think that for 1), you will see more C-states than for 2) and that possibly the missing C-states are not added for 3).

It looks that when your machine doesn't hum, it doesn't save so much power. Try to change the timer frequency, I suspect that frequency of the hum tracks it. Try to set it at 1000 Hz if it's not already there; possibly at this frequency, capacitors will do better work and filter the peaks on the power bus better. You can also use 100 Hz - maybe the hum will go lower and will be less hearable.
With regards, Pavel Troller

Yes, this is correct. The states are not being added for scenario 3). Here is the output for 1):

sharktop ~ # cat /proc/acpi/processor/CPU1/power

active state:            C3
max_cstate:              C8
bus master activity:     00000000

states:
C1: type[C1] promotion[C2] demotion[--]
latency[000] usage[00000010] duration[00000000000000000000]
C2: type[C2] promotion[C3] demotion[C1]
latency[001] usage[00003956] duration[00000000000010489906]
*C3: type[C3] promotion[--] demotion[C2]
latency[057] usage[00335124] duration[00000000001056908436]

For 2 and 3):

sharktop ~ # cat /proc/acpi/processor/CPU1/power

active state:            C2
max_cstate:              C8
bus master activity:     00000000

states:
C1: type[C1] promotion[C2] demotion[--]
latency[000] usage[00000010] duration[00000000000000000000]
*C2: type[C2] promotion[--] demotion[C1]
latency[001] usage[00131021] duration[00000000000232665865]

And the reason the hum seems to go away when AC is plugged back in, is because it switches to C2.

I have this question, however. While the CPU is powered down, /proc/cpuinfo still shows the full frequency of the chip, at 1823Mhz. When I enable cpufrequtils, and clock down the processor, there is no change in noise or power consumption, it's still noisy, and it's still . If this is the case, then why bother with cpufrequtils in the first place... also... I still have the question of why doesn't this happen in windows? What power state is windows running in to get as much or more battery life, and still have no humming noise?

It seems like the processor module must be doing something that isn't quite right. I heard that there's supposed to be a C0, and a C4 power state for the core duo processor, but I don't see those in the list of options. Any ideas as to why they don't show up?

Yeah. I tried doing this but the result was the same. Thanks for your help.

As far as i know, the humming appears in windows too. I tested it with the RMClock utility and on my laptop, switching to C4 was making the humming. But every other C-State was quite. You should tune the timing frquencies, like Pavel pointed out.

But i'm curios, why on linux the C4-State does not show up. The maximum working C-State on my system, on AC or battery is C3. Is there any hidden switch to enable it?

with regards, frank

Ok, thank you. With regard to the timing frequencies Is that in reference to the Kernel Frequency for Latency? Eg. 1000 / 250 / 100 ?

There's nothing that I've found the enable the C4 state. It would be nice, since that is definitely the most power saving state. And do you have any ideas why the sound would not occur in windows? I'm pretty sure it's using the lower power states, because battery lasts a heck of a lot longer than in gentoo.

I'm not sure if I was using RMClock correctly, but it seems like the humming did not occur in windows. Perhaps you could give me a little guidance on how to use the tool properly?

Thanks.
Lincoln

Is there a way to force the driver into a specific state? Or to manually add a state? I still cannot access C0 (max frequency), C4, or C5 power saving states, that are all supposed to be supported by the Intel Centrino Core Duo CPU

Can someone point me to the code that determines the voltage / amperage pairings for CPUs in power saving mode? Is this handled by the ACPI bios (bios function call), or does the kernel directly affect the power setting?

I'd like to take a look and see what's going on.

On Thu, 2006-12-21 at 16:44 -0500, Lincoln Baxter, III wrote:
[snip]

I can't recall where in the code this is, but it is the bios which provides the voltage/frequency pairings. The speed-step drivers for older processors actually have them hard-coded as a table.

If you're not seeing the highest frequency - I don't know what the problem is. Mine re-appeared after the rmmod psmouse trick I posted earlier. The CPU specs are in a separate SSDT on my laptop, which only shows up when the appropriate bios setting for speedstep is ticked, and the bios is "happy" (psmouse removed before shutdown).

Peter C.

Can you try patch from comment #180 from bug:
http://bugzilla.kernel.org/show_bug.cgi?id=5534
and also apply this one (didn't find any reference url, so it's copy and pasted, this one comes from the cpufreq list posted by Bruno Ducrot on 21.Nov.06). Be careful that you get into the "correct" firmware state before by booting windows (or unplug AC and battery for some minutes should also help, but not sure). Is this enough to get the machine to work correctly and stable with ACPI (cpufreq and ACPI info, pls try without suspend to disk, there are other issues with these machines)?:

processor_perflib.c::acpi_processor_ppc_notifier() check if the value returned by the processor's _PPC method is 0 and return failed if so. This is wrong since 0 indicate that the bios think the processor can go to the highest frequency. This patch for example fix the HP NX 6125 to allow its highest frequency to be available.

--- linux-2.6.19-rc6/drivers/acpi/processor_perflib.c 2006/11/21
10:18:39 1.1
+++ linux-2.6.19-rc6/drivers/acpi/processor_perflib.c 2006/11/21
10:18:55
@@ -83,8 +83,6 @@ static int acpi_processor_ppc_notifier(s

                goto out;
 
        ppc = (unsigned int)pr->performance_platform_limit;

- if (!ppc)
- goto out;

        if (ppc > pr->performance->state_count)
                goto out;

Thanks,

Thomas

Since it is somewhat related to ACPI, please open a bug in ACPI category on bugzilla.kernel.org. It is a great place to track this kind of issues.

bugzilla.kernel.org

It is not easy to track it in emals.