headers
Masao Uebayashi | 8 Aug 2007 11:49
Picon
Gravatar

stacked syscall args on N32 kernel + O32 userland

O32 programs put arguments, that can't be put on argument registers
(a[0-3] for O32), on stack, where 64-bit values are aligned to 64-bit
and 32-bit and smaller values are aligned to 32-bit.

The new syscall entry code Matt Thomas has just added (thanks!) to
matt-mips64 doesn't work if register_t is 64-bit.  The right code I
think would be

        * copyin() the whole arguments (sy_argsize) into kernel, and
        * copy each argument into register_t array.

But but we can't know sizes of each argument at this point.  Some may
be 64-bit, like off_t.  So we can't rearrange arguments into
register_t array.

Masao
Permalink | Reply | 0 comments |
headers
Masao Uebayashi | 8 Aug 2007 11:44
Picon
Gravatar

stacked syscall args on N32 kernel + O32 userland

O32 programs put arguments, that can't be put on argument registers
(a[0-3] for O32), on stack, where 64-bit values are aligned to 64-bit
and 32-bit and smaller values are aligned to 32-bit.

The new syscall entry code Matt Thomas has just added (thanks!) to
matt-mips64 doesn't work if register_t is 64-bit.  The right code I
think would be

	* copyin() the whole arguments (sy_argsize) into kernel, and
	* copy each argument into register_t array.

But but we can't know sizes of each argument at this point.  Some may
be 64-bit, like off_t.  So we can't rearrange arguments into
register_t array.

Masao
Permalink | Reply | 1 comment |
headers
Masao Uebayashi | 9 Aug 2007 06:57
Picon
Gravatar

Re: stacked syscall args on N32 kernel + O32 userland

> O32 programs put arguments, that can't be put on argument registers
> (a[0-3] for O32), on stack, where 64-bit values are aligned to 64-bit
> and 32-bit and smaller values are aligned to 32-bit.
> 
> The new syscall entry code Matt Thomas has just added (thanks!) to
> matt-mips64 doesn't work if register_t is 64-bit.  The right code I
> think would be
> 
> 	* copyin() the whole arguments (sy_argsize) into kernel, and
> 	* copy each argument into register_t array.
> 
> But but we can't know sizes of each argument at this point.  Some may
> be 64-bit, like off_t.  So we can't rearrange arguments into
> register_t array.

I get to understand that this is what compat netbsd32 is for.  That
is, reading 32-bit stack with 32-bit register and convert values into
64-bit register_t arguments.

Masao
Permalink | Reply | 0 comments |
headers
Martin Husemann | 13 Aug 2007 12:26
Picon

current on evbmips

Has anyone tried running -current on some evbmips hardware?
I tried on a an alchemy based board and failed - now trying to narrow down
the problem.

Martin
Permalink | Reply | 6 comments |
headers
Martin Husemann | 14 Aug 2007 11:42
Picon

Re: current on evbmips

On Mon, Aug 13, 2007 at 12:26:53PM +0200, Martin Husemann wrote:
> Has anyone tried running -current on some evbmips hardware?
> I tried on a an alchemy based board and failed - now trying to narrow down
> the problem.

It looks like something in interrupt handling is broken - I get an "endless"
interrupt recursion on INT 5 (used as clockintr), these two lines repeat
in the backtrace untill the kernel stack overflows:

cpu_intr+bc (83fff000,375,0,8000) ra 80275b94 sz 56
mips32_KernIntr+84 (f801,b4004104,104,4) ra 8028b3d8 sz 128

(ipending = 0x8000: MIPS_INT_MASK_5)

Any hints where to look?

Martin
Permalink | Reply | 4 comments |
headers
Izumi Tsutsui | 14 Aug 2007 16:14
Picon
Gravatar

Re: current on evbmips

martin <at> duskware.de wrote:

> It looks like something in interrupt handling is broken - I get an "endless"
> interrupt recursion on INT 5 (used as clockintr), these two lines repeat
> in the backtrace untill the kernel stack overflows:
> 
> cpu_intr+bc (83fff000,375,0,8000) ra 80275b94 sz 56
> mips32_KernIntr+84 (f801,b4004104,104,4) ra 8028b3d8 sz 128

cobalt is working fine so mips3_clockintr.c shouldn't be a problem.
How is curcpu()->ci_cycles_per_hz set in yamon_setcpufreq()?
---
Izumi Tsutsui
Permalink | Reply | 3 comments |
headers
Martin Husemann | 14 Aug 2007 18:55
Picon

Re: current on evbmips

On Tue, Aug 14, 2007 at 11:14:46PM +0900, Izumi Tsutsui wrote:
> How is curcpu()->ci_cycles_per_hz set in yamon_setcpufreq()?

Looks good to me:

ci_cpu_freq: 324000000
ci_cycles_per_hz: 632813
ci_divisor_delay: 324

Martin
Permalink | Reply | 2 comments |
headers
Martin Husemann | 16 Aug 2007 10:49
Picon

Re: current on evbmips

Sorry, seems it was a local change - so my own faul. After fixing that,
I still end up in:

panic: TLB out of universe: ksp 0xc5fe9fd8 epc 0x80209e84 vaddr 0xbc9df000
Stopped in pid 71.1 (dev_mkdb) at       netbsd:cpu_Debugger+0x4:        jr      r
a
                bdslot: nop
db> bt                     
cpu_Debugger+4 (83fff000,b1100000,0,104) ra 8020a010 sz 0
panic+190 (83fff000,c5fe9fd8,80209e84,bc9df000) ra 802b55e8 sz 48
au_iointr+148 (0,0,80209e84,0) ra 7168 sz 80                     
PC 0x7168: not in kernel space              
0+7168 (0,0,80209e84,0) ra 0 sz 0
User-level: pid 71.1             

Martin
Permalink | Reply | 1 comment |
headers
Izumi Tsutsui | 16 Aug 2007 11:33
Picon
Gravatar

Re: current on evbmips

martin <at> duskware.de wrote:

> panic: TLB out of universe: ksp 0xc5fe9fd8 epc 0x80209e84 vaddr 0xbc9df000
> Stopped in pid 71.1 (dev_mkdb) at       netbsd:cpu_Debugger+0x4:        jr      r

FYI, I saw the similar panic on kernel stack overflow caused by
wrong acks against pci interrupts (i.e. a bug in pci_intr_map())
on arc.
---
Izumi Tsutsui
Permalink | Reply | 0 comments |
headers
David Young | 21 Aug 2007 02:38
Picon
Favicon

Re: current on evbmips

On Mon, Aug 13, 2007 at 12:26:53PM +0200, Martin Husemann wrote:
> Has anyone tried running -current on some evbmips hardware?
> I tried on a an alchemy based board and failed - now trying to narrow down
> the problem.

With some patches from Andrew, my RouterBOARD 153 with Atheros NIC is
not hanging early during boot, however, I got this LOCKDEBUG panic before
I got a login prompt:

Starting utd6.
Mutex error: lockdebug_barrier: spin lock held

lock address : 0x00000000c0130600 type     :               spin
shared holds :                  0 exclusive:                  1
shares wanted:                  0 exclusive:                  0
current cpu  :                  0 last held:                  0
current lwp  : 0x000000008143d040 last held: 0x000000008143d040
last locked  : 0x00000000801caa00 unlocked : 0x00000000801cabec
owner field  : 000000000000000000 wait/spin:                0/1

panic: LOCKDEBUG
Stopped in pid 1784.1 (utd6) at netbsd:cpu_Debugger+0x4:        jr      ra
                bdslot: nop
db> bt
cpu_Debugger+4 (81ff0000,d,0,0) ra 801795b0 sz 0
panic+184 (81ff0000,d,0,0) ra 801721c4 sz 48
lockdebug_abort1+70 (81ff0000,d,0,0) ra 801724c4 sz 32
lockdebug_barrier+180 (81ff0000,d,0,0) ra 8014db8c sz 56
mutex_vector_enter+204 (81ff0000,d,0,0) ra 8010b53c sz 48
uvm_uarea_alloc+24 (81ff0000,d,0,0) ra 80143588 sz 32
(Continue reading)

Permalink | Reply | 0 comments |

Gmane