Re: I/O bus reset to fix CMD MSCP controllers (and probably others)

On Sat, May 24, 2025 at 01:09:53PM +0200, Johnny Billquist wrote:
> I think the proper solution is to reset the controller in boot.

Yes, thats what I think too. But I don't think I can be bothered to
write close() entry points for every standalone driver that should have
them.

> If we are playing around with the mapping, we certainly might be messing up
> controllers, and that could possibly be an issue even if we later restore
> mappings back as they were. So at worst that just leaves the problem in
> place, but possibly makes it even more obscure.

Maybe, but then this is just restoring the way we handled the uba map
before the support for Qbus/Unibus memories was added, and I'm not aware
of the old behaviour having caused any problems before. So I'm not
convinced that these concerns should stop us from providing the
workaround in the kernel, if only for a limited time to provide a
working upgrade path.

The impression that NetBSD/vax has left on Robert with his VAX 4000/200
was "no release since 3.1.1 ever worked", caused by minor issues that
stopped it from booting. I've recently updated his system from 3.1.1 to
10.1 one step at a time, iterating through the last releases of each
branch since then. Twice I ran into a problem where the size of GENERIC
had increased beyond what boot supported, which wouldn't have caused
issues had the change to boot been pulled up into the previous releases.
-6 suffered KA660-specific panic, which also could have avoided had the
fix for it been pulled up. And of course this MSCP problem, which was
introduced in 2015 and first shipped in a release in 2018.

I see little point in assigning blame for that (other than to myself,
perhaps, for not having had time for NetBSD/vax for many years), but for
some reason I feel motivated to do better this time.

The change I'm proposing for the uba(4) driver in the kernel is intended
to serve as a workaround for this particular issue, and solely for the
purpose of providing a working upgrade path. Having this change in -10
will allow upgrading from a system that's still stuck on -7 or prior due
to this issue, and without requiring extra steps such as manually
upgrading boot. If we really want to, we can revert it after or perhaps
even before -11 branches, whenever that may be. Or perhaps we can not
even put it into HEAD, only straight into -10, provided that is
permitted by NetBSD's pullup rules.

> Interesting find. And something I never even thought about. But I can
> certainly see how this could be an issue with some firmware. It probably
> gets completely stuck in some loop trying to access memory.

That's what I thought. I suspect other controller's firmwares just do
better, or else we'd have caught that much earlier.


Hans


-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown