|
From the victim:
Linux won't load on my 9595-SOC (P90). The boot freeze at the
"Checking for HLT command".
From Rick Hohensee:
HLT is a Pentium-and-up instruction Linux uses to idle if it's
available. A 386 kernel won't even look for it.
From Dr. Jim:
So the question remains- why does the HLT freak out a Pentium box?
I believe that question was answered:
> The problem hinges around the fact that the FPU test disables the
timer interrupt.
> No idea why.
From Dr. Jim:
I'm not sure where, but I think I saw a mention of the P90 as
having >some< FDIVd steppings.
From the Replacement Program FAQ:
Q3: What speeds of the Pentium processor are affected by the floating point
flaw?
A3: If you have a 60, 66, 75, 90 or 100MHz Pentium processor,
it is possible you may be affected with the floating point flaw. To check
if you are affected, use CPUID. Any speeds higher than 100MHz do not have
the FPU flaw.
Don't blame me, but sorry Jim, but you are wrong. Direct from
the kernel-sources:
From Stephan Goll:
if (mca_pentium_flag) {
/* The IBM Model 95 machines with pentiums lock up on
* fpu test, so we avoid it. All pentiums have inbuilt
* FPU and thus should use exception 16. We still do
* the FDIV test, although I doubt there where ever any
* MCA boxes built with non-FDIV-bug cpus.
---------
printk("mca-pentium specified, avoiding FPU coupling test... ");
if (!boot_cpu_data.fdiv_bug)
printk("??? No FDIV bug? Lucky you...\n");
else
printk("detected FDIV bug though.\n");
return;
}
---------
See bugs.h for more details.
Greetings,
Stephan
From Louis Ohland:
OK, campers, this is real answers. Maybe not the full truth, but
answers.
Exception 16?
The snippet of code inferrs that it was intended to test
for the bug, and give either thumbs up or down, but not lock up. Why does
(!boot_cpu_data.fdiv_bug) fail?
From Su:
I'd tend to agree with Jim's assessment that it's the *test* that
causes the hang. I found this in 'bugs.h':
/*
* check if exception 16 works correctly.. This is truly evil
* code: it disables the high 8 interrupts to make sure that
* the irq13 doesn't happen. But as this will lead to a lockup
* if no exception16 arrives, it depends on the fact that the
* high 8 interrupts will be re-enabled by the next timer tick.
* So the irq13 will happen eventually, but the exception 16
* should get there first..
*/
This comment is in a function that is called before the one that says
it's "Checking 'hlt' instruction...". I'm wondering if the high 8
interrupts get re-enabled (and therefore the IRQ 13) *before* the exception
16 arrives, and when the ASM code that actually does the HLT is executed,
the system hangs.
I haven't been through all the code yet, just bugs.h, so this is just
a guess...
From Dr. Jim:
What I'm wondering is if it isn't another 'gotcha' resulting from
the fact that MCA interrupts are level-triggered rather than edge-triggered.
If a level-triggered interrupt remains asserted, and
you are looking for an edge-trigger, you will never see it. Tony? Peter?
Comments?
What to Do?
From Dr. Jim Shorney:
Is there a parameter you can pass to the bootdisk?
At the boot prompt: yourkernelname mca-pentium
|