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>