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

[Dave McGuire <mcguire%neurotica.com@localhost>]

On 3/28/25 11:01, 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 :-)

  I wonder if this is in any way related to the issue of CMD TMSCP tape 
controllers hanging when accessed?  It seems like an odd coincidence.

           -Dave

--
Dave McGuire, AK4HZ
New Kensington, PA