Reliably creating MCA on white box Itanium-1
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.
Quoted 8 lines
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_handlerinmca.c. A working example usingPAL_CACHE_WRITEwould 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.
Signature · 3 lines
Thanks Jack Steiner (651-683-5302) (vnet 233-5302) [email protected]
Quoted 5 lines · Jack Steiner
Quoted 5 lines
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?
Quoted 7 lines
Quoted 3 lines
Loading a duplicate ITC is no good, I need an MCA that actually enters
ia64_mca_ucmc_handlerinmca.c. A working example usingPAL_CACHE_WRITEwould 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.
Quoted 13 lines
Quoted 10 lines · Jack Steiner
Quoted 8 lines
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_handlerinmca.c. A working example usingPAL_CACHE_WRITEwould be nice.
Quoted 5 lines
Quoted 2 lines
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.Sdoes 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.
Signature · 3 lines
Thanks Jack Steiner (651-683-5302) (vnet 233-5302) [email protected]
Quoted 2 lines · Keith Owens
Because
mca_asm.Sdoes 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
Quoted 8 lines
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