SCSI woes.

[Lucio de Re lucio@proxima.alt.za]

Geoff (does anyone at Bell Labs have names? I'm still racking my brain
as to who jmk is, I'm sure I *ought* to know :-)

I'm using your mail as a checklist, please feel free to give me hell if
this is annoying:

> I have used the AHA1542CP in several machines; I think I've used it
> with the Seagate ST12400N and on another occasion with bigger disks
> and 9pcfs.  I don't think I've ever seen your symptoms.  You've got
> the 1542 i/o port base set to 0x330, the drive's SCSI id set to 0, and
> the bus is terminated correctly (if you've only a single SCSI device,
> it should have termination enabled internally or have a SCSI
> terminator attached)?

I'm not sure about the termination.  The drive seems to operate
correctly under (shudder) WinNT, and I've set the termination jumper(s)
so that the drive provides termination power, has termination on and
parity enabled.  I find the controller can be very forgiving, but not
reliably so, alternative jumper configurations will be gratefully
accepted.

> ... b.com will only look at 0x330 for a SCSI host
> adapter.  Have you configured the adapter with Adaptec's `SCSISelect'
> program, accessible at boot time with control-a?  SCSISelect should
> also be able to probe the disk a little, as a sanity check.
>
The disk, as I mentioned, behaves fine.  PnP sets the adapter's IRQ to
10 because of a PCI ethernet card (I'll hopefully get to the ethernet
too, eventually), which is why I disable PnP.  This results in the
default AHA configuration applying, although naturally I have reason to
be concerned about PnP doing evil things with IRQ 11 itself.  I removed
the Ether card to no noticeable improvement, perhaps reserving IRQ 11
for an ISA legacy card will make a difference, I had not considered
that possibility.  Nopes, still get "adaptec0: invdcmd #01, len 5", etc.

> Disabling plug-and-play also disables the 1542CP's BIOS (because it
> then effectively becomes a 1542CF but the BIOS is for the 1542CP and
> the versions don't match), which I don't believe is needed if you only
> run Plan 9.
>
Ouch!  How, then, do I convince PnP to leave the AHA's default settings
unchanged (I see it returns IRQ 10 and DMA 7, then again, b.com does
ask the controller, whose I/O address certainly doesn't change :-(

> An unrelated potential problem is that the 1542 has a built-in floppy
> controller that may need to be disabled (switch 5) if your system
> already has one.
>
Nopes, taken care of that.

> The SEE ALSO section of scuzz(8) is a good place to find out where to
> learn more about SCSI; there's also a newer book called something like
> `The SCSI and IDE Standards' that's quite good.  A quick introduction,
> geared to FreeBSD, can be found through
> `http://www.freebsd.org/handbook/handbook.html' (it's
> `http://www.freebsd.org/handbook/handbook127.html' today, but they
> keep renumbering it).

Seems to have lingered in the same spot long enough for me to catch it
:-)
I'll now read through it and see if I can discover where I'm going
wrong.

I can certainly not find any explanation for the invalid command
report.  As I read it, what's happening is that the POLL command issuer
is feeding dud data to the controller, or somesuch.  I'll make sure I
have the most recent version of b.com on the boot floppy (I'm sure it
currently has the CD-ROM version) and, additionally or alternatively,
will hack at the sources to produce a copy that will help me diagnose
the problem.

Thanks for your encouragement.
--
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.