[linuxsh-shmedia-dev] SCSI status

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

Following the breakthrough on Friday of apparently getting swap to work
to a SCSI disk, today I've been experimenting with filesystems:

* used fdisk to create 4 primary partitions (3 big, 1 small to be used
  for swap) : seemed to work OK

* created 2x ext3 filesystems

* use rsync to mirror NFS filesystems onto the SCSI ones : kernel locked
  up eventually, PC inside journal_commit_transaction

So for now, just using ext2.

* similar on ext2, found I was getting NETDEV watchdog firing, + lots of
  PCI Interrupts with PCI INT=0x200, CIR=0x400000[67f].  Note : not arb
  interrupts this time.  Once the NETDEV watchdog fired, the machine was
  effectively stuck.

* after moving SCSI card to a 5V slot, the PCI interrupts went away.

* several attempts at rsync'ing the NFS filesystem onto an ext2 on the
  SCSI, using find|md5sum on the NFS server to generate a golden
  reference, and using md5sum -c on the Cayman to check the copy.
  Sometimes a very small number of files are unreadable.  A number of
  files (typically about 100 in 15000) have failed checksums.  The
  failing files vary from one 'md5sum -c' run to another.

* trying to boot with the SCSI ext2 filesystem as the root doesn't work
  - there are lots of console messages like 

  08:01: rw=0, want=1614831682, limit=2458608
  attempt to access beyond end of device

* if I run e2fsck on the partition right after booting, but before it's
  been mounted, the partition appears clean.  If I try after doing
  'mount;umount' there is always some corruption.  If I keep doing
  e2fsck, there is new corruption every time.  If I halt & reboot, the
  filesystem appears uncorrupted again.

* Also, umount doesn't make the filesystem state 'clean' as it should.

* Currently I've got flush_page_to_ram calling flush_dcache_page and the
  multiple read stuff in the SCSI driver commented out, to see if these
  improve things.  Not sure one way or the other yet.

So overall it's close, but nowhere near good enough to be a production
filesystem.  I've no idea if the remaining problems I'm seeing are
hardware or software related.  Some behaviour looks like it could be
coherency related, either between cache and memory, or between memory
and disc.

Anybody seen anything like this before, or have experiments that would
be useful to try out?

Cheers
Richard

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