What about the processors (PPro)? Are they both from the same
series, same lot number (or whatever they call it - I forgot)?
I've seen processors, both Intel, but with different manufac-
ruring characteristics that wouldn't work together.
Try another pair, from the same lot, and see if it works.
gnd
>Date: Tue, 04 Apr 2000 19:05:06 +0200
>From: Paolo Mantegazza <[EMAIL PROTECTED]>
>MIME-Version: 1.0
>To: Sergey Osechinskiy <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Subject: Re: [rtl] SMP error
>Content-Transfer-Encoding: 7bit
>
>Sergey Osechinskiy wrote:
>>
>> Hello all,
>>
>> Sorry it took me so long to test the patch that was released so fast. I was
tied up with a non-linux project.
>> On a first glance this patch seemed to remedy the problem - at least the idle
rtlinux/ idle linux system does NOT get stuck on "TLB IPI wait". Yet the
slightest load (network, ftp download of 500K file) brings the system to its
knee with the "stuck on TLB IPI wait on CPU#0" messages displayed at a slow rate
(NO rtl module inserted).
>> I have tried to enable the MTRR (Memory Type Range Register) support in
"Processor Type and parameters" configuration. It is recommended for fixing the
problem with buggy SMP BIOSes which only set MTRRs for the boot CPU and not the
secondary CPUs. Helas, the system dies even at boot time with "hda: lost
interrupt" message.
>>
>> The boot messages have the following entries (same as reported by Surya):
>>
>> Apr 3 11:40:06 dualpro kernel: RTL started
>> Apr 3 11:40:06 dualpro kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
>> ........
>> Apr 3 11:40:06 dualpro kernel: stuck on TLB IPI wait (CPU#0)
>> Apr 3 11:40:06 dualpro kernel: stuck on TLB IPI wait (CPU#0)
>>
>> I've tried rtai-1.2 with linux2.2.14 kernel. I do not see any "TLB IPI wait"
messages (as Paolo explained, RTAI's way of doing it is now to leave tlb
invalidate IPIs as hard interrupts). But when I load rtai modules with ldmod
script, I get a very similar message "Unable to handle kernel NULL pointer
dereference at virtual address 00000000", and system becomes very unstable (for
sure dies when trying rtai example stress).
>> I have used a copyto script for patching, make calibrate, and used spm apic
scheduler (make instapic).
>>
>> All this tells me that something is wrong with my hardware. The motherboard
Intel Buckeye B440FX DP is "fully MPS 1.4 compliant with appropriate Pentium Pro
extensions" (though linux boot messages show version 1.1 compatibility ???).
Processors are not overclocked (200 MHz). The motherboard is not very modern and
probably not very many rtlinux/rtai users will have it - it has a separate CPU
"Britanny" board, PCI-to-PCI bridge and requires a special power supply (not ATX
nor AT style).
>>
>> I am sure both rtlinux and rtai were successfully tested on SMP systems. It
would be nice to know some examples of SMP system configuration that work great
with rtlinux / rtai (Pentium Pro and Pentium II/ III).
>>
>> Thanks,
>>
>
>Speaking of RTAI. You cannot go on doing anything if you get that
>message at insmod, and that message has nothing to do with TLB. It is
>likely you did something wrong with the installation procedure.
>
>The lot of tests you find in RTAI have worked for days on dual: SOLTEK,
>ASUS and ABIT MBs.
>
>Ciao, Paolo.
>-- [rtl] ---
>To unsubscribe:
>echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
>echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
>---
>For more information on Real-Time Linux see:
>http://www.rtlinux.org/rtlinux/
-------------< G. N. DeSouza >-------------
---------< [EMAIL PROTECTED]>---------
--< http://rvl1.ecn.purdue.edu/~gnelson >--
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
