Okay, cool.  It looks like I've wasted everybody's time.  The IRQ was failing when
processes were directed to /dev/sd1a and /dev/sd2a, but /dev/sd1c and /dev/sd2c refer
to the disks, as they should under NetBSD-alpha.

Next time I'll give it a week or so before I post  (hah!),
dhop

David Hopper wrote:

> Concerning direction to a so-called 'empty' controller, that's my error.  The boot
> messages reveal that isp1 is indeed the controller with the three disks; the IRQ
> mapping is still nutty, however.
>
> Thanks,
> dhop
>
> Jason Thorpe wrote:
>
> > On Tue, 14 Dec 1999 09:37:13 -0800
> >  David Hopper <dhop@nwlink.com> wrote:
> >
> >  > Dec 11 15:23:30 terran /netbsd: sd1: no disk label
> >  > Dec 11 15:24:58 terran /netbsd: isp1: command for target 2 lun 0 was aborted
> >  > Dec 11 15:24:58 terran /netbsd: stray kn300 irq 8
> >  > Dec 11 15:25:28 terran /netbsd: isp1: command for target 2 lun 0 was aborted
> >  > Dec 11 15:25:28 terran /netbsd: stray kn300 irq 8
> >  >
> >  > Could this be related to the recent changes to mcpcia.c to recognise the <3
> >  > PCI busses in the 1200 variant?  Is there cruft left over elsewhere from the
> >  > kn300 define that hasn't been updated?  (Armchair troubleshooting by a
> >  > nonprogrammer, there :)
> >
> > Seems obvious that the interrupt mapping is wrong.
> >
> > If the interrupt mapping code is using NetBSD device unit numbers instead
> > of real PCIA hose numbers, that's going to be a problem; the unit numbers
> > are totally arbitrary, and should not be used to determine locality on a
> > bus.
> >
> >         -- Jason R. Thorpe <thorpej@nas.nasa.gov>