panic: ipi_send: couldn't send ipi
John Baldwin
jhb at FreeBSD.org
Tue Sep 28 11:04:44 PDT 2004
On Tuesday 28 September 2004 12:54 pm, Kris Kennaway wrote:
> On Tue, Sep 28, 2004 at 11:34:51AM -0400, Ken Smith wrote:
> > On Tue, Sep 28, 2004 at 12:16:20PM +0400, Andrew Belashov wrote:
> > > I have install this patch.
> > >
> > > Hardware: Sun Ultra 60 Creator 3D, 2 x UltraSparc IIi @ 450 MHz, 1 GB
> > > memory.
> > >
> > > OS: FreeBSD bel.localdomain 5.2-CURRENT FreeBSD 5.2-CURRENT #32:
> > > Tue Sep 28 11:14:38 MSD 2004
> > > bel at bel.localdomain:/usr/obj/usr/src/sys/SUNC3D sparc64
> > >
> > > Messages from console:
> > >
> > > cpu_ipi_send: raised ipi_retries_max to 2000
> > > cpu_ipi_send: raised ipi_retries_max to 3000
> >
> > Thank you very much for testing this out.
> >
> > Unless someone thinks this would be a problem I'll wait another couple
> > of days and if nobody else has any further input I'll leave the existing
> > code as-is but bump the max retries to 5000 for the 5.3 release. I'm
> > still curious about what the underlying problem is but it'll take some
> > time to track down I think. I did manage to find a machine to test
> > this on late yesterday and some initial attempts at triggering the
> > problem by generating a lot of disk I/O didn't seem to trigger it.
> >
> > Your case seems to be a bit extreme - I'm wondering if it has something
> > to do with the Creator 3D. I don't think it is the only thing that can
> > cause the problem to crop up but it might be something that makes the
> > situation "worse".
> >
> > Kris, was your problem machine one of the machines here?
>
> I don't remember if any of those were SMP, but this was on phk's dual
> u60. I applied the patch in PR 66314, and while I haven't had a
> repeat of the ipi panic, it did fall over with one of the other panics
> I regularly see on this machine. Also, jhb seemed to think there was
> an underlying MI problem, and this patch would only delay the
> occurence of the panic.
Well, on x86 when I make the spin longer it will just spin forever and
deadlock. If on sparc64 it can stay up for long periods of time w/o
deadlocking under heavy load then a moderate bump on the upper limit might be
a good idea.
--
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-sparc64
mailing list