A cautionary tale: trying to be 'too smart' with interrupts

[roondar]

Originally Posted by ross

Yes.
There could be a 'blitter storm' because of tiny blits or slow CPU response or bus hogged, but only before the queue is emptied,

Indeed, I could understand those problems given what we've talked about. Those would also cause oddities and weird behaviour. Just different ones.

and certainly a 'blitter overlap' can not happen like experienced by roondar.
So probably something is wrong elsewhere and i'm very curious about it.

Indeed, I am very curious myself. Part of me thinks that phx's suggestion that something else touches the Blitter or the Blitter finished flag would explain everything, but I just don't think that actually happens. I'll be sure to do a search on all source code to see if I missed something, but what bothers me about that idea is that this is a new development (as in, it only recently started crashing). And I happen to know that the new code I've added definitely does not do it's own Blitting or interrupt handling.

Anyway, I'll give some of the ideas here a try later tonight and let you know how it goes. Maybe I can find the problem with some renewed effort and a bag of tips and tricks.

Still 99% sure I must be doing something silly somehow, somewhere. Now to find it!

[grond]

If it was just that the RTE came too soon after the IRQ-ACK, then how come the original Commodore devs found this problem and had the fix in the kickstart? I don't think it is likely that the OS interrupt handlers exit that fast after the IRQ-ACK. An 040 was fast but not that fast.

[roondar]

On the A4000/68040/68060/Vampire interrupt ACK problem, I remember a recent thread where Toni Wilen wrote about this. Here is what he had to say about it:

Originally Posted by Toni Wilen

Problem is Paula being slow, it needs one more CCK after INTREQ/INTENA write before it changes IPL lines (if RTE finishes during that extra CCK, CPU still sees old interrupt active and it can happen if all the stacked data is in caches).

This is from: http://eab.abime.net/showpost.php?p=...4&postcount=11

IIRC he's made similar comments in the past, so I guess the problem really is Paula being slow and the second ACK is used just to delay the CPU long enough to not trigger this issue.

[Kalms]

This might be relevant: http://eab.abime.net/showthread.php?t=91412

Snippet from our blitter interrupt handler after that thread discussion:

;----------------------------------------------------------------------------------
; Level3 / blitter interrupt callback
;   should be called by the level3 handler in order to trigger multiple consecutive blits

InterruptDrivenStandardBlits_level3BlitterCallback

		; Hack: Sometimes, some OS code can trigger a blitter interrupt.
		; We have observed this happening on KS1.3 when the CIAB TOD counter
		;   triggers an alarm (when counter goes $fff -> $1000, a hardware glitch
		;   makes the counter read out as $000000 for a few cycles, and the comparison
		;   value is set to $000000 - this results in a Lev6 interrupt being signalled).
		; The OS Lev6 interrupt handler does some work, and ends with
		;   writing $8040 to INTENA and INTREQ.
		; It probably does this because it gets confused and thinks it is time
		;   to activate the QBlit blitter queue logic.
		; It does this even if the application has called OwnBlitter.
		; This can happen in the middle of an ongoing blit operation.
		; To protect against such spurious interrupts, we will test whether there is
		;   a blit currently in-progress and, if so, not do anything blitter related
		;   within this interrupt handler.
		; The BLTDONE bit is set while a blit is in-progress.

		btst	#DMAB_BLTDONE-8,$dff000+dmaconr
		bne.s	.blitInProgress
		...
.blitInProgress
		rts

[roondar]

@Kalms: that is a very interesting and partially scary bit of information... It wasn't what was going wrong, but thanks for the info!

@Thread:
I fixed it

This is in no small part due to all your hints and tips, so thanks all of you here at EAB - you've been very helpful!

---
For those who want to know the final problem and solutions:
There were two problems in my code. The first was the double acknowledge. It caused the Blitter queue to inevitably stop running after a random amount of time had passed by allowing higher level interrupts to run in between the two acknowledge writes. This code would take longer than the blit and thus, the queue would break.

I had never noted this before, because my earlier blits were fairly big and thus even a relatively long higher level interrupt would fit in the time of the blit.

The second problem was the Blitter interrupt being triggered while. Well, as it turns out, phx gave the conclusive hint here when he questioned whether or not that was triggered elsewhere in my code. I checked all my code and found a botched attempt at an atomic action in my non-interrupt code. During this bugged code, I disabled interrupts - but first read their state in INTREQR. Then when re-enabling interrupts, I also wrote back those earlier values.

I have no idea why I did that, but it sure as <explicative> wasn't the right thing to do . That code could (and in indeed did) get interrupted right after the read of the interrupt status but before they were actually disabled. So, in rare situations, the CPU would read the INTREQ value containing the Blitter interrupt triggering just before the interrupt was actually serviced. And write this value back into INTREQ during a blit after the blitter interrupt rte'd. And boom was the result.

It's all quite logical if you understand how the 68000 and Amiga deal with interrupts, but I clearly didn't when I wrote this code and it caused all this mayhem. In my defence, the bit of code that crashed was two years old

As to why it didn't happen before? Well, that was just pure luck and nothing more. Sooner or later, this code would've crashed the machine. The above rarity is also why changing unrelated code would make the problem appear/reappear - as the timing changed, it became either more or less likely that the above situation could trigger.

---
The fixes are:
1) disable interrupts and re-enable interrupts during the main program without reading and then afterwards writing the interrupt request value.

2) use one interrupt acknowledge write, at the start of the Blitter handler rather than at the end.

I've done both and the program just works now. No more mysterious behaviour. Again, thanks to all who assisted - I learned some new things and now have better idea how to debug these things should they happen again. Should the code for the fixes be valuable, I'd be happy to share it - though it is fairly simple in the end.

[hooverphonique]

I see a potential problem..

I think

btst	#6,intreq+1(a6)

should be

btst	#6,intreqr+1(a6)

;-)

[roondar]

Ah, that is a typo in the copy I made for the thread. The actual code does indeed btst on intreqr+1

[hooverphonique]

Originally Posted by roondar

Ah, that is a typo in the copy I made for the thread. The actual code does indeed btst on intreqr+1

Be careful to modify code, you post to get help, to such a detailed degree - you may hide the problem(s) from the people you're asking

[roondar]

Originally Posted by hooverphonique

Be careful to modify code, you post to get help, to such a detailed degree - you may hide the problem(s) from the people you're asking

Indeed, you are correct here - a direct copy would've been better.