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

[Robert Doerfler <rodo%bloerp.de@localhost>]

> On 03/28/2025 4:01 PM CET Anders Magnusson <ragge%tethuvudet.se@localhost> wrote:
>
>
> Den 2025-03-28 kl. 15:28, skrev Johnny Billquist:
> > On 2025-03-28 15:05, Anders Magnusson wrote:
> > > Besides that, resetting the Unibus before autoconfig starts should do
> > > no harm, but there may be devices that takes a significant time to
> > > become ready after a ubareset (since ubareset should normally be
> > > something that is done i a quite controlled fashion). Don't know if
> > > that will affect any of the currently existing drivers.
> > I am sortof surprised that the CMD controller would have that kind of
> > bug. Even more so if this is a problem that only started appearing
> > after a certain version of NetBSD. But if it has been thoroughly
> > diangosed...
> > Anyway, one thing I know from the past is that some sloppy MSCP code
> > can fail to work on the CMD controller, but get away with it on the
> > DEC controllers. There was an example of that in 2.11BSD for the boot
> > loader that I had to fix. The normal driver was doing it correct, but
> > the code in the bootloader was not. Booting from an UDA50 worked fine,
> > but my CMD did not. I can dig up the exact details if needed. But I do
> > remember it was only a few bits that needed correction for things to
> > work right.
> Please do! It may solve the problem for the friend of Hans without
> having to reset the Unibus :-)
>

Well, actually - that was me, and this bug has already been discussed on this list before (see https://mail-index.netbsd.org/port-vax/2024/03/14/msg004949.html, March 13, 2024).

Out of pure curiosity, I tried reproducing the issue and was able to trigger it with every single NetBSD release after 3.1.1.

PS: The Unibus reset resolved the issue entirely on my setup.