From owner-freebsd-current@FreeBSD.ORG Wed Mar 5 01:52:10 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F98C1065670; Wed, 5 Mar 2008 01:52:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id DFD738FC24; Wed, 5 Mar 2008 01:52:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m251oc0q077989; Tue, 4 Mar 2008 18:50:38 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 04 Mar 2008 18:51:07 -0700 (MST) Message-Id: <20080304.185107.-1270942879.imp@bsdimp.com> To: sobomax@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <47CDF0FE.9040405@FreeBSD.org> References: <57AF36D8-0F83-4DF8-BEAA-CF3B59EAA361@rabson.org> <20080304.090741.-1631526462.imp@bsdimp.com> <47CDF0FE.9040405@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gnn@FreeBSD.org, xcllnt@mac.com, current@FreeBSD.org, re@FreeBSD.org Subject: Re: IPSEC/crypto is broken in FreeBSD/powerpc 7.0-RELEASE! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 01:52:10 -0000 In message: <47CDF0FE.9040405@FreeBSD.org> Maxim Sobolev writes: : M. Warner Losh wrote: : > In message: <57AF36D8-0F83-4DF8-BEAA-CF3B59EAA361@rabson.org> : > Doug Rabson writes: : > : : > : On 4 Mar 2008, at 15:36, M. Warner Losh wrote: : > : : > : > In message: <9299FBBE-F58A-4107-991D-1C851EB8802C@rabson.org> : > : > Doug Rabson writes: : > : > : I can't see the code which adds this device on a first look. Can you : > : > : tell me the filename and I'll take a quick look at it. : > : > : > : > The problem actually turns out to be in how the powerpc nexus does : > : > things. It does them in a very un-nexus-like way. The nexus attached : > : > drivers ask for hardware details, which isn't done elsewhere. This : > : > means when you mix and match the ones that expect to be explicitly set : > : > and the ones that don't that you run into trouble. : > : > : > : > This needs to be reworked. : > : : > : Perhaps the crypto stuff should add itself to root0 instead of nexus. : > : > I think that would cause other problems... : : OK, since nobody seems to be interested enough to fix the issue in : question I have spent some time to dig out what's going on. Disclaimer: : it's my first serious encounter with newbus, so that I might be wrong : somewhere. How could you possibly conclude that.... I've been working all day since i took time out of my day to track it down this morning... : Apparently the issue in hand is caused by superposition of three facts: : : 1. The nexus/powerpc code creates bunch of children devices using : information from the OF in the probe routine (should be probably attach : routine), with NULL devclass. : : 2. The opencrypto creates fake "cryptosoft" device and adds it as a : child to the newbus. It doesn't provide any actual probe code in the : driver to check that the offered device is in fact one that has been : created earlier. : : 3. The newbus code for some not very clear to me reason offers devices : in the NULL devclass to every driver registered in the system. : : As a result of (1), (2) and (3) as well as current phase of the moon, : the bunch of OF-devices created in (1) are offered to the "cryptosoft" : driver before powerpc drivers and since there is no probe routine the : "cryptosoft" driver attaches to all of them. : : This could be fixed by either altering probe in the "cryptosoft" to : check that the device offered is in fact one that has been created : earlier, or changing nexus/powerpc code to assign non-NULL devclass to : child devices that it has generated from OF to match devclass of the : relevant drivers (pcib, unin are the most important ones). The following : patch uses the second approach. It would be nice if somebody with more : newbus clue can review/comment. The patch also moves relevant code from : nexus_probe() into nexus_attach(). : : http://sobomax.homeunix.org/~sobomax/powerpc_crypto.diff This patch isn't right at all. Like I said in other mail, the proper fix is to reparent things the way I suggested. Warner