On 2015/09/11 19:44, Masanobu SAITOH wrote:
Hi, Jonathan.
On 2015/09/09 23:02, Jonathan A. Kollasch wrote:
On Tue, Sep 08, 2015 at 12:58:31PM +0900, MAEKAWA Masahide wrote:
On 2015/09/08 0:59, Jonathan A. Kollasch wrote:
- abuse of the pcitag_t (I have patches that fix this.)
Your pat
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 manual, requires I use the
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
a
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 UGEN_SH
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
} http://nxr.netbsd
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 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 O_NONBLOCK
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. When I hit
> Strg+Alt+Esc in
[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 rea
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
with
11 matches
Mail list logo
