|Subject:||Re: Got trap No.23 when booting mips32 ?|
|From:||David Daney <email@example.com>|
|Date:||Thu, 22 Oct 2009 09:03:05 -0700|
|Cc:||"Kevin D. Kissell" <firstname.lastname@example.org>, Sergei Shtylyov <email@example.com>, firstname.lastname@example.org|
|References:||<email@example.com> <4ADF32D1.firstname.lastname@example.org> <email@example.com> <4ADFAC5E.firstname.lastname@example.org> <email@example.com>|
|User-agent:||Thunderbird 22.214.171.124 (X11/20090320)|
2009/10/22 Kevin D. Kissell <firstname.lastname@example.org>:wilbur.chan wrote:Kernal didn't resgister IRQ 23 when booting. Hmm....the only '23' number I can find in kernel is in traps.c. Why a 23 IRQ was triggered?The usual reason would be a failure to correctly initialize an interrupt controller, or the Status.IM mask field. The kernel complains precisely *because* IRQ 23 wasn't registered, but an interrupt was nevertheless delivered that was decoded as being that IRQ. Regards, Kevin K.Thanks for your suggestion. And I found that , as a matter of fact , kernel has registered No.23 as a trap. In trap_init : /* 1419 * Only some CPUs have the watch exceptions. 1420 */ 1421 if (cpu_has_watch) 1422 set_except_vector(23, handle_watch); So, if a No.23 "signal" happened , kernel should invoke handle_watch instead. But why here kernel complained ? and why kernel entered the IRQ branch (do_IRQ) rather than trap branch?
You still don't understand. You are not getting the watch exception. The '23' you see is not at all related to the exception code in the C0_cause register.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH -v4 9/9] tracing: add function graph tracer support for MIPS, David Daney|
|Next by Date:||Re: [PATCH -v4 9/9] tracing: add function graph tracer support for MIPS, Steven Rostedt|
|Previous by Thread:||Re: Got trap No.23 when booting mips32 ?, wilbur.chan|
|Next by Thread:||Re: Got trap No.23 when booting mips32 ?, David VomLehn|
|Indexes:||[Date] [Thread] [Top] [All Lists]|