In early January, I requested assistance for a SCSI problem, and I seem
to have fixed it, so I want to document how, for the record.  Here was
my problem:

I had a stable Pentium 166 running NetBSD 1.4.1, with a PCI SCSI adaptor
and a bunch of disks.  I decided to upgrade to a Pentium III 866, but
the SCSI board (an Adaptec AHA-2940U) refused to work properly in the
new system.  In particular, the system took over a minute to go through
its hardware-level start-up (between installing the SCSI BIOS and showing
the "big rectangle" screen listing the hardware configuration and IRQs).
Then, while booting, NetBSD reported this kind of stuff:

  probe(ahc1:0:0): SCB 1d - timed out in Message-out phase, SEQADDR ==
    0xbb SCSIRATE == 0x0
  probe(ahc1:0:0): BDR message in message buffer
  probe(ahc1:0:0): SCB 1d - timed out in Message-out phase, SEQADDR ==
    0x153 SCSIRATE == 0x0
  probe(ahc1:0:0): no longer in timeout, status = 0
  ahc1: Issued Channel A Bus Reset. 1 SCBs aborted

Over a period of many hours, I had tried the SCSI controller in each
of the three PCI slots on that motherboard, and I had changed the PROM
settings to enable or disable various onboard devices (to try to solve
IRQ conflicts).  I had tried to boot a 1.4.1 floppy, a set of 1.5.2
floppies, and my 1.4.1 system on disk (and even a couple of Slackware
Linux floppies!).  All had reported SCSI timeouts.

After some discussion on this list at the time, I was at this point:

>   (1) This SCSI board *should* work on my Pentium III system.
>   (2) At least one person has had a similar problem which was solved
>       by using a different motherboard.  Not entirely clear whether
>       that was a case of flaky motherboard or the motherboard tickled
>       a bug in the O/S.
>   (3) The fact that my system occasionally hangs in hardware boot
>       while identifying the devices suggests a hardware problem.
>   (4) It is possible that a BIOS upgrade (of the SCSI card?) would
>       help.  I will check the web site to see what is suggested.
>   (5) However, there is also a known problem in NetBSD which resembles
>       the one I report.  One person has seen Linux handle his
>       problematic configuration correctly (whereas Linux 2.4.5 reports
>       timeouts for me).  FreeBSD is thought to have the best driver
>       for this SCSI board.  I will try to boot with FreeBSD and see if
>       the problem goes away.
> 
> I'll report back when I have news; in the meantime, I'll still monitor
> here in case people here have more to say.  Many thanks to all of you
> who answered my questions.

Well, Adaptec's web site had pretty much zilch on the AHA-2940U,
and the appearance of that part number in lists also containing
"AHA-2940", "AHA-2940UW", and "AHA-2940 Ultra" suggests they they are
not the same.  I tried to register the product to be able to ask a
question on their "A.S.K." service, but the product seemed to be too
old to register.

However, reading Adaptec's A.S.K. answers gave me some ideas concerning
Plug and Play, and it told me something I didn't know: all PCI slots
are not necessarily equal, and some controllers need to be placed in
a "bus master slot" (I didn't know PCI had such things).  Of course,
my motherboard documentation had nothing at all on this.  It turns out
that this allows the SCSI controller to work on my motherboard:

  (1) In the CMOS "set-up", set "plug-and-play aware O/S" to "No".
  (2) Do not use slot 2 for the SCSI adapter; slot 3 works.  (I did
      not try slot 1 because it is blocked by the motherboard's
      modem port add-on mini-card.)

This gives both the SCSI card and the onboard ethernet controller the
same IRQ (11), but nevertheless the system seems to be working, even when
I use a SCSI disk and the network at the same time.  (That motherboard
gives me essentially no real control over IRQs.  Harumph.)

I'm now going to finish assembling this system, and I'm going to move
most of the O/S from the IDE disk to the SCSI disk.  If any further
oddities crop up, then after I retrieve whatever I end up throwing out
the window in a fit of frustration, I'll report here.  If I don't
follow up, then the measure described above was sufficient.

Thanks again to all who helped!

Anne.
-- 
Ms. Anne Bennett, Senior Analyst, IITS, Concordia University, Montreal H3G 1M8
anne@alcor.concordia.ca                                        +1 514 848-7606