Re: libusb performance on 8.1
On 03/02/2011, at 17:52, Hans Petter Selasky wrote: I am trying to get it working at the moment, however I'm only finding it capable of 4 or 8 Mb/sec (512 or 1024 byte EP), although perhaps I don't understand how to do ISO transfer properly. Hi, You need to set the multiplier to 2 or 3. Then you get 3*1024 bytes at maximum. OK, so I need.. usb_xf[i].xf = libusb_alloc_transfer(3); p = malloc(3 * 1024); libusb_fill_iso_transfer(usb_xf[i].xf, h, 0x82 p, 3 * 1024, 3, usbcb, usb_xf[i], 2000); ? BTW do you have a feel for the latency in bulk vs iso? I currently have 5-10 msec of buffering in the hardware which I plan on increasing but I'm not sure what a reasonable amount would be :) I put a logic analyser on my board and it shows fairly regular requests from the hardware (16kbyte bursts every 2msec or so) however I see glitches occasionally - 5.5ms, 7.5ms. I am not sure if they are attributable to userland scheduling (in which case writing a kernel driver should help) or some subtlety in USB itself. Are you using two isochronous transfers or just one? It is a single in endpoint. The device also has 2 in bulk and 2 out bulk endpoints for other data but they are idle while the iso one is running. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: libusb performance on 8.1
On Thursday 03 February 2011 11:24:23 Daniel O'Connor wrote: On 03/02/2011, at 17:52, Hans Petter Selasky wrote: I am trying to get it working at the moment, however I'm only finding it capable of 4 or 8 Mb/sec (512 or 1024 byte EP), although perhaps I don't understand how to do ISO transfer properly. Hi, You need to set the multiplier to 2 or 3. Then you get 3*1024 bytes at maximum. OK, so I need.. usb_xf[i].xf = libusb_alloc_transfer(3); p = malloc(3 * 1024); libusb_fill_iso_transfer(usb_xf[i].xf, h, 0x82 p, 3 * 1024, 3, usbcb, usb_xf[i], 2000); No. Please read the description of wMaxPacketSize in the USB2.0 spec, and the multiplier bits. High-speed USB executes 8 isoc packets per second! Number of packets should not be less than 56 for High-speed USB due to underflow risc. usb_xf[i].xf = libusb_alloc_transfer(56); p = malloc(3 * 1024 * 56); libusb_fill_iso_transfer(usb_xf[i].xf, 0x82, p, 3 * 56 * 1024, 56, usbcb, usb_xf[i], 2000); libusb_set_iso_packet_lengths(usb_xf[i].xf, 3 * 1024); You need to allocate 2x libusb_alloc_transfer(56) and submit to get double buffering! --HPS ___ 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/153929: The umodem driver doesn't support the MTK 3329 GPS chipset.
On Wed, Feb 2, 2011 at 20:35, Hans Petter Selasky hsela...@c2i.net wrote: Can you verify the attached patch with your device? It works fine with my device. ugen1.3: MTK at usbus1 umodem_probe: umodem_probe: umodem_probe: umodem0: GPS COM(comm_if) on usbus1 umodem_get_caps: no CM desc (faking one) umodem_get_caps: no ACM desc umodem_attach: Missing descriptor. Assuming data interface is next. umodem_find_data_iface: Match at index 0 umodem0: data interface 0, has CM over data, has no break ___ 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/153929: The umodem driver doesn't support the MTK 3329 GPS chipset.
The following reply was made to PR usb/153929; it has been noted by GNATS. From: Mykhaylo Yehorov yeho...@gmail.com To: Hans Petter Selasky hsela...@c2i.net Cc: freebsd-usb@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: usb/153929: The umodem driver doesn't support the MTK 3329 GPS chipset. Date: Thu, 3 Feb 2011 15:56:43 +0200 On Wed, Feb 2, 2011 at 20:35, Hans Petter Selasky hsela...@c2i.net wrote: Can you verify the attached patch with your device? It works fine with my device. ugen1.3: MTK at usbus1 umodem_probe: umodem_probe: umodem_probe: umodem0: GPS COM(comm_if) on usbus1 umodem_get_caps: no CM desc (faking one) umodem_get_caps: no ACM desc umodem_attach: Missing descriptor. Assuming data interface is next. umodem_find_data_iface: Match at index 0 umodem0: data interface 0, has CM over data, has no break ___ 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/153929: commit references a PR
The following reply was made to PR usb/153929; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: usb/153929: commit references a PR
Date: Thu, 3 Feb 2011 18:26:00 + (UTC)
Author: hselasky
Date: Thu Feb 3 18:25:55 2011
New Revision: 218229
URL: http://svn.freebsd.org/changeset/base/218229
Log:
Fix for detection of MTK 3329 GPS USB devices.
Submitted by:Mykhaylo Yehorov
PR: usb/153929
Approved by: thompsa (mentor)
Modified:
head/sys/dev/usb/serial/umodem.c
head/sys/dev/usb/usbdevs
Modified: head/sys/dev/usb/serial/umodem.c
==
--- head/sys/dev/usb/serial/umodem.c Thu Feb 3 18:07:05 2011
(r218228)
+++ head/sys/dev/usb/serial/umodem.c Thu Feb 3 18:25:55 2011
(r218229)
@@ -197,6 +197,8 @@ static void*umodem_get_desc(struct usb_
static usb_error_t umodem_set_comm_feature(struct usb_device *, uint8_t,
uint16_t, uint16_t);
static void umodem_poll(struct ucom_softc *ucom);
+static void umodem_find_data_iface(struct usb_attach_arg *uaa,
+ uint8_t, uint8_t *, uint8_t *);
static const struct usb_config umodem_config[UMODEM_N_TRANSFER] = {
@@ -311,13 +313,30 @@ umodem_attach(device_t dev)
0 - 1, UDESCSUB_CDC_UNION, 0 - 1);
if ((cud == NULL) || (cud-bLength sizeof(*cud))) {
- device_printf(dev, Missing descriptor.
+ DPRINTF(Missing descriptor.
Assuming data interface is next.\n);
- if (sc-sc_ctrl_iface_no == 0xFF)
+ if (sc-sc_ctrl_iface_no == 0xFF) {
goto detach;
- else
- sc-sc_data_iface_no =
- sc-sc_ctrl_iface_no + 1;
+ } else {
+ uint8_t class_match = 0;
+
+ /* set default interface number */
+ sc-sc_data_iface_no = 0xFF;
+
+ /* try to find the data interface backwards */
+ umodem_find_data_iface(uaa,
+ uaa-info.bIfaceIndex - 1,
+ sc-sc_data_iface_no, class_match);
+
+ /* try to find the data interface forwards */
+ umodem_find_data_iface(uaa,
+ uaa-info.bIfaceIndex + 1,
+ sc-sc_data_iface_no, class_match);
+
+ /* check if nothing was found */
+ if (sc-sc_data_iface_no == 0xFF)
+ goto detach;
+ }
} else {
sc-sc_data_iface_no = cud-bSlaveInterface[0];
}
@@ -398,6 +417,36 @@ detach:
}
static void
+umodem_find_data_iface(struct usb_attach_arg *uaa,
+uint8_t iface_index, uint8_t *p_data_no, uint8_t *p_match_class)
+{
+ struct usb_interface_descriptor *id;
+ struct usb_interface *iface;
+
+ iface = usbd_get_iface(uaa-device, iface_index);
+
+ /* check for end of interfaces */
+ if (iface == NULL)
+ return;
+
+ id = usbd_get_interface_descriptor(iface);
+
+ /* check for non-matching interface class */
+ if (id-bInterfaceClass != UICLASS_CDC_DATA ||
+ id-bInterfaceSubClass != UISUBCLASS_DATA) {
+ /* if we got a class match then return */
+ if (*p_match_class)
+ return;
+ } else {
+ *p_match_class = 1;
+ }
+
+ DPRINTFN(11, Match at index %u\n, iface_index);
+
+ *p_data_no = id-bInterfaceNumber;
+}
+
+static void
umodem_start_read(struct ucom_softc *ucom)
{
struct umodem_softc *sc = ucom-sc_parent;
Modified: head/sys/dev/usb/usbdevs
==
--- head/sys/dev/usb/usbdevs Thu Feb 3 18:07:05 2011(r218228)
+++ head/sys/dev/usb/usbdevs Thu Feb 3 18:25:55 2011(r218229)
@@ -536,6 +536,7 @@ vendor SPEEDDRAGON 0x0e55 Speed Dragon M
vendor HAWKING0x0e66 Hawking
vendor FOSSIL 0x0e67 Fossil, Inc
vendor GMATE 0x0e7e G.Mate, Inc
+vendor MEDIATEK 0x0e8d MediaTek, Inc.
vendor OTI0x0ea0 Ours Technology
vendor YISO 0x0eab Yiso Wireless Co.
vendor PILOTECH 0x0eaf Pilotech
@@ -2120,6 +2121,9 @@ product MCT DU_H3SP_USB232 0x0200 D-Link
product MCT USB2320x0210 USB-232 Interface
product MCT SITECOM_USB2320x0230 Sitecom
Re: kern/118093: firewire bus reset hogs CPU, causing data to be lost
New data: USB causes the same problem that firewire does. FreeBSD 8.0 amd64 nfe0: NVIDIA nForce4 CK804 MCP9 Networking Adapter port 0xb400-0xb407 mem 0xfebf9000-0xfebf9fff irq 23 at device 10.0 on pci0 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4101 mem 0xfe4f-0xfe4f irq 19 at device 0.0 on pci5 fwohci1: NEC uPD72871/2 mem 0xfdeff000-0xfdef irq 19 at device 8.0 on pci2 ehci0: NVIDIA nForce4 USB 2.0 controller mem 0xfebfe000-0xfebfe0ff irq 22 at device 2.1 on pci0 Plugging in a USB_to_RS-232 bridge generates: ugen0.2: Prolific Technology Inc. at usbus0 uplcom0: Prolific Technology Inc. USB-Serial Controller D, class 0/0, rev 1.10/ 4.00, addr 2 on usbus0 And networking is locked out for too long, and data is lost. (The node sending data via Ethernet has too small a transmit buffer, but is a closed source closed hardware black box and cannot be fixed. Once data is lost it is lost forever, it cannot be recreated, so this is very bad.) The FreeBSD box receiving data has a very large receive buffer, but if another device driver locks out networking it doesn't help. Changing the printf(9)s to log(9)s fixes the problem, but this is not a good workaround, there are LOTS of printfs in the kernel, I keep hitting new ones. Printf(9) alone isn't the problem, adding printfs to chown(2) does not cause the problem, but printfs from device drivers do. (usb, firewire, ...) My theory is there is a locking conflict. Here is lock profiling data for USB_RS-232 bridge being plugged in printfs locking out networking: debug.lock.prof.enable: 0 debug.lock.prof.reset: 0 debug.lock.prof.stats: max wait_max total wait_total countavg wait_avg cnt_hold cnt_lock name 251240 0 499982 0 303 1650 0 0 0 /usr/src/sys/dev/usb/usb_request.c:322 (sx:0123456789ABCDEF - USB device SX lock) 104255 0 110429 0 2 55214 0 0 0 /usr/src/sys/dev/usb/usb_device.c:2459 (sx:123456789ABCDEF - USB config SX lock) 104217 029670949 0 47087630 0 0 0 /usr/src/sys/kern/uipc_sockbuf.c:148 (sx:so_rcv_sx) - 101962 0 103089 0 27 3818 0 0 0 /usr/src/sys/kern/kern_condvar.c:145 (sleep mutex:Giant) 51071 0 81088 0 3 27029 0 0 0 /usr/src/sys/kern/kern_cons.c:422 (spin mutex:cnputs_mtx) 23049 0 31351 0 2 15675 0 0 0 /usr/src/sys/kern/vfs_syscalls.c:3508 (lockmgr:ufs) 12408 0 978544 0 971 1007 0 0 0 /usr/src/sys/kern/vfs_vnops.c:604 (lockmgr:ufs) 11466 0 744372 0 11567 64 0 0 0 /usr/src/sys/kern/vfs_bio.c:2559 (lockmgr:bufwait) 11141 0 501155 03850130 0 0 0 /usr/src/sys/kern/vfs_bio.c:1835 (lockmgr:bufwait) 6115 0 61720 0 26 2373 0 0 0 /usr/src/sys/dev/usb/usb_request.c:322 (sx:123456789ABCDEF - USB device SX lock) 5551 0 16749 0 19881 0 0 0 /usr/src/sys/kern/vfs_subr.c:1693 (lockmgr:syncer) 3043 03749 0 6624 0 0 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1321 (sleep mutex:struct mount mtx) 2333 09901 0 36275 0 0 0 /usr/src/sys/kern/vfs_mount.c:2231 (sleep mutex:struct mount mtx) 2055 09462 0 100 94 0 0 0 /usr/src/sys/kern/subr_hints.c:117 (sleep mutex:kernel environment) 1649 0 79272 03846 20 0 0 0 /usr/src/sys/kern/vfs_bio.c:2963 (sleep mutex:vm object) 1636 0 36196 0 15515 2 0 0 0 /usr/src/sys/vm/vm_page.c:1052 (sleep mutex:vm page queue free mutex) 1205 0 55601 0 15411 3 0 0 0 /usr/src/sys/kern/vfs_bio.c:2545 (sleep mutex:bufobj interlock) 1076 01076 0 1 1076 0 0 0 /usr/src/sys/kern/vfs_subr.c:1693 (lockmgr:ufs) 1069 0 31117 0 30 1037 0 0 0 /usr/src/sys/kern/kern_mutex.c:147 (sleep mutex:nfe0) 848 03752 01359 2 0 0 0 /usr/src/sys/ufs/ffs/ffs_vfsops.c:1297 (sleep mutex:vnode interlock) 754 0 10016 03846 2 0 0 0 /usr/src/sys/ufs/ffs/ffs_softdep.c:4274 (sleep mutex:Softdep Lock) 739 02463 0 4615 0 0 0 /usr/src/sys/kern/vfs_subr.c:1693 (lockmgr:devfs) 540 03370 01365 2 0 0 0 /usr/src/sys/kern/vfs_subr.c:3179 (sleep
Re: libusb performance on 8.1
On 04/02/2011, at 14:32, Daniel O'Connor wrote: OK, I have that, it seems I need to work on the firmware as it's not sending data properly when I set it to iso. I'll work on that and try and figure it out. Unfortunately there isn't much example code on isochronous data transfer with the FX2 :( However I see the requests return saying they are complete but the amount of data transferred is 0. Setting the short not OK flag doesn't change the behaviour. I'm not sure if this is a bug in libusb, expected behaviour, or a bug in my program. I think this might be the FX2 sending zero length packets because its FIFO is empty. Now to figure out why it isn't triggering :-/ -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: libusb performance on 8.1
On 04/02/2011, at 15:18, Daniel O'Connor wrote: I'm not sure if this is a bug in libusb, expected behaviour, or a bug in my program. I think this might be the FX2 sending zero length packets because its FIFO is empty. Now to figure out why it isn't triggering :-/ Looks like my firmware managed to confuse the device enough that a power cycle was required, it now transfers data. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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
