Bernd, Actually thinking about it why do we even bother switching the LVL5 handler, why not just poke a value some place to say that its a deferred exception v.s. a hardware exception? I understand the referral but why do we bother installing the handler in a dynamic way? I'm confused on this seems odd too me.
Marc Bernd Schmidt writes: > Marc Hoffman wrote: > > > 2. hardware dispatches to ex_trap_c unless otherwise handled > > 3. ex_trap_c, modifies the LVL5 hardware event handler so no > > hardware events can occur until the exception finishes (correct)? > > then the exception is deferred to LVL5. > > Actually it's only modified so that we can transfer control from an > exception context to an interrupt context. It's restored immediately in > _exception_to_level5. > > We can't really run kernel code in an exception context, so we chose > IRQ5 as it's the highest-priority interrupt and can't be interrupted > other than by another exception. This only happens for actual > exceptions though: for things like syscalls, we transfer to a > low-priority IRQ15 context which can be interrupted. > understood and that is the intent, of the architecture. > > CPLB faults must be handled in an exception context since they can arise > from kernel code running in an IRQ5 context. The handler code for this > must be written with special care so as to not cause additional exceptions. > and thats a real challenge seems like it works pretty robust to me I haven't seen a double fault yet. :) > > > Bernd > -- > This footer brought to you by insane German lawmakers. > Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen > Registergericht Muenchen HRB 40368 > Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough _______________________________________________ Uclinux-dist-devel mailing list Uclinux-dist-devel@blackfin.uclinux.org http://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
