From owner-freebsd-current@FreeBSD.ORG Tue Mar 4 15:04:36 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 1BA601065677; Tue, 4 Mar 2008 15:04:36 +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 A50D98FC22; Tue, 4 Mar 2008 15:04:35 +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 m24F34O4071003; Tue, 4 Mar 2008 08:03:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 04 Mar 2008 08:03:32 -0700 (MST) Message-Id: <20080304.080332.-1975970122.imp@bsdimp.com> To: dfr@rabson.org From: "M. Warner Losh" In-Reply-To: <0B526200-AE42-436D-BB28-51B396D95FC5@rabson.org> References: <47CCDA8A.60004@errno.com> <0B526200-AE42-436D-BB28-51B396D95FC5@rabson.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, re@freebsd.org, current@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: Tue, 04 Mar 2008 15:04:36 -0000 In message: <0B526200-AE42-436D-BB28-51B396D95FC5@rabson.org> Doug Rabson writes: : : On 4 Mar 2008, at 06:41, Marcel Moolenaar wrote: : : > : > On Mar 3, 2008, at 9:13 PM, Sam Leffler wrote: : > : >> Marcel Moolenaar wrote: : >>> : >>> On Mar 3, 2008, at 6:18 PM, Maxim Sobolev wrote: : >>> : >>>> Hi, : >>>> : >>>> It appears to be that "options IPSEC" along with "device crypto" : >>>> breaks FreeBSD/powerpc kernel badly. When enabling these options, : >>>> apparently kernel doesn't perform any initialization tasks (I : >>>> don't see usual probe/init sequence output) but jumps straight : >>>> into root fs mounting after initing crypto(4) and ipsec(4), which : >>>> is not usable since no devices has been attached. Keyboard is not : >>>> working either. : >>> : >>> The problem is with device crypto. It attaches to nexus(4) and : >>> expects to be the only child. As you can see from the log, all : >>> children of nexus suddenly become instantiations of cryptosoft(4) : >>> rather then the usual drivers that attach. : >>> : >>> The swcr_probe() function should check that the device it gets : >>> is really the one created for it. : >>> : >> : >> Don't know about "expects to be the only child" but I did was jhb : >> said was right. : > : > A driver's probe function gets called for all devices on the bus : > the driver has an attachment on. Typically the probe function : > performs some tests to see if the device in question corresponds : > to hardware the driver works with. For PCI this is typically the : > vendor and device ID. In this case, swcr_probe() always returns : > success, no matter what device it's passed. This only works if : > it's the only device on the bus... : > : >> If you know otherwise please fix it. : > : > I'll play with it. I think the best way is to do it the same as : > null(4). There's nothing in the probe function we can test for. : : In cases like this, where the bus and children are 'soft' : organisational devices rather than actual hardware, normally the probe : routines just look at the device name to work out what to return. I'm not sure what you are suggesting here, since the name is set by newbus before probe is called. Warner