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

In message: <47CDF0FE.9040405@xxxxxxxxxxx>
Maxim Sobolev <sobomax@xxxxxxxxxxx> writes:
: M. Warner Losh wrote:
: > In message: <57AF36D8-0F83-4DF8-BEAA-CF3B59EAA361@xxxxxxxxxx>
: > Doug Rabson <dfr@xxxxxxxxxx> writes:
: > :
: > : On 4 Mar 2008, at 15:36, M. Warner Losh wrote:
: > :
: > : > In message: <9299FBBE-F58A-4107-991D-1C851EB8802C@xxxxxxxxxx>
: > : > Doug Rabson <dfr@xxxxxxxxxx> writes:
: > : > : 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.
: > : >
: > : > The problem actually turns out to be in how the powerpc nexus does
: > : > things. It does them in a very un-nexus-like way. The nexus attached
: > : > drivers ask for hardware details, which isn't done elsewhere. This
: > : > means when you mix and match the ones that expect to be explicitly set
: > : > and the ones that don't that you run into trouble.
: > : >
: > : > This needs to be reworked.
: > :
: > : Perhaps the crypto stuff should add itself to root0 instead of nexus.
: >
: > I think that would cause other problems...
:
: OK, since nobody seems to be interested enough to fix the issue in
: question I have spent some time to dig out what's going on. Disclaimer:
: it's my first serious encounter with newbus, so that I might be wrong
: somewhere.

How could you possibly conclude that.... I've been working all day
since i took time out of my day to track it down this morning...

: Apparently the issue in hand is caused by superposition of three facts:
:
: 1. The nexus/powerpc code creates bunch of children devices using
: information from the OF in the probe routine (should be probably attach
: routine), with NULL devclass.
:
: 2. The opencrypto creates fake "cryptosoft" device and adds it as a
: child to the newbus. It doesn't provide any actual probe code in the
: driver to check that the offered device is in fact one that has been
: created earlier.
:
: 3. The newbus code for some not very clear to me reason offers devices
: in the NULL devclass to every driver registered in the system.
:
: As a result of (1), (2) and (3) as well as current phase of the moon,
: the bunch of OF-devices created in (1) are offered to the "cryptosoft"
: driver before powerpc drivers and since there is no probe routine the
: "cryptosoft" driver attaches to all of them.
:
: This could be fixed by either altering probe in the "cryptosoft" to
: check that the device offered is in fact one that has been created
: earlier, or changing nexus/powerpc code to assign non-NULL devclass to
: child devices that it has generated from OF to match devclass of the
: relevant drivers (pcib, unin are the most important ones). The following
: patch uses the second approach. It would be nice if somebody with more
: newbus clue can review/comment. The patch also moves relevant code from
: nexus_probe() into nexus_attach().
:
: http://sobomax.homeunix.org/~sobomax/powerpc_crypto.diff

This patch isn't right at all. Like I said in other mail, the proper
fix is to reparent things the way I suggested.

Warner

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: IPSEC/crypto is broken in FreeBSD/powerpc 7.0-RELEASE!
    ... The nexus/powerpc code creates bunch of children devices using information from the OF in the probe routine, with NULL devclass. ... The opencrypto creates fake "cryptosoft" device and adds it as a child to the newbus. ... It doesn't provide any actual probe code in the driver to check that the offered device is in fact one that has been created earlier. ...
    (freebsd-current)
  • Re: newbus integration of MOD_QUIESCE
    ... The only way to fix it is to do a three-phase commit and that would ... newbus cannot solve that problem for us either. ... >method if possible to reduce the load on driver writers. ... discovering new things before you do the unload. ...
    (freebsd-arch)
  • to list all the devices in freebsd &definition analyse
    ... i got some anornymous definition on devclass driver and device that ... i think they seems reasonable but how can devclass Represents a bus ... Represents a bus or leaf-level end-device driver. ...
    (freebsd-hackers)
  • to list all the devices in freebsd &definition analyse
    ... i got some anornymous definition on devclass driver and device that ... i think they seems reasonable but how can devclass Represents a bus ... Represents a bus or leaf-level end-device driver. ...
    (freebsd-questions)
  • Re: misc questions about the device&driver arch
    ... just create a new devclass,and link it self into the parent ... busdevice's driver link and do nothing .what is the use of the driver ... that with some hardware mechanisms the pci bridge driver can do global pci ... resource window reconfiguration.so good to the hotplugin pci device for it ...
    (freebsd-hackers)