From owner-freebsd-hackers@FreeBSD.ORG Mon May 23 17:22:54 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 CC22A106566C for ; Mon, 23 May 2011 17:22:54 +0000 (UTC) (envelope-from philip-freebsd1@soeberg.net) Received: from pasmtpA.tele.dk (pasmtpa.tele.dk [80.160.77.114]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6178FC16 for ; Mon, 23 May 2011 17:22:54 +0000 (UTC) Received: from mail.soeberg.net (0x573f534a.cpe.ge-1-1-0-1109.bynqu1.customer.tele.dk [87.63.83.74]) by pasmtpA.tele.dk (Postfix) with ESMTP id DBCDC80027B for ; Mon, 23 May 2011 19:22:52 +0200 (CEST) Received: from [192.168.1.199] ([192.168.1.199]) (authenticated user philip@soeberg.net) by mail.soeberg.net (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for freebsd-hackers@freebsd.org; Mon, 23 May 2011 19:22:53 +0200 Message-ID: <4DDA97EA.20705@soeberg.net> Date: Mon, 23 May 2011 19:22:50 +0200 From: Philip Soeberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4DDA6B95.3090704@soeberg.net> <201105231032.20084.jhb@freebsd.org> In-Reply-To: <201105231032.20084.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Reply-To: philip-freebsd1@soeberg.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 17:22:54 -0000 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?