[ltp] Thinkpad X30, 2.6.21-rc5, and the hdaps module.

[Steve Thompson]

--- Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:

> On Sun, 08 Apr 2007, Steve Thompson wrote:
> > Another issue which I am interested in getting feedback on is the
> > speedstep functions in the kernel.  If the IBM bios is configured for
> > maximum power savings, the CPU frequency on battery will be as low as
> > 200MHz (maxing out at  700 or so I think) whereas the linux kernel
> never
> > detects the processor as having more than two rates: 1197000 798000,
> as
> > shown in scaling_available_frequencies.  Obviously, this affects
> programs
> > like xine.  The workaround is to set the BIOS so it does not scale the
> > frequency back quite so far.  This, however, will tend to reduce
> battery
> > life.
> >
> > Is there some known reason why the BIOS can set a wider range of CPU
> > frequencies than linux, or am I experiencing an artifact of the
> limited
> > experience IBM ACPID developers have with the X30 model?
> 
> 1. ACPI tables might tell the kernel not to set all those frequencies.

That's entirely possible.

> 2. Your machine might be blacklisted by the cpufreq module and it
> reduces the capabilities.

I doubt it.

> 3. A bug somewhere is causing the problem.

A bug seems likely.  As I have time I will isolate the invariants of this
problem, but I don't reboot the machine all that much so it will take a
little time to isolate exactly who is doing what to whom.  I am somewhat
curious as to why the BIOS can set the CPU down to as low as 200MHz with
linux thinking it can step the processer up and down at entirely different
rates.  It just seems odd.

> Anyway, ibm-acpi has nothing to do with it, and you should open a bug
> report
> in bugzilla.kernel.org (but check if there aren't open bugs about these
> issues already, before opening a new one).

You're probably right, but I'll have to get more information before I
decide who needs to look at the problem.  Maybe I will simply end up
updating the BIOS if that will correct deficiencies in the current ACPI
tables I have.

> > Finally, I seem to have found that the X30 may actually have an
> > accelerometer similar to the one used in more recent models for hdaps.
>  I
> > *thought* I had read somewhere that it did, but I realise that was
> > incorrect.  Nevertheless, I saw that hdaps is only probed after the
> system
> > is checked against a whitelist.  Removing the whitelist check does not
> > magically get it working, but subsequent probing indicates that there
> > might  actually be a chip there.  
> 
> Install tp_smapi and its hdaps patch.  Use *that* one to try to locate
> an
> HDAPS firmware in your X30.  The stuff in Linux mainline is hopeless.

Hopeless, you say?  I thought they were careful about that sort of thing,
what with 2.6 being a production cycle and all.  2.7 should be where all
the real fun occurs.

> > A quick modification to the hdaps.c module to dump the 30 bytes at
> 0x1600
> 
> Don't do this.
 
> > Now I am no expert, but that sure looks like there's a bunch of
> registers
> > sitting there at the appropriate locations.  The initialization
> proceedure
> 
> Yes, there is.  Go to thinkwiki, get the EC manuals, and learn about it.
> Get the tp_smapi source, read it, and work from there.
> 
> > At any rate, I'm wondering if the folks here who also have X30s would
> mind
> > checking what their machine shows when those bytes are dumped.  If you
> 
> *Don't* *mess* *with* *these* *IO* *ports*.   They are sensitive to
> reads.

You're perfectly correct, of course.  Arbitrary ports may reset counters
or trigger actions and arbitrary events when read.  Of course, it is
usually the case that initiating a primary device function requires an IO
port write.  Sure, there's lots of buggy hardware (and people, if you
believe the stories about aliens) out there that will jump right off into
the hardware equivalent of undefined behaviour when probed
indiscriminately.

Arbitrarily reading IO ports associated with a network or SCSI controller
-- especially behind the back of the OS --  can be particularly bad.  But
if one looks at /proc/ioports and makes sure he is not bashing on
something already installed and not associated with the device under test,
then there is not too much risk -- particularly if you do it on a quite
system immediately after a `sync`.

But in this case it's too late, and I have emperical proof that wacking on
that port range with 'inb' is not immediately fatal.  I actively encourage
other X30 users to give it a shot if they are willing to take full
responsibility for the possible consequences of their actions.

> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh

You worry too much.


Regards,

Steve
 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com