SCSI woes.

SCSI woes.

[geoff]

i saw the `If the BIOS is enabled' comment, but he said
he'd disabled p'n'p, which disables the bios in the 1542cp.

SCSI woes.

[Berry]

>>>presotto@plan9.bell-labs.com said:
 > > 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 :-)
 >
 > No, we are a society of nameless faceless individuals.
 > 		#6

I am not a number!  I am a free variable!

  --berry

SCSI woes.

[presotto]

> 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 :-)

No, we are a society of nameless faceless individuals.
		#6

SCSI woes.

[jmk]

if you look in the driver (kernel or b.com) as to which command "adaptec0: invdcmd #01, len 5"
refers to (Cmbinit = 0x01), the following comment in the reset routine may give
a clue
	/*
	 * If the BIOS is enabled on the 1542C/CF and BIOS options for support of drives
	 * > 1Gb, dynamic scanning of the SCSI bus or more than 2 drives under DOS 5.0 are
	 * enabled, the BIOS disables accepting Cmbinit to protect against running with
	 * drivers which don't support those options. In order to unlock the interface
	 * it is necessary to read a lock-code using Cextbios and write it back using
	 * Cmbienable; the lock-code is non-zero.
	 */

i think this was an addition after the cd-rom was cut.

--jim

SCSI woes.

[Lucio]

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.

SCSI woes.

[geoff]

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)?  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.

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.

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.

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).

SCSI woes.

[Lucio]

The Plug-and-Play (disabled) AHA1542CP adapter and Seagate ST12400N
drive combination that I have allocated to my future Plan 9 file server
causes PCFS to return zero heads and zero cylinders, the number of
sectors and bytes per track (3145968 (0x3000f0) and 1610735616,
respectively) also seem unreasonable:

hd0: 0 cylinders 0 heads 3145968 sectors/track 1610735616 bytes

This is then followed by, perhaps understandably:

adaptec0: invdcmd #01, len 5
scsiwait timed out
adaptec0: invdcmd #02, len 1

in various groupings; "can't read partition block" seems to be the
eventual prognosis.  I do get some

scsi?: cap 1, sec 0

messages as well, where the question mark above has been 0, 1, 2, 3 and
4 so far.

I'm going to rebuild PCFS with some additional debugging to see if I
can remedy the situation and get the file server running.  As I know
frightfully little about SCSI, any suggestions, recommendations and
labour/headache saving advice will be greatly appreciated.

Ha!  PCFS gave up after "scsi6: cap 1, sec 0" although I'm not
convinced that a register dump following "exception/interrupt 0" is
going to simplify my efforts much :-)
--
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.