[MiNT] CT2 Bus errors with mint

[Maurits van de Kamp <maurits@bassment.demon.nl>]

Hiya :)

Well, I have a working Falcon/CT2 now, and I can use Cubase Audio with
it so at least I can live. :) Now I am still stuck with the problem that
in turbo mode, buserrors appear (seamingly random) during MiNTos bootup.
Centek, in their famous arrogance, just blame MiNT (ooh mint gives lots
of trouble with the ct2) and that's that, so I'll have to do some
investigating myself before I can convince them that the hardware is at
least PART of the problem.

The buserrors appear at several different moments in several different
processes. (Mostly the error is reported to be caused by init or sh.)
One extra oddity, is that every time a buserror has occurred (anytime)
during the boot, n.aes will lock up after the start message. Everything
else works, but n.aes won't start. I can change my ttytab to start a
getty on the console, kill n.aes, and then I can login on the console,
all works fine, but starting n.aes won't work until I reboot.

The strangest thing is that this will only happen during (or shortly
after) boots. When the machine is up and running including n.aes, it's
rock solid. The buserrors only occur during the parsing of mint.cnf or
the rc-files, or straight after the boot - a buserror in bash right
after I login. I thought it might have something to do with the strong
HD- and memory activity during boot. However, I interrupted the boot by
putting "exec u:\usr\bin\bash" in mint.cnf, and then waiting a while
when this shell starts, and then typing exit to continue the boot. Still
buserrors will hapen after this interruption, or even in the shell
itself.

I don't expect answers from just this information (would be nice though)
;) but I'd like some help to get started on some further investigation:

1. What MiNT-version is most stable with the ct2 for other ct2-users? 

2. Do I remember it right that a buserror can also mean a hardware
failure (bus timeout)?

3. How can I look at what exactly causes the buserror? I tried running
mintnp.prg from MonST, but it doesn't interrupt the program flow on the
moment of the error, probably because they're never caused by mintnp.prg
itself. I'd like to be taken to a monitor screen on the moment of the
crash and then see whether the code really did something illegal (ie a
register had a weird value). If not, I can send the motherboard straight
to France and tell Centek to get off their butts. ;)

Thanks for any help!

Maurits.

---

iMac - Whinegums without the taste