Got trap No.23 when booting mips32 ?

Got trap No.23 when booting mips32 ?

[wilbur.chan]

Hi all,


I've got some problem when booting mips32.


I got a No.23 trap when calling start_kernel --->  local_irq_enable :


irq 23, desc: 802a98a0, depth: 1, count: 0, unhandled: 0
->handle_irq():  80148c6c, handle_bad_irq+0x0/0x2b4
->chip(): 8029f738, 0x8029f738
->action(): 00000000
  IRQ_DISABLED set
unexpected IRQ # 23


No.23 trap is a Watch trap, which means that, when

"Physical address of load/store matched enabled value in


WatchLo/ WatahHi registers." happened, a No.23 trap was triggered by cpu.


So I used macro

__u32 watch_regh0= read_c0_watchhi0();
__u32 watch_regl0= read_c0_watchlo0();

to retrieve value from WatchHi and WatchLo,found them 0x1 and 0x0
respectively,which mean that ,

'r' together with  'w' bits were set to zero and no trap should be triggered.


But now , I got a 23 trap, why ?


At last , I used  to set WatchHi to 0x0, but failed , found it  still 0x1 after

calling write_c0_watchhi0(0)


Any suggestion would be grateful.

regards

Re: Got trap No.23 when booting mips32 ?

[David Daney]

wilbur.chan wrote:
> Hi all,
> 
> 
> I've got some problem when booting mips32.
> 
> 
> I got a No.23 trap when calling start_kernel --->  local_irq_enable :
> 
> 
> irq 23, desc: 802a98a0, depth: 1, count: 0, unhandled: 0
> ->handle_irq():  80148c6c, handle_bad_irq+0x0/0x2b4
> ->chip(): 8029f738, 0x8029f738
> ->action(): 00000000
>   IRQ_DISABLED set
> unexpected IRQ # 23
> 
> 

IRQ != c0_cause.ExcCode

You should look up your kernel's IRQ to  interrupt source mapping to see 
what is connected to IRQ 23.

David Daney

Re: Got trap No.23 when booting mips32 ?

[wilbur.chan]

2009/10/22 David Daney <ddaney@caviumnetworks.com>:

> IRQ != c0_cause.ExcCode
>
> You should look up your kernel's IRQ to  interrupt source mapping to see
> what is connected to IRQ 23.
>
> David Daney
>

2009/10/22 Sergei Shtylyov <sshtylyov@ru.mvista.com>:
>> No.23 trap is a Watch trap, which means that, when
>
>   IRQ # is not a trap #, so the rest of your speculations don't apply.
> "unexpected IRQ" probably means that an IRQ occurs for which no handler has
> been installed...
>
> WBR, Sergei
>

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?

Re: Got trap No.23 when booting mips32 ?

[Sergei Shtylyov]

Hello.

wilbur.chan wrote:

> Hi all,

> I've got some problem when booting mips32.

> I got a No.23 trap when calling start_kernel --->  local_irq_enable :

> irq 23, desc: 802a98a0, depth: 1, count: 0, unhandled: 0
> ->handle_irq():  80148c6c, handle_bad_irq+0x0/0x2b4
> ->chip(): 8029f738, 0x8029f738
> ->action(): 00000000
>   IRQ_DISABLED set
> unexpected IRQ # 23

> No.23 trap is a Watch trap, which means that, when

    IRQ # is not a trap #, so the rest of your speculations don't apply.
"unexpected IRQ" probably means that an IRQ occurs for which no handler has 
been installed...

WBR, Sergei

Re: Got trap No.23 when booting mips32 ?

[wilbur.chan]

2009/10/22 David Daney <ddaney@caviumnetworks.com>:
> IRQ != c0_cause.ExcCode
>
> You should look up your kernel's IRQ to  interrupt source mapping to see
> what is connected to IRQ 23.
>
> David Daney
>


2009/10/22 Sergei Shtylyov <sshtylyov@ru.mvista.com>:
>   IRQ # is not a trap #, so the rest of your speculations don't apply.
> "unexpected IRQ" probably means that an IRQ occurs for which no handler has
> been installed...
>
> WBR, Sergei
>


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?

Re: Got trap No.23 when booting mips32 ?

[Kevin D. Kissell]

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.

Re: Got trap No.23 when booting mips32 ?

[wilbur.chan]

2009/10/22 Kevin D. Kissell <kevink@paralogos.com>:
> 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?

Re: Got trap No.23 when booting mips32 ?

[David Daney]

wilbur.chan wrote:
> 2009/10/22 Kevin D. Kissell <kevink@paralogos.com>:
>> 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.

David Daney

Re: Got trap No.23 when booting mips32 ?

[David VomLehn]

>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?

It looks like you are confusing interrupts and exceptions. Exceptions
are a generally a change in the flow of execution of a processor due to
a condition internal to the processor. So, a divide by zero is an a exception.

An interrupt is a change in execution flow due to a device external to the
processor. Keyboards use interrupts to indicate that a key has been
pressed.

Things can be slightly confusing on the MIPS processor because interrupts
are normally treated as a type of exception. In this case, the exception
type in the ExcCode field of the Cause register is "Int". If your system
uses the external vectored interrupt controller, it will not use an
exception and will instead use an array of interrupt handlers.

In your case, you are getting interrupt request (IRQ) number 23. The message
you are getting indicates that no device driver has told the kernel that
it can handle this interrupt. I suggest that you consult the documentation
for your system to determine which device is using IRQ 23 and ensure that
you have a device driver installed for that device. It is unusual that
a device would cause an interrupt without actions from the device driver;
you might want to investigate the possibility that your system is
incorrectly configured, causing the incorrect IRQ to be generated.

I suggest reading the book, "See MIPS Run Linux" by Dominic Sweetman, to learn
more about the low level details of interrupts and exceptions on the MIPS
processor. For exact details, consult "MIPS32® Architecture For Programmers
Volume III: The MIPS32® Privileged Resource Architecture", available at
mips.com (you need to sign up for a free account)

David VL

Re: Got trap No.23 when booting mips32 ?

[wilbur.chan]

Thank you guys!


 IRQ 23 is console interrupt , and I forgot to disable it during
kernel booting ,before console_init, so I got this problem. (I'm
playing with kexec)

Thank you again!