3a843d7cd3
Handling mailbox interrupts was broken in multiple respects, the combination of which was hiding the bugs most of the time. - The ibox interrupt mask was open initially even though there are no waiters on a newly created SPU. - Acknowledging the mailbox interrupt did not work because it is level triggered and the mailbox data is never retrieved from inside the interrupt handler. - The interrupt handler delivered interrupts with a disabled mask if another interrupt is triggered for the same class but a different mask. - The poll function did not enable the interrupt if it had not been enabled, so we might run into the poll timeout if none of the other bugs saved us and no signal was delivered. We probably still have a similar problem with blocking read/write on mailbox files, but that will result in extra wakeup in the worst case, not in incorrect behaviour. Signed-off-by: Arnd Bergmann <arndb@de.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org> |
||
---|---|---|
.. | ||
alpha | ||
arm | ||
arm26 | ||
cris | ||
frv | ||
h8300 | ||
i386 | ||
ia64 | ||
m32r | ||
m68k | ||
m68knommu | ||
mips | ||
parisc | ||
powerpc | ||
ppc | ||
s390 | ||
sh | ||
sh64 | ||
sparc | ||
sparc64 | ||
um | ||
v850 | ||
x86_64 | ||
xtensa |