id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	field_blocks	field_dependson	field_seealso
243	ppc32 exception handling broken	Jakub Jermář	Martin Decky	"This problem is described in [http://lists.modry.cz/cgi-bin/private/helenos-devel/2010-May/006343.html this] mailing list thread.

Excerpt from symptoms:

{{{
On PowerPC I sometimes trigger the assertion

        PREEMPTION_DISABLED in preemption_enable() with stack trace:
           preemption_enable()
           event_is_subscribed()
           putchar()
           vprintf_str_write()
           printf_core()
           vprintf()
           printf()
           waitq_sleep_timeout()
           _semaphore_down_timeout()
           _mutex_lock_timeout()
           pt_lock()
           page_table_lock()
           pht_refill()
           exc_dispatch()

    and

        (!PREEMPTION_DISABLED) || (PARAM_NON_BLOCKING(flags, usec)) with
        stack trace:
           waitq_sleep_timeout()
           _mutex_lock_timeout()
           pt_lock()
           page_table_lock()
           pht_refill()
           exc_dispatch()

}}}


Initial assesment by Martin:

{{{
I believe that I already know the reason for the problems on ppc32: The 
code does not respect the assumption that the THE structure must be 
always valid, even in the interrupt context.

The reason lies in the complicated exception handling mechanism where 
all memory virtualization is turned off. Thus you cannot use the 
thread's original stack for storing the context (because generally you 
don't know where in the physical memory the kernel stack is).

Currently we use a dedicated kernel stack, which certainly does not 
contain the THE structure. Suprisingly this worked fine for many years 
until your changeset 434 where you added the !PREEMPTION_DISABLED 
assertion. Even more suprisingly this was probably the first time the 
exception code started to touch the THE structure.
}}}
"	defect	closed	critical	0.5.0	helenos/kernel/ppc32	mainline	fixed	sashimi_regression			#343