> I made a snapshot of NetBSD-current for the i386 yesterday, and I just put it
> up for FTP at:
> 
> 	ftp://ftp.netbsd.org/pub/NetBSD/arch/i386
> 
> The files in there should be pretty explanatory; the .fs files are disk image
> There is now only one "kernel-copy" disk image, which will work with all of
> the disk controllers supported by -current.  [...]
> 
> Enjoy!  Tell me how it works.  (There are known bugs, but if the snapshot is
> "completely broken", I'd like to know so I can see what I can do about it.

Well, now count me in with the "doesn't work for me" crowd.  The kernel from
the inst-1.0A.fs floppy boots, but it starts seeing double and instead of
seeing just my Adaptec 1542CF, it claims to see a phantom BusLogic BT742 (I
guess) at the same port #, IRQ and DRQ.  It then gets real unhappy with not
being able to find/see anything from this phantom BusLogic card:

... [scrolled off-screen initial boot messages] ...
real mem = 16646144
avail mem = 14524416
using 228 buffers containing 933888 bytes of memory
isa0 (root)
com0 at isa0 port 0x3f8-0x3ff irq 4: ns82450 or ns16450, no fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns82450 or ns16450, no fifo
lpt0 at isa0 port 0x378-0x37f irq 7
[ Here's the good Adaptec probe info ]
aha0: 1542C/CF detected, unlocking mailbox
aha0 at isa0 port 0x330-0x333 irq 11 drq 5
scsibus0 at aha0
aha0 targ 0 lun 0: <SEAGATE, ST21200N, 8630> SCSI2 0/direct fixed
sd0 at scsibus0: 1006MB, 2700 cyl, 9 head, 84 sec, 512 bytes/sec
aha0 targ 4 lun 0: <TOSHIBA, CD-ROM XM-3401TA, 1094> SCSI2 5/cdrom removable
cd0 at scsibus0: drive empty
aha0 targ 5 lun 0: <EXABYTE, EXB-8200, 253X> SCSI1 1/sequential removable
st0 at scsibus0: drive empty
[ Here's the bogus phantom BusLogic probe info ]
bt0 at isa0 port 0x330-0x333 irq 11 drq 5 bt0: bt_cmd, cmd/data port full
: version B.0, bt-127424496: bt_cmd, cmd/data port empty 7
bt0: bt_cmd, host not idle(0x20)
async, no parity, 0 mbxs
bt0 targ 0: sync, offset 1, period 200nsec
scsibus1 at bt0
probe(bt0:0:0): timed out
bt0: not taking commands!
panic: should call debugger here (bt742a.c)
hit reset please

All of the messages relating to the Adaptec and the targets seen on scsibus0
are genuine and correct.  There is however no BusLogic card in the system
whatsoever, so all of the bt0/scsibus1 messages are bogus.

I noticed that the "INSTALL" kernel config that Chris mentions as being the
source for the snapshot kernel contains

aha0    at isa? port 0x330 irq ? drq ?  # Adaptec 154[02] SCSI controllers
...
bt0     at isa? port 0x330 irq ? drq ?  # BusLogic [57]4X SCSI controllers
...
uha0    at isa? port 0x330 irq ? drq ?  # UltraStor [13]4f SCSI controllers

So apparently the presence of the "real" Adaptec 1542CF is fooling the
BusLogic "btprobe" probe (really "bt_find") into thinking there's one there,
but it's certainly not fooling the UltraStor "uhaprobe" driver probe.
(Then again, wasn't a goal of the BusLogic stuff to be Adaptec-compatible at
 one point?)

I now suspect there's good reason why /usr/src/sys/dev/isa/bt742a.c::bt_find() 
contains

	switch (info.bus_type) {
	case BT_BUS_TYPE_24BIT:
		/* XXXX How do we avoid conflicting with the aha1542 probe? */

I guess I'm curious as to why the 1.0 kcaha-1.0.fs kernel seems to be able
to recognize the Adaptec without also thinking there's a BusLogic board at
the same port/IRQ/DRQ there as well, whereas this -current kernel doesn't?

I'm assuming most folks with this model Adaptec would probably be using these
default(?) Port/IRQ/DRQ settings, so wouldn't this be happening to just about
everyone?

HTH,

	- Greg