Re: Kernel panic when copying data to umass device (USB4BSD) - problem found

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
> RAM.
>
> > 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.

--HPS