linux-mips
[Top] [All Lists]

Re: Got trap No.23 when booting mips32 ?

To: "Kevin D. Kissell" <kevink@paralogos.com>
Subject: Re: Got trap No.23 when booting mips32 ?
From: "wilbur.chan" <wilbur512@gmail.com>
Date: Thu, 22 Oct 2009 22:55:51 +0800
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>, ddaney@caviumnetworks.com, linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bg1b5aIXppFKOJqP/24e05lhEJlNlvQBg2pAqpdhygM=; b=EEHAH2YYPtO+CFG7lZpcNJOw+uderRGaghY6ujIjUjZtmHrzpQ1BTNt8vntldi+DzO ZWC4NGat9U3yrlWycgLmXWRgXltwoJ1pARDztRXa8aDicYDH6lHNj3CMwrHjziQKJSpg 75Qrk1p90517Rg1dFOOoyuCFjdftHbvzMUvMw=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vKAiOPXf8euUfD/sWHTfU2kjytrQ1ceO4+Bonact0qgR/8H67GKrOF+07bGJ9YqFlS gVHU91vfqSTjgCqVRh3sskenS0Br7N6JxcaOoT/ImXsY1Ng+jBRgqyo8lNffQxDLVzDi BNhBWy+eXjEHKW4aSqqcyFjrl0wZ8nTAQ+zo0=
In-reply-to: <4ADFAC5E.5020506@paralogos.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <e997b7420910210740l4a8fefai27c81152a6c288ef@mail.gmail.com> <4ADF32D1.6030801@ru.mvista.com> <e997b7420910211704w67517b3bud6f4757a35945ba@mail.gmail.com> <4ADFAC5E.5020506@paralogos.com>
Sender: linux-mips-bounce@linux-mips.org
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?

<Prev in Thread] Current Thread [Next in Thread>