Date: Wed, 28 Dec 2005 11:49:22 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, nate@root.org Subject: Re: cvs commit: src/sys/dev/em if_em.c Message-ID: <20051228084922.GW1496@FreeBSD.org> In-Reply-To: <20051227.223401.73653853.imp@bsdimp.com> References: <20051222090955.E621416A4D5@hub.freebsd.org> <43B1CE9E.1060602@root.org> <20051227.223401.73653853.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner, On Tue, Dec 27, 2005 at 10:34:01PM -0700, M. Warner Losh wrote: M> : This probably means that the PCI memory space isn't fully initialized M> : but an interrupt has been triggered. If you then go and try to poke the M> : hardware, then you can hang the system. M> M> Most of the other drivers explicitly turn off their interrupt handler M> or mark their softc as 'suspended' until the resume code gets to run. M> Those that mark the softc as suspended exit the ISR immediately w/o M> touching the hardware. The em driver doesn't seem to do either of M> these things. I have tried this, and it doesn't help. I was setting a flag in suspend handler and clearing it in resume handler. em_intr() exited always if the flag was on. Howerver, this didn't help - the strange interrupt happend after the resume handler has been run. P.S. Yesterday I also noticed same 0xffffffff check in if_re.c -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051228084922.GW1496>