Re: IPSEC/crypto is broken in FreeBSD/powerpc 7.0-RELEASE!

On 4 Mar 2008, at 15:03, M. Warner Losh wrote:

> In message: <0B526200-AE42-436D-BB28-51B396D95FC5_at_rabson.org>
>            Doug Rabson <dfr_at_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.

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.