Re: [linuxsh-shmedia-dev] SCSI status

[Richard C. <Ric...@su...>]

Hi Paul,

* Paul Mundt <le...@li...> [2003-06-30]:
> I see one potential user that might be a problem.. looking at the driver
> itself, in __sync_scsi_data(), it wraps to pci_dma_sync_sg() and
> pci_dma_sync_single() .. we're covered for the first one, but not the latter.
> 
> Try this patch out, see if it helps any:

I applied this, and it fixes some of the corruption.  For example,
e2fsck now appears to leave the disc on a good state, a 2nd 'e2fsck -f'
doesn't find errors.  And the error rate on a 'md5sum -c' run over a
mirror of /usr looks a lot healthier - still not perfect, but the error
rate is > an order of magnitude better.

The problem with umount leaving the filesystem 'not clean', as reported
by dumpe2fs and e2fsck, is still there.

So your patch is a huge step in the right direction, but we're still
hunting for a 2nd bug too somewhere.

FYI I've also tried replacing the body of dma_cache_wback_inv by
flush_cache_all, but that made no difference.  (I was trying to check a
theory I had that a recently recycled page was being allocated for a
readin from the disc, but there were still stale cache entries of the
wrong colour for that page which wouldn't get cleared out by the
existing dma_cache_wback_inv algorithm.  This seems to be disproven
now.)

I've going back to do more trials with the D-cache disabled to confirm
whether it's 100% reliable then.  If so, we'll have to keep looking for
a cache coherency problem.  I'll keep you informed.

-- 
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
  P.    /// ric...@su...  ///  rc...@rc...
Curnow  \\\ http://www.superh.com/    ///  www.rc0.org.uk