On Tuesday 24 May 2011 23:48:30 Daniel O'Connor wrote:
I find that my application has rare problems where it does not get a reply
from the micro to a control bus packet, or perhaps the micro doesn't
receive it (I need to add a sequence number or similar to my protocol to
try and detect it I
On 25/05/2011, at 9:33, Hans Petter Selasky wrote:
On Tuesday 24 May 2011 23:48:30 Daniel O'Connor wrote:
I find that my application has rare problems where it does not get a reply
from the micro to a control bus packet, or perhaps the micro doesn't
receive it (I need to add a sequence number
On Wednesday 25 May 2011 09:47:50 Daniel O'Connor wrote:
On 25/05/2011, at 9:33, Hans Petter Selasky wrote:
On Tuesday 24 May 2011 23:48:30 Daniel O'Connor wrote:
I find that my application has rare problems where it does not get a
reply from the micro to a control bus packet, or perhaps
On 25/05/2011, at 9:51, Hans Petter Selasky wrote:
current. There is also a new utility called usbdump, which can be used to
figure out what is going on.
I am running 9-current (in production for my sins..)
usbdump is useful but consumes too much CPU at my data rate :(
You probably
On 5/25/11 12:54 AM, Daniel O'Connor wrote:
On 25/05/2011, at 9:51, Hans Petter Selasky wrote:
current. There is also a new utility called usbdump, which can be used to
figure out what is going on.
I am running 9-current (in production for my sins..)
usbdump is useful but consumes too much
on 19/05/2011 22:27 Shah, Vishal said the following:
In FreeBSD 8 USB driver, commands are asynchronously sent from umass layer
onto
the wire, in other words, multiple threads are involved before the command is
sent from the umass layer all the way to the wire. Since the usb_proc is not
On Wednesday 25 May 2011 17:01:24 Andriy Gapon wrote:
on 19/05/2011 22:27 Shah, Vishal said the following:
In FreeBSD 8 USB driver, commands are asynchronously sent from umass
layer onto the wire, in other words, multiple threads are involved
before the command is sent from the umass layer
Hi Hans Petter,
Thanks for looking into this.
The command is not hanging on a USB device. The issue is, command never
reaches the USB device. As I understand it, after receiving the command
from the upper layers, umass layer will just enqueue the xfer at the
USBD layer. And then usb_proc process
On Wednesday 25 May 2011 19:37:01 Shah, Vishal wrote:
Hi Hans Petter,
Thanks for looking into this.
The command is not hanging on a USB device. The issue is, command never
reaches the USB device. As I understand it, after receiving the command
from the upper layers, umass layer will just
do start_read/stop_read and start_write/stop_write map directly to the
userland read(2) and write(2) calls?
i had looked at this previously, and am a bit confused on if the above
is correct.
even if they are the direct interface to read(2)/write(2), the issue of
a poll method for select(2)
Hi,
On Wednesday 25 May 2011 21:02:29 Jim Bryant wrote:
do start_read/stop_read and start_write/stop_write map directly to the
userland read(2) and write(2) calls?
No, but they are called from these calls. The idea is that you use the FIFO
mechanism already present there when moving data, and
11 matches
Mail list logo
