Date: Wed, 05 Dec 2012 08:35:31 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: current@freebsd.org, Warner Losh <imp@bsdimp.com> Subject: Re: Call for testers, users with scsi cards Message-ID: <1354721731.87661.98.camel@revolution.hippie.lan> In-Reply-To: <alpine.BSF.2.00.1212041456040.4081@desktop> References: <alpine.BSF.2.00.1212041131340.4081@desktop> <C442208D-42DF-4986-A88E-A7E404F3CCA3@bsdimp.com> <1354658563.87661.23.camel@revolution.hippie.lan> <alpine.BSF.2.00.1212041456040.4081@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2012-12-04 at 14:58 -1000, Jeff Roberson wrote: > On Tue, 4 Dec 2012, Ian Lepore wrote: > > > On Tue, 2012-12-04 at 14:49 -0700, Warner Losh wrote: > >> On Dec 4, 2012, at 2:36 PM, Jeff Roberson wrote: > >> > >>> http://people.freebsd.org/~jeff/loadccb.diff > >>> > >>> This patch consolidates all of the functions that map cam control blocks for DMA into one central function. This change is a precursor to adding new features to the I/O stack. It is mostly mechanical. If you are running current on a raid or scsi card, especially if it is a lesser used one, I would really like you to apply this patch and report back any problems. If it works you should notice nothing. If it doesn't work you will probably panic immediately on I/O or otherwise no I/O will happen. > >> > >> I haven't tested it yet. My only comment from reading it though would be to make subr_busdma.c be dependent on cam, since it can only used from cam. We've grown sloppy about noting these dependencies in the tree... > >> > >> Warner > > > > Hmmm, if it's only used by cam, why isn't it in cam/ rather than kern/ ? > > kib pointed out drivers that use ccbs but do not depend on cam. Ahh, I didn't realize. > I also > intend to consolidate many of the busdma_load_* functions into this > subr_busdma.c eventually. I will add a load_bio and things like load_uio > and load_mbuf don't need to be re-implemented for every machine. I will > define a MD function that allows you to add virtual or physical segments > piecemeal (as they all currently have) so that function may be called for > each member in the uio, mbuf, ccb, or bio. I'm afraid the current near-identicalness of things like the load_mbuf implementations have more to do with the cut-and-paste nature of how the non-x86 implementations came to be, rather than actual correctness. A proper implementation of the load_mbuf routines on architectures with VIVT cache should involve setting some flags in the map so that the sync operations can be handled differently for mbufs than for anonymous memory. (Mbufs are allowed to bend the rules about DMA buffers being aligned to cacheline boundaries.) The uio-related busdma operations for VIVT cache platforms are probably just plain wrong -- like "would cause a panic" type wrong if they were actually invoked. I posted a set of patches that fix all the problems I know of in the armv4 busdma implementation, except for the uio stuff. It didn't get much comment at the time and lacks a champion who can actually commit the code. They won't even apply cleanly anymore because of other changes that have happened, I guess I should go re-spin the patchset and post it again. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1354721731.87661.98.camel>