This is a discussion on Re: Kernel panic when copying data to umass device (USB4BSD) -problem found - FreeBSD ; On Friday 07 November 2008, Alexey Shuvaev wrote: > On Fri, Nov 07, 2008 at 06:11:26PM +0100, Hans Petter Selasky wrote: > > Hi Jeremy, > > > > I've reproduced the issue with some mods to the usb2_busdma.c on ...
On Friday 07 November 2008, Alexey Shuvaev wrote:
> On Fri, Nov 07, 2008 at 06:11:26PM +0100, Hans Petter Selasky wrote:
> > Hi Jeremy,
> > I've reproduced the issue with some mods to the usb2_busdma.c on 32-bit
> > arcitecture and have made a fix for this problem.
> > Try the following patch and re-test!
> Thanks a lot! I have rebuild the kernel with this patch
> > http://perforce.freebsd.org/chv.cgi?CH=152624
> and so far no panics. Indeed, the system I am using is amd64 with 4Gb of
> > Some mem-stick benchmarks would be nice ...
> What exactly do you mean?
> I have done:
> dd if=file_on_one_stick of=/dev/null bs=1m (12.5 Mb/s)
> dd if=/dev/random of=file_on_the_stick bs=1m count=128 (2.6 Mb/s)
> and the same tests with USB-microSDHC adapter with 8Gb card
> (20 MB/s read, 15 Mb/s write).
> Anything else?
No, that looks very good. Maybe you could also do a md5 on the transferred
data, just to see if there are data errors.
BTW: I have forced my 32-bit system to use bounce buffers now, and I have
found more problems!
Warner: I see that bus-dma is allocating bounce buffers for the EHCI/OHCI/UHCI
transfer descriptors and queue heads, even though I use "bus_dmamem_alloc()"
with the COHERENT flag and everything. I suspect that the problem is
that "bus_dmamem_alloc()" is optimised to use "malloc()" which then
automatically will imply a possible bounce buffer. Even if I use PAGE_SIZE
byte allocations it goes wrong. Maybe I also need to set the alignment to
PAGE_SIZE bytes, to really ensure that "busdma" is not putting the TD's and
QH's in the wrong part of the memory from the beginning?
This is a big problem, because the busdma API does not allow flushing single
fields of these descriptors, which is an absolute mandatory feature during
USB operation. On NetBSD this is possible. What should we do? I guess this is
the root problem of USB(2) not working reliable on 64-bit architectures.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"