Re: The SpedStep crash problem ...
In the depths of that dark day Tue Oct 23, the words of Martin Sk?tt were the beacon:
> OK, we are now a couple of people here on the list who are struggling with
> random crashes of our laptops. The standard solution is to disable SpeedStep
> in the BIOS. Until now this haven't helped on my machine, but I have many
> SpeedStep settings and I still haven't tried all of them.
> Disabling SpeedStep is a workaround, but it's not acceptible for me as a
> private laptop buyer. What is the problem with Linux and SpeedStep? Does it
> affect all machines (judgeing from this list, no) and what is that happen? In
> my own case it has always happened while running on AC power, but a good
> explanation to this is that I run on AC 99% of the time. My model of machine[1]
> can be delivered with Linux pre-installed by IBM and they don't mention any
> problems nor do they mention that SpeedStep has been disabled so they must have
> a workaround.
> I found this post for the linux kernel list with Google:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.3/1308.html
> Its Pavel Machek posting a path for arch/i386/kernel/time.c which might be
> fixing a problem for an unhappy T20 owner. There is no reply to the post and
> I can't find any indication in time.c (in 2.4.12) that is has been added to
> the Linus tree. Did this patch work for anyone? Is it Linux which has a
> problem with speedstep or is it hardware related?
>
> As I mentioned before disabling SpeedStep is not a solution (only a workaround)
> to the problem. The last option I need to test for my SpeedSetting is
> disabled. I have intentionally left this for last because it means that my CPU
> is clocked down from 800 to 650Mhz. My laptop is my only newer machine (the
> alternative is a desktop 133Mhz pentium). A 150Mhz stepdown in clock speed is
> not something I can accept (OK when running on battery, but not on AC).
>
> This post, and hopefully it's reply's, are a precedent to me contacting IBM
> Denmark who, hopefully can provide an acceptable solution. I am, as you might
> have guessed, angry and disappointed with this problem. I was confident
> buying this machine because it's can be shipped with Linux and I therefore
> took for granted that it would run flawlessly, but no. It could be a bug in
> my hardware, but there is also other people with this problem, do they all
> have defect machines?
>
> [1]My machine is an IBM T22 and I'm using kernel 2.4.5 with SGI XFS 1.0.1
> patched in.
> --
I would love to hear IBM's official word on speedstep, as they are
AFAIK the only laptop manufacturer (as opposed to reseller) to support
Linux.
In any case, the problem as I understand it is that there is some
communication required among the CPU, BIOS, and OS in order for the OS
to know when the CPU speed is changing and to take any action it needs
to handle the change. This requires some proprietary extensions which
Intel is not willing to release for use in open source software.
I also recall reading on lkml (although I haven't been able to find
this in the archives) at some point that the delay loops that are
calibrated at boot time are the problem with Linux and speedstep.
Linux works fine if the processor speed increases, but if the
processor speed decreases (as can happen with speedstep) some
synchronization in the kernel stops working. Again, I wish I could be
more specific, but I can't find this thread.
I did find one thread that indicates that ACPI support is a factor at
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0106.1/0721.html ,
I currently have ACPI support disabled since I haven't found it
complete enough to be useful in the past, and if it's not useful I'd
rather keep it out of my kernel. I'll try a kernel with ACPI and see
if my machine still locks up with speedstep enabled.
Reply to: