|
From: Richard C. <Ric...@su...> - 2003-07-01 14:47:24
|
Hi Paul,
* Paul Mundt <le...@li...> [2003-07-01]:
> On Tue, Jul 01, 2003 at 03:01:55PM +0100, Richard Curnow wrote:
> > sg[i].dma_address = page_to_bus(sg[i].page) +
> > sg[i].offset;
> > + dma_cache_wback_inv((unsigned long) bus_to_virt(sg[i].dma_address), sg[i].length);
> >
> If you do this, you'll also want to do a similar flush in pci_unmap_sg(). I
> don't know if this is specifically needed, since on anything else requiring
> coherency, it seems to be omitted.
As far as I can tell, I've got the disc working reliably now. Some
experiments that I've done are:
* a workload of 2 compilations, a configure (all these 3 in a while true
loop with make {dist}clean), top, X, 2x gkrellm, several xterms & 7 or
8 instances of our 'burnout' program. The load average was over 13,
and the Cayman was 70-110Mb deep in swap with periodic bursts of
intense swap in and swap out activity. This ran without a hitch for
44 minutes until it died with a PCI ARB and the SCSI bus got wedged.
I think this is reasonably convincing in itself that the SCSI access
is now reliable.
* I mirrored my NFS filesystems onto the SCSI disc partitions, and
modified the GDB download script to make root=/dev/sda1 on the
command line. For several boots I had the root and home filesystems
on the SCSI, with no NFS discs brought up at all. However, I've
discontinued this just for now because I need to do more work with the
shell scripts run by init to get fsck, umount etc working properly on
boot and shutdown.
During these trials, I had flush_dcache_page inside flush_page_to_ram.
I need to do more runs to evaluate where we stand now on making
flush_page_to_ram a no-op again.
I'm currently merging from the external BK and retesting, then I'll push
this fix out.
Cheers
Richard
--
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
P. /// ric...@su... /// rc...@rc...
Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk
|