Subject: Re: port-shark/22355 [was: Help needed to fix NetBSD/shark]
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: Julio M. Merino Vidal <jmmv84@gmail.com>
List: port-arm
Date: 08/03/2007 12:32:46
Hi,
Based on my limited understanding of ARM assembly (as in "just
learned the basics yesterday") and after countless hours of crappy
debugging, I think I have found THE^Wa bug in the isa_irq.S file.
With my change (see below) the machine seems to work fine, but I have
also made it work in so many different and flawed ways (see the
beginning of this thread or the contents of the PR) that I'm unsure
if this is correct or not.
The thing is that the file contains this loop:
Lfind_highest_ipl:
ldr r2, [r7, r9, lsl #2]
tst r8, r2
subeq r9, r9, #1
beq Lfind_highest_ipl
AIUI, this locates the highest IPL at which the received IRQs have to
be served. After the beq, r9 contains the number of this IPL, and r2
contains the spl_mask for that level.
But, the code does this just afterwards:
/* r9 = SPL level of highest priority interrupt */
add r9, r9, #1
ldr r2, [r7, r9, lsl #2]
Thus reloading r9 and r2 with the values of the calculated IPL + 1.
Which is what seems to be incorrect to my untrained eye. Am I right?
See the patch below for my proposed fix, assuming that this is
effectively broken. If it is correct, I'll commit it soon and make
shark work again :-)
Thanks!
Index: arch/shark/isa/isa_irq.S
===================================================================
RCS file: /cvsroot/src/sys/arch/shark/isa/isa_irq.S,v
retrieving revision 1.7
diff -u -p -r1.7 isa_irq.S
--- arch/shark/isa/isa_irq.S 9 Mar 2007 19:21:59 -0000 1.7
+++ arch/shark/isa/isa_irq.S 3 Aug 2007 10:25:24 -0000
@@ -199,8 +199,6 @@ Lfind_highest_ipl:
beq Lfind_highest_ipl
/* r9 = SPL level of highest priority interrupt */
- add r9, r9, #1
- ldr r2, [r7, r9, lsl #2]
mvn r2, r2
orr r0, r0, r2
On 30/07/2007, at 16:14, Izumi Tsutsui wrote:
> jmmv84@gmail.com wrote:
>
>> According to the PR, delivering events through a serial
>> console may show some progress (which I believe and will explain
>> below), but I don't have one to try.
>
> ddb trace after break on serial console shows:
>
> ---
> :
> cpu@0 at ofbus4 not configured
> ofbus5 at ofbus0 (udp)
> nfs at ofbus5 not configured
> ipl_bio=ffffbfff ipl_net=ffffbfdf ipl_tty=ffffaf5d ipl_vm=ffffaf5d
> ipl_audio=ffff2d5d ipl_imp=ffff2d5d ipl_high=ffff2d5d
> ipl_serial=ffff2d45
> clock: hz=64 stathz = 0 profhz = 0
> boot device: cs0
> root on cs0
> nfs_boot: trying DHCP/BOOTP
> Stopped in pid 0.2 (system) at netbsd:cpu_Debugger+0x4: \
> mov r15, r14
>
> db> tr
> netbsd:comintr+0xc
> scp=0xf0049dfc rlv=0xf01b5b18 (netbsd:irq_entry+0x174)
> rsp=0xf2443f34 rfp=0xf2443f98
> r10=0x00000000 r9=0x00000010
> r8=0x00000010 r7=0xf029d558 r6=0xf1134e00 r5=0xf0295158
> r4=0x00000080
> netbsd:cpu_idle+0xc
> scp=0xf016be70 rlv=0xf00f21e0 (netbsd:idle_loop+0x68)
> rsp=0xf2443f9c rfp=0xf2443fb0
> r4=0xf24e1d00
> netbsd:idle_loop+0xc
> scp=0xf00f2184 rlv=0xf016f2fc (netbsd:lwp_trampoline+0x14)
> rsp=0xf2443fb4 rfp=0x00000000
> r5=0xf24e1d00 r4=0xf00f2178
> db> show event
>
> :
>
> evcnt type 1: soft clock = 17
> evcnt type 1: soft net = 1
> evcnt type 1: soft serial = 12
> evcnt type 1: isa irq 4 = 12
> evcnt type 1: isa irq 5 = 2
> db>
>
> Looks a kernel jumps into cpu_idle(9) at IPL_CLOCK?
> ---
> Izumi Tsutsui
--
Julio M. Merino Vidal <jmmv84@gmail.com>