[9fans] Plan 9 sd53c8xx vs. sym53c875r3

[9fans] Plan 9 sd53c8xx vs. sym53c875r3

[David Evers]

Hi -

I'm trying to bring Plan 9 up on a PII/SE440BX with a SCSI
disk attached to a Symbios 53c875 rev. 3 controller.  It
sort of half works, in a way that makes me suspect problems
in the sd driver.  I was wondering if you (as the author)
might have any insights into what to do next.

By "half works", I mean:

- the June 17th install floppy can see the disk, runs rio and
  installs all the bits apparently correctly

- a boot floppy created by that install can see the disk, 9fat,
  plan9.ini etc. and successfully boots the kernel

- we get to /rc/bin/termrc, get through the ipconfig stuff, then
  when we bind '#S', one of two things happen, depending on the
  recent boot history of the machine:

  - from power off, or on the first ctl-alt-del from the install floppy,
    the bind '#S' pauses for a minute or so, then the rest of
    termrc fails with a number of "test: exec header invalid"
    messages.  The kernel seems healthy enough (^T^T commands ok)
    but of course we never make it to rio.

  - sometimes, in circumstances that I can't pin down completely
    but believe to be deterministic, it all works just fine: we get
    to rio as glenda and experience no further (visible) problems.
    (For instance, cold booting the install floppy, then ctl-alt-del
    to the boot floppy, then when that hangs ctl-alt-del to the boot
    floppy again seems to work reliably).

Poking around from the install floppy rio session, it seems that
there's nothing wrong with the bits on the disk (xd test looks ok).
So I'm wondering if there's a problem with the 53c875 setup.

The same machine works fine under Linux; the README for the Linux
driver mentions that it works around various chip bugs.  The one
that caught my eye was:

  "This problem is described in SYMBIOS DEL 397, Part Number 69-039241,
ITEM 4.

   In some complex situations, 53C875 chips revision <= 3 may start a
PCI
   Write and Invalidate Command at a not cache-line-aligned 4 DWORDS
boundary.
   This is only possible when Cache Line Size is 8 DWORDS or greater.
   Pentium systems use a 8 DWORDS cache line size and so are concerned
by
   this chip bug, unlike i486 systems that use a 4 DWORDS cache line
size.

   When this situation occurs, the chip may complete the Write and
Invalidate
   command after having only filled part of the last cache line involved
in
   the transfer, leaving to data corruption the remainder of this cache
line."

And the Linux driver dutifully makes sure to clear the WRIE bit in the
ctest3 register.

Do you think this is likely to be the cause of my problem?
Would I be able to turn this off from the on-card BIOS? (The
Plan 9 driver doesn't seem to touch this particular bit.)
Am I wrong to suspect the driver at all?

Thanks for any hints you can give!

Cheers,

---- Dave