Re: Call for testers, users with scsi cards

From: Ian Lepore <freebsd_at_damnhippie.dyndns.org>
Date: Wed, 05 Dec 2012 08:35:31 -0700
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
Received on Wed Dec 05 2012 - 14:35:49 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC