> yep, if the BIOS lets us so far, this explains things. Could you try
> removing the setup_IO_APIC(); line from smp.c? Does this fix the problem?
I should have resent the boot messages:
<4>Linux version 2.1.89 (root@kg1) (gcc version egcs-2.91.14 980315 (gcc-2.8.0 release)) #82 Tue+Mar 17 20:59:22 CET 1998
<4>INIT IRQ
<4>Console: 16 point font, 400 scans
<4>Console: colour VGA+ 80x25, 1 virtual console (max 63)
<4>PCI: BIOS32 Service Directory structure at 0xc00fb000
<4>PCI: BIOS32 Service Directory entry at 0xfb400
<4>PCI: PCI BIOS revision 2.10 entry at 0xfb430
<4>Probing PCI hardware.
<4>PCI->APIC IRQ transform: (B0,I0,P-1) -> -1
<4>PCI->APIC IRQ transform: (B0,I7,P-1) -> -1
<4>PCI->APIC IRQ transform: (B0,I7,P-1) -> -1
<4>PCI->APIC IRQ transform: (B0,I8,P0) -> -1
<4>PCI->APIC IRQ transform: (B0,I9,P0) -> -1
<4>PCI->APIC IRQ transform: (B0,I11,P0) -> -1
<4>Calibrating delay loop... 33.13 BogoMIPS
...
<4>CPU0: Cyrix 6x86 2x Core/Bus Clock stepping 17
<5>SMP motherboard not detected. Using dummy APIC emulation.
<4>Starting kswapd v 1.5
The setup_IO_APIC(); is never reached, because: SMP motherboard not detected
Anyway: The BogoMIPS are calculated before.
I think, I found the offending instructions. After several kernel compiles,
I can switch on and off the problem, by changing one line in head.S
head.S:40
8<------------------------------------------------------------
ENTRY(stext)
ENTRY(_stext)
startup_32:
/*
* Set segments to known values
*/
cld
movl $(__KERNEL_DS),%eax
mov %ax,%ds
mov %ax,%es
mov %ax,%fs
mov %ax,%gs
#ifdef __SMP__
orw %bx,%bx
/* jmp 1f // ******* Uncomment this to not offend the 6x86 ******** */
jz 1f
/*
*New page tables may be in 4Mbyte page mode and may
* be using the global pages.
*
* NOTE! We have to correct for the fact that we're
* not yet offset PAGE_OFFSET..
*/
#define cr4_bits mmu_cr4_features-__PAGE_OFFSET
movl %cr4,%eax # Turn on 4Mb pages
orl cr4_bits,%eax
movl %eax,%cr4
#endif
8<------------------------------------------------------------------------
1. Is my version of head.S screwed ? I have some Cyrix patches in there
(way below these lines) and applying patches (for kernel update) sometimes
failed, which I resolved manually. Does your head.S look the same ?
The statement with %cr4 makes no sense to me:
mmu_cr4_features is defined nowhere. (At least, I couldn't find.)
Here's what the compiler makes of it:
root@kg1:/usr/src/Linux-2.1/linux/arch/i386/kernel #
egcc -E head.S -D__SMP__ -I/usr/src/Linux-2.1/linux/include -D__KERNEL__
...
movl %cr4,%eax # Turn on 4Mb pages
orl mmu_cr4_features- ((0x1000- (2304) )<<20) ,%eax
movl %eax,%cr4
...
Here's what the assembler outputs: (objdump -d head.o)
...
19: 0f 20 e0 movl %cr4,%eax
1c: 0b 05 00 00 00 orl 0x90000000,%eax
21: 90
22: 0f 22 e0 movl %eax,%cr4
...
What is this supposed to do? Shouldn't we just orl $16,%eax to make
Pentiums happy. Or maybe orl $16-__PAGE_OFFSET,%eax ?
2. Skipping these insns (by adding the jmp) prevents the 6x86 from slowing
down.
The CR4 register on 6x86 is undocumented (and even illegal).
On 6x86MX we got four bits in it:
2 = TSD(Time Stamp Disable), 3 = DE(Debugging Extensions),
7 = PGE(Page Global Enable), 8 = PCE(Performance Counter Enable)
Can we move these insns downwards, until the processor vendor is detected?
Or we delete %cr4 again after detecting a cyrix?
3. BTW, the 6x86 traps on access to %cr4. If I insert a kernel module
accessing %cr4, I see the following:
invalid operand: 0000
CPU: 0
EIP: 0010:[<7485a219>]
EFLAGS: 00010206
eax: 00000000 ebx: 00000002 ecx: 7310c000 edx: 701c92a4
esi: 6ffff3bc edi: 00000000 ebp: 00000000 esp: 7218df60
ds: 0018 es: 0018 ss: 0018
Process cr4 (pid: 317, process nr: 14, stackpage=7218d000)
>>EIP: 7485a219 cannot be resolved
Trace: 7485a35b
Trace: 7485a303
Code:
Code: 0f 22 e0 movl %eax,%cr4
Code: 0f 20 e0 movl %cr4,%eax
(If you're interested in the module's code, please let me know.)
When head.S is started, the CPU is still in real mode, right? Is this why
it ignores the illegal CR4 access?
Comments ?
-- Kurt Garloff, Dortmund <K.Garloff@ping.de> PGP key on http://student.physik.uni-dortmund.de/homepages/garloff- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu