From owner-freebsd-current Mon May 17 8: 1: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (Postfix) with ESMTP id 65F3F14E96 for ; Mon, 17 May 1999 08:00:57 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id JAA28161; Mon, 17 May 1999 09:00:51 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA22502; Mon, 17 May 1999 09:00:50 -0600 Date: Mon, 17 May 1999 09:00:50 -0600 Message-Id: <199905171500.JAA22502@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Christopher Masto Cc: Assar Westerlund , current@FreeBSD.ORG Subject: Re: zzz crashing in current OR inthand_remove not removing handlers properly In-Reply-To: <19990516235949.A18232@netmonger.net> References: <5lr9ogzaqf.fsf@assaris.sics.se> <19990516235949.A18232@netmonger.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Hi, on a -current from around a week ago `zzz' always managed to crash > > my machine. The relevant parts from the panic and the backtrace are > > included below. > > > > It seems that the cause of this was a stray interrupt was arriving > > after having unloaded the driver. For some reason it wasn't handled > > by isa_strayintr, and the reason for that was that inthand_remove > > didn't manage to remove the interrupt (and get it replaced by the > > stray function) correctly. After applying the patch at the end of > > this mail I can once again sleep my laptop succesfully. > > Wow. I think that's actually done the trick. Not only can I suspend, > but I can now remove my 3C589 without a panic. > > ... well, I just managed to lock up the machine.. but I think that was > from a missed remove event. I must have lost that polling patch > somewhere along the way. If you're polling, it's *REAL* easy to lockup the machine inside the card's interrupt handler, with no chance of it every escaping since the 'poll' can't interrupt the IRQ. The solution is to not poll and to make sure insertion/removal events generate an interrupt which can inform the card's interrupt handlers that there is no more card. (That's one of the main reasons polling is a very bad idea.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message