Date: Thu, 3 Sep 2009 15:10:06 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alexander Motin <mav@freebsd.org> Cc: Ryan Rogers <webmaster@doghouserepair.com>, current@freebsd.org Subject: Re: non aligned DMA transfer attempted Message-ID: <200909032210.n83MA67F059073@apollo.backplane.com> References: <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw> <4AA03346.5010608@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
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.
I seem to recall that the same issue popped up a few months ago on
these lists, too.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200909032210.n83MA67F059073>