BeOS Driver Tips and Tricks

This is meant to be a repository for all the knowledge people have learned the hard way while writing BeOS drivers. This is not light reading material. All material has been edited to keep the fluff to a minimum (.sigs, etc...)
From Simon Thornington:
Subject: Re: dev #3033: aliens generating interrupts?
  Date: Wed, 2 Apr 1997 17:02:59 -0800
  From: William Adams 

>Subject: Re: dev #3033: aliens generating interrupts?
>To: William Adams 
>Date: Wed, 2 Apr 1997 12:29:34 -0800 (PST)
>This message is generated when the processor get interrupted, but when
>it goes to look at the interrupt source register, none of the
>interrupt sources appear to be interrupting.
>This typically happens because of a device driver bug.  Once common problem
>is that the device driver's interrupt handler is calling
>release_sem instead of release_sem_etc with the DO_NOT_RESCHEDULE
>flag set, and then doing something to clear the interrupt on the
>actual device hardware.  Since calling release_sem does in fact cause
>a reschedule, the interrupt handler will continue running 'later', possibly
>even on another processor (on beboxes and MP macs).  If the device in the
>meantime has another interrupt ready, and the interrupt handler then clears
>the interrupt, you lose an interrupt!
>If the clearing happens at just the right time, i.e after the device has
>generated the interrupt causing the cpu taking i.o interrupts to be
>interrupted, but before that cpu can read the interrupt source register,
>you get the wonderful 'ALIENS...' message.
>>Anyone want to comment on this.
>>-- William
>>>Date: Tue, 1 Apr 1997 20:53:32 -0500 (EST)
>>>Subject: dev #3033: aliens generating interrupts?
>>>From: Simon Thornington 
>>>I just got a message on serial4 as follows:
>>>I wouldn't think anything of it, except that I am writing a device
>>>driver and have been having problems with interrupts that don't appear
>>>to be from me.  What does this message mean?

Page maintained by Mike Perham (