LPMC: I-Cache Parity Error

[Lakshmi Nagarajan_1]

System panics and reboots after above message. INDEX file (after dump)
indicates panic: ,isr.ior=0'1034002e.0'a82a1200
HP Hardware Engineer checked out the system and gave it a clean bill. HP
Support checked out the tombstones and crash files and couldn't see why this
would occur. System panics regularly (every couple of weeks or so).
Any help would be appreciated. Thanks.

[John Bean_3]

I have seen the Low Priority Machine Check I-Cache Parity Error before. It
happens when a CPU does a parity check and it fails. These messages usually
show up in dmesg. Sometimes it will cause a system to panic.

If I see one of them, I just kinda ignore it, but keep it in the back of my
head. If I see two of them or see them regularly, I would have HP come out and
determine which CPU is causing the error and get them to change out that CPU
board.

[fredrik gauffin_1]

No one should have to accept that their system panics
every once in a while. What I mostly recommend my customers in such cases is
that they set up the dump
filesystem under /var/adm/crash (I am assuming you are running HP-UX 10.X or
11.X). That is create a logical
volume that equals the size of the systems memory plus
an additional twelve to fifteen megabytes to fit the
kernel in, then mount this filesystem under /var/adm/crash (also enter this
into /etc/fstab). Now when the system panics the dump that is automatically
created will be stored in your swap area or more correctly the dumparea, you
can find out your dumparea by typing lvlnboot -v and look at the dump lvol it
is normally the same as your primary swap (/dev/vg00/lvol2). During the next
boot the dump will be transferred from the swap/dump area into /var/adm/crash,
simply tar (1M) the files, normally with names like bounds, core.0 and so forth
onto a tape and send the tape into your local HP Support Center for analysis.
There are some other ways of doing this, however a sizeable portion of disk is
still needed in order to do this. The described way is also by far the easiest
one.

I wish you good luck.

[Lakshmi Nagarajan_1]

John,
Thanks. I'll log another call to HP.

[Dave Wherry_1]

We had the same problem on a K260, UX10.20. HP was able to determine from the
dump that it was a processor. We ran diagnostics on it and it passed. We
replaced it and two weeks later had another similar crash. The dump that time
specifically pointed to proc. 2. We replaced that and it has been fine.
If HP can not determine which processor is causing this, demand that all of
your procs. be replaced.