ath(4) failing with ath_reset for AR9285

[Matthew Dillon]

:Hi,
:
:The problem is "dfbsd should port over the ath driver." ;-)
:
:The actual cause is likely radio related - the AR9285 code that Rui
:initially ported over was based on what was in ath9k and it was
:suitably unfinished. (So it's not Rui's fault, he did a great job with
:what he had.) I subsequently found/fixed/ported a bunch of stuff with
:an ath9k developer as we *ahem* discovered the ath9k support was
:incomplete.
:
:In fact, if the dragonfly bsd guys were interested, I could have my
:arm twisted into forking off a "shared" project where we have a shared
:ath driver and HAL, and pull it into *BSD as a contrib project.
:
:That way I'd only have to fix bugs once (hah), and everyone could
:immediately benefit from it.
:
:What do you all think? You'd (mostly) get 802.11n for free. :-)
:
:Adrian

    I'd say we're definitely interested, but I don't know how easy it would
    be to maintain a common infrastructure.  I have to say honestly that it
    might not be worth maintaining a common infrastructure for the driver.
    DragonFly's network subsystem differs hugely from FreeBSD's and the
    wireless infrastructure also has some major differences on top of that.

    We're working with Rui's original port of the 802.11 infrastructure
    to DragonFly, plus various hacks we added afterwords to stabilize it.

    The major differences relative to his port are related to the fact
    that the WLAN pseudo-interfaces and the ATH (and other) physical
    interfaces used different locks, but were able to call each other
    recursively via the 802.11 framework.  This led to the drivers doing
    crazy unlock/relock sequences and STILL hitting deadlocks in some cases.
    But even with the unlock/relock sequences that left the driver open
    to reentrancy issues which we were constantly hitting.

    So in our network infrastructure I basically gave up on the 802_11
    psuedo-vs-phy locking issue and I have a single global serializer
    that covers the *entire* wireless infrastructure on the system...
    all pseudo-interfaces and all physical interfaces use the same
    serializer.

    --

    In our normal network subsystem there are also major differences.
    We have an ifnet serializer that is installed on a per-driver basis
    (but as per above, for the wireless physical interfaces we just specify
    a single global serializer), but the system infrastructure is
    responsible for acquiring the serializer (our version of the driver
    locks) rather than the drivers having to code them up for each entry
    point, which greatly simplifies driver design).  Even the fan-in/fan-out
    locking for multiple rx/tx queues is handled by the higher level
    system for the most part, for things like IF_EMX.

    We also have to always change all the M_NOWAIT allocations in FreeBSD
    drivers that appear to be used for everything, including small one-time
    critical driver structures, to M_INTWAIT in DragonFly.  I guess M_NOWAIT
    in FreeBSD doesn't actually ever return NULL, but in DragonFly it can
    return NULL in virtually any situation (such as if a lock cannot be
    acquired non-blocking).

    Plus some (mostly) minor changes to numerous other things... differences
    in how BUSDMA works, for example.  Other issues such as DragonFly not
    overloading the stdio namespace so kernel printfs in dragonfly are
    'kprintf()' not 'printf()', and allocations are 'kmalloc()' rather
    than 'malloc', and so forth.

    --

    Sorry, don't mean to discourage you.  I'd really love there to be an
    easier way to synchronize driver code too.

						-Matt