Created attachment 9487 [details]
acpidump of nx7400

Created attachment 9488 [details]
dmesg of nx7400

Created attachment 9489 [details]
kernconfig of my nx7400

Created attachment 9490 [details]
lshw output of nx7400

Can you try modprobe of 'acpi-cpufreq' and check whether that one has any luck?

Nope, cpufreq doesn't come up:

root@backofen:~$ modprobe acpi-cpufreq
FATAL: Error inserting acpi_cpufreq 
(/lib/modules/2.6.17-10-generic/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): 
No such device

Created attachment 9557 [details]
Unknown cpu

The problem is that the CPU is not known to the speedstep-centrino driver. It
is model 15 but there is no entry for a model number 15 in the driver. However,
even adding this model number doesn't make it work, but hopefully this
additional info will help. Attached is my cpuinfo file as I seem to have the
same notebook.

Model numbers in speedstep-centrino are for legacy reasons. Models numbers are 
not required for all CPUs that the driver supports. Kernel ideally gets all 
the required information from BIOS using ACPI and enable speedstep. That is 
how speedstep is designed to work. Just that BIOS folks messes up things from 
time to time. I haven't yet actually looked at acpidump in this case to figure 
out whether the BIOS is the problem here. Will do it soon.

I the mean time can you make sure that you are running with latest BIOS and 
also check whether there are any speedstep related option in BIOS and if it is 
there make sure they are enabled. They are typically called as Enhanced 
Speedstep, EIST, Intel Speedstep or similar names.

Also, does any of the driver (acpi_cpufreq or speedstep_centrino) used to work 
on this system with any of the earlier kernels?

I've got the same problem with HP's nx7400. Downgrading the bios from F07 to F06
doesn't seem to be possible because in my case this leads to a total dead laptop
but I've read a lot of pages that speedstepping works before upgrading the bios
to F07 which is also the latest bios version.

Can someone post the output of acpidump on this system. You can find acpidump 
in latest version of pmtools here
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

I am not able to parse the acpidump output in comment #1

Hi Venkatesh Pallipadi,

I do also have the HP nx7400 (RH402ET) and got the same Problem on Debian
Testing (Etch) with Kernel 2.6.17-2.

You can view my acpidump here:
http://www.bytearena.com/acpidump.txt

Regards,
Torsten

Created attachment 9569 [details]
acpidump

Looked at acpidump from comment #11. BIOS indeed does not have any ACPI objects
needed to support P-states.With this BIOS, in all likelyhood, even Windows will
not be able to make any P-state changes on this system. Please open a bug report
for BIOS folks at HP.

Opening a bug for HP would be great but they don't show any reaction to a lot of
threads in the HP forums as well as to telephone calls to the HP Hotline. Does
anyone know who to assign a bug which will be noticed by them?

Many HP models seem to be affected.
See
http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1056713
And 
http://bugzilla.kernel.org/show_bug.cgi?id=7157

This seems not to be an isolated incident. Win XP speedstepping seems fine (at
least the fan blows a lot less).

Maybe HP has changed the way the BIOS reports speedstepping information? 

I have confirmed that speedstep works fine in Win XP. The CPU normally runs at
1Ghz and occasionally go up to 1.66Ghz which is the max for my T5500 CPU.

What I don't get is how this can work fine in Windows while not at all in Linux.

Do you know of any Windows tool I can use to extract information to help debug
this? Maybe dump ACPI data in Windows?

@Henrik Harmsen

I read that the "Debugging Tools for Windows" can make an acpi dump, but as I
don't use Windows I can't try it.

It could be worth a try: http://www.microsoft.com/whdc/devtools/debugging/

Henrik,
May be your BIOS config is different from that of Torsten in comment #11. Can 
you attach the dmesg and acpidump from your system?

Created attachment 9586 [details]
ACPI dump of my nx7400

Created attachment 9587 [details]
dmesg from henriks nx7400

I'm working on getting an ACPI dump from WinXP and will get that up here as soon
as I can.

Another person confirmed that speedstepping is working fine with Windows XP. CPU
Type 'CPU Intel Core 2 Duo'.

Usenet/German:
<Message-ID: <cb49m2tf95dcojfdpkhag1bd2upq78imbh@4ax.com>>

acpidump from comment #19 looks exactly same as the earlier one with no trace of
speedstep related information whatsoever.

How speedstep works on Windows on this platform is still a mystery... 

Venkatesh,

I tried to file a bug-report by calling HP several times and by getting in
contact with someone from HP through their forums and e-mail contact.

The guys working at the hotline don't care at all, because it works fine with
Windows and no one from the HP staff responds to any of the forum threads (e.g.
http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1075649).

As speedsted does not work in at least the models NX9420, NX6310, NC6400 and the
NX7400,this like a not so minor bug to me.

As you work at Intel maybe you know someone at HP who cares.

BTW: Thanks a lot for your help!

Regards,
Torsten

Created attachment 9620 [details]
raw acpidump from henriks nx7400

Well, I haven't yet been able to make a successful acpi dump from WinXP. I got
close, but even though I got all things in place, no useful output. Windows is
just a frustrating pile of eh, well, frustration... So, on to some easier
reverse engineering... :-)

What I did instead was to have a look at the BIOS rom images (F.06 with working
speedstep and F.07 without) and inside I did indeed find tables that looked
like real speedstep ACPI tables even with the newest F.07 ROM. However, the
BIOS images are not fit for direct ACPI table extraction...
 
So instead I made an "extended" ACPI dump (attached) of the memory area around
where the ACPI tables are in my machine. This dump is a raw binary dump of 64
kbytes. When I ran the normal acpidump the ACPI tables where located around
0x3f7e0000 (see my previous attachment in comment 19) so I created a binary
dump from that address and 64 kbytes in size.

Now, if you load the attached dump into the ghex2 binary editor (or any other
hex editor) you will, if you search for the string SSDT, find what looks like
multiple SSDT tables. Some of them seems to contain stuff like _PCT which I
understand is vital for speedstep. 

So maybe the kernel is reading the wrong SSDT table or there are multiple
tables? I will continue to investigate, but I found the current results
interesting enough to report.

I looked a little more in the binary dump I just uploaded and I can see that
there is actually a new SSDT table _immediately_ following the first SSDT table
(the one which acpidump found). The next SSDT table contains stuff like _PPC,
_PSS and _PCT. Maybe if the acpi code could simply read and merge multiple
consecutive SSDTs then we would have this solved. 

Sorry for spamming but this is exciting. Solving puzzles with a hex editor is
always fun. :-)

Ehm, I did some googling and tripped over a patent, of all things!... See:

http://www.patentstorm.us/patents/7017034-fulltext.html

This was issued to HP in march 2006. I don't know what to make of it, but I
guess I just found the culprits... The timing certainly fits exactly...
(My goodness, I really didn't expect to trip over a patent!)
I browsed the patent and it looks like it's on the implementation of the
firmware, so I really don't think (hope) that it creates a problem for Linux
since we probably only need to adhere to some weird subclause of the ACPI
standard to get this right... (Just guessing here).

Well, I can't say for sure the patent is connected to this bug report but my
instinct tells me yes for sure...

Henrik,

you did insanely great investigations!!
I really hope and think this will help to solve this bug report.

Thanks a lot,
Torsten

Hi Henrik,
thanks a lot. A really good Job you did! It sounds that we don't have to wait
for HP waking up :o)
 
@Venkatesh Pallipadi
Also thank you for your work!
bye
Ralf

Good news!

HP finally responded in a thread at the HP Business Forums.
"We do have an F.08 release internally that resolves this issue. I don't know
what the timeframe for release to the web is but it should be coming soon."

(http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=1075649)

Fantastic news: a new BIOS Version F.08 is out now!
http://h18007.www1.hp.com/support/files/hpcpqnk/us/locate/64_6268.html

Sorry for posting again, but I just successfully updated my BIOS to version F.08.

HP fixed the problem and speedstepping just works like a charm on my notebook! :)

For those of you who don't want to use wine just to unarchive the BIOS image as
it's a .exe with an installer, I uploaded the iso of the bootable FreeDOS image
including the latest BIOS F.08 to my webserver:
http://www.bytearena.com/nx7400/nx7400_bios_f.08_freedos_image.iso
md5-checksum: 4d12514469b81b8f9a40b86b4ae1d8fc

For the more curious, here's my acpidump with the new F.08 BIOS:
http://www.bytearena.com/nx7400/acpidumpf08.txt

Regards,
Torsten

Thats great news :))...

Yipee. A fix! :-) Will try the new bios tonight. :-)

-- Henrik

I've tried the new bios and speedstepping now works for me on an nx7400 with c2d
1.66 GHz processor. Some potentially interesting information:

% lshal|egrep 'smbios.bios|system.product'
  system.product = 'HP Compaq nx7400 (RH399EA#AK8) F.08'  (string)
  smbios.system.product = 'HP Compaq nx7400 (RH399EA#AK8)'  (string)
  smbios.bios.release_date = '10/23/2006'  (string)
  smbios.bios.version = '68YGU Ver. F.08'  (string)
  smbios.bios.vendor = 'Hewlett-Packard'  (string)

Hi,
I'm sorry to say that, but for me speedstepping still don't works. In the
meantime I've tried all Linux distris with 686 as well as with a 386 kernel in
different versions. Either the Speedstepping doesn't work at all or it just
works between 1 and 1,33GHz though cat /proc/cpuinfo delivers the right
informations. 

Under /sys/devices/system/cpu/... I've found that speedstepping should work
between 1 and 1,83GHz but it doesn't and I've made it work just sometimes by
using a Live CD with Ubuntu. Here the CPU's steps are correct but after
installing it the frequency scales again only between 1 and 1,33GHz. In my
opinion there is still a problem left. Has anyone an Idea what to do? The Bios
is already updated to F08.



TIA
Ralf

Yes, I have this problem too. I have found the following solution somewhere in a
ubuntu forum:
Type as root:
cpufreq-set -c 0 -u 1833000 ; cpufreq-set -c 1 -u 1833000

Hi Thomas,
great! I suppose I've tried everything to solve this problem without any success
and now it works.

Thanks a lot
Ralf

Looks like the issue is solved with BIOS update. Closing the bug.