From owner-freebsd-hackers@FreeBSD.ORG Tue May 24 11:55:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E2EC106566C for ; Tue, 24 May 2011 11:55:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 558D78FC0A for ; Tue, 24 May 2011 11:55:40 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EC72946B32; Tue, 24 May 2011 07:55:39 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 77ED68A04F; Tue, 24 May 2011 07:55:39 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org, philip-freebsd1@soeberg.net Date: Tue, 24 May 2011 07:47:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <4DDA6B95.3090704@soeberg.net> <201105231032.20084.jhb@freebsd.org> <4DDA97EA.20705@soeberg.net> In-Reply-To: <4DDA97EA.20705@soeberg.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105240747.02381.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 24 May 2011 07:55:39 -0400 (EDT) Cc: Subject: Re: device_detach() on a device used by ixgbe driver ( FreeBSD 7-STABLE through to 9-CURRENT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 11:55:40 -0000 On Monday, May 23, 2011 1:22:50 pm Philip Soeberg wrote: > On 23-05-2011 16:32, John Baldwin wrote: > >> I assume this (transcanding from FreeBSD 7.0-STABLE through to FreeBSD > >> 9-CURRENT) is in error? I would expect sys/dev/ixgbe/ixgbe.c's probe() > >> function to return BUS_PROBE_DEFAULT, which is the "Base OS default > >> driver".. > > > > Yes, that is true. > > > >> If this is true, then we should probably also update > >> sys/kern/device_if.m's description of the probe() method as to reflect > >> the BUS_PROBE_* return values in a clearer way than is currently described. > >> Do you want me to provide a patch? (it's really a one liner for ixgbe.c > >> and a couple of alterations to the device_if.m, if need be) > > > > device_if.m was probably just never updated from when BUS_PROBE_* were added. > > Updating it would be a good thing. > I'll submit a patch tomorrow with an updated description and a fix for > the ixgbe then.. > > > >> I would also expect the ixgbe.c driver to do a quick resource_disabled() > >> in it's attach() function, so that we can disable specific adapters > >> through kenv hint.ix.0.disabled=1.. > > > > I think ixgbe has to be fixed to use BUS_PROBE_DEFAULT. Very few drivers > > should use '0' for their probe return value. > > > > but since it does return zero, do you have any idea how I can force it > to detach allowing me in instead? I've been stabbing high and low at it > for hours now, and nothing seem to get me anywhere.. short of hacking > the ixgbe_attach() function address, I can't seem to figure out a way to > kill the systems way of re-attaching the device to the ixgbe just after > I've detached it. > > rather frustrating.. It's like a catch-22 problem.. > > and worse, the ixgbe driver is per default included as a static module, > so loader.conf "ix_load=no" will have no effect (unless I'm mistaken?) > > I'm running out of ideas as to how I can attach myself to that Intel > device instead of the ixgbe when it is linked static and with a return > of zero in it's probe().. And I'm also out of ideas as to how to disable > that damn module altogether, short of recompiling the kernel.. > > any ideas? Short of dynamically patching ixgbe_probe()'s return value at runtime? No, no ideas. :( -- John Baldwin