From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 01:08:46 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 DDB361065678; Fri, 19 Sep 2008 01:08:46 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 81EF58FC1E; Fri, 19 Sep 2008 01:08:46 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8J0nYXs020211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 17:49:35 -0700 (PDT) (envelope-from sobomax@sippysoft.com) Message-ID: <48D2F720.2060608@sippysoft.com> Date: Thu, 18 Sep 2008 17:49:36 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "M. Warner Losh" References: <57AF36D8-0F83-4DF8-BEAA-CF3B59EAA361@rabson.org> <20080304.090741.-1631526462.imp@bsdimp.com> <47CDF0FE.9040405@FreeBSD.org> <20080304.193120.-625041952.imp@bsdimp.com> In-Reply-To: <20080304.193120.-625041952.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Sep 2008 01:32:30 +0000 Cc: re@FreeBSD.ORG, gnn@FreeBSD.ORG, xcllnt@mac.com, 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: Fri, 19 Sep 2008 01:08:47 -0000 Sorry for the delay. After applying the patch I see the following message in the verbose log: Sep 18 23:42:33 sobomac kernel: nexus0: , type (unknown) (no driver attached) Not sure if it's OK or not. M. Warner Losh wrote: > OK. Digging deeper into this problem shows that sparc64 also appears > to do the same things to the nexus bus children that powerpc does. > There may be other nexus devices that do this, and rewriting them to > conform to the x86 conventions would take a little bit of effort. > > I'm starting to think that the architecturally clean way to solve this > issue is to allow children to ask if they have a fixed devclass or a > wildcard one in newbus. This is easy to implement, but as I typed > this up, something inside me rebelled. In this scenario, the newbus > would grow a new function device_is_wildcard() that drivers could > call. > > The other way to fix this is to return a better value from the probe > routine for those devices that attach to the nexus. A quick grep of > the tree suggests that opencrypto is the only MI driver that uses this > trick. There are a few MD drivers that use it as well, but they are > all well controlled. Here's a quick hack. If you want to test this > out without changing newbus, change the cryptosoft.c probe routine to > return (BUS_PROBE_HOOVER - 1) rather than zero. > > Comments? Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com