From owner-cvs-src@FreeBSD.ORG Wed Dec 28 08:49:27 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5E4416A420; Wed, 28 Dec 2005 08:49:27 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77DCF43D4C; Wed, 28 Dec 2005 08:49:26 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBS8nMbl027258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Dec 2005 11:49:22 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBS8nMlg027257; Wed, 28 Dec 2005 11:49:22 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 28 Dec 2005 11:49:22 +0300 From: Gleb Smirnoff To: "M. Warner Losh" Message-ID: <20051228084922.GW1496@FreeBSD.org> References: <20051222090955.E621416A4D5@hub.freebsd.org> <43B1CE9E.1060602@root.org> <20051227.223401.73653853.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051227.223401.73653853.imp@bsdimp.com> User-Agent: Mutt/1.5.6i 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2005 08:49:27 -0000 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