Date: Tue, 04 Mar 2008 08:03:32 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: dfr@rabson.org 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! Message-ID: <20080304.080332.-1975970122.imp@bsdimp.com> In-Reply-To: <0B526200-AE42-436D-BB28-51B396D95FC5@rabson.org> References: <47CCDA8A.60004@errno.com> <FDC693C6-708A-4DC0-8D0C-2CCDDD50E876@mac.com> <0B526200-AE42-436D-BB28-51B396D95FC5@rabson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <0B526200-AE42-436D-BB28-51B396D95FC5@rabson.org>
Doug Rabson <dfr@rabson.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080304.080332.-1975970122.imp>