Date: Thu, 3 Sep 2009 23:31:07 -0600 From: Scott Long <scottl@samsco.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Ryan Rogers <webmaster@doghouserepair.com>, Alexander Motin <mav@freebsd.org>, current@freebsd.org Subject: Re: non aligned DMA transfer attempted Message-ID: <A1B223C6-7291-4F86-B8AC-4EB5EF12F409@samsco.org> In-Reply-To: <200909032210.n83MA67F059073@apollo.backplane.com> References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw> <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 3, 2009, at 4:10 PM, Matthew Dillon wrote: > This is a known problem with physio and/or the ATA driver, > depending > on your viewpoint. See kern/kern_physio.c. > > The physio code directly maps the userland buffer via vmapbuf() and > supplies it as a BIO to the device. The ATA driver does not use > BUSDMA (and never has)... it assumes BIOs are minimally aligned. > Wrong. > But BIOs generated from kern_physio.c use user addresses directly > and > thus might only be byte-aligned. > > The CAM pass-through device has the same problem. > Huh? Are you confused by the physaddr interface of CAM? > The problem occurs most often when running a cd/dvd player or > burner > which declares operational structures it intends to read() or > write() > on the stack, sometimes even with char[] arrays. > > The solution I came up for with DFly was to implement bounce > buffers > manually in kern_physio.c and the CAM pass-through device for any > user data that was not 16-byte aligned. I considered implementing > bounce buffers in all the disk drivers that were missing it but > there are other serious problems trying to bounce dma buffers > that deep > in the device hierarchy... you can hit low-memory deadlocks if the > driver isn't written carefully enough (and most aren't). The > BUSDMA > API has never been easy to work with for anyone trying to use the > async data buffer bouncing load feature... most drivers just > force it > to run synchronously and thus hit the deadlock issues. > Wrong. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A1B223C6-7291-4F86-B8AC-4EB5EF12F409>