[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-driver-discuss
Subject:    [driver-discuss] weirdness in SCSA dma stuff
From:       "Garrett D'Amore" <garrett () damore ! org>
Date:       2008-09-25 15:08:28
Message-ID: 48DBA96C.8060404 () damore ! org
[Download RAW message or body]

So, I've gotten reports of a strange bug in my SDcard, which seems to be 
limited to using the card during single user mode on a laptop.  The 
message that comes through is:

Sep 25 13:23:22 martin-nb rootnex: [ID 561485 kern.warning] WARNING: 
sdcard: coding error detected,
 the driver is using ddi_dma_attr(9S) incorrectly. There is a small risk 
of data corruption in part
icular with large I/Os. The driver should be replaced with a corrected 
version for proper system op
eration. To disable this warning, add 'set rootnex:rootnex_bind_warn=0' 
to /etc/system(4).

Researching the i86pc rootnex code, it looks like this happens when the 
resource can't be mapped completely and wholly, and DDI_DMA_PARTIAL is 
not supplied at the time the resource binding occurs.

Now the mysterious part is that my drivers perform no DMA binding on 
their own, but rely entirely on SCSA to do the work.  Specifically, the 
driver uses the new style SCSA packet management routines specified by 
PSARC 2005/680.  (I.e. it uses tran_setup_pkt, & company.)  My read on 
this is that the end result should be that the SCSA framework binds SCSI 
packets using DDI_DMA_PARTIAL, at least on x86 platforms.

None of the drivers involved call ddi_dma_xxx_bind on their own -- 
instead they rely on the SCSA layer to do the DMA binding for them.

Yet, somehow this isn't happening with the DDI_DMA_PARTIAL, and I can't 
figure out why.

Anyone have any ideas, or has anyone seen this problem elsewhere before?

    - Garrett
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
[prev in list] [next in list] [prev in thread] [next in thread]