From owner-freebsd-current Sun Feb 16 22:24:22 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7EC037B401; Sun, 16 Feb 2003 22:24:20 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3A1443F93; Sun, 16 Feb 2003 22:24:19 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h1H6OJ3Y027189; Sun, 16 Feb 2003 23:24:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 16 Feb 2003 23:23:39 -0700 (MST) Message-Id: <20030216.232339.93361034.imp@bsdimp.com> To: nate@root.org Cc: current@FreeBSD.ORG, wpaul@FreeBSD.ORG Subject: Re: sys/pci/if* fixes From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Nate Lawson writes: : * Does each device that uses miibus need to explicitly call : device_delete_child when it is detaching? Should it do it also in its : attach routine if it encounters an error? I assume all drivers need to do : this after a successful mii_phy_probe(). Yes. Yes. Yes. : * Does it need to call bus_generic_detach on itself? Yes. At least I've had lots of luck doing it and it doesn't hurt. : * Is it ok to return other errors (ENOMEM) from a device_attach method? Yes. Lots of devices return other errors, ENXIO is a common one. ENOMEM was an invention in the early days and is likely slightly bogus because it is supposed to be for malloc failures, not 'I can't get this resource' in general (but given its long usage, the bogusness level is fairly low). Matt's point about 'disabling interrupts' is that the driver writer should turn off the 'please interrupt on interesting things' bit in the device's registers. It should enable this bit the very last thing in the attach routine and the race should be solved that way. What Matt fails to realize is that in the shared interrupt case there's a problem. Some devices will indicate that they have interesting events that have happened, even when the interrupt mask register is 'cleared'. In those cases, once the ISR is registered and fielding interrupts (possibly from other devices) the race condition exists. Short of turning off ALL interrupts from the processor (or some way of doing a spl-like masking of interrupt), the race would still be there. Unless I misunderstand what Matt is saying. I'm still concerned about LOR that happens. If you hold a driver lock when ether_ifattach is called, you'll have a lock order: DRIVER_LOCK IFNET_LOCK however, the slotmo routine takes IFNET_LOCK and then calls the watchdog routine. Typically, in this routine, you take out the driver lock, which results in the following lock order: IFNET_LOCK DRIVER_LOCK when I was tracking down the interrupt problem on kldload for cardbus, I noticed a LOR like this in dc, but I couldn't find where it was happening at the time and now that the interrupt problem is solved, I'm not seeing the LOR since interrupts happen and I don't get to the watchdog routine :-(. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message