Date: Wed, 23 Nov 2005 15:02:05 -0800 From: "Darren Pilgrim" <dmp@bitfreak.org> To: "'Scott Long'" <scottl@samsco.org>, "'Kris Kennaway'" <kris@obsecurity.org> Cc: freebsd-current@freebsd.org Subject: RE: em interrupt storm Message-ID: <002801c5f081$f01ff200$642a15ac@smiley> In-Reply-To: <43842D41.1050401@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Scott Long > >>On Tue, 2005-11-22 at 22:03 -0500, Kris Kennaway wrote: > >> > >>>I am seeing the em driver undergoing an interrupt storm whenever the > >>>amr driver receives interrupts. In this case I was running newfs on > >>>the amr array and em0 was not in use: <...> > >>>This is on both 6.0-RELEASE and 6.0-STABLE. > > This is apparently a side effect of how we process interupts, which is > different from Windows and Linux. Since we mask the interrupt in the > APIC while the ithread runs, the Intel hardware tries to outsmart us > and continue delivering the interrupt via irq16. There are been > rumors on ways to turn off this 'feature', but none of them seem to > work. Since ithreads are integral to SMPng, and masking the APIC pins > in integral to making ithreads work, the solution will probably be to > be more aggressive in adopting MSI, and in doing filtered interrupt > handlers that don't require the APIC to be masked. Note that Solaris > and Darwin would likely exhibit the same problem since they handle > interrupts similar to us. Scott, from your message the problem is going to on any E7520 chipset, regardless of the NICs, disk controllers, etc. used in the system. Does this problem also exist for the E7525 chipset? I know the two are almost identical, but I figured it would be good to make sure. I ask because I have a machine with a Supermicro X6DAL-G (which uses the E7525) on which I got messages about interrupt storms during builds. This was back before if_em was fixed, so they were shelved along with use of the em interface until if_em was fixed. My apologies for not having the exact messages. I don't having access to the logs. 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002801c5f081$f01ff200$642a15ac>