Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted
On Saturday 06 December 2008, Marcel Moolenaar wrote: On Dec 6, 2008, at 4:34 AM, Hans Petter Selasky wrote: Hi, After various feedback from several people I have made a new patch proposal that will fix the busdma problem. See: http://perforce.freebsd.org/chv.cgi?CH=154181 Review wanted! The USB stack has a fixed page size of 4K. On our 64-bit platforms PAGE_SIZE is at least 8K. Your change is sloppy in that respect and doesn't make the distinction. That makes the patch a kluge. The definition of BUS_DMA_NO_REALIGN is based on circumstantial evidence only and as such, works as a side-effect. I don't think that's a good design. I don't think there's any reason not to preserve the page offset in all cases. So far all hardware worked whether or not their DMA pages were bounced and the non-bounced pages would have a possible non-zero page offset, whereas the bounced pages would always have a zero page offset. In short: it works either way. In particular, it works with the page offset preserved. Why not preserve it always? What's the downside? Hi Marcel, I think you might be right there. There is one case in which I don't understand what is the correct busdma behaviour. If the DMA tag has an alignment of 4 bytes, and the memory loaded is not aligned to four bytes, then should a bounce page be used? If yes, then you will need to clear the page offset. Else not. NOTE: We are not talking about allocating DMA memory, only loading it. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted
On Sat, Dec 06, 2008 at 01:34:54PM +0100, Hans Petter Selasky wrote: Hi, After various feedback from several people I have made a new patch proposal that will fix the busdma problem. See: http://perforce.freebsd.org/chv.cgi?CH=154181 Review wanted! I don't know how to patch the psyco interface for SUN. Maybe there is nothing that needs to be patched? Neither sparc64 nor sun4u has support for bounce buffers; it's not really worth the effort to implement IOMMU-bypass and bounce buffers for the few devices only doing 32-bit DMA and for = 32-bit DMA the IOMMU takes care of the address translation for all practical purposes. In any case this isn't specific to psycho(4). Marius ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted
Hi, After various feedback from several people I have made a new patch proposal that will fix the busdma problem. See: http://perforce.freebsd.org/chv.cgi?CH=154181 Review wanted! I don't know how to patch the psyco interface for SUN. Maybe there is nothing that needs to be patched? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted
In message: [EMAIL PROTECTED] Hans Petter Selasky [EMAIL PROTECTED] writes: : Hi, : : It turns out my initial patch need to be limited to the use-case only. Before : I start any real work, I want to know if anyone will object if I implement : the following new BUS_DMA flag into FreeBSD's busdma system? : : amd64/amd64/busdma_machdep.c : i386/i386/busdma_machdep.c : arm/arm/busdma_machdep.c : ia64/ia64/busdma_machdep.c : mips/mips/busdma_machdep.c : powerpc/powerpc/busdma_machdep.c : sparc64/sparc64/bus_machdep.c : sun4v/sun4v/bus_machdep.c : sys/bus_dma.h : : /* : * The following flag specifies that no re-alignment of individual : * memory pages is allowed when loaded into DMA. It can only be used : * when maxsegsz is equal to PAGE_SIZE and alignment is less : * than or equal to 1. : * : * Background: Some kinds of DMA hardware only stores the full : * physical address of the first memory page when multiple memory : * pages are loaded into DMA. Consequtive memory pages only gets the : * non-offset part of the physical address updated. The hardware : * computes the amount of data that should be stored in the first : * memory page from the minimum of the total transfer length and : * PAGE_SIZE minus the initial page offset. When the initial page : * offset is not preserved the hardware ends up transferring an : * invalid number of bytes to or from the initial memory page. : */ : #define BUS_DMA_NOREAL 0x400 /* no page re-alignment allowed */ : : : : Without this new feature in busdma the USB hardware will not work when the DMA : data is placed on bounce pages, for example on 64-bit architectures with more : than 4GB of RAM. I'm having trouble understanding the need for this patch. Can you provide a patch to usb2 to use it as well as doing one of the implementations (say i386 or amd64) so that it is easier to judge the problem it is trying to solve? Warner ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted
Hi, It turns out my initial patch need to be limited to the use-case only. Before I start any real work, I want to know if anyone will object if I implement the following new BUS_DMA flag into FreeBSD's busdma system? amd64/amd64/busdma_machdep.c i386/i386/busdma_machdep.c arm/arm/busdma_machdep.c ia64/ia64/busdma_machdep.c mips/mips/busdma_machdep.c powerpc/powerpc/busdma_machdep.c sparc64/sparc64/bus_machdep.c sun4v/sun4v/bus_machdep.c sys/bus_dma.h /* * The following flag specifies that no re-alignment of individual * memory pages is allowed when loaded into DMA. It can only be used * when maxsegsz is equal to PAGE_SIZE and alignment is less * than or equal to 1. * * Background: Some kinds of DMA hardware only stores the full * physical address of the first memory page when multiple memory * pages are loaded into DMA. Consequtive memory pages only gets the * non-offset part of the physical address updated. The hardware * computes the amount of data that should be stored in the first * memory page from the minimum of the total transfer length and * PAGE_SIZE minus the initial page offset. When the initial page * offset is not preserved the hardware ends up transferring an * invalid number of bytes to or from the initial memory page. */ #define BUS_DMA_NOREAL 0x400 /* no page re-alignment allowed */ Without this new feature in busdma the USB hardware will not work when the DMA data is placed on bounce pages, for example on 64-bit architectures with more than 4GB of RAM. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Serious] busdma bug in -current in relation to USB hardware - review wanted
On Nov 16, 2008, at 5:08 AM, Hans Petter Selasky wrote: Hi, It turns out my initial patch need to be limited to the use-case only. Before I start any real work, I want to know if anyone will object if I implement the following new BUS_DMA flag into FreeBSD's busdma system? amd64/amd64/busdma_machdep.c i386/i386/busdma_machdep.c arm/arm/busdma_machdep.c ia64/ia64/busdma_machdep.c mips/mips/busdma_machdep.c powerpc/powerpc/busdma_machdep.c sparc64/sparc64/bus_machdep.c sun4v/sun4v/bus_machdep.c sys/bus_dma.h /* * The following flag specifies that no re-alignment of individual * memory pages is allowed when loaded into DMA. It can only be used * when maxsegsz is equal to PAGE_SIZE and alignment is less * than or equal to 1. * * Background: Some kinds of DMA hardware only stores the full * physical address of the first memory page when multiple memory * pages are loaded into DMA. Consequtive memory pages only gets the * non-offset part of the physical address updated. The hardware * computes the amount of data that should be stored in the first * memory page from the minimum of the total transfer length and * PAGE_SIZE minus the initial page offset. When the initial page * offset is not preserved the hardware ends up transferring an * invalid number of bytes to or from the initial memory page. */ #define BUS_DMA_NOREAL 0x400 /* no page re-alignment allowed */ No objection, but please call it BUS_DMA_NOREALIGN NOREAL reads as NO-REAL and not as NO-RE-AL. And with real addressing an existing concept, confusion is not far around the corner... -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
