Date: Tue, 27 Dec 2005 22:35:31 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: nate@root.org Cc: cvs-src@freebsd.org, scottl@samsco.org, glebius@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/em if_em.c Message-ID: <20051227.223531.128616574.imp@bsdimp.com> In-Reply-To: <43B1D120.9080604@root.org> References: <43B1CE9E.1060602@root.org> <43B1D121.1080309@samsco.org> <43B1D120.9080604@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <43B1D120.9080604@root.org>
Nate Lawson <nate@root.org> writes:
: Scott Long wrote:
: > Nate Lawson wrote:
: >> This probably means that the PCI memory space isn't fully initialized
: >> but an interrupt has been triggered. If you then go and try to poke
: >> the hardware, then you can hang the system.
: >>
: >
: > I can believe your first statement, but not your second. Hanging the
: > system on an aborted memory read cycle (as opposed to just throwing a
: > #SERR) would indicate a highly highly broken chipset. In any case, if
: > we ever implement PCI hotplug then we'll have to deal with the effects
: > of aborted PCI transfers anyways.
: >
: > Scott
:
: It's not the PCI write that hangs the system, it's the behavior of the
: device written to. It may never release the interrupt. Using an NMI to
: debug would be good.
Chances are there's a suprious interrupt (from the device's point of
view) that gets into emintr. Since the em driver doesn't mark itself
as 'suspended' and use that to short-circuit the ISR, we hit this
problem. I think that this is most likely the problem...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051227.223531.128616574.imp>