lkml.org 
[lkml]   [1998]   [Mar]   [20]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 20 Mar 1998 15:17:13 +0100
FromKurt Garloff <>
SubjectRe: SMP speed on 6x86 UP
On Fri, Mar 20, 1998 at 10:46:32AM +0100, MOLNAR Ingo wrote:

> 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

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.177 / U:0.020 seconds]
©2003-2008 Jasper Spaans