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

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