[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Fixing USB ethernet for FreeBSD 7.0.
- To: Alfred Perlstein <alfred_(_at_)_freebsd_(_dot_)_org>
- Subject: Re: RFC: Fixing USB ethernet for FreeBSD 7.0.
- From: Ian Dowse <iedowse_(_at_)_iedowse_(_dot_)_com>
- Date: Sun, 03 Dec 2006 00:51:09 +0000
- Cc: freebsd-smp_(_at_)_freebsd_(_dot_)_org, freebsd-usb_(_at_)_freebsd_(_dot_)_org
In message <20061201191731_(_dot_)_GR38808_(_at_)_elvis_(_dot_)_mu_(_dot_)_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
freebsd-usb_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscribe_(_at_)_freebsd_(_dot_)_org"