Re: q: a trivial question of usb2_transfer_unsetup()

[Hans Petter Selasky]

On Friday 27 March 2009, Weongyo Jeong wrote:
 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()?

Hi,

usb2_transfer_unsetup() calls usb2_transfer_drain() which ensures that the 
callback has exited before returning. Even if you drop the private transfer 
lock in the callback and pick it up before returning.

--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

Proposed USB data buffer changes

[Andrew Thompson]

Hi,


I want the USB peripheral driver API to be solid before 8.0 so things dont bite
us down the line. I have discussed this privately with Hans already and want to
put it out for public consumption.


With the new USB code the buffer management has been merged into the
xfer structure and this dictates the layout of the usb drivers and how
locking is performed.

This uses a state machine (my attempt to show below)

 |- |- XFER  -| -|
 |   |   |   |
- callback_fn -
 |   |   |   |
 |   - SETUP (copyin) -|   |
 |   |
 -   COMPLETE (copyout)   -|

It can take an external buffer instead of the copyin/out but it doesnt really
simplify things at all.

The problems I see with this approach are

 1. It is in contrast to other major operating systems, making porting
drivers harder. Windows, Linux and oldUSB all use a URB style of data
handling. 

 2. It greatly complicates locking as the xfer lock can not be dropped
until the xfer is resubmitted. This requirement to hold the lock
creates a big problem for get/put of data to another layer (eg TTY),
to avoid lock order reversals the drivers are generally written to
share the lock with the lower/upper layer (eg TTY).

 3. In the general case data can not be directly queued on the xfer (must be
picked up by the state machine callback). This limits the options for
designing a driver and may require the driver to implement a queue.

I think its vital that we separate out the data buffers from the xfer
(its actually a pipe in usb speak). It should draw from the Linux API which is
simple and I believe works quite well. The data buffer is represented as a usb
URB which is allocated either at attach or on the fly and then queued on the
xfer (pipe) for processing. An arbitrary number of URB buffers can be on the
queue.

As the buffer would only have a single reference it would not need explicit
locking, the callback would not need the xfer lock to be held at all and this
would make it _much_ easier to handoff the data without LOR.

This reduction in locking means that the driver and the xfer do not need to
share a lock either, something that is mandatory now. The xfer can have a
private lock for enqueue/start/stop.

Example functions could be,

 usb_alloc_urb - Creates a URB representing data and housekeeping, the data
 section can be allocated or passed in from say a mbuf.
 This can also perform the DMA foo.

 usb_submit_urb - Queues the URB on the usb pipe.

I dont think this would take much work. The xfer callbacks would be changed to
take a URB and a few changes to queuing. It was mentioned the reason for this
approach was to preallocate and do DMA setup on attach but this can still
easily be done with the above. 

Comments?


cheers,
Andrew
___
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

u3g panic

[Mike Tancsa]

Hi,
I was trying the u3g driver in FreeBSD on RELENG_7. The 
previous version from the webpage seemed to work ok, but the one 
MFC'd causes a panic if I


load the driver
and attach the stick


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xc
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc357d71f
stack pointer   = 0x28:0xc2fccbc0
frame pointer   = 0x28:0xc2fccbf4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 26 (irq19: uhci1)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 2m39s
Physical memory: 498 MB
Dumping 42 MB: 27 11

(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc07198b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc0719b89 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc09e495c in trap_fatal (frame=0xc2fccb80, eva=12) at 
/usr/src/sys/i386/i386/trap.c:939
#4  0xc09e4be0 in trap_pfault (frame=0xc2fccb80, usermode=0, eva=12) 
at /usr/src/sys/i386/i386/trap.c:852

#5  0xc09e558c in trap (frame=0xc2fccb80) at /usr/src/sys/i386/i386/trap.c:530
#6  0xc09c9c6b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7  0xc357d71f in u3gstub_BBB_cb (xfer=0xc3578600, priv=0x0, 
err=USBD_NORMAL_COMPLETION)

at /usr/src/sys/modules/u3g/../../dev/usb/u3g.c:475
#8  0xc06950d5 in usb_transfer_complete (xfer=0xc3578600) at 
/usr/src/sys/dev/usb/usbdi.c:979
#9  0xc06879bb in uhci_transfer_complete (xfer=0xc3578600) at 
/usr/src/sys/dev/usb/uhci.c:2109

#10 0xc0687b07 in uhci_idone (ii=Variable ii is not available.
) at /usr/src/sys/dev/usb/uhci.c:1449
#11 0xc068800d in uhci_softintr (v=0xc319a000) at 
/usr/src/sys/dev/usb/uhci.c:1324
#12 0xc0690c72 in usb_schedsoftintr (bus=0xc319a000) at 
/usr/src/sys/dev/usb/usb.c:844
#13 0xc0688ce3 in uhci_intr1 (sc=0xc319a000) at 
/usr/src/sys/dev/usb/uhci.c:1224
#14 0xc0688fad in uhci_intr (arg=0xc319a000) at 
/usr/src/sys/dev/usb/uhci.c:1139
#15 0xc06f781b in ithread_loop (arg=0xc31a4000) at 
/usr/src/sys/kern/kern_intr.c:1088
#16 0xc06f4369 in fork_exit (callout=0xc06f7660 ithread_loop, 
arg=0xc31a4000, frame=0xc2fccd38)

at /usr/src/sys/kern/kern_fork.c:810
#17 0xc09c9ce0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264
(kgdb)


On CURRENT, it shows and seems to work fine.

Root mount waiting for: usbus1
ugen0.2: Novatel Wireless at usbus0
u3g0: Data Interface on usbus0
u3g0: Found 2 ports.


0[freebsd-current2]# usbconfig
ugen0.1: OHCI root HUB nVidia at usbus0, cfg=0 md=HOST spd=FULL 
(12Mbps) pwr=ON
ugen1.1: EHCI root HUB nVidia at usbus1, cfg=0 md=HOST spd=HIGH 
(480Mbps) pwr=ON
ugen0.2: Novatel Wireless HSUPA Modem Novatel Wireless at usbus0, 
cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen0.3: USB-Serial Controller Prolific Technology Inc. at usbus0, 
cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen0.4: Token 255.255.255.255 2.7.195 Aladdin Knowledge Systems 
Ltd. at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON

0[freebsd-current2]# cu -l /dev/cuaU0.0
Connected
ati
Manufacturer: Novatel Wireless Incorporated
Model: Ovation MC950D Card
Revision: 3.15.02.0-00  [2008-03-04 09:19:50]
IMEI: 356846015465400
+GCAP: +CGSM,+DS,+ES

OK







Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
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