[ On Thursday, September 23, 2004 at 16:16:27 (-0400), Greg A. Woods wrote: ]
> Subject: Re: port-alpha/21472 and kern/16379 (ohci/USB problems on Alpha)
>
> Re: kern/16379: Serious problems with the ohci driver on a DEC PWS 500au (Alpha)
> Re: port-alpha/21472: USB device interferes with IDE device; interrupt lossage
> 
> OK, so removing the USB devices from the kernel doesn't solve the
> problem well enough, at least not for 1.6.x on the ES40.

The work-around so far seem to be both removing the USB devices from the
kernel and being very careful to avoid ever accessing the CD-ROM or
anything else related to ISA IRQs.  (I installed a SCSI CD-ROM in order
to do the install from CD.)

Now as far as I can tell Tru64 UNIX identifies the exact same IRQs for
these devices, so the interrrupt lines appear to be routed correctly
when NetBSD starts.  Tru64 doesn't show the IRQ numbers when it boots
(and I can't figure out how to make the kernel more verbose on boot),
but from what I can tell from the header files

If anybody can point me to anything more specific about IRQ mapping in
Tru64 UNIX, let me know -- I've got a full test system at my disposal,
complete with the compiler and everything so far as I can tell.


One thing that's interesting though is that the ISA bus devices are not
reported by NetBSD as having an "isa irq", and neither are they
identified as "dec 6600 irq", but rather just a plain "irq":

	isa0 at sio0
	com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
	com0: console
	com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
	pckbc0 at isa0 port 0x60-0x64
	pcppi0 at isa0 port 0x61
	midi0 at pcppi0: PC speaker
	spkr0 at pcppi0
	isabeep0 at pcppi0
	fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
	fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec

Of course maybe these devices really are (also?) mapped to the same PCI IRQs?


At this point, given the "stray isa irq" messages it seems to me as if
the device drivers identify the right interrupt lines for themselves but
that these interrupts are never passed to the drivers when they happen
(or the drivers ignore them?) and thus they fall out as "stray".
I.e. they're happening, and we know the right numbers, but nobody's
listening.  Could it be so simple?

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>