* Re: Reliably creating MCA on white box Itanium-1
2003-07-03 6:29 Reliably creating MCA on white box Itanium-1 Keith Owens
@ 2003-07-03 13:27 ` Jack Steiner
2003-07-04 1:26 ` Keith Owens
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Jack Steiner @ 2003-07-03 13:27 UTC (permalink / raw)
To: linux-ia64
>
> Is there a way of reliably creating an MCA on a white box Itanium 1?
> B3 processors, firmware is B117A. Failing that, what about creating an
> MCA on a white box Itanium-2?
>
> Loading a duplicate ITC is no good, I need an MCA that actually enters
> ia64_mca_ucmc_handler in mca.c. A working example using
> PAL_CACHE_WRITE would be nice.
Why doesnt loading a duplicate TR (not TC) work for you? I've used that
method and found it to be reliable.
Another way that is reliable (at least on our hardware) is to do a
load from a non-existent region 6 or 7 address. The failure modes are
different between region 6 & 7, but they both reliably produce MCAs.
--
Thanks
Jack Steiner (651-683-5302) (vnet 233-5302) steiner@sgi.com
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Reliably creating MCA on white box Itanium-1
2003-07-03 6:29 Reliably creating MCA on white box Itanium-1 Keith Owens
2003-07-03 13:27 ` Jack Steiner
@ 2003-07-04 1:26 ` Keith Owens
2003-07-04 1:42 ` Jack Steiner
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Keith Owens @ 2003-07-04 1:26 UTC (permalink / raw)
To: linux-ia64
On Thu, 3 Jul 2003 08:27:36 -0500 (CDT),
Jack Steiner <steiner@sgi.com> wrote:
>>
>> Is there a way of reliably creating an MCA on a white box Itanium 1?
>> B3 processors, firmware is B117A. Failing that, what about creating an
>> MCA on a white box Itanium-2?
>>
>> Loading a duplicate ITC is no good, I need an MCA that actually enters
>> ia64_mca_ucmc_handler in mca.c. A working example using
>> PAL_CACHE_WRITE would be nice.
>
>
>Why doesnt loading a duplicate TR (not TC) work for you? I've used that
>method and found it to be reliable.
Because mca_asm.S does not call the C code for TLB errors. I want to
test the C code on standard hardware.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Reliably creating MCA on white box Itanium-1
2003-07-03 6:29 Reliably creating MCA on white box Itanium-1 Keith Owens
2003-07-03 13:27 ` Jack Steiner
2003-07-04 1:26 ` Keith Owens
@ 2003-07-04 1:42 ` Jack Steiner
2003-07-04 12:56 ` Grant Grundler
2003-07-09 15:27 ` Luck, Tony
4 siblings, 0 replies; 6+ messages in thread
From: Jack Steiner @ 2003-07-04 1:42 UTC (permalink / raw)
To: linux-ia64
>
> On Thu, 3 Jul 2003 08:27:36 -0500 (CDT),
> Jack Steiner <steiner@sgi.com> wrote:
> >>
> >> Is there a way of reliably creating an MCA on a white box Itanium 1?
> >> B3 processors, firmware is B117A. Failing that, what about creating an
> >> MCA on a white box Itanium-2?
> >>
> >> Loading a duplicate ITC is no good, I need an MCA that actually enters
> >> ia64_mca_ucmc_handler in mca.c. A working example using
> >> PAL_CACHE_WRITE would be nice.
> >
> >
> >Why doesnt loading a duplicate TR (not TC) work for you? I've used that
> >method and found it to be reliable.
>
> Because mca_asm.S does not call the C code for TLB errors. I want to
> test the C code on standard hardware.
Seems to me that a TLB error caused by a duplicate TR dropin *should* call
C code. A MCA caused by a duplicate TR is a software bug that should
panic the system.
I understand that TLB parity errors would be silently corrected in mca_asm.S
by reloading the TLB.
--
Thanks
Jack Steiner (651-683-5302) (vnet 233-5302) steiner@sgi.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Reliably creating MCA on white box Itanium-1
2003-07-03 6:29 Reliably creating MCA on white box Itanium-1 Keith Owens
` (2 preceding siblings ...)
2003-07-04 1:42 ` Jack Steiner
@ 2003-07-04 12:56 ` Grant Grundler
2003-07-09 15:27 ` Luck, Tony
4 siblings, 0 replies; 6+ messages in thread
From: Grant Grundler @ 2003-07-04 12:56 UTC (permalink / raw)
To: linux-ia64
On Fri, Jul 04, 2003 at 11:26:37AM +1000, Keith Owens wrote:
> Because mca_asm.S does not call the C code for TLB errors. I want to
> test the C code on standard hardware.
will "cat /dev/mem > /dev/null" work for you?
I know xdm used to MCA the box becuase it was reading /dev/mem.
grant
^ permalink raw reply [flat|nested] 6+ messages in thread* RE: Reliably creating MCA on white box Itanium-1
2003-07-03 6:29 Reliably creating MCA on white box Itanium-1 Keith Owens
` (3 preceding siblings ...)
2003-07-04 12:56 ` Grant Grundler
@ 2003-07-09 15:27 ` Luck, Tony
4 siblings, 0 replies; 6+ messages in thread
From: Luck, Tony @ 2003-07-09 15:27 UTC (permalink / raw)
To: linux-ia64
> Seems to me that a TLB error caused by a duplicate TR dropin
> *should* call
> C code. A MCA caused by a duplicate TR is a software bug that should
> panic the system.
>
> I understand that TLB parity errors would be silently
> corrected in mca_asm.S
> by reloading the TLB.
The patch that I posted recently (June 25th) for recovery
from TLB MCA errors (for 2.4 ... version for 2.5 will be
out soon). Should do what you want. The assembly code checks
the "processor state parameter" to see if there was a TLB
error, if there is, then it fixes it by purging the TLB and
reloading ITR[0,1], DTR[0,1,2]. It then calls the C-code
handler (in case there are other errors in the same MCA, and
to give the upper level code an opportunity to do whatever
logging it wants to do).
-Tony
^ permalink raw reply [flat|nested] 6+ messages in thread