Re: QVSS driver

[Felix Deichmann <m4j0rd0m0%gmail.com@localhost>]

2015-09-23 3:24 GMT+02:00 Charles Dickman <chd%chdickman.com@localhost>:
> I am curious if anybody did any testing with the qv driver recently
> added to the kernel.

Unfortunately not yet. My QVSS is still buried in a BA23 in the
basement, and I get/take new interesting machines in LIFO fashion at
the moment...

> This is arguably a bug in the driver too.

Looking at SIMH and the driver code, I'd say both have bugs:
SIMH's QVSS masks 16 bits for the interrupt controller and should be
fixed to reflect the real thing.
And as far as I understand, the driver doesn't use uh_lastiv cleanly.
uh_lastiv starts a contiguous pool at 0x200 as per uba.c. Its
decremented value ("next" value) is used by the "next" device using
programmable vectors. In qv.c, you do that, but rely on the hardware
to mask 8 bits, and don't write back the actual 8-bit value to
uh_lastiv. This will, more theoretically but well, lead to duplicate
vectors after the next 64 taken vectors.

Also, what I don't understand is why do you need two vectors from the
pool? The vertical retrace interrupt is only used for qv_match() but
disabled again, right? Only the DUART has its interrupt registered
then, so you could reuse the previous vector.

Having said that, I cannot find why our driver shouldn't work with a
virtual QVSS using 9-bit vectors as everything is handled more or less
automatically. Could you explain what exactly goes wrong?

BTW, is there a reason why the QVSS stuff alone is in arch/vax/uba/,
while QDSS and everything else is in dev/qbus/?

> I am packing up my VAXen and getting ready to move to a house with a
> 1600sqft basement that is all mine.

Wow, my machine room (storage alone) is a 4 m^2 (43 sqft) basement
section by now. For me selecting interesting and smaller stuff is the
key (and often hard). :)

Regards,
Felix