[ugen bulk read ahead code]
This code was written under my direction back in 2006 to support the
specific use case of the USRP with GNU radio. The only reason it's
needed is to get better pipelining to get closer to the max transfer
speeds.
So:
are you doing something where not using
hello folks. Perhaps someone on this list can enlighten me as to
where I'm going wrong, but I think there may be an issue with ugen(4) when
using the bulk read ahead and write behind code in conjunction with file
descriptors which are in O_NONBLOCK mode. This is with NetBSD/i386 5.2
On 09/24/15 08:07, Brian Buhrow wrote:
hello folks. Perhaps someone on this list can enlighten me as to
where I'm going wrong, but I think there may be an issue with ugen(4) when
using the bulk read ahead and write behind code in conjunction with file
descriptors which are in
Hi
Was that understandable? I can also provide a photo of the screen
showing the whole stack and panic message, if required. Though I think
it´s reproducible easily.
2015-09-22 9:01 GMT+02:00 Stephan :
> Hi
>
> I´m running a pretty recent image of 7.0_RC3 on my RPI2.
On Sep 24, 12:00pm, Nick Hudson wrote:
} Are you sure about this? I'm not sure why ugen_bulkra_intr doesn't start
} a new transfer, but see below.
}
} I wonder if
}
} http://nxr.netbsd.org/xref/src/sys/dev/usb/ugen.c#697
} http://nxr.netbsd.org/xref/src/sys/dev/usb/ugen.c#1221
On 09/24/15 15:52, Brian Buhrow wrote:
On Sep 24, 12:00pm, Nick Hudson wrote:
} Are you sure about this? I'm not sure why ugen_bulkra_intr doesn't start
} a new transfer, but see below.
}
} I wonder if
}
} http://nxr.netbsd.org/xref/src/sys/dev/usb/ugen.c#697
}
Given that you want short reads, why are you setting read ahead? Are
you failing to get enough throughput without it?
pgprITHBwCeBl.pgp
Description: PGP signature
On Sep 24, 3:55pm, Nick Hudson wrote:
} Subject: Re: Potential problem with reading data from usb devices with uge
} On 09/24/15 15:52, Brian Buhrow wrote:
} > I forgot to mention the libusb1 calls do request the
} > USB_SET_SHORT_XFER via ioctl(2).
} This doesn't matter / help here as
hello. I don't necessarily need the read ahead functionality, though
it might be useful when I start doing large transfers to and from the Apple
devices. However, what I want is the non-blocking functionality which,
according to the manual, requires I use the read ahead code to get. It
Brian Buhrow writes:
> hello. I don't necessarily need the read ahead functionality, though
> it might be useful when I start doing large transfers to and from the Apple
> devices. However, what I want is the non-blocking functionality which,
> according to the
10 matches
Mail list logo