RFC: Fixing USB ethernet for FreeBSD 7.0.
iedowse at iedowse.com
Sat Dec 2 16:51:12 PST 2006
In message <20061201191731.GR38808 at elvis.mu.org>, Alfred Perlstein writes:
>I recently had the displeasure of trying to use an USB etherdongle
>under FreeBSD. Result: panic when the interface was started.
>I fixed it using a stopgap:
>There are still some major issues:
>1) requires Giant.
>2) several error paths will still panic the kernel.
>I would like to fix them, however that does not seem easy given the
FYI, some USB ethernet drivers are better than others in this respect
- for example, axe(4) uses sx locks and task queues to avoid the
worst of the issues. The problems remaining in axe are that the
error recovery code in axe_encap should use a task queue, and there
are some cases where if_ioctl routines are called with other locks
On the issue of calling if_ioctl while holding locks, I think this
can happen when if_addmulti() holds locks and calls if_ioctl to
synchronise the hardware with the software state from ifp->if_multiaddrs.
Almost all other if_ioctl calls occur in a context where blocking
is allowed, so it may be possible to rework the if_addmulti() code
paths so that the outer ioctl() code could first update the software
state, release locks and then perform the if_ioctl to synchronise
the hardware state.
>Using callbacks to do all IO during an interrupt is programatically
>complex and painful. For instance, take the case of the following
>code pulled from aue_stop() (which can be called from interrupt
Note though that most USB ethernet devices require just a single
USB transfer per packet, so it's typically only during error recovery
and setup that asynchronous I/O is too tricky. That's probably easy
enough to fix with a queued task, and since error recovery is rare
it doesn't matter too much if many devices share a task queue.
If there are devices requiring multiple commands to be sent during
normal sending/receiving of packets then you'd probably also want
a separate thread for the TX and RX paths if you were to do the
More information about the freebsd-smp