Date: Mon, 18 Jul 2005 13:53:08 -0600 From: Scott Long <scottl@samsco.org> To: Robert Watson <rwatson@freebsd.org> Cc: arch@freebsd.org Subject: Re: Network-related device drivers and MPSAFEty: status, and plans for 7.0 Message-ID: <42DC08A4.2060001@samsco.org> In-Reply-To: <20050718183717.N9430@fledge.watson.org> References: <20050718183717.N9430@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: [...] > > if_dc Tulip driver -- mutexes present, not used unless IS_MPSAFE > set to non-0, so un-exercised. > As has been discussed, throwing the switch on this one is scary since the driver is so overloaded with parallel codepaths to handle slightly incompatible hardware. Also, mutex recursion was often a common problem with early locking attempts (due to the non-SMP-friendly design on miibus). Do we know if this driver suffers from this or not? > > if_fxp Intel EtherExpress PRO/100 Ethernet device driver. > Mutexes present and exercised; not marked IFF_NEEDSGIANT, > but not marked INTR_MPSAFE (see if_fxpvar.h#define). > Also, Giant passed into busdma for call-back lock. Maybe > we can just throw the switch? bus_dmamap_load_mbuf() doesn't do deferalls, so the mutex argument in the tag is unused in this case. Don't take it as an indication of Giant-ness. It would be good to put an appropriate lock into the tag in case it's needed in the future. Or the lock arg can just be set to NULL, NULL for now. > > if_hme Sun Microelectronics STP2002-STQ Ethernet interfaces > device driver. Generally fine, but Giant referenced in > budma callback. Can this be fixed easily? See my comment on fxp. > > if_nve NVIDIA nForce MCP Networking Adapter device driver. > Mutexes present and exercised; not marked IFF_NEEDSGIANT, > but not marked INTR_MPSAFE. Also, busdma callbacks > reference Giant. Maybe we can just throw the switch? This driver has many many more problems that just locking. > if_ti Alteon Networks Tigon PCI gigabit ethernet driver. > Mutexes present and exercised, not marked MPSAFE. I'm working on this one and using it as a testbed for alternate locking strategies. The downside to this driver is that the initialization code isn't quite right and results in making it very hard to use. > > if_owi Lucent Hermes, Intersil PRISM and Spectrum24 IEEE 802.11 > driver (old). Mutexes present and exercised, not marked > MPSAFE. Actually, I think that owi can be removed for 7.0. Maybe even 6.0. It only existed as a stopgap for the 802.11 framework transition. > > if_aue, if_axe, if_cdce, if_cue, if_kue, if_rue, if_udav, if_ural > Countless USB device drivers -- locking present, > exercised, but all running under Giant, presumably due to > the USB framework. Someone has a big TODO item here. I don't think that we can assume that USB will get fixed for 7.0. It would be nice if it does, but we shouldn't plan to orphan these drivers because of it. [...] Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42DC08A4.2060001>