Re: [RFC] USBdump patches
On Wed, Nov 24, 2010 at 07:35:30PM +1300, Andrew Thompson wrote: On 24 November 2010 18:46, Weongyo Jeong weongyo.je...@gmail.com wrote: On Wed, Nov 24, 2010 at 01:59:47PM +1300, Andrew Thompson wrote: On 24 November 2010 13:36, Jung-uk Kim j...@freebsd.org wrote: On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote: - BPF was normally for ethernet frames (most operations were based on mbuf including the machine filter and there were a lot of assumptions the input buffer is mbuf type. For example, handling BPF_LD|BPF_W|BPF_ABS). However the USB packet isn't like mbuf style that it's just a linear buffer. So the most important code or assumption wasn't compatible. BPF can deal with linear buffer just fine. For example, ng_bpf(4) does it. Please see sys/netgraph/ng_bpf.c. - Just making the patch for BPF code, it looked like a trick or a hack to me because I couldn't define what BPF should be. If you don't want to touch bpf.c for some reason, netgraph(4) (- ng_bpf) may be an alternate solution for you. - I could not define BPF exactly myself that what BPF should cover. I agreed with that BPF is for ethernet packet filtering but could not make sure myself that BPF could cover USB packets. BPF is a generic packet filter machine, i.e., bytecode is generic enough for any type of data stream. I agree that this is the best way forward, if it can be achieved. Attached is what I really wanted to do. USB pf is greatly simplified and perfectly satisfy me. It'll fully benefit from changes of BPF code. I'll commit this version into HEAD if no objections. Looks good. Is this compatible with the wireshark pcap format? Not yet. I think it could happen soon. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] USBdump patches
On Tue, Nov 23, 2010 at 11:19:33PM +0100, Hans Petter Selasky wrote: Hi, Please find attached official usbdump patch from HPS trying to re-use as much as possible of Weongyo's code which was committed not long ago. You need to SVN up to the latest 9-current. This patch should fix all USB-dump issues reported so far! 1) Fix for proper offset calculation on ISOCHRONOUS reception. 2) Fixes for device mode. 3) PF-virtual-machine is OK (and done before copy of data). 4) Can load and unload the PF-code like a module. How to use: cd /usr/src cat usbdump_r215656_patch.txt | patch You need to make new kernel, but not userland. Install sys/dev/usb/usb_pf.h into /usr/include/dev/usb/ and make all install in src/usr.sbin/usbdump . After reboot: kldload usb_pf usbdump -d -1 -vvv man usbdump NACK. You already could recognize that the patch is quite big and multiple patches are mixed into one. Please separate into smallest pieces then send freebsd-usb@ again. I don't want to do a jumbo jump. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] USBdump patches
On Tue, Nov 23, 2010 at 06:52:36PM -0500, Jung-uk Kim wrote: On Tuesday 23 November 2010 06:31 pm, Jung-uk Kim wrote: [CC sanitized] On Tuesday 23 November 2010 06:01 pm, Hans Petter Selasky wrote: Dear Weongyo, NACK. You already could recognize that the patch is quite big and multiple patches are mixed into one. Please separate into smallest pieces then send freebsd-usb@ again. I don't want to do a jumbo jump. Technically, I don't like the copy-and-pasted code from bpf.c and bpf_filter.c. Was it really necessary? Is the dump file in PCAP format? Please enlighten me if I missed something. The following paragraph is extracted from email I sent to rwatson@ because he also asked same question to me. And I added CC to freebsd-usb@ to share my story with other developers who might think similar. Hello Roberts, I understand what you're worry and agree with you that if I could remove this duplication it'd be best one. I think it could be happen enough later if we could reach the consensus. The biggest confusions I encountered during implementing? (porting) it for USB packet filter were as follows. Please let me know if there are something I missed: - BPF was normally for ethernet frames (most operations were based on mbuf including the machine filter and there were a lot of assumptions the input buffer is mbuf type. For example, handling BPF_LD|BPF_W|BPF_ABS). However the USB packet isn't like mbuf style that it's just a linear buffer. So the most important code or assumption wasn't compatible. - Just making the patch for BPF code, it looked like a trick or a hack to me because I couldn't define what BPF should be. - I could not define BPF exactly myself that what BPF should cover. I agreed with that BPF is for ethernet packet filtering but could not make sure myself that BPF could cover USB packets. Please tell me your opinion if you guys have better approach. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] USBdump patches
On Tue, Nov 23, 2010 at 07:36:47PM -0500, Jung-uk Kim wrote: On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote: On Tue, Nov 23, 2010 at 06:52:36PM -0500, Jung-uk Kim wrote: On Tuesday 23 November 2010 06:31 pm, Jung-uk Kim wrote: [CC sanitized] On Tuesday 23 November 2010 06:01 pm, Hans Petter Selasky wrote: Dear Weongyo, NACK. You already could recognize that the patch is quite big and multiple patches are mixed into one. Please separate into smallest pieces then send freebsd-usb@ again. I don't want to do a jumbo jump. Technically, I don't like the copy-and-pasted code from bpf.c and bpf_filter.c. Was it really necessary? Is the dump file in PCAP format? Please enlighten me if I missed something. The following paragraph is extracted from email I sent to rwatson@ because he also asked same question to me. And I added CC to freebsd-usb@ to share my story with other developers who might think similar. Hello Roberts, I understand what you're worry and agree with you that if I could remove this duplication it'd be best one. I think it could be happen enough later if we could reach the consensus. The biggest confusions I encountered during implementing? (porting) it for USB packet filter were as follows. Please let me know if there are something I missed: - BPF was normally for ethernet frames (most operations were based on mbuf including the machine filter and there were a lot of assumptions the input buffer is mbuf type. For example, handling BPF_LD|BPF_W|BPF_ABS). However the USB packet isn't like mbuf style that it's just a linear buffer. So the most important code or assumption wasn't compatible. BPF can deal with linear buffer just fine. For example, ng_bpf(4) does it. Please see sys/netgraph/ng_bpf.c. - Just making the patch for BPF code, it looked like a trick or a hack to me because I couldn't define what BPF should be. If you don't want to touch bpf.c for some reason, netgraph(4) (- ng_bpf) may be an alternate solution for you. - I could not define BPF exactly myself that what BPF should cover. I agreed with that BPF is for ethernet packet filtering but could not make sure myself that BPF could cover USB packets. BPF is a generic packet filter machine, i.e., bytecode is generic enough for any type of data stream. Oh I see what you mean. `buflen' was a key variable whether the buffer is mbuf or linear buffer that I missed it. You saved my enough time. :-) I think we could reduce significant code of USB pf. And I'll provide a second patch for this. Please forgive my ignorance. Thank you! regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] USBdump patches
On Wed, Nov 24, 2010 at 01:59:47PM +1300, Andrew Thompson wrote: On 24 November 2010 13:36, Jung-uk Kim j...@freebsd.org wrote: On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote: - BPF was normally for ethernet frames (most operations were based on mbuf including the machine filter and there were a lot of assumptions the input buffer is mbuf type. For example, handling BPF_LD|BPF_W|BPF_ABS). However the USB packet isn't like mbuf style that it's just a linear buffer. So the most important code or assumption wasn't compatible. BPF can deal with linear buffer just fine. For example, ng_bpf(4) does it. Please see sys/netgraph/ng_bpf.c. - Just making the patch for BPF code, it looked like a trick or a hack to me because I couldn't define what BPF should be. If you don't want to touch bpf.c for some reason, netgraph(4) (- ng_bpf) may be an alternate solution for you. - I could not define BPF exactly myself that what BPF should cover. I agreed with that BPF is for ethernet packet filtering but could not make sure myself that BPF could cover USB packets. BPF is a generic packet filter machine, i.e., bytecode is generic enough for any type of data stream. I agree that this is the best way forward, if it can be achieved. Yes it's best. I think it could be achieved. I'll make the patch. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] USBdump patches
On Wed, Nov 24, 2010 at 01:59:47PM +1300, Andrew Thompson wrote: On 24 November 2010 13:36, Jung-uk Kim j...@freebsd.org wrote: On Tuesday 23 November 2010 07:18 pm, Weongyo Jeong wrote: - BPF was normally for ethernet frames (most operations were based on mbuf including the machine filter and there were a lot of assumptions the input buffer is mbuf type. For example, handling BPF_LD|BPF_W|BPF_ABS). However the USB packet isn't like mbuf style that it's just a linear buffer. So the most important code or assumption wasn't compatible. BPF can deal with linear buffer just fine. For example, ng_bpf(4) does it. Please see sys/netgraph/ng_bpf.c. - Just making the patch for BPF code, it looked like a trick or a hack to me because I couldn't define what BPF should be. If you don't want to touch bpf.c for some reason, netgraph(4) (- ng_bpf) may be an alternate solution for you. - I could not define BPF exactly myself that what BPF should cover. I agreed with that BPF is for ethernet packet filtering but could not make sure myself that BPF could cover USB packets. BPF is a generic packet filter machine, i.e., bytecode is generic enough for any type of data stream. I agree that this is the best way forward, if it can be achieved. Attached is what I really wanted to do. USB pf is greatly simplified and perfectly satisfy me. It'll fully benefit from changes of BPF code. I'll commit this version into HEAD if no objections. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 05, 2010 at 07:30:38PM +0100, Hans Petter Selasky wrote: Hi, In the patch attached to this e-mail I included Matthew Fleming's patch aswell. 1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles the words of the callout and USB API's terminology for doing the same. 2) I turns out I need to have code in subr_taskqueue.c to be able to make the operations atomic. 3) I did not update the manpage in this patch. Will do that before a commit. 4) My patch implements separate state keeping in struct task_pair, which avoids having to change any KPI's for now, like suggested by John Baldwin I think. 5) In my implementation I hard-coded the priority argument to zero, so that enqueuing is fast. Comments are welcome! The patch looks almost you moved usb_process.c code into taskqueue(9) that I means it still follows that a entry which enqueued at last should be executed at last. It seems that at least it's not a general for taskqueue(9). In my humble opinion it looks a trick. I think it'd better to find a general solution to solve it though I used sx(9) lock in my patches. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [CFR 2-3/n] removes uther dependency of axe(4)
On Mon, Nov 01, 2010 at 09:30:25AM +0100, Hans Petter Selasky wrote:
On Sunday 31 October 2010 23:43:04 Weongyo Jeong wrote:
+static void
+axe_watchdog(void *arg)
+{
+ struct axe_softc *sc = arg;
+ struct ifnet *ifp = sc-sc_ifp;
+
+ if ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0)
+ return;
+
Hi,
Please explain what is wrong with the existing code regarding code
synchronisation. Your patch is very big and is likely to introduce problems.
Hello Hans,
I think your approach to synchronize the multiple tasks isn't bad though
the implementation of approach isn't familiar with me comparing the
other task queue implementations. It seems to me that it's a customized
task queue implementation only for USB subsystem.
I oppose the introduction of SX-locks. Please explain why you think SX-locks
are better than the USB process taskqueue.
I'd like to say that I also don't like SX locks that the reason is
mentioned at CONTEXT section of sx(9) man page.
I think using SX lock and the USB process taskqueue are both bad that if
I could avoid using it, I'll willing to avoid it to use it. But the
problem is that it's inevitable. I think we could choice one of two
approaches that one is using SX lock other is using USB process
taskqueue. The result of both would same, serialization.
Regarding to the approach there'll be pros and cons:
Pros of using SX lock:
- Don't need to create extra thread.
- Simple to read. Other developers could catch writer's intention
easily.
Cons of using SX lock:
- Unexpecting sleep with holding mutex according to CONTEXT section
of sx(9) man page. It should be used carefully.
- Adds another lock to the driver.
Pros of using USB process taksqueue:
- Please fill.
Cons of using USB process taskqueue:
- No atomic operation that it need to be drained explicitly with
sleeping that adds extra quirk code.
- Tasks would be merged into one if the task is enqueued multiple
times during pending that it means the writer takes care extra
exceptions. It could lead to unexpected device behavior depending
on device characteristics.
- At least two threads are involved. One is caller thread other
would be worker thread (USB process). It makes weak to race
conditions. It always make code complex.
Are you absolutely sure that all the IOCTL's that are called are allowed to
block in the way you have programmed?
Of course not because I'm a human. Human always do a mistake. :-) But
there are few cases which need to be atomic in USB devices. For
example, device up and down. It means sx(9) lock would be used very
limited places only.
The checks in xxx_watchdog() are not good enough. axe_tick() will execute
synchronous USB functions, which sleep for many hundreds of microseconds. You
should add this check before the sleepout_reset() too, and is this code
called
with any lock locked? I.E. Are you doing the clearing of IFF_DRV_RUNNING
atomic to testing this flag? Else the result can be random?
Maybe xxx_watchdog() would be called with holding the driver lock so
at least ifp-if_drv_flags would be protected.
regards,
Weongyo Jeong
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [CFR] add usb_sleepout.[ch]
On Mon, Nov 01, 2010 at 09:10:43AM +0100, Hans Petter Selasky wrote:
On Monday 01 November 2010 03:03:48 Weongyo Jeong wrote:
On Sun, Oct 31, 2010 at 03:09:49PM +0100, Hans Petter Selasky wrote:
On Sunday 31 October 2010 01:19:01 Weongyo Jeong wrote:
Hello USB guys,
1) All the sleepout_xxx() functions need mutex asserts.
Hi,
It looks it don't need it because callout(9) does it instead of sleepout
routines. Moreover sleepout don't create any mutexes in itself.
Ok.
2) Is it allowed to call callout_stop() / callout_reset() unlocked at
all?
Yes as long as it doesn't have side effects. It seems no drivers hold a
lock to call callout_stop() / callout_reset().
All USB drivers do to ensure state coherency.
What are the concequences if the mutex associated with the sleepout is
NULL ?
I added KASSERT macro to check this case at below. However the sleepout
pointer normally never be NULL because the intention of usage was as
follows:
struct driver_softc {
struct sleepout sleepout;
struct sleepout_task sleepout_task;
};
sleepout_create(sc-sleepout, blah);
Only it could be happen if `struct sleepout' is allocated by
dynamically though it's not my first purpose.
3) As per the current implementation it can happen that the task'ed
timeout is called after that sleepout_stop() is used. The code should
have a check in the task function to see if the sleepout() has been
cancelled or not, when the mutex associated with the sleepout is locked.
Yes it's true but it'd better to implement first taskqueue_stop() than
adding it sleepout routines directly. However no plans yet because I
couldn't imagine a side effect due to lack of this feature. Please let
me know if I missed the something important.
Maybe not when you are implementing a watchdog timer for ethernet, but then
you are limiting the use of those functions to USB ethernet only. The problem
happens when you are updating a state-machine in the callback and cannot
trust
that a stop cancelled the sleepout. All existing USB functions are written
this way. I.E. no completion done callback after usbd_transfer_stop().
For example if your watchdog is calling if_start() somehow, and then you do
an
if_down() which stops the watchdog, and then you can end up triggering the
if_start() after if_down(), which is incorrect.
OK that it makes sense to me. I'll try to make a patch, taskqueue_stop().
4) Should the functions be prefixed by usb_ ?
I don't have a preference for this. I think it's no problem to change
it. It could happen soon.
5) In drain you should drain the callout first, then drain the tasqueue.
Else the timer can trigger after the taskqueue is drained.
Have you considered using the USB sub-systems taskqueue, instead of the
kernel
one, so that jobs can be serialised among the two? Else you end up
introducing
SX-locks in all drivers? Is that on purpose?
As mentioned at the previous email. I prefer to use SX lock than
taskqueue. Please refer my email which sent just minutes ago.
It's fixed. Thank you for your review and the updated version is
embedded at this email.
regards,
Weongyo Jeong
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
[CFR 2/n] removes uther dependency of aue(4)
Hello,
The following patch is to remove uether(4) dependency of aue(4) and
change logs would be as follows:
- removes uether module dependency of aue(4) that finally uether
module would be gone. The reasons why I'm trying to remove uether
module are that
I discussed with USB ethernet maintainers about whether it's
useful or not. yongari@ answered that it's not helpful, not
straight forward to understand and make code complex.
- adds newly two uether APIs, uether_alloc_unr and uether_free_unr for
backward compatibility because current interface names for each
ethernet devices are linux-style `ue[0-9]+'. The naming rule would
be kept at STABLE_8 but not sure at STABLE_9.
If no objections I'd like to see this patch at HEAD.
regards,
Weongyo Jeong
Index: usb_ethernet.c
===
--- usb_ethernet.c (revision 214568)
+++ usb_ethernet.c (working copy)
@@ -597,5 +597,19 @@ uether_rxflush(struct usb_ether *ue)
}
}
+int
+uether_alloc_unr(void)
+{
+
+ return (alloc_unr(ueunit));
+}
+
+void
+uether_free_unr(int unit)
+{
+
+ free_unr(ueunit, unit);
+}
+
DECLARE_MODULE(uether, uether_mod, SI_SUB_PSEUDO, SI_ORDER_ANY);
MODULE_VERSION(uether, 1);
Index: if_aue.c
===
--- if_aue.c(revision 214568)
+++ if_aue.c(working copy)
@@ -81,6 +81,8 @@ __FBSDID($FreeBSD$);
#include sys/lock.h
#include sys/mutex.h
#include sys/condvar.h
+#include sys/socket.h
+#include sys/sockio.h
#include sys/sysctl.h
#include sys/sx.h
#include sys/unistd.h
@@ -88,6 +90,19 @@ __FBSDID($FreeBSD$);
#include sys/malloc.h
#include sys/priv.h
+#include net/if.h
+#include net/if_arp.h
+#include net/if_dl.h
+#include net/if_media.h
+#include net/if_types.h
+#include net/bpf.h
+#include net/ethernet.h
+
+#include miibus_if.h
+
+#include dev/mii/mii.h
+#include dev/mii/miivar.h
+
#include dev/usb/usb.h
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h
@@ -96,6 +111,7 @@ __FBSDID($FreeBSD$);
#defineUSB_DEBUG_VAR aue_debug
#include dev/usb/usb_debug.h
#include dev/usb/usb_process.h
+#include dev/usb/usb_sleepout.h
#include dev/usb/net/usb_ethernet.h
#include dev/usb/net/if_auereg.h
@@ -197,14 +213,6 @@ static usb_callback_t aue_intr_callback;
static usb_callback_t aue_bulk_read_callback;
static usb_callback_t aue_bulk_write_callback;
-static uether_fn_t aue_attach_post;
-static uether_fn_t aue_init;
-static uether_fn_t aue_stop;
-static uether_fn_t aue_start;
-static uether_fn_t aue_tick;
-static uether_fn_t aue_setmulti;
-static uether_fn_t aue_setpromisc;
-
static uint8_t aue_csr_read_1(struct aue_softc *, uint16_t);
static uint16_taue_csr_read_2(struct aue_softc *, uint16_t);
static voidaue_csr_write_1(struct aue_softc *, uint16_t, uint8_t);
@@ -217,6 +225,20 @@ static voidaue_reset_pegasus_II(struct aue_softc
static int aue_ifmedia_upd(struct ifnet *);
static voidaue_ifmedia_sts(struct ifnet *, struct ifmediareq *);
+static int aue_ioctl(struct ifnet *, u_long, caddr_t);
+static voidaue_start(struct ifnet *);
+static voidaue_start_locked(struct ifnet *);
+static voidaue_init(void *);
+static voidaue_stop_locked(struct aue_softc *);
+static voidaue_setmulti(void *, int);
+static voidaue_setmulti_locked(struct aue_softc *);
+static voidaue_rxflush(struct aue_softc *);
+static int aue_rxbuf(struct aue_softc *, struct usb_page_cache *,
+ unsigned int, unsigned int);
+static voidaue_setpromisc(void *, int);
+static voidaue_setpromisc_locked(struct aue_softc *);
+static voidaue_init_locked(struct aue_softc *);
+static voidaue_watchdog(void *);
static const struct usb_config aue_config[AUE_N_TRANSFER] = {
@@ -283,24 +305,19 @@ MODULE_DEPEND(aue, ether, 1, 1, 1);
MODULE_DEPEND(aue, miibus, 1, 1, 1);
MODULE_VERSION(aue, 1);
-static const struct usb_ether_methods aue_ue_methods = {
- .ue_attach_post = aue_attach_post,
- .ue_start = aue_start,
- .ue_init = aue_init,
- .ue_stop = aue_stop,
- .ue_tick = aue_tick,
- .ue_setmulti = aue_setmulti,
- .ue_setpromisc = aue_setpromisc,
- .ue_mii_upd = aue_ifmedia_upd,
- .ue_mii_sts = aue_ifmedia_sts,
-};
-
#defineAUE_SETBIT(sc, reg, x) \
aue_csr_write_1(sc, reg, aue_csr_read_1(sc, reg) | (x))
#defineAUE_CLRBIT(sc, reg, x) \
aue_csr_write_1(sc, reg, aue_csr_read_1(sc, reg) ~(x))
+static void
+aue_pause(struct aue_softc *sc, unsigned int _ticks)
+{
+
+ usb_pause_mtx(sc-sc_mtx, _ticks);
+}
+
static uint8_t
aue_csr_read_1(struct aue_softc *sc, uint16_t reg)
{
@@ -314,7 +331,8 @@ aue_csr_read_1(struct aue_softc *sc, uint16_t reg)
USETW(req.wIndex, reg);
USETW(req.wLength, 1);
- err = uether_do_request(sc-sc_ue, req, val, 1000);
+ err
[CFR 3/n] removes uther dependency of axe(4)
Hello,
As one of patch series it's for patching axe(4) without dependency of
uether module. The change log would be almost same like the previous
patch log.
regards,
Weongyo Jeong
Index: if_axereg.h
===
--- if_axereg.h (revision 214604)
+++ if_axereg.h (working copy)
@@ -185,7 +185,7 @@ struct axe_sframe_hdr {
uint16_t ilen;
} __packed;
-#defineGET_MII(sc) uether_getmii((sc)-sc_ue)
+#defineGET_MII(sc) (device_get_softc(sc-sc_miibus))
/* The interrupt endpoint is currently unused by the ASIX part. */
enum {
@@ -195,20 +195,35 @@ enum {
};
struct axe_softc {
- struct usb_ethersc_ue;
+ struct ifnet*sc_ifp;
+ device_tsc_dev;
+ device_tsc_miibus;
+ struct usb_device *sc_udev; /* used by uether_do_request() */
struct mtx sc_mtx;
- struct usb_xfer *sc_xfer[AXE_N_TRANSFER];
+ struct sx sc_sx;
+ struct usb_xfer *sc_xfer[AXE_N_TRANSFER];
+
+ /* ethernet address from eeprom */
+ uint8_t sc_eaddr[ETHER_ADDR_LEN];
+ struct ifqueue sc_rxq;
+
+ struct sleepout sc_sleepout;
+ struct sleepout_tasksc_watchdog;
+ struct task sc_setmulti;
+ struct task sc_setpromisc;
+
+ int sc_unit;
int sc_phyno;
-
int sc_flags;
#defineAXE_FLAG_LINK 0x0001
#defineAXE_FLAG_7720x1000 /* AX88772 */
#defineAXE_FLAG_1780x2000 /* AX88178 */
-
uint8_t sc_ipgs[3];
uint8_t sc_phyaddrs[2];
};
+#defineAXE_SXLOCK(_sc) sx_xlock((_sc)-sc_sx)
+#defineAXE_SXUNLOCK(_sc) sx_xunlock((_sc)-sc_sx)
#defineAXE_LOCK(_sc) mtx_lock((_sc)-sc_mtx)
#defineAXE_UNLOCK(_sc) mtx_unlock((_sc)-sc_mtx)
#defineAXE_LOCK_ASSERT(_sc, t) mtx_assert((_sc)-sc_mtx, t)
Index: if_axe.c
===
--- if_axe.c(revision 214604)
+++ if_axe.c(working copy)
@@ -89,6 +89,8 @@ __FBSDID($FreeBSD$);
#include sys/lock.h
#include sys/mutex.h
#include sys/condvar.h
+#include sys/socket.h
+#include sys/sockio.h
#include sys/sysctl.h
#include sys/sx.h
#include sys/unistd.h
@@ -96,6 +98,19 @@ __FBSDID($FreeBSD$);
#include sys/malloc.h
#include sys/priv.h
+#include net/if.h
+#include net/if_arp.h
+#include net/if_dl.h
+#include net/if_media.h
+#include net/if_types.h
+#include net/bpf.h
+#include net/ethernet.h
+
+#include miibus_if.h
+
+#include dev/mii/mii.h
+#include dev/mii/miivar.h
+
#include dev/usb/usb.h
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h
@@ -104,6 +119,7 @@ __FBSDID($FreeBSD$);
#defineUSB_DEBUG_VAR axe_debug
#include dev/usb/usb_debug.h
#include dev/usb/usb_process.h
+#include dev/usb/usb_sleepout.h
#include dev/usb/net/usb_ethernet.h
#include dev/usb/net/if_axereg.h
@@ -178,23 +194,26 @@ static miibus_readreg_t axe_miibus_readreg;
static miibus_writereg_t axe_miibus_writereg;
static miibus_statchg_t axe_miibus_statchg;
-static uether_fn_t axe_attach_post;
-static uether_fn_t axe_init;
-static uether_fn_t axe_stop;
-static uether_fn_t axe_start;
-static uether_fn_t axe_tick;
-static uether_fn_t axe_setmulti;
-static uether_fn_t axe_setpromisc;
-
static int axe_ifmedia_upd(struct ifnet *);
static voidaxe_ifmedia_sts(struct ifnet *, struct ifmediareq *);
static int axe_cmd(struct axe_softc *, int, int, int, void *);
static voidaxe_ax88178_init(struct axe_softc *);
static voidaxe_ax88772_init(struct axe_softc *);
static int axe_get_phyno(struct axe_softc *, int);
+static voidaxe_watchdog(void *);
+static voidaxe_init(void *);
+static voidaxe_init_locked(struct axe_softc *);
+static int axe_ioctl(struct ifnet *, u_long, caddr_t);
+static voidaxe_start(struct ifnet *);
+static voidaxe_start_locked(struct ifnet *);
+static voidaxe_tick(struct axe_softc *);
+static voidaxe_stop(struct axe_softc *);
+static voidaxe_stop_locked(struct axe_softc *);
+static voidaxe_setmulti_locked(struct axe_softc *);
+static voidaxe_setpromisc(void *, int);
+static voidaxe_setpromisc_locked(struct axe_softc *);
static const struct usb_config axe_config[AXE_N_TRANSFER] = {
-
[AXE_BULK_DT_WR] = {
.type = UE_BULK,
.endpoint = UE_ADDR_ANY,
@@ -250,18 +269,14 @@ MODULE_DEPEND(axe, ether, 1, 1, 1);
MODULE_DEPEND(axe, miibus, 1, 1, 1);
MODULE_VERSION(axe, 1);
-static const struct usb_ether_methods axe_ue_methods = {
- .ue_attach_post = axe_attach_post,
- .ue_start = axe_start,
- .ue_init = axe_init,
- .ue_stop = axe_stop
[CFR 4/n] removes uether dependency of cdce(4)
Hello,
This patch is to remove a uether dependency of cdce(4) and some style(9)
changes. The change logs would be as follows:
o removes uether dependency.
o defines CDCE_DEV to clean up the supported device list.
o uses bzero instead of memset.
o style(9) - get rid of extra spaces and parentheses.
Please reviews.
regards,
Weongyo Jeong
Index: if_cdce.c
===
--- if_cdce.c (revision 214604)
+++ if_cdce.c (working copy)
@@ -61,6 +61,8 @@ __FBSDID($FreeBSD$);
#include sys/lock.h
#include sys/mutex.h
#include sys/condvar.h
+#include sys/socket.h
+#include sys/sockio.h
#include sys/sysctl.h
#include sys/sx.h
#include sys/unistd.h
@@ -68,6 +70,14 @@ __FBSDID($FreeBSD$);
#include sys/malloc.h
#include sys/priv.h
+#include net/if.h
+#include net/if_arp.h
+#include net/if_dl.h
+#include net/if_media.h
+#include net/if_types.h
+#include net/bpf.h
+#include net/ethernet.h
+
#include dev/usb/usb.h
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h
@@ -77,6 +87,7 @@ __FBSDID($FreeBSD$);
#defineUSB_DEBUG_VAR cdce_debug
#include dev/usb/usb_debug.h
#include dev/usb/usb_process.h
+#include dev/usb/usb_sleepout.h
#include usb_if.h
#include dev/usb/net/usb_ethernet.h
@@ -99,14 +110,16 @@ static usb_callback_t cdce_ncm_bulk_write_callback
static usb_callback_t cdce_ncm_bulk_read_callback;
#endif
-static uether_fn_t cdce_attach_post;
-static uether_fn_t cdce_init;
-static uether_fn_t cdce_stop;
-static uether_fn_t cdce_start;
-static uether_fn_t cdce_setmulti;
-static uether_fn_t cdce_setpromisc;
-
static uint32_tcdce_m_crc32(struct mbuf *, uint32_t, uint32_t);
+static int cdce_ioctl(struct ifnet *, u_long, caddr_t);
+static voidcdce_start(struct ifnet *);
+static voidcdce_start_locked(struct ifnet *);
+static voidcdce_init(void *);
+static voidcdce_init_locked(struct cdce_softc *);
+static voidcdce_stop_locked(struct cdce_softc *);
+static int cdce_rxmbuf(struct cdce_softc *, struct mbuf *, unsigned int);
+static struct mbuf *cdce_newbuf(void);
+static voidcdce_rxflush(struct cdce_softc *);
#ifdef USB_DEBUG
static int cdce_debug = 0;
@@ -120,7 +133,6 @@ SYSCTL_INT(_hw_usb_cdce, OID_AUTO, interval, CTLFL
#endif
static const struct usb_config cdce_config[CDCE_N_TRANSFER] = {
-
[CDCE_BULK_RX] = {
.type = UE_BULK,
.endpoint = UE_ADDR_ANY,
@@ -174,7 +186,6 @@ static const struct usb_config cdce_config[CDCE_N_
#if CDCE_HAVE_NCM
static const struct usb_config cdce_ncm_config[CDCE_N_TRANSFER] = {
-
[CDCE_BULK_RX] = {
.type = UE_BULK,
.endpoint = UE_ADDR_ANY,
@@ -255,29 +266,21 @@ MODULE_DEPEND(cdce, uether, 1, 1, 1);
MODULE_DEPEND(cdce, usb, 1, 1, 1);
MODULE_DEPEND(cdce, ether, 1, 1, 1);
-static const struct usb_ether_methods cdce_ue_methods = {
- .ue_attach_post = cdce_attach_post,
- .ue_start = cdce_start,
- .ue_init = cdce_init,
- .ue_stop = cdce_stop,
- .ue_setmulti = cdce_setmulti,
- .ue_setpromisc = cdce_setpromisc,
-};
-
static const struct usb_device_id cdce_devs[] = {
- {USB_VPI(USB_VENDOR_ACERLABS, USB_PRODUCT_ACERLABS_M5632,
CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_AMBIT, USB_PRODUCT_AMBIT_NTL_250,
CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_COMPAQ, USB_PRODUCT_COMPAQ_IPAQLINUX,
CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_GMATE, USB_PRODUCT_GMATE_YP3X00,
CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN,
CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_MOTOROLA2, USB_PRODUCT_MOTOROLA2_USBLAN2,
CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_NETCHIP, USB_PRODUCT_NETCHIP_ETHERNETGADGET,
CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2501,
CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5500, CDCE_FLAG_ZAURUS)},
- {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SL5600, CDCE_FLAG_ZAURUS |
CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLA300, CDCE_FLAG_ZAURUS |
CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC700, CDCE_FLAG_ZAURUS |
CDCE_FLAG_NO_UNION)},
- {USB_VPI(USB_VENDOR_SHARP, USB_PRODUCT_SHARP_SLC750, CDCE_FLAG_ZAURUS |
CDCE_FLAG_NO_UNION)},
+#defineCDCE_DEV(v,p,i) { USB_VPI(USB_VENDOR_##v,
USB_PRODUCT_##v##_##p, i) }
+ CDCE_DEV(ACERLABS, M5632, CDCE_FLAG_NO_UNION),
+ CDCE_DEV(AMBIT, NTL_250, CDCE_FLAG_NO_UNION),
+ CDCE_DEV(COMPAQ, IPAQLINUX, CDCE_FLAG_NO_UNION),
+ CDCE_DEV(GMATE, YP3X00, CDCE_FLAG_NO_UNION),
+ CDCE_DEV(MOTOROLA2, USBLAN, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION),
+ CDCE_DEV(MOTOROLA2, USBLAN2, CDCE_FLAG_ZAURUS | CDCE_FLAG_NO_UNION),
+ CDCE_DEV(NETCHIP, ETHERNETGADGET, CDCE_FLAG_NO_UNION),
+ CDCE_DEV(PROLIFIC, PL2501
Re: [CFR] add usb_sleepout.[ch]
On Sun, Oct 31, 2010 at 03:09:49PM +0100, Hans Petter Selasky wrote:
On Sunday 31 October 2010 01:19:01 Weongyo Jeong wrote:
Hello USB guys,
The following patch is to add a implementation, called `sleepout'.
Please reviews. I'd like to commit it into HEAD if no objections.
Adds `sleepout' prototype which is a comic combination of callout(9) and
taskqueue(8) only for USB drivers to implement one step timer. In
current USB drivers using callout(9) interface they all have two step
execution flow as follows:
1. callout callback is fired by the interrupt context. Then it needs
to pass it to USB process context because it could sleep(!) while
callout(9) don't allow it.
2. In the USB process context it operates USB commands that most of
times it'd be blocked at least 125 us (it'd be always true for USB)
In a view of driver developer it'd be more convenient if USB stack has a
feature like this (timer supporting blocking).
Hi,
I think this is a good idea too.
However, there are some atomic issues I think you need to fix first.
1) All the sleepout_xxx() functions need mutex asserts.
It looks it don't need it because callout(9) does it instead of sleepout
routines. Moreover sleepout don't create any mutexes in itself.
2) Is it allowed to call callout_stop() / callout_reset() unlocked at all?
Yes as long as it doesn't have side effects. It seems no drivers hold a
lock to call callout_stop() / callout_reset().
What are the concequences if the mutex associated with the sleepout is NULL ?
I added KASSERT macro to check this case at below. However the sleepout
pointer normally never be NULL because the intention of usage was as
follows:
struct driver_softc {
struct sleepout sleepout;
struct sleepout_task sleepout_task;
};
sleepout_create(sc-sleepout, blah);
Only it could be happen if `struct sleepout' is allocated by
dynamically though it's not my first purpose.
3) As per the current implementation it can happen that the task'ed timeout
is
called after that sleepout_stop() is used. The code should have a check in
the
task function to see if the sleepout() has been cancelled or not, when the
mutex associated with the sleepout is locked.
Yes it's true but it'd better to implement first taskqueue_stop() than
adding it sleepout routines directly. However no plans yet because I
couldn't imagine a side effect due to lack of this feature. Please let
me know if I missed the something important.
4) Should the functions be prefixed by usb_ ?
I don't have a preference for this. I think it's no problem to change
it. It could happen soon.
5) In drain you should drain the callout first, then drain the tasqueue. Else
the timer can trigger after the taskqueue is drained.
It's fixed. Thank you for your review and the updated version is
embedded at this email.
regards,
Weongyo Jeong
Index: usb_sleepout.c
===
--- usb_sleepout.c (revision 0)
+++ usb_sleepout.c (revision 0)
@@ -0,0 +1,149 @@
+/*-
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include sys/cdefs.h
+__FBSDID($FreeBSD$);
+#include sys/param.h
+#include sys/systm.h
+#include sys/kernel.h
+#include sys/lock.h
+#include sys/malloc.h
+#include sys/mutex.h
+
+#include dev/usb/usb_sleepout.h
+
+void
+sleepout_create(struct sleepout *s, const char *name)
+{
+
+ KASSERT(s != NULL, (sleepout ptr is NULL));
+
+ s-s_taskqueue = taskqueue_create(name, M_WAITOK,
+ taskqueue_thread_enqueue, s-s_taskqueue);
+ /* XXX adjusts the priority. */
+ taskqueue_start_threads(s-s_taskqueue, 1, PI_NET, %s sleepout,
+ name);
+}
+
+void
+sleepout_free(struct sleepout *s)
+{
+
+ KASSERT(s != NULL, (sleepout ptr is NULL));
+
+ taskqueue_free(s-s_taskqueue);
+}
+
+static void
+_sleepout_taskqueue_callback(void *arg, int pending)
+{
+ struct sleepout_task *st = arg;
+
+ (void)pending;
+
+ if (st-st_mtx != NULL)
+ mtx_lock(st-st_mtx);
+
+ st-st_func(st-st_arg);
+
+ if (st-st_mtx != NULL)
+ mtx_unlock(st-st_mtx);
+}
+
+void
+sleepout_init(struct sleepout *s, struct sleepout_task
[CFR] add usb_sleepout.[ch]
Hello USB guys,
The following patch is to add a implementation, called `sleepout'.
Please reviews. I'd like to commit it into HEAD if no objections.
Adds `sleepout' prototype which is a comic combination of callout(9) and
taskqueue(8) only for USB drivers to implement one step timer. In
current USB drivers using callout(9) interface they all have two step
execution flow as follows:
1. callout callback is fired by the interrupt context. Then it needs
to pass it to USB process context because it could sleep(!) while
callout(9) don't allow it.
2. In the USB process context it operates USB commands that most of
times it'd be blocked at least 125 us (it'd be always true for USB)
In a view of driver developer it'd be more convenient if USB stack has a
feature like this (timer supporting blocking).
regards,
Weongyo Jeong
Index: usb_sleepout.c
===
--- usb_sleepout.c (revision 0)
+++ usb_sleepout.c (revision 0)
@@ -0,0 +1,122 @@
+/*-
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include sys/cdefs.h
+__FBSDID($FreeBSD$);
+#include sys/param.h
+#include sys/systm.h
+#include sys/kernel.h
+#include sys/lock.h
+#include sys/malloc.h
+#include sys/mutex.h
+
+#include dev/usb/usb_sleepout.h
+
+void
+sleepout_create(struct sleepout *s, const char *name)
+{
+
+ s-s_taskqueue = taskqueue_create(name, M_WAITOK,
+ taskqueue_thread_enqueue, s-s_taskqueue);
+ /* XXX adjusts the priority. */
+ taskqueue_start_threads(s-s_taskqueue, 1, PI_NET, %s sleepout,
+ name);
+}
+
+void
+sleepout_free(struct sleepout *s)
+{
+
+ taskqueue_free(s-s_taskqueue);
+}
+
+static void
+_sleepout_taskqueue_callback(void *arg, int pending)
+{
+ struct sleepout_task *st = arg;
+
+ (void)pending;
+
+ if (st-st_mtx != NULL)
+ mtx_lock(st-st_mtx);
+
+ st-st_func(st-st_arg);
+
+ if (st-st_mtx != NULL)
+ mtx_unlock(st-st_mtx);
+}
+
+void
+sleepout_init(struct sleepout *s, struct sleepout_task *st, int mpsafe)
+{
+
+ st-st_sleepout = s;
+ callout_init(st-st_callout, mpsafe);
+ TASK_INIT(st-st_task, 0, _sleepout_taskqueue_callback, st);
+ st-st_mtx = NULL;
+}
+
+void
+sleepout_init_mtx(struct sleepout *s, struct sleepout_task *st, struct mtx
*mtx,
+int flags)
+{
+
+ st-st_sleepout = s;
+ callout_init_mtx(st-st_callout, mtx, flags);
+ TASK_INIT(st-st_task, 0, _sleepout_taskqueue_callback, st);
+ st-st_mtx = mtx;
+}
+
+static void
+_sleepout_callout_callback(void *arg)
+{
+ struct sleepout_task *st = arg;
+ struct sleepout *s = st-st_sleepout;
+
+ taskqueue_enqueue(s-s_taskqueue, st-st_task);
+}
+
+int
+sleepout_reset(struct sleepout_task *st, int to_ticks, sleepout_func_t ftn,
+void *arg)
+{
+
+ st-st_func = ftn;
+ st-st_arg = arg;
+ return (callout_reset(st-st_callout, to_ticks,
+ _sleepout_callout_callback, st));
+}
+
+int
+sleepout_pending(struct sleepout_task *st)
+{
+
+ return (callout_pending(st-st_callout));
+}
+
+int
+sleepout_stop(struct sleepout_task *st)
+{
+
+ return (callout_stop(st-st_callout));
+}
+
+int
+sleepout_drain(struct sleepout_task *st)
+{
+ struct sleepout *s = st-st_sleepout;
+
+ taskqueue_drain(s-s_taskqueue, st-st_task);
+ return (callout_drain(st-st_callout));
+}
Property changes on: usb_sleepout.c
___
Added: svn:mime-type
+ text/plain
Added: svn:keywords
+ Id
Added: svn:eol-style
+ native
Index: usb_sleepout.h
===
--- usb_sleepout.h (revision 0)
+++ usb_sleepout.h (revision 0)
@@ -0,0 +1,53 @@
+/*-
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY
Re: USB_ERR_TIMEOUT and USB_ERR_STALLED
On Mon, Oct 25, 2010 at 10:16:00AM +0400, Boris Samorodov wrote: On Sat, 23 Oct 2010 16:49:59 -0700 Weongyo Jeong wrote: On Thu, Oct 21, 2010 at 10:56:12PM +0200, Hans Petter Selasky wrote: Weongyo is working on a usbdump utility to monitor ongoing USB traffic. It's merged into HEAD not too lately. :-) It'll be Fixes a typo. Sorry for confusing. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB_ERR_TIMEOUT and USB_ERR_STALLED
On Thu, Oct 21, 2010 at 10:56:12PM +0200, Hans Petter Selasky wrote: On Thursday 21 October 2010 17:02:30 Mike Tancsa wrote: I am trying to use RELENG_8 to monitor a number of APC upses and it seems when there are more than one, I start to see a lot of USB errors with the devices coming and going In the logs, I see a lot of # grep USB /var/log/all.log | tail Oct 21 10:24:05 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub4 Oct 21 10:25:47 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub4 Oct 21 10:27:45 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub4 Oct 21 10:29:44 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub4 Oct 21 10:30:35 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub5 Oct 21 10:32:35 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub4 Oct 21 10:37:04 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub4 Oct 21 10:38:38 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub4 Oct 21 10:44:14 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub5 Oct 21 10:45:09 upsmon1 root: Unknown USB device: vendor 0x051d product 0x0002 bus uhub5 # usbconfig ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: UHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: EHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.2: product 0xf103 vendor 0x2001 at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.2: Back-UPS RS 1500 FW:8.g8 .D USB FW:g8 American Power Conversion at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen3.3: Back-UPS RS 1500 FW:8.g8 .D USB FW:g8 American Power Conversion at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen3.4: Back-UPS RS 1500 FW:8.g9a.D USB FW:g9a American Power Conversion at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen3.5: Back-UPS RS 1500 FW:8.g8 .D USB FW:g8 American Power Conversion at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen3.6: Back-UPS RS 1500 FW:8.g9a.D USB FW:g9a American Power Conversion at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen3.7: Back-UPS RS 1500 FW:8.g4 .D USB FW:g4 American Power Conversion at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen3.8: USB2.0 Hub vendor 0x05e3 at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen3.9: Back-UPS RS 1500 FW:8.g8 .D USB FW:g8 American Power Conversion at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen3.10: Back-UPS RS 1500 FW:8.g7 .D USB FW:g7 American Power Conversion at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen3.11: Back-UPS RS 1500 FW:8.g8 .D USB FW:g8 American Power Conversion at usbus3, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON This is with a kernel from Oct 4th, i386. Any idea what might be up or how to debug this ?? Setting hw.usb.debug to anything 0 causes the system to almost hang under the load unfortunately. ---Mike Weongyo is working on a usbdump utility to monitor ongoing USB traffic. It's merged into HEAD not too lately. :-) regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: q: Memory modified after free in usb2
On Wed, Mar 25, 2009 at 10:46:54AM +0100, Hans Petter Selasky wrote: On Wednesday 25 March 2009, Weongyo Jeong wrote: Hello Hans :), I think porting uath(4) to usb almost have done that it works well to associate with AP and for WPA but I'm suffered from a strange panic after detach as follows: Memory modified after free 0xc4da3600(508) val=2400 @ 0xc4da3600 panic: Most recently used by USBdev cpuid = 0 KDB: enter: panic [thread pid 17 tid 100036 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why The detach step is like as follows: usb2_transfer_unsetup(sc-sc_xfer, UATH_N_XFERS); ... uath_free_rx_data_list(sc); uath_free_tx_data_list(sc); uath_free_cmd_list(sc, sc-sc_cmd, UATH_CMD_LIST_COUNT); that I've checked all memory leaks or calls after freeing memory but it looks it's not a driver problem. To solve this problem I modified codes slightly like below: usb2_transfer_unsetup(sc-sc_xfer, UATH_N_XFERS); usb2_pause_mtx(NULL, 5 * hz); ... uath_free_rx_data_list(sc); uath_free_tx_data_list(sc); uath_free_cmd_list(sc, sc-sc_cmd, UATH_CMD_LIST_COUNT); After adding it I couldn't see `Memory modified after free' messages anymore. My question is that I can't understand why adding usb2_pause_mtx() helps this symptom? Did you drain all the taskqueues before unsetup ? It looks I found a problem that some tasks running by net80211 causes this problem. It looks calling usb2_transfer_unsetup() after ieee80211_ifdetach(ic) solves the problem. Thanks! regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: q: Memory modified after free in usb2
On Thu, Mar 26, 2009 at 09:02:02AM +0100, Hans Petter Selasky wrote:
On Thursday 26 March 2009, Weongyo Jeong wrote:
On Wed, Mar 25, 2009 at 10:46:54AM +0100, Hans Petter Selasky wrote:
To solve this problem I modified codes slightly like below:
usb2_transfer_unsetup(sc-sc_xfer, UATH_N_XFERS);
usb2_pause_mtx(NULL, 5 * hz);
...
uath_free_rx_data_list(sc);
uath_free_tx_data_list(sc);
uath_free_cmd_list(sc, sc-sc_cmd, UATH_CMD_LIST_COUNT);
After adding it I couldn't see `Memory modified after free' messages
anymore. My question is that I can't understand why adding
usb2_pause_mtx() helps this symptom?
Did you drain all the taskqueues before unsetup ?
Yes. All I used was two callouts that the driver currently doesn't use
usb2_proc_create() and tried to drain its before calling
usb2_transfer_unsetup() but it still encounters `Memory modified after
free'.
Hi,
Is this the link to the complete code?
http://perforce.freebsd.org/fileViewer.cgi?FSPC=//depot/user/weongyo/wireless/src/sys/dev/usb/wlan/if_uath.cREV=24
Yes.
1) The manpage states: This function MUST NOT be called while holding any
locks ...
|UATH_LOCK(sc);
|callout_drain(sc-stat_ch);
|callout_drain(sc-watchdog_ch);
505: 159831 21 |UATH_UNLOCK(sc);
callout_stop() is not callout_drain() !
Same sematics with USB2. transfer_stop()/transfer_drain()
It looks it's my mistake to lock before going into callout_drain(9).
2) Instead of copying the data twice, use the .ext_buffer=1 flag to instruct
USB to not allocate its own buffer in struct usb2_config, see umass.c for
example, and the and
usb2_set_frame_data(xfer,
urb-transfer_buffer, 0);
Before you start the hardware!
Actually you can save alot of copying if you can exploit the multi-frame
feature of the USB-stack for BULK transfers! Then you have to set frames
1 in usb2_config structure. For example you would then copy in the header to
wMaxPacketSize bytes, and use the data pointer for the rest, given that the
IP-packet is not that defragged.
This is what I want! I'll apply it immediately. Thanks! :-)
3) There is a chicken egg problem at detach.
I suspect that uath_bulk_tx_callback() is called with the USB_ERR_CANCELLED
error. And here you seem to access freed memory. I think you need to re-think
how you get that last node freed. Maybe it should be done by the if_stop()
and not at cancelled, because according to detach, you will do if_stop()
first and then cancel USB and unless you drain, you are not certain that the
callback is complete!
|default:
|data = STAILQ_FIRST(sc-sc_datatx_active);
|if (data == NULL)
|goto setup;
2605: 159735 3 |if (data-ni != NULL) {
|ieee80211_free_node(data-ni);
|data-ni = NULL;
|ifp-if_oerrors++;
|}
2610: 159733 1 |if (xfer-error != USB_ERR_CANCELLED) {
|xfer-flags.stall_pipe = 1;
|goto setup;
|}
I recommend that you do the usb2_transfer_unsetup() first at detach like in
if_rum.c and the other WLAN drivers. That will solve your problem, and maybe
you have to fix the datatx_active queue, so that the last data is not stuck
there for ever ???
Thank you for advice again. I'll try to do some more tests. It looks
ordering is important when detaching and with looking other WLAN drivers
it seems calling ieee80211_ifdetach(ic) should be moved before
usb2_transfer_unsetup(9) including if_zyd.c, if_ural.c and if_ral.c
regards,
Weongyo Jeong
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
q: a trivial question of usb2_transfer_unsetup()
Hello Hans, I have a simple question that is there a possibility for .mh.callback of usb2_config to be called after usb2_transfer_unsetup()? regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
q: Memory modified after free in usb2
Hello Hans :), I think porting uath(4) to usb almost have done that it works well to associate with AP and for WPA but I'm suffered from a strange panic after detach as follows: Memory modified after free 0xc4da3600(508) val=2400 @ 0xc4da3600 panic: Most recently used by USBdev cpuid = 0 KDB: enter: panic [thread pid 17 tid 100036 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why The detach step is like as follows: usb2_transfer_unsetup(sc-sc_xfer, UATH_N_XFERS); ... uath_free_rx_data_list(sc); uath_free_tx_data_list(sc); uath_free_cmd_list(sc, sc-sc_cmd, UATH_CMD_LIST_COUNT); that I've checked all memory leaks or calls after freeing memory but it looks it's not a driver problem. To solve this problem I modified codes slightly like below: usb2_transfer_unsetup(sc-sc_xfer, UATH_N_XFERS); usb2_pause_mtx(NULL, 5 * hz); ... uath_free_rx_data_list(sc); uath_free_tx_data_list(sc); uath_free_cmd_list(sc, sc-sc_cmd, UATH_CMD_LIST_COUNT); After adding it I couldn't see `Memory modified after free' messages anymore. My question is that I can't understand why adding usb2_pause_mtx() helps this symptom? regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: q: Memory modified after free in usb2
On Wed, Mar 25, 2009 at 10:46:54AM +0100, Hans Petter Selasky wrote: On Wednesday 25 March 2009, Weongyo Jeong wrote: Hello Hans :), I think porting uath(4) to usb almost have done that it works well to associate with AP and for WPA but I'm suffered from a strange panic after detach as follows: Memory modified after free 0xc4da3600(508) val=2400 @ 0xc4da3600 panic: Most recently used by USBdev cpuid = 0 KDB: enter: panic [thread pid 17 tid 100036 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why The detach step is like as follows: usb2_transfer_unsetup(sc-sc_xfer, UATH_N_XFERS); ... uath_free_rx_data_list(sc); uath_free_tx_data_list(sc); uath_free_cmd_list(sc, sc-sc_cmd, UATH_CMD_LIST_COUNT); that I've checked all memory leaks or calls after freeing memory but it looks it's not a driver problem. To solve this problem I modified codes slightly like below: usb2_transfer_unsetup(sc-sc_xfer, UATH_N_XFERS); usb2_pause_mtx(NULL, 5 * hz); ... uath_free_rx_data_list(sc); uath_free_tx_data_list(sc); uath_free_cmd_list(sc, sc-sc_cmd, UATH_CMD_LIST_COUNT); After adding it I couldn't see `Memory modified after free' messages anymore. My question is that I can't understand why adding usb2_pause_mtx() helps this symptom? Did you drain all the taskqueues before unsetup ? Yes. All I used was two callouts that the driver currently doesn't use usb2_proc_create() and tried to drain its before calling usb2_transfer_unsetup() but it still encounters `Memory modified after free'. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: q: USB_SET_TIMEOUT in ugen.
On Thu, Mar 19, 2009 at 09:01:23AM +0100, Hans Petter Selasky wrote: On Thursday 19 March 2009, Weongyo Jeong wrote: ugen_default_read_callback:384: actlen=0, aframes=0 ugen_default_read_callback:384: actlen=0, aframes=0 ugen_read_clear_stall_callback:477: f=0xc4d5b000: stall cleared One difference from the old ugen implementation is that a stall error does not cause any error to be returned to userland! You could try to return a ZLP on errors. Try this patch: http://perforce.freebsd.org/chv.cgi?CH=159423 If you need to distinguish a ZLP from a STALL, then you have to use the new libusb! Ugen is not meant to be a replacement for libusb! Thanks you for a patch but it's not a answer what I want because my symptom is that recv(2) waits forever before or returns 0 after applying your patch. It shouldn't return 0 or nothing that the size of the recv(2) return value should be 512. I tried to dump USB transactions using USB analyzer and the dump file is available at: http://people.freebsd.org/~weongyo/uathload_20090319_export.txt Interesting packets could be found after 241 transactions and the steps of program are as follows: write(endpoint 0x1, buf, 512); write(endpoint 0x2, buf, 512); write(endpoint 0x2, buf, 512); write(endpoint 0x2, buf, 512); write(endpoint 0x2, buf, 512); read(endpoint 0x81, buf, 512); -- here error. As you can see with looking the dump file, ugen couldn't catch the read event even though the USB stick responses data at Transaction 264, 265 and 266. It looks the problem is in ugen(4). As looking usb_generic.c it looks the read/write pipe are opened on the fly when read(2) or write(2) systemcalls are called though in the previous ugen(4) in usb1 all pipes are opened at open(2). Could this difference affect this symptom? I'd try to test another cases. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: q: USB_SET_TIMEOUT in ugen.
On Thu, Mar 19, 2009 at 02:32:23PM +0100, Hans Petter Selasky wrote:
Hi,
On Thursday 19 March 2009, Weongyo Jeong wrote:
On Thu, Mar 19, 2009 at 09:01:23AM +0100, Hans Petter Selasky wrote:
On Thursday 19 March 2009, Weongyo Jeong wrote:
ugen_default_read_callback:384: actlen=0, aframes=0
ugen_default_read_callback:384: actlen=0, aframes=0
ugen_read_clear_stall_callback:477: f=0xc4d5b000: stall cleared
One difference from the old ugen implementation is that a stall error
does not cause any error to be returned to userland!
You could try to return a ZLP on errors. Try this patch:
http://perforce.freebsd.org/chv.cgi?CH=159423
If you need to distinguish a ZLP from a STALL, then you have to use the
new libusb! Ugen is not meant to be a replacement for libusb!
Thanks you for a patch but it's not a answer what I want because my
symptom is that recv(2) waits forever before or returns 0 after applying
your patch. It shouldn't return 0 or nothing that the size of the recv(2)
return value should be 512.
The ugen interface is now double buffered, so it will read data in the
background! The old was not double buffered. There are currently only two
buffers. If you see the packet in the analyzer it has most likely also ended
up in a UGEN buffer.
I tried to dump USB transactions using USB
analyzer and the dump file is available at:
http://people.freebsd.org/~weongyo/uathload_20090319_export.txt
What happens if you change:
|if (read(msg, rxmsg, sizeof(rxmsg)) !=
sizeof(rxmsg)) {
215: |VERBOSE(%s, \n);
|err(-1, error reading msg (%s),
msgdev);
|break;
|}
Into while loop for sake of testing? So that if the length is 0 you loop one
more time and if you have more than X zero lengths returned, you break?
I tried to do your suggestion but no changes. read(2) returned always 0
(after applying http://perforce.freebsd.org/chv.cgi?CH=159423) that it
looks ugen missed a transaction the device sent to the host.
Interesting packets could be found after 241 transactions and the steps
of program are as follows:
write(endpoint 0x1, buf, 512);
write(endpoint 0x2, buf, 512);
write(endpoint 0x2, buf, 512);
write(endpoint 0x2, buf, 512);
write(endpoint 0x2, buf, 512);
read(endpoint 0x81, buf, 512); -- here error.
As you can see with looking the dump file, ugen couldn't catch the read
event even though the USB stick responses data at Transaction 264, 265
and 266. It looks the problem is in ugen(4). As looking usb_generic.c
it looks the read/write pipe are opened on the fly when read(2) or
write(2) systemcalls are called though in the previous ugen(4) in usb1
all pipes are opened at open(2). Could this difference affect this
symptom? I'd try to test another cases.
The old ugen would also do a clear-stall which the new one does not do,
unless
you do an IOCTL before the first read! That is also something you can try.
Also I tried this with commenting out all of ioctl(2) calls. But after
it it looks recv(2) never returns.
regards,
Weongyo Jeong
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
q: USB_SET_TIMEOUT in ugen.
Hello, During porting uath(4) to usb2 I found the following code failed to run: data = open(/dev/usb/0.2.2, O_WRONLY, 0); timeout = UATH_DATA_TIMEOUT; if (ioctl(data, USB_SET_TIMEOUT, timeout) 0) err(-1, %s: USB_SET_TIMEOUT(%u), datadev, UATH_DATA_TIMEOUT); and the error was: uathload: /dev/usb/0.2.2: USB_SET_TIMEOUT(1000): Invalid argument It looks it's ok with calling ioctl(msg, USB_SET_TIMEOUT, ..) to /dev/usb/0.2.1 And the behaviour of program isn't likely with usb1 that it worked well in usb1. After writing some data into msg and data pipe there was no any response using read(2). The problem source can be found at:. http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/weongyo/wireless/src/usr.sbin/uathloadHIDEDEL=NO Are there something I missed in here? regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: q: USB_SET_TIMEOUT in ugen.
On Wed, Mar 18, 2009 at 08:52:47AM +0100, Hans Petter Selasky wrote:
Hi,
On Wednesday 18 March 2009, Weongyo Jeong wrote:
Hello,
During porting uath(4) to usb2 I found the following code failed to run:
data = open(/dev/usb/0.2.2, O_WRONLY, 0);
timeout = UATH_DATA_TIMEOUT;
if (ioctl(data, USB_SET_TIMEOUT, timeout) 0)
err(-1, %s: USB_SET_TIMEOUT(%u), datadev,
UATH_DATA_TIMEOUT);
and the error was:
uathload: /dev/usb/0.2.2: USB_SET_TIMEOUT(1000): Invalid
argument
Use the following macro instead:
#define USB_SET_TX_TIMEOUT _IOW ('U', 137, int)
There also is a match for USB_SET_RX_TIMEOUT .
USB_SET_TIMEOUT has been removed.
Also don't forget to include usb_ioctl.h .
Another idea:
Port the program to libusb
It looks it's ok with calling ioctl(msg, USB_SET_TIMEOUT, ..) to
/dev/usb/0.2.1
And the behaviour of program isn't likely with usb1 that it worked well
in usb1. After writing some data into msg and data pipe there was no
any response using read(2). The problem source can be found at:.
http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/weongyo
/wireless/src/usr.sbin/uathloadHIDEDEL=NO
Are there something I missed in here?
See hints above.
Thank you for advise. :-) I've solve `Invalid argument' error. However
the program looks it still doesn't work. All functions the problem used
are open(2), ioctl(2), read(2) and write(2). I think I can try to use
libusb but it'd be better if it works again using the above 4 system
calls.
Is it supported in CURRENT or is it a one of regression?
regards,
Weongyo Jeong
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: q: USB_SET_TIMEOUT in ugen.
On Wed, Mar 18, 2009 at 02:54:17PM +0100, Hans Petter Selasky wrote:
On Wednesday 18 March 2009, Weongyo Jeong wrote:
On Wed, Mar 18, 2009 at 08:52:47AM +0100, Hans Petter Selasky wrote:
Hi,
On Wednesday 18 March 2009, Weongyo Jeong wrote:
Hello,
During porting uath(4) to usb2 I found the following code failed to
run:
data = open(/dev/usb/0.2.2, O_WRONLY, 0);
timeout = UATH_DATA_TIMEOUT;
if (ioctl(data, USB_SET_TIMEOUT, timeout) 0)
err(-1, %s: USB_SET_TIMEOUT(%u), datadev,
UATH_DATA_TIMEOUT);
and the error was:
uathload: /dev/usb/0.2.2: USB_SET_TIMEOUT(1000): Invalid
argument
Use the following macro instead:
#define USB_SET_TX_TIMEOUT _IOW ('U', 137, int)
There also is a match for USB_SET_RX_TIMEOUT .
USB_SET_TIMEOUT has been removed.
Also don't forget to include usb_ioctl.h .
Another idea:
Port the program to libusb
It looks it's ok with calling ioctl(msg, USB_SET_TIMEOUT, ..) to
/dev/usb/0.2.1
And the behaviour of program isn't likely with usb1 that it worked well
in usb1. After writing some data into msg and data pipe there was no
any response using read(2). The problem source can be found at:.
http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/weo
ngyo /wireless/src/usr.sbin/uathloadHIDEDEL=NO
Are there something I missed in here?
See hints above.
Thank you for advise. :-) I've solve `Invalid argument' error. However
the program looks it still doesn't work. All functions the problem used
are open(2), ioctl(2), read(2) and write(2). I think I can try to use
libusb but it'd be better if it works again using the above 4 system
calls.
Is it supported in CURRENT or is it a one of regression?
regards,
Weongyo Jeong
What other IOCTL's are used?
Can you make a debug trace:
sysctl hw.usb2.ugen.debug=15
sysctl hw.usb2.dev.debug=15
?
It's a simple program so only USB_SET_RX_TIMEOUT and USB_SET_TX_TIMEOUT
are set via ioctl(2). And the result is as follows:
[r...@kkk /usr/p4/w/usr.sbin/uathload]# ./uathload -d /dev/ugen0.2 -v
usb2_open:823: fflags=0x0003
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374bc0 need uref=1
usb2_ref_device:243: ref udev - needed
usb2_fifo_create:409: Endpoint device, searching for 0x01
usb2_fifo_create:480: dev_get_pipe(1, 0x0)
usb2_fifo_create:507: dev_get_pipe(1, 0x1)
usb2_fifo_create:536: fifo index = 0
ugen_open:158: flag=0x1
ugen_open:158: flag=0x2
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374bc0 need uref=0
usb2_ref_device:235: ref write
usb2_ref_device:239: ref read
usb2_ioctl:1021: fflags=3, cmd=0x80045572
ugen_ioctl:1388: cmd=0x80045572
ugen_ioctl:1566: error=-3
usb2_uref_location:297: ref udev
ugen_ioctl_post:1963: cmd=0x80045572
ugen_ioctl_post:2164: error=0
usb2_open:823: fflags=0x0002
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374740 need uref=1
usb2_ref_device:243: ref udev - needed
usb2_fifo_create:409: Endpoint device, searching for 0x02
usb2_fifo_create:480: dev_get_pipe(2, 0x0)
usb2_fifo_create:536: fifo index = 2
ugen_open:158: flag=0x2
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374740 need uref=0
usb2_ref_device:235: ref write
usb2_ioctl:1021: fflags=2, cmd=0x80045589
ugen_ioctl:1388: cmd=0x80045589
ugen_ioctl:1566: error=-3
usb2_uref_location:297: ref udev
ugen_ioctl_post:1963: cmd=0x80045589
ugen_ioctl_post:2164: error=0
Load firmware aru5523.bin (builtisn) to /dev/ugen0b.2
send block 20: 147368 bytes _remainingwrite:1291:
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374bc0 need uref=0
usb2_ref_device:235: ref write
usb2_ref_device:239: ref read
usb2_write:1362: transfer 512 bytes to 0xc8382038
ugen_default_write_callback:434: actlen=0, aframes=0
ugen_default_write_callback:434: actlen=0, aframes=0
ugen_default_write_callback:434: actlen=512, aframes=1
u : dsata...b2_write:1291:
usb2_ref_device:165: usb2_ref_device, cpd=0xc8374740 need uref=0
usb2_ref_device:235: ref write
usb2_write:1362: transfer 2048 bytes to 0xc839c038
ugen_default_write_callback:434: actlen=0, aframes=0
ugen_default_write_callback:434: actlen=0, aframes=0
ugen_default_write_callback:434: actlen=2048, aframes=1
u : wsait for ack...b2_ref_device:165: usb2_ref_device,
cpd=0xc8374bc0 need uref=0
usb2_ref_device:235: ref write
usb2_ref_device:239: ref read
usb2_read:1222: sleeping
ugen_default_read_callback:384: actlen=0, aframes=0
ugen_default_read_callback:384: actlen=0, aframes=0
ugen_read_clear_stall_callback:477: f=0xc4d5b000: stall cleared
[...again...]
ugen_default_read_callback:384: actlen=0, aframes=0
ugen_default_read_callback:384: actlen=0, aframes=0
ugen_read_clear_stall_callback:477: f=0xc4d5b000: stall cleared
[...again...]
ugen_default_read_callback:384: actlen=0, aframes=0
ugen_default_read_callback:384: actlen=0
Re: USB support in NDIS -- IFF_NEEDSGIANT?
On Fri, Mar 13, 2009 at 11:37:57AM +, Robert Watson wrote: On Tue, 17 Feb 2009, Weongyo Jeong wrote: As you know, I've been gradually working to eliminate all non-MPSAFE network device driver infrastructure for 8.0, having removed non-MPSAFE network protocol infrastructure in 7.0. In reviewing remaining drivers using IFF_NEEDSGIANT, I spotted this in the NDIS code: ... Having taken a glance, it looks like this was added specifically to support USB devices attached via NDIS. AFAIK all of usb wireless drivers had it so I couldn't avoid it when I had implemented. With the new USB code, are NDIS drivers still supported? I think that it would be supported at 8.0 And in the new world order, is this IFF_NEEDSGIANT still required? Probably we can remove the IFF_NEEDSGIANT flags at the new USB code. Can I simply remove it once the old USB code is on the way out the door? IMHO yes I think. Dear all: A few weeks have passed, so I wanted to check in and see how this project was going -- are we at a point yet where removing IFF_NEEDSGIANT won't cause significant loss of functionality? In the current, NDIS USB porting almost have completed and it doesn't use IFF_NEEDSGIANT anymore. With some tests it looks it works well so I think it wouldn't cause any loss of functionality. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB support in NDIS -- IFF_NEEDSGIANT?
On Mon, Feb 16, 2009 at 11:33:18AM +, Robert Watson wrote: Dear all: As you know, I've been gradually working to eliminate all non-MPSAFE network device driver infrastructure for 8.0, having removed non-MPSAFE network protocol infrastructure in 7.0. In reviewing remaining drivers using IFF_NEEDSGIANT, I spotted this in the NDIS code: 718 if_initname(ifp, device_get_name(dev), device_get_unit(dev)); 719 ifp-if_mtu = ETHERMTU; 720 ifp-if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; 721 if (sc-ndis_iftype == PNPBus) 722 ifp-if_flags |= IFF_NEEDSGIANT; 723 ifp-if_ioctl = ndis_ioctl; 724 ifp-if_start = ndis_start; 725 ifp-if_init = ndis_init; Having taken a glance, it looks like this was added specifically to support USB devices attached via NDIS. AFAIK all of usb wireless drivers had it so I couldn't avoid it when I had implemented. With the new USB code, are NDIS drivers still supported? I think that it would be supported at 8.0 And in the new world order, is this IFF_NEEDSGIANT still required? Probably we can remove the IFF_NEEDSGIANT flags at the new USB code. Can I simply remove it once the old USB code is on the way out the door? IMHO yes I think. (Note that the plan is to remove all device drivers that still require IFF_NEEDSGIANT some time before 8.0, probably starting with disabling them from the build in about 2-3 weeks). regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP: urtw(4) to be committed soon
On Wed, Jan 21, 2009 at 02:38:18PM +0800, Kevin Lo wrote: Weongyo Jeong wrote: Hello, Hi Weongyo, I would like to commit urtw(4) driver for supporting Realtek's 8187L wireless chipset based on USB into HEAD by the end of the week if there are no objections. And the license of files would be as follows that AFAIK it's based on OpenBSD's template license file: /*- * Copyright (c) 2008 Weongyo Jeong weon...@freebsd.org * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ Because I'm not a lawyer it'd definitely fail to answer about your detailed questions. Just one thing I want to is that it's okay if it's enough to use in *BSD, OpenSolaris and etc. Not want to go into troubles. :-) I'm looking for a person to port from USB to NEWUSB and if you want to test you can find the sources at: http://people.freebsd.org/~weongyo/urtw_20090119.tar.gz Works for me, thanks. Though it's quite a bit slower, that's a job for another day :-) $ dmesg | grep urtw0 urtw0: vendor 0x0bda RTL8187_Wireless, class 0/0, rev 1.10/1.00, addr 2 on uhub0 urtw0: WARNING: using obsoleted IFF_NEEDSGIANT flag $ ifconfig plip0: flags=108810POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT metric 0 mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 urtw0: flags=108843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NEEDSGIANT metric 0 mtu 2290 ether 00:40:0c:04:3b:2a media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:40:0c:04:3b:2a inet 192.168.1.116 netmask 0xff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid MSI channel 11 (2462 Mhz 11g) bssid 00:11:09:0c:2f:91 country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS Thank you for testing. :-) The performance issue is a known issue that I think we need to fix a rate control routine for urtw(4). I tried to use wlan_amrr(4) but concluded it's hard to apply it without documents because I couldn't find a flag whether the tx is failed or not. It looks it's not enough with just looking USB_STATUS value of usb callbacks. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP: NDIS USB code has been committed
On Sat, Dec 27, 2008 at 06:36:56PM +0800, Ganbold wrote: Weongyo Jeong wrote: Hello, Just for information. The code for supporting NDIS USB drivers has been committed into HEAD. Please tell me if you encounter problems. Tried to compile kernel, but gives error. Is it related to your commit? ... cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/DEVIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/DEVIL -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/usb2/ndis/../../../dev/usb2/ndis/if_ndis_usb2.c In file included from /usr/src/sys/modules/usb2/ndis/../../../dev/usb2/ndis/if_ndis_usb2.c:60: @/dev/if_ndis/if_ndisvar.h:121: error: expected specifier-qualifier-list before 'usbd_xfer_handle' @/dev/if_ndis/if_ndisvar.h:212: error: expected specifier-qualifier-list before 'usbd_pipe_handle' *** Error code 1 1 error *** Error code 2 ... Yes. It's related with my commit that now if_ndisvar.h has some structures referring to the original USB framework so it breaks on the newusb. Now building NDIS part on the newusb have decoupled from the default build. I hope now the builds are recovered. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: HEADSUP: NDIS USB support to be merged soon
On Tue, Dec 23, 2008 at 05:18:00PM +0100, Hans Petter Selasky wrote: On Tuesday 23 December 2008, Alfred Perlstein wrote: [[ Moved to -usb. ]] Hans, can you look at this for the usb4bsd switchover, it doesn't look that challenging to port. thank you, -Alfred I will have a look at it. Meanwhile, can Weongyo have a look at the following file: /usr/src/sys/dev/usb2/core/usb2_compat_linux.c I suppose we have to do NDIS in a similar way. Sorry I couldn't follow. Could you please elaborate it? IIRC NDIS's approach to support Windows Binary and a approach to support Linux Binary Compatibility are different. I'm not sure we can do it like what the linuxulator is doing. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
HEADSUP: NDIS USB support to be merged soon
Hello, Before several months ago I'd requested CFT about NDIS USB support. Now I'd like to merge the result into HEAD and want to hear opinions and problems from users because many problems have fixed now and I think it's stable to use. If no objections, I would like to merge it by the end of the week or the next week. For those of you wanting to test, please rebuild/reinstall ndiscvt(8) after applying the patch which can be found as follows: http://people.freebsd.org/~weongyo/patch_ndisusb_20081223.diff This work is based on USB1 framework so I'm also looking for a person to port this from USB1 to USB2. regards, Weongyo Jeong ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
