em interrupt storm
ambrisko at ambrisko.com
Thu Dec 1 12:09:50 PST 2005
Kris Kennaway writes:
| On Thu, Dec 01, 2005 at 11:53:00AM -0800, Doug Ambrisko wrote:
| > Kris Kennaway writes:
| > | On Thu, Dec 01, 2005 at 11:32:10AM -0800, Doug Ambrisko wrote:
| > | > On Thursday 24 November 2005 01:27 am, Kris Kennaway wrote:
| > | > > On Wed, Nov 23, 2005 at 03:02:05PM -0800, Darren Pilgrim wrote:
| > | > > > Until this gets "fixed" in FreeBSD, what should those of us who are
| > | > > > effectively stuck with this hardware do to avoid the problem? Does the
| > | > > > problem exist in RELENG_4?
| > | > >
| > | > > Yes, on the same machine I first mentioned.
| > | >
| > | > Is this is SMP on or off? I think it might be okay if SMP if off.
| > |
| > | With SMP, I don't recall if I tried it without. SMP is pretty useless
| > | on 4.x (often hurts more than it helps), so this may be an acceptable
| > | workaround for the OP.
| > Could you try without SMP? I wonder if the BIOS sets things up okay
| > in UP mode. I saw strangeness on our PE2850's in SMP mode that didn't
| > happen in UP mode. This is with 4.X.
| Without SMP, the amr and em0 devices are both assigned to irq10.
| There does not appear to be an interrupt storm coming from amr
| activity (60 interrupts/sec on irq10), but I don't know if this irq
| configuration would have stormed anyway, and of course the shared
| interrupt is sub-optimal.
That seems consistant with what I've seen. FWIW, I have a storm
detector in our patched amr driver. If I see more then 500
calls to the interrupt handler per tick then I wait until they
slow down. This prevents the death spiral I saw in SMP mode.
It looks like we'll be looking into this more since we are seeing
problems when adding more NIC's in the box. To date we've been
band-aiding the problem.
More information about the freebsd-current