Re: Hangs and reboots under high loads, oops with DEBUG_SHIRQ

[Attila Nagy]

On 2007.08.01. 0:08, Roger Heflin wrote:
> Attila Nagy wrote:
> > HARDWARE ERROR
> > HARDWARE ERROR. This is *NOT* a software problem!
> > Please contact your hardware vendor
> > CPU 1 BANK 0 TSC 1167e915e93ce
> > MCG status:RIPV MCIP
> > MCi status:
> > Uncorrected error
> > Error enabled
> > Processor context corrupt
> > MCA: Internal Timer error
> > STATUS b200004010000400 MCGSTATUS 5
> > This is not a software problem!
> > Run through mcelog --ascii to decode and contact your hardware vendor
> >
> > HARDWARE ERROR
> > HARDWARE ERROR. This is *NOT* a software problem!
> > Please contact your hardware vendor
> > CPU 1 BANK 5 TSC 1167e915e9ea8
> > MCG status:RIPV MCIP
> > MCi status:
> > Uncorrected error
> > Error enabled
> > Processor context corrupt
> > MCA: Internal Timer error
> > STATUS b200221024080400 MCGSTATUS 5
> > This is not a software problem!
> > Run through mcelog --ascii to decode and contact your hardware vendor
>
> Attila,
>
> We had some issues with very similar boards all of the problems
> seem to be around the PCIX bus area of the machine, setting the
> PCIX buses to 66 mhz in the bios made things stable (but slow).   Not 
> using
> the PCIX bus also seemed to make things work.   We got MCE's and
> other odd crashes under heavy IO loads.   I believe turning things
> down to 100mhz made things more stable, but things still crashed.
>
> Supermicro reported being able to fix the issue with:
> setting the PCI Configuration -> PCI-e I/O performance
> setting to Colasce 128B.
>
> I am not exactly sure where to set it as we did not try it
> as we had already changed to a different motherboard that did not
> have the issue.
>
> If this works please tell me.
Roger, you are my hero. :)
With that PCI-e setting (again, for the record, this is on a Supermicro 
X7DBE motherboard,
and the BIOS setting is PCIe I/O performance, which has two states: 
Coalesce and Payload 256B)
all of the four machines have survived a half day of continous bashing. 
Previously one, or two
machines typically fell off after such amount of IO load, so it looks 
promising so far.
I hope this won't change over the time.

BTW, this is still with 2.6.21.5, because the SCSI target stuff I use 
(SCST) has some
-I hope temporary- problems with changed (deleted) interfaces in newer 
kernels.

Should the DEBUG_SHIRQ problem in e1000 affect stability (or performance)?

Thanks,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/