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, an
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) s
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 ju
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 i
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
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 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 CPU
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 :(
>
> Y
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 pe
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
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
11 matches
Mail list logo
