Date: Sun, 16 Feb 2003 23:23:39 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: nate@root.org Cc: current@FreeBSD.ORG, wpaul@FreeBSD.ORG Subject: Re: sys/pci/if* fixes Message-ID: <20030216.232339.93361034.imp@bsdimp.com> In-Reply-To: <Pine.BSF.4.21.0302141503110.39134-100000@root.org> References: <Pine.BSF.4.21.0302141503110.39134-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <Pine.BSF.4.21.0302141503110.39134-100000@root.org>
Nate Lawson <nate@root.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030216.232339.93361034.imp>