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

On 2025-03-28 16:53, Dave McGuire wrote:
> 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.

Not at all impossible. I know that under RSX, as well as 2.11BSD, CMD 
controllers (as well as TMSCP CMD) are running just fine.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol