Re: Profiling a murderer
- From: "Tim Clarke" <SpamBlock_MonetaimCom@xxxxxxxxxxxxx>
- Date: Thu, 04 Aug 2005 13:24:36 GMT
> > None of the Tribble, Spock nor Corvette "take over" the bus
>
> In the test setup there are two adapters, the planar SCSI is disabled and
> the add-on enabled, and there is one SCSI bus.
There's still the MCA bus for I/O to/from the chipset(s) don't forget.
> > (just like you can have multiple XGA & XGA/2 adapters installed)
>
> Identified by the XGA Instance.
Which is a shorthand way of specifying and I/O port range, amongst other
things.
> > so you get multiple responders for an " IN AL,port "
> > instruction, causing problems on the bus in that way. Just my thoughts.
>
> Identified by the SCSI "I/O Address", SysConfig assigns unique addresses
to
> planar SCSI and Corvette in Mod. 77, so that should not happen?
But, if the "planar Spock" is logically disabled, SysConfig MAY NOT believe
that those I/O addresses should be treated as "still reserved" . In that
case, if the chipset still decodes and responds to I/O to those ports AND
you happen to have configured the Corvette to the same I/O ports, (due to
SysConfig not being aware that "Disabled" for the "planar Spock" may not
mean TOTALLY deactivated) you could end up with multiple responders to I/O
to those ports. Am I any clearer now?
> With planar Spock disabled and Corvette + new HD, the first boot reports
> "Adapter Busy" for Spock (00096701U 181S), then auto-config finds out
error
> in FRU of a SCSI device and sets the FRU [of the test Barracuda] to 0. The
> FRU procedure is skipped when the initial planar Spock HD is connected to
> Corvette.
>
> This suggest that auto-config detects at a certain checkpoint the new SCSI
> device. The other question is how the individiual IBM SCSI adapters in a
> multiple SCSI adapter config gather information about the configuration.
A planar with "built-in SCSI chipset" MUST have code to configure and
operated the "logical adapter" and any connected devices. This will
reference the planar's Extended CMOS and POS bytes, which will be known to
it. However, a BIOS ROM on an (e.g. Corvette) adapter WILL NOT know about
"Planar SCSI" and the extended CMOS and POS layout and usage. In this case,
IIRC, BOTH the system BIOS and Corvette BIOS will be vying for control of
all adapters with IDs in that "special" 0x8nnn-0x8FFF range. If the system
BIOS is "controlling" the Corvette, then you have "old code" managing a
"newer adapter", but it WILL know that the planar SCSI is "Disabled". If the
Corvette BIOS has control, the you have "newer BIOS", BUT it knows damn-all
about the why's and wherefores of the planar SCSI chipset.
> Only one BIOS will be enabled, the adapter in the lowest numbered slot
will
> be selected as the boot host adapter. Multiple AHA-1640 work with a
certain
> I/O address convention in such a case and you can select which adapter
BIOS
> to disable.
With PS/2's with on-planar SCSI this IS NOT THE CASE, nor is it the case for
8595 and 9595 complexes (which is why SysConfig shows "No resources
configured" in the BIOS address range on these systems, the SYSTEM BIOS
knows to deactivate the adapter ROM BIOS for those "special" IDs.. The SCSI
BIOS is effectively in the SYSTEM BIOS. This MUST ALSO be the case for
systems with on-planar SCSI and the additional POS info. that relates
thereto.
> A dump of Corvette's init C8EFC.ADF shows repeated scans of certain memory
> regions and far calls, but this dump does not show the register contents
and
> I did not single-step.
>
> I know, it is not really needed to disable the planar SCSI but it is an
> interesting experiment. Suggestions, speculations are welcome.
It's my guess that it's a case of either fix the SYSTEM BIOS to prevent it
from controlling anything other than its own SCSI chipset, or get out the
logic probe and check if the on-planar SCSI really is DISABLED and totally
inactive when so configured.
--
Regards,
Tim Clarke (a.k.a. WBST)
.
- Follow-Ups:
- Re: Profiling a murderer
- From: UZnal
- Re: Profiling a murderer
- References:
- Profiling a murderer
- From: Louis Ohland
- Re: Profiling a murderer
- From: William R. Walsh
- Re: Profiling a murderer
- From: UZnal
- Re: Profiling a murderer
- From: wm_walsh
- Re: Profiling a murderer
- From: UZnal
- Re: Profiling a murderer
- From: Tim Clarke
- Re: Profiling a murderer
- From: UZnal
- Profiling a murderer
- Prev by Date: Re: SCSI mission impossible
- Next by Date: Re: Reliable and easy to install and use KVM switch
- Previous by thread: Re: Profiling a murderer
- Next by thread: Re: Profiling a murderer
- Index(es):
Relevant Pages
|
Loading