# Dothan (Pentium-M) speedstep ACPI not working

## noidgone

Hey guys,

I've been trying all angles on this problem without success.

I've tried both the ACPI P-State driver compiled into the kernel, the depreciated speedstep-centrino driver and a patched for Dothan speedstep-centrino without success.

My result has been constantly a Dothan B1 processor stuck on 600MHz when I have two processors of 1.8GHz and 1.6GHz both in Toshiba Tecra A2 laptops.

They used to work by leaving the BIOS to do the work and the processors would be just fine but now they both seem stuck on the minimum frequency setting.  I'm pretty sure this has been that case since the 3.X series kernels and it used to let the BIOS do it in 2.6...

I don't have many requirements so a compiled in standard governor is just fine for me.  I don't need userspace management of the frequency such as laptop tools or cpufreqd.  I just want it to behave something approximating the ondemand governor so I've just been trying the simplest approach of compiling that into the kernel.  I've tried other governor settings of performance and powersave but all with the same 600MHz result.

I think the DSDT is fine as it reports the expected 6 frequencies.  It might be somewhat non-standard ACPI knowing the Toshiba 'enhancements' but the dmesg output seems to suggest it's at least getting the information it needs.

I'm aware Dothan processors have always been a problem back in the days of speedstep-centrino.o, but I thought it was fixed with the latest ACPI drivers? And like I said I tried the speedstep-centrino patched with the frequency maps of the 1.8 and 1.6 GHz processors and that didn't work.

----------

## Jaglover

Welcome to the forums!

Is the problem still present if you boot a well-known Linux distro liveCD/USB? Debian, *buntu, SysRescueCd, Grml, etc?

----------

## noidgone

yeah, I didn't dig deep however, I only tried gparted (which I'm guessing is based on one of the mainline liveCDs?) same symptoms stuck on 600MHz.  The ACPI output from dmesg was similar but not identical to my Gentoo install.

It recognised the S0, S3, S4, S5 states and also showed something like "ACPI added _OSI Processor Device"

It also places the DSDT at an address just like in my local Gentoo.  I think my local Gentoo reports all 6 frequency states however.

The Toshiba extras also loads in the LiveCD without any apparent error.

Locally in Gentoo I've also loaded with ACPI full debug option modes enabled in the kernel and it doesn't output much different to normal (at least in the standard logs and dmesg).

I noticed that part way though the later 2.6 kernel series they included tables for Dothan in addition to Banias then had removed the Dothan tables in speedstep-centrino driver but only left in the Banias tables (I think this has to do with the 4 voltages that Dothan processors can handle depending on their quality assessment at manufacturing, but for some reason the kernel doesn't contain the most conservative options of Dothan tables).  So I patched the speedstep-centrino kernel code to include the Dothan tables but it still didn't allow it to work.  The 3 series kernel seems to have the Banias tables inherent to the driver but not the Dothan tables.  It does have some manual modes for Dothan B0 and C0 series (which might be the single voltage Dothan versions?) but mine are the 1.8GHz and 1.6GHz Dothan CPUs with 4 possible voltages.

This processor is not the original for the Tecra (it originally had a Celeron Banias), but I've updated the BIOS (though still ancient) and the ACPI tables and DSDT is at least registering.  I've checked the BIOS and there are very limited options relating to ACPI.  It also has the Pentium-M icon come up early in post, so I'm assuming from this that the BIOS is quite capable of handling the Dothan chip.  Perhaps not, as I think Celeron Banias to Dothan was the real step with regard to introducing Centrino capability?..  (maybe someone can elaborate on that?)

I suspect it doesn't work in the 3 series kernels while it did at one stage back in the 2.6 series (maybe even 2.4).

Do you think I should go to the effort of trying a different LiveCD?  I would've thought that gparted was mainstream enough?  I've also thought about digging out my old Banias chip and throwing that in to see if it works with this kernel (and I'm guessing it would), though I've been pig-headed so far just bashing away at the kernel head-on, and really what would that add to my knowledge anyway?..

Thanks for your reply!

----------

## noidgone

also, I've been operating on the assumption that the BIOS is fine as it is reporting the 6 frequencies to ACPI (at least what I see in dmesg) but maybe this is not the case at all.  Maybe the BIOS is buggy and ACPI is getting some information on the CPU type but can't actually interact with it?

----------

## Jaglover

I'd say get SystemRescueCd, put it on a USB stick (becomes handy in many situations if you are a computer person) and try different kernels from it.

----------

## noidgone

well I've also emerged other kernels from the portage tree and given them a try already; a few days ago I tried 3.0.101 (I think it was a little different in the speedstep-centrino tables) then I also reverted back to some 3.something middle aged kernel and three different recent kernels from normal upgrades have all had the same problem (3.10.25 and 3.10.17 at least recently).  I guess the LiveCD options will also have ACPI setups that are more dynamic and might be a little clever in installation, maybe something with anaconda on it or something or perhaps whatever Ubuntu has?

Probably wont have a shot to download any other LiveCDs for the next few days but might try a few in a couple of days when my downloads reset, and what about KNOPPIX? Last I knew, years ago, Knoppix was good for hardware detection and Backtrack linux was pretty awesome at those nitty-gritty problems, anaconda used to be good for Fedora but recently I've noticed it to trip up on basic machines, I've used SystemRescueCD before and found it quite good but no idea how good it's hardware detection is, in the meanwhile anyone else out there have some intimate knowledge or special info on Dothan ACPI problems?

----------

## noidgone

So I've tried 4 different LiveCD flavours (including SystemRescueCD) all with the same result.

I'm starting to think that perhaps the 600 MHz was a problem all along as a confusing factor was that I had a similar Toshiba laptop as a donation laptop for parts that contained the original CPU, I'm guessing these processors never did anything but 600 MHz in these laptops (maybe).

I've since used an old Banias Celeron (ugh) 1.4 GHz CPU and while I haven't spent the time getting frequency scaling to work, it does indeed work at 1.4 GHz, which while the Level 2 cache is one-quarter the size, the processing speed has shown a perceived improvement.

All of this leads me to believe that the Embedded Controller is not updated for the precise processor in the computer, the Dothan 1.8 GHz (B1 speedstep).  It's strange.  I've seen in the log of the BIOS updates from Toshiba that the Dothan frequency scaling was added for the 1.4 and 1.5 GHz processors in the previous version, however, my understanding is that the Embedded Controller is what is likely to control the frequency scaling and interfacing with the CPU.  I've not seen any updates of the Embedded Controller for this model via Toshiba.  Are there any linux utilities specifically designed for this?

Does anyone own a Toshiba Tecra A2 (or Satellite A50) with a higher processing speed Dothan in it?  Is it possible to donate the controller firmware code for me to update it on mine?  I know this model was released with the 1.6 and 1.8 GHz processors so there must exist an update somewhere for it...  I doubt Toshiba will be very helpful for a 13 year old lappy either?..

Also note that the Tecra A2 is also known as the Satellite A50 in some markets.

----------

