Bug 7514
Summary: | No centrino-speedstepping w/ HP nx7400 (rh402et) | ||
---|---|---|---|
Product: | ACPI | Reporter: | Holger Adams (public.email) |
Component: | Power-Processor | Assignee: | Venkatesh Pallipadi (venki) |
Status: | REJECTED INVALID | ||
Severity: | normal | CC: | 4632, acpi-bugzilla |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.27-10 up to 2.6.18.2 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
acpidump of nx7400
dmesg of nx7400 kernconfig of my nx7400 lshw output of nx7400 Unknown cpu acpidump ACPI dump of my nx7400 dmesg from henriks nx7400 raw acpidump from henriks nx7400 |
Description
Holger Adams
2006-11-13 12:07:24 UTC
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. |