Alexander Arkhipov <arkhipov@tst.spb.su> wrote in message
news:d6hnot$eci$1@inn.qnx.com…
Alexander Arkhipov <> arkhipov@tst.spb.su> > wrote in message
news:d648c1$dg7$> 1@inn.qnx.com> …
Alexander Arkhipov <> arkhipov@tst.spb.su> > wrote in message
news:d628ei$sst$> 1@inn.qnx.com> …
Problem was solwed by rebuilding my device with 32 bytes FIFOs at
bulk
endpoint (not interface descriptors, they are still 64), and by
using a
URB_SHORT_XFER_OK flag for a bulk data transfer at my driver. Now
it’s
stable.
So, I have a one more little question > 
> Can anybody told me why
in
devb-umass QSS used SHORT bulk transfers? Sorry for my curiousness,
but
I
have a deadline >
The USB stack will mark the URB with an error if it receives less
data
than
was requested unless the flags is set.
Hmmm… But at previos configuration of my device I had 64bytes bulk
endpoints, and requests for bulk data trasfers 1024bytes, trasfer rate
was
about 4Kb/sec. But you can see below that i had memory leaks. What was
that?
After recofiguration all works fine. At other OS, such as Win & Linux
was no
problems with both configurations.
can you run “io-usb -dohci” instead of “devu-ohci”
Allready tryed, the same effect.
The umass driver sets this by default. It knows how many bytes its
expecting
and can deal with less data
if the device decides to send less data.(see SCSI spec ) some
commands
can
have variable length data.
You saying about URB_SHORT_XFER_OK flag? I got it. But with it was
problems too. I have a one more driver for USB-Serial converter. So it
was
developed in QNX6.2.1. Device set the packetend flag every 1 millisecond
independet from baudrate. In 6.2 I didn’t used URB_SHORT_XFER_OK for
data
transfers and usbd_urb_status returned a “real” actual data length, but
when
I tryed to run it on 6.3 it always returned 0 data length, unless I had
added this flag. Is it right?
You should add this flag if you expect to receive less data then
requested.
If the device sends a short packet then
this will terminate the transfer on that endpoint. I dont think this
flag
was supported for 6.2.
Yes, it seams that it was not supported, but usbd_urb_status returned
right actual length of data transfer.
text:0804B2B8 push 0Dh ; 13 byte -
packet
size !!! ???
text:0804B2BA push dword ptr [esi+0CCh] ; 10h
buffer
(16byte)
text:0804B2C0 push 5 ; URB_DIR_IN
|
URB_SHORT_XFER_OK
text:0804B2C2 push dword ptr [esi+0F0h] ; not!
linked
URB ???
text:0804B2C8 call _usbd_setup_bulk
text:0804B2CD add esp, 0FFFFFFF4h
text:0804B2D0 push 0FA0h ; TIMEOUT???
(4000
milliseconds)
text:0804B2D5 push esi ; user data
text:0804B2D6 push offset sub_804B110 ;
bulk_callback
text:0804B2DB push dword ptr [esi+0DCh] ;
bulk_in_pipe
text:0804B2E1 push dword ptr [esi+0F0h] ; urb
text:0804B2E7 call sub_80499D8 ; usbd_io
Only 13 byte data transfers!? Why?
Sorry, I missed one more call.
Not all transfers are 13 bytes
( UMASS Protocol see > www.usb.org > for spec)
command phase 31 bytes
data phase n bytes
status phase 13 bytes
Hmm, you mean n <= 32 bytes (for data transfers) ? As I see in
usbd-umass:
…
text:0804A011 push 10h ; 16 bytes
text:0804A013 call _usbd_alloc
…
text:0804A05E push 10h ; 16 bytes
text:0804A060 call _usbd_alloc
…
text:0804A075 push 20h ; 32 bytes
text:0804A077 call _usbd_alloc
…
text:0804A08C push 14h ; 20 bytes
text:0804A08E call _usbd_alloc
…
So, we have a 32 bytes buffer at maximum, but at specification i read
this: "wMaxPacketSize Word 00??h Maximum packet size. Shall be 8, 16, 32
or
64 bytes (08h,10h, 20h, 40h).
". Why you do not use 64 bytes packets?
Commands can take variable length data phase. For a SCSI_READ command n
will
be
multiple of 512 a multiple block size. The USB stack/chip takes care of
splitting the
transactions in proper packet sizes.
You mean that “device umass chip” take cares about it?
OHCI chip
But if you are using only a half (32bytes of 64) of data transfer buffer
that means that you have a slower transfer rate, am I right?
There is really no difference to the USB stack if the endpoint size is 32 or
64 bytes. There would be slower transfer rates if your
endpoint size is 32 bytes due to protocol overhead. (see USB spec ) I don’t
know why you see a memory leak in the driver with 64 byte
endpoint size. Memory allocation is done in the USB stack when a URB comes
in from the client driver and free’d when they complete.
I don’t see a memory leak with the MASS storage driver/or network drivers
and they both use 64 byte endpoints. There must be
something with your driver/device combination thats trigger this situation.
You see, I just want to understand why when I’m using 64 bytes data
packets for bulk transfers I have a memory leaks, in my case data
trasfer
rate is very important. Maybe usb stack works wrong with this length?
There should be no problem with 64 byte endpoints. Mass storage devices
all
of 64 byte endpoints.
There is a problem. As you can see at previous posts, Interface descriptor
has still 64 bytes bulk endpoints, but transfers are 32bytes now.
Nor sure I understand. Your device has 64 byte endpoints but your usbd_io
requests are for 32 bytes ?
Is the device sending 64 or 32 ?
Or your device endpoint says 64. Your usd_io() requests are for 1024
and your device only send 32 bytes at a time ?
And why timeout is so big?
Timeouts are really intended to catch situations wher the device
stops
responding.
Transactions could also timeout of the USB stack doesn’t get a
chance to
run
due
to a higher priority process consuming CPU.
And as i see linked URBs still not released?
Not sure what you are referring to. Linked URB’s are supported.
So, if they are supported now, why they are not used it in devb-umass?
As you can see, from this listing:
Simply because you don’t see a usbd_alloc() for a larger buffer does not
mean
the driver is not using transfers larger than 32 bytes. The endpoints are 64
bytes.
A block of data is 512 bytes, how else is the driver going to read 1 block
of data ?
The transfers have to be at least 512 bytes or it wouldn’t be able to read a
single
disk block of data.
I’m reffering to:
text:0804A047 push 0
text:0804A049 call _usbd_alloc_urb
text:0804A04E mov [ebx+0F0h], eax
I think it’s in your’s insertion function?
Henry
Thanx.
Hello Henry, maybe this can helps:
It seams that I have memory leaks at devu-ohci. Just look at
this:
#sin -l 1 -P devu-ohci memory
—Cut—
devu-ohci 253962 72K 19M 24K
596K
58786
zero 07FA8000
00000000 ----- -----
4K
RWX
zero 07FAD000
00000000 ----- -----
4K
RWX
zero 07FBC000
00000000 ----- -----
4K
RWX
zero 07FC6000
00000000 ----- -----
4K
RWX
zero 08046000
00000000 ----- -----
8K
RW_
devu-ohci 08048000 00000000 72K
SR_X_
20K
PRW__
zero 0805F000
00000000 ----- -----
48K
RW_
zero 0806B000
00000000 ----- -----
19M
RW_N
^^^ from where?!
mem 40100000
DB024000 ----- -----
4K
SRW_N
ldqnx.so.2 B0300000 00453000 344K
SR_X
20K
PRWX_
CRASH…
devu-ohci 253962 72K 9361K 24K
596K
68114
zero 07FA8000
00000000 ----- -----
4K
RWX
zero 07FAD000
00000000 ----- -----
4K
RWX
zero 07FBC000
00000000 ----- -----
4K
RWX
zero 07FC6000
00000000 ----- -----
4K
RWX
zero 08046000
00000000 ----- -----
8K
RW_
devu-ohci 08048000 00000000 72K
SR_X_
20K
PRW__
zero 0805F000
00000000 ----- -----
48K
RW_
—Cut—
So?
Its difficult to know if the problem is in the device, client
driver
or USB
stack.
Have you verified that the device is still functioning
properly
when
this
occurs ?
Can check the URB status to see if any errors are reported.
For the removal problem :
You should check to see if the device has been removed and
stop
enqueing
URBS. Set a flag in the removal callback and check for it
before
you
enqueue
a URB.
Henry
guest <> guest@anonymous.com> > wrote in message
news:d4nukp$g1j$> 1@inn.qnx.com> …
What version of OS are you running ?
QNX 6.3.0 SP1
Host Controller driver devu-ohci
Read function is:
const int USB_TIMEOUT = USBD_TIME_INFINITY;
const int BULK_PURE_BLOCK_LENGTH = 1024;
void* work_control(void* arg) {
…
while (1) {
for (c = 0; c < BULK_BUFFERS ; c++) {
usbd_setup_bulk(bulk_urb[c], URB_DIR_IN, bulk_mem[c],
BULK_PURE_BLOCK_LENGTH);
usbd_io(bulk_urb[c], dc[0]->bulk_ep4_pipe,
dc_bulk_cbf_ep4_0 ,
bulk_mem[c], USB_TIMEOUT);
dc_bulk_wait_ep4_0(bulk_urb[c], dc[0]->bulk_ep4_pipe);
}
bulk callback is:
void dc_bulk_cbf_ep4_0( struct usbd_urb *urb, struct
usbd_pipe
*pipe, void
*hdl ) {
pipe = pipe, hdl = hdl;
pthread_sleepon_lock( );
pthread_sleepon_signal( urb );
pthread_sleepon_unlock( );
return;
}
bulk wait is:
int dc_bulk_wait_ep4_0( struct usbd_urb *urb, struct
usbd_pipe
*pipe) {
_uint32 ustatus;
_uint32 alen;
int status;
pthread_sleepon_lock( );
while( ( status = usbd_urb_status( urb, &ustatus, &alen ))
EBUSY ) {
pthread_sleepon_wait( urb );
}
pthread_sleepon_unlock( );
return(alen);
}
Alexander Arkhipov <> arkhipov@tst.spb.su> > wrote in message
news:d45dg0$mai$> 1@inn.qnx.com> …
Hello everybody! We designed our own device with 4 +
Control
endpoints,
Bulk In, Bulk In, Interrupt In and Interrupt Out.
Interrupts
for
command
level and Bulks for data transfer. But after I transfered
aproximatly
2.6 Mb
of data my device hanged. Only slay’ing devu-ohci helps to
get
it
works.
And
one more detail: it i’m trying to remove device i have the
folowing
message
fro usdi library: udi_transfer_complete:
usbdi_client_event 9
(sometimes
12). What does this message means?
9 is EBADF. Is your driver still running after you unplug
the
device ?
Is you driver trying to enqueue IO for the device after it
has
been
removed
?
Is if possible to post the source for your driver ?
Henry
Regards,
Alexander
.
.
.
.
.