| that probed SB just like above, but with IRQ 10 instead of 9, and

  I have exactly the same problem. First, it tried to put the sb
on IRQ 5, sharing interrupt with my third com, then it put it on
IRQ 9, which gave me a non-functional sb.

  The patch below -- while it does not correct the problem --
at least provides a possible workaround. You can put an
"options ISAPNP_ALLOC_INTR_MASK=0xfc00" in your kernel config,
and it will hand out IRQ 10 to the sb.

  No idea whether this is TRT though...

	mjl



===================================================================
RCS file: /cvsroot/src/sys/dev/isapnp/isapnp.c,v
retrieving revision 1.33
diff -a -b -u -r1.33 isapnp.c
--- isapnp.c	1999/03/22 09:38:58	1.33
+++ isapnp.c	1999/03/23 23:02:59
@@ -259,7 +259,12 @@
 		return 0;
 	}
 
-	if (isa_intr_alloc(ic, i->bits, i->type, &irq) == 0) {
+#ifndef ISAPNP_ALLOC_INTR_MASK
+#define ISAPNP_ALLOC_INTR_MASK (~0)
+#endif
+
+	if (isa_intr_alloc(ic, ISAPNP_ALLOC_INTR_MASK & i->bits,
+			   i->type, &irq) == 0) {
 		i->num = irq;
 		return 0;
 	}