Follow up on DMA related crashes

[Steven Hirsch]

Hi, Joerg.

I have some information that may help you figure out the underlying
problem. On a hunch, I installed a DEC SLU board in the system and used
that for the console instead of emulating it on the QBone.

With this done, the crashes appear to be gone! I've been able to run a
full fsck under 2.11 BSD many times in a row without incident. Previously
it would make through a single operation only about 1 in 5 tries.

One thought: How do you arrange interrupt and DMA priority when multiple
devices + memory are emulated in the QBone? Is it possible there's some
confusion when the console device is added to the mix?

It's not a huge problem to run with a real SLU, but it does seem like the
combination of MSCP controller, memory and emulated serial port should
work.

Steve

[Joerg Hoppe]

Steve,

thats a big success, thank you.
Sorting the different Interrupts and DMA request is one complex task in
the software.
I'll try to reproduce your setup ... perhaps after Xmas, when the dust
settles.

As I understand, you operate just an M8192 and the original 2.11BSD
script from QBones SDcard.
Can you give the failing "fsck" call ... I think mounted root / can not
be checked?

kind regards,
Joerg

[Steven Hirsch]

On Wed, 14 Dec 2022, Joerg Hoppe wrote:

> Steve,
>
> thats a big success, thank you.

> Sorting the different Interrupts and DMA request is one complex task in
> the software.

I'm sure it is - but my guess is that something is tangled. Hopefully it
can be found.

> I'll try to reproduce your setup ... perhaps after Xmas, when the dust
> settles.

> As I understand, you operate just an M8192 and the original 2.11BSD
> script from QBones SDcard. Can you give the failing "fsck" call ... I
> think mounted root / can not be checked?

It can be done from single-user mode. The fsck program creates a scratch
file and unmounts the root filesystem before checking. Just issue, e.g.

# fsck /dev/ra0a

Tell it 'Y' to any and all questions.

Hardware in the system is an M8192 11/73 CPU and the QBone - nothing else.
The cmd file I use is in my earlier post.

One observation: When running the 'master' branch of your software, the
lockups always trigger the assert crash I posted earlier. When using the
'beta' branch, the lockups still occur but there is no assert. The QBone
environment '>>>' still responds to 'Enter', but freezes up if you try to
actually execute a command and must be killed with Ctrl-C. Perhaps this
is a clue?

Enjoy your holidays and let me know if you have any questions when you do
find time to test?

Steve

>
> kind regards,
> Joerg
>
>
>> Hi, Joerg.
>>
>> I have some information that may help you figure out the underlying
>> problem.  On a hunch, I installed a DEC SLU board in the system and used
>> that for the console instead of emulating it on the QBone.
>>
>> With this done, the crashes appear to be gone!  I've been able to run a
>> full fsck under 2.11 BSD many times in a row without incident.  Previously
>> it would make through a single operation only about 1 in 5 tries.
>>
>> One thought:  How do you arrange interrupt and DMA priority when multiple
>> devices + memory are emulated in the QBone?  Is it possible there's some
>> confusion when the console device is added to the mix?
>>
>> It's not a huge problem to run with a real SLU, but it does seem like the
>> combination of MSCP controller, memory and emulated serial port should
>> work.
>>
>> Steve
>>
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "UniBone" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to unibone+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/unibone/49473174-9a8d-3345-0e3a-25647df2b172%40gmail.com.
>