> From: nathanw@mit.edu (Nathan J. Williams)
>
> <cgd@netbsd.org> (Chris G. Demetriou) writes:
>
> > Jason R Thorpe <thorpej@zembu.com> writes:
> > >  > * What's up with the interrupt line having a bad value? I'm wondering
> > >  >   if SRM is just bypassing device 7, since it's mostly used in Digital
> > >  >   Unix for the IDE controller, which has the wacky ISA-compat
> > >  >   interrupts and I/O mapping. 
> > > 
> > > It could be that, or it could be encoded to indicate which ISA IRQ its
> > > using.  Dunno for sure.
> > 
> > perhaps only a numerological trick, but:
> > 
> > he said SRM claimed it was IRQ 10 in the isacfg table, and that it had
> > line 234 in the device line field, right?
> > 
> > 234 -> 0xea -> 0xe << 8 + 10.
>
> A bunch of other people have made this speculation. I'd love to see
> some actual confirmation, but meantime I patched up pci_550.c assuming
> that it's true, and now I have working USB on the PWS500au.
>
> The patches still need work. My basic idea was to check if the
> given interrupt line is between 0xe0 and 0xef, and call
> sio_intr_*. This is fine for _intr_map and _intr_establish, but for
> _disestablish I need some way to distinguish a dec_550 intr cookie from a
> sio intr cookie, and I haven't found a good mechanisim yet. 


Sigh, look at line 147 of alpha/pci/pci_6600.c. When I did the EV6
port the USB host bridge had 0xea in its PCI LINE register as well.

	ross