From owner-freebsd-current@FreeBSD.ORG Tue Mar 4 15:18:33 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 E0CFB106566B; Tue, 4 Mar 2008 15:18:33 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by mx1.freebsd.org (Postfix) with ESMTP id 917D28FC20; Tue, 4 Mar 2008 15:18:33 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from router.rabson.org ([80.177.232.241] helo=itchy.rabson.org) by anchor-post-32.mail.demon.net with esmtp (Exim 4.67) id 1JWYuF-0008bi-6v; Tue, 04 Mar 2008 15:18:18 +0000 Received: from macbook.rabson.org (macbook.rabson.org [IPv6:2002:50b1:e8f2:1:21e:52ff:fe73:8011]) by itchy.rabson.org (Postfix) with ESMTP id A88EB3F9F; Tue, 4 Mar 2008 15:17:55 +0000 (GMT) Message-Id: <9299FBBE-F58A-4107-991D-1C851EB8802C@rabson.org> From: Doug Rabson To: M. Warner Losh In-Reply-To: <20080304.080332.-1975970122.imp@bsdimp.com> Content-Type: multipart/signed; boundary=Apple-Mail-9-850892521; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 4 Mar 2008 15:17:55 +0000 References: <47CCDA8A.60004@errno.com> <0B526200-AE42-436D-BB28-51B396D95FC5@rabson.org> <20080304.080332.-1975970122.imp@bsdimp.com> X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: ClamAV 0.92/6124/Tue Mar 4 12:01:21 2008 on itchy.rabson.org X-Virus-Status: Clean X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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:18:34 -0000 --Apple-Mail-9-850892521 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 4 Mar 2008, at 15:03, M. Warner Losh wrote: > 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. What I meant was that the probe routine should check the device name and only return success if the names match. Now I've had a chance to re-load some of those old memories from tape, I think the newbus code does this for you but only if the device being probed was added with a name. Un-named devices, (e.g. if device_add_child was called with a NULL name) need to have some other way of doing the right thing in probe. 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. --Apple-Mail-9-850892521--