[okl4-developer] second wombat

Ashish Bijlani ashish.bijlani at gmail.com
Fri Oct 10 17:10:02 EST 2008


The fault is due to external data abort on non-linefetch fault status
= 10. how do i fix this?

On Thu, Oct 9, 2008 at 11:28 PM, Geoffrey Lee <glee at ok-labs.com> wrote:
> On Thu, Oct 09, 2008 at 11:06:36PM -0400, Ashish Bijlani wrote:
>> l4_map_page is not being called for L2_1 (init process, wombat2)
>> faulting address i.e. 0x800bd0
>>
>
> You will probably need to read through the code and manually trace
> execution.  Right now there isn't much information other than it fails
> for some reason.  Assuming the success case it will end up in the
> mapping functions in arch/l4/mm/ and map it in.
>
>        -gl
>
>> "
>> VFS: Mounted root (ext2 filesystem) readonly.
>> vserial: init done (handle: 1, owner: 1c001, mask: 2)
>> LINUX1: flush_thread called
>> LINUX1: start_thread current = 8192dd60  pc = 800bd0, sp = 1b02f30 name: L_1
>> LINUX2 RUNNING INIT
>> LINUX2: execve called
>> init_new_context: 8212dd60 mm=82226d40, eas=8002bed0
>> LINUX2: memory fault = 1ff7ff1
>> LINUX2: pte fault, pte = 0
>> LINUX2: PTE PRESENT
>> LINUX2: l4_map_page: address = 0xffff7ff1
>> activate_mm: 8212dd60, old = 8189cc80, new = 82226d40 PID = 31
>> resume: 82226d40 : pid 31
>> LINUX2: flush_thread called
>> LINUX2: memory fault = 65ca8
>> LINUX2: pte fault, pte = 0
>> LINUX2: page fault, address = 65ca8
>> LINUX2: PTE PRESENT
>> LINUX2: l4_map_page: address = 0x3e065ca8
>> LINUX2: memory fault = 81d7e0
>> LINUX2: pte fault, pte = 0
>> LINUX2: page fault, address = 81d7e0
>> LINUX2: PTE PRESENT
>> LINUX2: l4_map_page: address = 0x3e81d7e0
>> LINUX2: memory fault = 1959fd3
>> LINUX2: pte fault, pte = 8223087d
>> LINUX2: PTE PRESENT
>> LINUX2: l4_map_page: address = 0x3f959fd3
>> LINUX2: start_thread current = 8212dd60  pc = 800bd0, sp = 1959f30 name: L2_1
>> LINUX1: flush_thread called
>> LINUX1: start_thread current = 81986580  pc = 800bd0, sp = 1a87ed0
>>
>> What could be wrong here? What should I look for next?
>>
>> -Ashish
>>
>> On Thu, Oct 9, 2008 at 11:05 PM, Ashish Bijlani
>> <ashish.bijlani at gmail.com> wrote:
>> > l4_map_page is not being called for L2_1 (init process, wombat2)
>> > faulting address i.e. 0x800bd0
>> >
>> > "
>> > VFS: Mounted root (ext2 filesystem) readonly.
>> > vserial: init done (handle: 1, owner: 1c001, mask: 2)
>> > LINUX1: flush_thread called
>> > LINUX1: start_thread current = 8192dd60  pc = 800bd0, sp = 1b02f30 name: L_1
>> > LINUX2 RUNNING INIT
>> > LINUX2: execve called
>> > init_new_context: 8212dd60 mm=82226d40, eas=8002bed0
>> > LINUX2: memory fault = 1ff7ff1
>> > LINUX2: pte fault, pte = 0
>> > LINUX2: PTE PRESENT
>> > LINUX2: l4_map_page: address = 0xffff7ff1
>> > activate_mm: 8212dd60, old = 8189cc80, new = 82226d40 PID = 31
>> > resume: 82226d40 : pid 31
>> > LINUX2: flush_thread called
>> > LINUX2: memory fault = 65ca8
>> > LINUX2: pte fault, pte = 0
>> > LINUX2: page fault, address = 65ca8
>> > LINUX2: PTE PRESENT
>> > LINUX2: l4_map_page: address = 0x3e065ca8
>> > LINUX2: memory fault = 81d7e0
>> > LINUX2: pte fault, pte = 0
>> > LINUX2: page fault, address = 81d7e0
>> > LINUX2: PTE PRESENT
>> > LINUX2: l4_map_page: address = 0x3e81d7e0
>> > LINUX2: memory fault = 1959fd3
>> > LINUX2: pte fault, pte = 8223087d
>> > LINUX2: PTE PRESENT
>> > LINUX2: l4_map_page: address = 0x3f959fd3
>> > LINUX2: start_thread current = 8212dd60  pc = 800bd0, sp = 1959f30 name: L2_1
>> > LINUX1: flush_thread called
>> > LINUX1: start_thread current = 81986580  pc = 800bd0, sp = 1a87ed0
>> >
>> > What could be wrong here? What should I look for next?
>> >
>> > -Ashish
>> >
>> > On Thu, Oct 9, 2008 at 1:36 AM, Geoffrey Lee <glee at ok-labs.com> wrote:
>> >> On Thu, Oct 09, 2008 at 01:26:33AM -0400, Ashish Bijlani wrote:
>> >>> oh ok. but doesn't this say that there are unhandled page fault cases
>> >>> in wombat?
>> >>
>> >> No, it says that OK Linux assumes the mapping operation request
>> >> should succeed.  It should be reasonable to expect so, but there might
>> >> have been modifications or misconfiguration for it to end up not
>> >> being the case.
>> >>
>> >>        -gl
>> >>
>> >>>
>> >>> On Thu, Oct 9, 2008 at 1:23 AM, Geoffrey Lee <glee at ok-labs.com> wrote:
>> >>> > On Thu, Oct 09, 2008 at 01:14:35AM -0400, Ashish Bijlani wrote:
>> >>> >> Upon removing the commented "#if" in kernel/syscall_loop.c I get this
>> >>> >> error message when wombat2 tries to run "init"
>> >>> >
>> >>> > This doesn't tell you why the memory is not mapped via the L4
>> >>> > kernel pagetables.  You need to put debug in the arch/l4/mm functions
>> >>> > that actually do the mapping.
>> >>> >
>> >>> >        -gl
>> >>> >
>> >>> >>
>> >>> >> kernel BUG at kernel-2.6.23-v2/arch/l4/kernel/syscall_loop.c:136!
>> >>> >> del: f0104740/8, remove client space f0104910/6
>> >>> >>
>> >>> >> vserial: init done (handle: 1, owner: 1c001, mask: 2)
>> >>> >> LINUX1: start_thread current = 8192dd60  pc = 800bd0, sp = 1c5ff30 name: L_1
>> >>> >> LINUX2 RUNNING INIT
>> >>> >> kernel BUG at kernel-2.6.23-v2/arch/l4/kernel/syscall_loop.c:136!
>> >>> >> del: f0104740/8, remove client space f0104910/6
>> >>> >> LINUX1: start_thread current = 81986580  pc = 800bd0, sp = 1debed0 name: L_16
>> >>> >> LINUX1: start_thread current = 819862e0  pc = 800bd0, sp = 1dbfed0
>> >>> >>
>> >>> >> Thanks,
>> >>> >> Ashish
>> >>> >>
>> >>> >> On Wed, Oct 8, 2008 at 11:43 PM, Geoffrey Lee <glee at ok-labs.com> wrote:
>> >>> >> > On Tue, Oct 07, 2008 at 06:55:05PM -0400, Ashish Bijlani wrote:
>> >>> >> >> upon enabling tracepoints in the kernel i get the following msgs:
>> >>> >> >>
>> >>> >> >> DABT @ 3e800bd0 [00800bd0], pc = 00800bd0, tcb = f0030dc0, fs = 10
>> >>> >> >> PF @ 3e800bd0 [3e800bd0], pc = 00800bd0, tcb = f0030dc0, fs = 0
>> >>> >> >> user execute pagefault by 0002c001 at 3e800bd0, ip=00800bd0, ksp=f001ff80
>> >>> >> >> SYS_IPC: current: 0002c001, to_tid: 00024001, from_tid: 00024001, tag:
>> >>> >> >> 0xffe1c002 (label=0xffe1, SR~, u=2)
>> >>> >> >
>> >>> >> > You should check to see whether any pagefault ipc is received.
>> >>> >> > Because it's the same address everytime, I suspect some memory mapping
>> >>> >> > operation is not succeeding.  The mm-related functions are
>> >>> >> > in the arch/l4/mm directory.
>> >>> >> >
>> >>> >> >        -gl
>> >>> >> >
>> >>> >> >
>> >>> >> >>
>> >>> >> >> DABT @ 3e800bd0 [00800bd0], pc = 00800bd0, tcb = f0030dc0, fs = 10
>> >>> >> >> PF @ 3e800bd0 [3e800bd0], pc = 00800bd0, tcb = f0030dc0, fs = 0
>> >>> >> >> user execute pagefault by 0002c001 at 3e800bd0, ip=00800bd0, ksp=f001ff80
>> >>> >> >> SYS_IPC: current: 0002c001, to_tid: 00024001, from_tid: 00024001, tag:
>> >>> >> >> 0xffe1c002 (label=0xffe1, SR~, u=2)
>> >>> >> >>
>> >>> >> >> DABT @ 3e800bd0 [00800bd0], pc = 00800bd0, tcb = f0030dc0, fs = 10
>> >>> >> >> PF @ 3e800bd0 [3e800bd0], pc = 00800bd0, tcb = f0030dc0, fs = 0
>> >>> >> >> user execute pagefault by 0002c001 at 3e800bd0, ip=00800bd0, ksp=f001ff80
>> >>> >> >> SYS_IPC: current: 0002c001, to_tid: 00024001, from_tid: 00024001, tag:
>> >>> >> >> 0xffe1c002 (label=0xffe1, SR~, u=2)
>> >>> >> >>
>> >>> >> >> DABT @ 3e800bd0 [00800bd0], pc = 00800bd0, tcb = f0030dc0, fs = 10
>> >>> >> >> PF @ 3e800bd0 [3e800bd0], pc = 00800bd0, tcb = f0030dc0, fs = 0
>> >>> >> >> user execute pagefault by 0002c001 at 3e800bd0, ip=00800bd0, ksp=f001ff80
>> >>> >> >> SYS_IPC: current: 0002c001, to_tid: 00024001, from_tid: 00024001, tag:
>> >>> >> >> 0xffe1c002 (label=0xffe1, SR~, u=2)
>> >>> >> >>
>> >>> >> >> Why is 0002c001 page faulting at the init thread PC (0x00800bd0)????
>> >>> >> >>
>> >>> >> >> Both LINUX1 and LINUX2 start executing from pc=0x800bd0
>> >>> >> >>
>> >>> >> >> LINUX1: start_thread current = 81f2dd60  pc = 800bd0, sp = 1e13f30 name: L_1
>> >>> >> >> LINUX2: start_thread current = 8272dd60  pc = 800bd0, sp = 1d80f30 name: L2_1
>> >>> >> >>
>> >>> >> >> But only LINUX2 page faults at 0x800bd0, I dunno why?
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> > showtcbext
>> >>> >> >> tcb/tid/name [current]: L2_1
>> >>> >> >> === L2_1 == TCB: f0030dc0 == ID: 0002c001 = e0801f00/e0801f00 ==
>> >>> >> >> APRIO/EPRIO: 0x62/0x62 ===
>> >>> >> >> UIP: 00800bd0   queues: Rb      space: f0104740/8   pager: L2_syscall
>> >>> >> >> USP: 01d80f30   tstate: RUNNING   ready: L2_1    :L2_1       pdir : f0105600
>> >>> >> >> sndhd : NIL_THRD  blocked : NIL_THRD:NIL_THRD   waiting_for : NIL_THRD
>> >>> >> >> ts length  :       0x2710 us, curr ts: 0x2710 us
>> >>> >> >> resources:    00000000 [ek], ARM [PID: 31, vspace: 0, domain: 7, dom_mask 4001]
>> >>> >> >> continuation: ffff0cf4   preemption_cont: 00000000
>> >>> >> >> scheduler: L2_sysca    exception_handler: L2_sysca
>> >>> >> >>   partner: NIL_THRD        saved partner: NIL_THRD      saved state: ABORTED
>> >>> >> >>   tcb_idx: a
>> >>> >> >> references: T f0101864
>> >>> >> >>
>> >>> >> >> user handle:          00000000  cop flags:           00
>> >>> >> >> preempt flags: 00 [~]
>> >>> >> >> incoming notify bits: 00000000  notify mask:         00000000
>> >>> >> >> last preempted_ip:    00000000  preempt_callback_ip: 00000000
>> >>> >> >>
>> >>> >> >> mr( 0): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> mr( 8): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> mr(16): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> mr(24): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> Message Tag: 0 untyped, label = 0, flags = -
>> >>> >> >>
>> >>> >> >> Acceptor: 00000000 (a)  Error code: 0
>> >>> >> >>
>> >>> >> >> Any ideas on this???
>> >>> >> >>
>> >>> >> >> Thanks,
>> >>> >> >> Ashish
>> >>> >> >>
>> >>> >> >> On Tue, Oct 7, 2008 at 6:48 PM, Ashish Bijlani <ashish.bijlani at gmail.com> wrote:
>> >>> >> >> > I disabled ig_serial in wombat1. however, wombat2 doesn't gives sh shell :
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > VFS: Mounted root (ext2 filesystem) readonly.
>> >>> >> >> > vserial: init done (handle: 1, owner: 1c001, mask: 2)
>> >>> >> >> > LINUX1: flush_thread called
>> >>> >> >> > LINUX1: start_thread current = 81f2dd60  pc = 800bd0, sp = 1e13f30 name: L_1
>> >>> >> >> > LINUX2 RUNNING INIT
>> >>> >> >> > LINUX2: execve called
>> >>> >> >> > LINUX2: flush_thread called
>> >>> >> >> > LINUX2: start_thread current = 8272dd60  pc = 800bd0, sp = 1d80f30 name: L2_1
>> >>> >> >> >
>> >>> >> >> > I can see wombat1 printks through KDB console but wombat1 init process
>> >>> >> >> > hangs. there is no wombat1 serial involved and vserial in iguana just
>> >>> >> >> > has 1 client (wombat2). Is there something that i'm missing?
>> >>> >> >> >
>> >>> >> >> > Thanks,
>> >>> >> >> > Ashish
>> >>> >> >> >
>> >>> >> >> > On Mon, Oct 6, 2008 at 11:51 PM, Ashish Bijlani
>> >>> >> >> > <ashish.bijlani at gmail.com> wrote:
>> >>> >> >> >> Thanks for the help Geoff. However, I tried disabling the serial
>> >>> >> >> >> console in the first wombat. Even then the serial console stuff
>> >>> >> >> >> doesn't work. It shows the same behavior - hangs and doesn' gimme
>> >>> >> >> >> bash/sh shell.
>> >>> >> >> >>
>> >>> >> >> >> -ashish
>> >>> >> >> >>
>> >>> >> >> >> On Mon, Oct 6, 2008 at 11:37 PM, Geoffrey Lee <glee at ok-labs.com> wrote:
>> >>> >> >> >>> On Mon, Oct 06, 2008 at 07:15:53PM -0400, Ashish Bijlani wrote:
>> >>> >> >> >>>> I think there is conflict between the init processes from the two wombats:
>> >>> >> >> >>>>
>> >>> >> >> >>>> vserial: init done (handle: 0, owner: 18001, mask: 2
>> >>> >> >> >>>> vserial: init done (handle: 1, owner: 1c001, mask: 2)
>> >>> >> >> >>>> start_thread current = 81f2dd60  pc = 800bd0, sp = 1ac5f30 name: L_1
>> >>> >> >> >>>> start_thread current = 8272dd60  pc = 800bd0, sp = 1e96f30 name: L2_1
>> >>> >> >> >>>
>> >>> >> >> >>> Ashish - if you are referring to the /sbin/init processes in
>> >>> >> >> >>> OK Linux they wouldn't be conflicting directly - each would run
>> >>> >> >> >>> in its own separate VM.  From the symptoms however it seems
>> >>> >> >> >>> that the serial sharing is getting confused, I would debug
>> >>> >> >> >>> the vserial <-> OK Linux interactions between the two
>> >>> >> >> >>> OK Linux VMs.
>> >>> >> >> >>>
>> >>> >> >> >>>        -gl
>> >>> >> >> >>>
>> >>> >> >> >>>>
>> >>> >> >> >>>> Does anybody have any idea?
>> >>> >> >> >>>>
>> >>> >> >> >>>> -Ashish
>> >>> >> >> >>>>
>> >>> >> >> >>>> On Mon, Oct 6, 2008 at 2:54 AM, Ashish Bijlani <ashish.bijlani at gmail.com> wrote:
>> >>> >> >> >>>> > I get Error Code = 2 for L_syscall and L2_syscall
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >> showtcbext
>> >>> >> >> >>>> > tcb/tid/name [current]: L1
>> >>> >> >> >>>> > No thread named: L1
>> >>> >> >> >>>> >> showtcbext
>> >>> >> >> >>>> > tcb/tid/name [current]: L_syscall
>> >>> >> >> >>>> > === L_syscall == TCB: f00309a0 == ID: 00020001 = e0501e00/e0501e00 ==
>> >>> >> >> >>>> > APRIO/EPRIO: 0x63/0x63 ===
>> >>> >> >> >>>> > UIP: 810b9a2c   queues: rB      space: f01049f8/5   pager: roottask
>> >>> >> >> >>>> > USP: 811cc5cc   tstate: WAIT_FOREVER  ready: NIL_THRD:NIL_THRD   pdir : f0105900
>> >>> >> >> >>>> > sndhd : NIL_THRD  blocked : L_syscal:L_syscal   waiting_for : L_timer
>> >>> >> >> >>>> > ts length  :       0x2710 us, curr ts: 0x2710 us
>> >>> >> >> >>>> > resources:    00000000 [ek], ARM [PID: 0, vspace: 1, domain: 10,
>> >>> >> >> >>>> > dom_mask 55510001]
>> >>> >> >> >>>> > continuation: f0002428   preemption_cont: 00000000
>> >>> >> >> >>>> > scheduler: L_syscal    exception_handler: roottask
>> >>> >> >> >>>> >  partner: L_timer        saved partner: NIL_THRD      saved state: ABORTED
>> >>> >> >> >>>> >  tcb_idx: 7
>> >>> >> >> >>>> > references: T f010184c->f0031380(I)->f0031420(I)->f0031358(I)->f00310c0(I)->f0031160(I)->f0031098(I)->f0030f60(I)->f0031000(I)->f0030f38(I)->f0030ca0(I)->f0030d40(I)->f0030c78(I)->f010844c(I)->f0030a80(I)
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > user handle:          00000000  cop flags:           00
>> >>> >> >> >>>> > preempt flags: 00 [~]
>> >>> >> >> >>>> > incoming notify bits: 00000000  notify mask:         00000000
>> >>> >> >> >>>> > last preempted_ip:    810040c4  preempt_callback_ip: 810041f8
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > mr( 0): 00000000 811cc648 811cc604 811cc608 811c4640 811cc648 01e97d44 000000c0
>> >>> >> >> >>>> > mr( 8): 00002654 00988e78 01e97d44 0002cef4 ef900066 40000010 00000000 00000000
>> >>> >> >> >>>> > mr(16): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> >>>> > mr(24): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> >>>> > Message Tag: 0 untyped, label = 0, flags = -
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > Acceptor: 00000000 (a)  Error code: 2
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >> showtcbext
>> >>> >> >> >>>> > tcb/tid/name [current]: L2_syscall
>> >>> >> >> >>>> > === L2_syscall == TCB: f0030b00 == ID: 00024001 = e0601e00/e0601e00 ==
>> >>> >> >> >>>> > APRIO/EPRIO: 0x63/0x63 ===
>> >>> >> >> >>>> > UIP: 81eb99c8   queues: rb      space: f0104910/6   pager: roottask
>> >>> >> >> >>>> > USP: 8282ff60   tstate: WAIT_FOREVER  ready: NIL_THRD:NIL_THRD   pdir : f0105800
>> >>> >> >> >>>> > sndhd : NIL_THRD  blocked : NIL_THRD:NIL_THRD   waiting_for : NIL_THRD
>> >>> >> >> >>>> > ts length  :       0x2710 us, curr ts: 0x2710 us
>> >>> >> >> >>>> > resources:    00000000 [ek], ARM [PID: 0, vspace: 1, domain: 5, dom_mask 401]
>> >>> >> >> >>>> > continuation: f0002428   preemption_cont: 00000000
>> >>> >> >> >>>> > scheduler: L2_sysca    exception_handler: roottask
>> >>> >> >> >>>> >  partner: ANY_THRD        saved partner: NIL_THRD      saved state: ABORTED
>> >>> >> >> >>>> >  tcb_idx: 8
>> >>> >> >> >>>> > references: T f0101854->f0030e00(I)->f0030ea0(I)->f0030dd8(I)->f0030be0(I)
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > user handle:          00000000  cop flags:           00
>> >>> >> >> >>>> > preempt flags: 00 [~]
>> >>> >> >> >>>> > incoming notify bits: 00000000  notify mask:         00000000
>> >>> >> >> >>>> > last preempted_ip:    81e07844  preempt_callback_ip: 81e042ec
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > mr( 0): 00000000 00000001 8282c000 00000000 8282c05c 81fbb4ec 8002c380 00000000
>> >>> >> >> >>>> > mr( 8): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> >>>> > mr(16): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> >>>> > mr(24): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> >>>> > Message Tag: 0 untyped, label = 0, flags = -
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > Acceptor: 00000000 (a)  Error code: 2
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > Upon debugging more I found out the Error Code 2 comes because of this :
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > "
>> >>> >> >> >>>> > Mount-cache hash table entries: 512
>> >>> >> >> >>>> > current = L2_syscall
>> >>> >> >> >>>> > SYS_EXCHANGE_REGISTERS: dest=NIL_THRD, control=0x80 [~~~~~~~~~~],
>> >>> >> >> >>>> > usp=00000000, uip=00000000, uflags=00000000, uhandle=0
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > current = L2_syscall
>> >>> >> >> >>>> > SYS_EXCHANGE_REGISTERS: dest=NIL_THRD, control=0x80 [~~~~~~~~~~],
>> >>> >> >> >>>> > usp=00000000, uip=00000000, uflags=00000000, uhandle=0
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > current = L2_syscall
>> >>> >> >> >>>> > SYS_EXCHANGE_REGISTERS: dest=NIL_THRD, control=0x80 [~~~~~~~~~~],
>> >>> >> >> >>>> > usp=00000000, uip=00000000, uflags=00000000, uhandle=0
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > Mount-cache hash table entries: 512
>> >>> >> >> >>>> > current = L_syscall
>> >>> >> >> >>>> > SYS_EXCHANGE_REGISTERS: dest=NIL_THRD, control=0x80 [~~~~~~~~~~],
>> >>> >> >> >>>> > usp=00000000, uip=00000000, uflags=00000000, uhandle=0
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > current = L_syscall
>> >>> >> >> >>>> > SYS_EXCHANGE_REGISTERS: dest=NIL_THRD, control=0x80 [~~~~~~~~~~],
>> >>> >> >> >>>> > usp=00000000, uip=00000000, uflags=00000000, uhandle=0
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > current = L_syscall
>> >>> >> >> >>>> > SYS_EXCHANGE_REGISTERS: dest=NIL_THRD, control=0x80 [~~~~~~~~~~],
>> >>> >> >> >>>> > usp=00000000, uip=00000000, uflags=00000000, uhandle=0
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > current = L_syscall
>> >>> >> >> >>>> > SYS_EXCHANGE_REGISTERS: dest=NIL_THRD, control=0x80 [~~~~~~~~~~],
>> >>> >> >> >>>> > usp=00000000, uip=00000000, uflags=00000000, uhandle=0
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > current = L_syscall
>> >>> >> >> >>>> > SYS_EXCHANGE_REGISTERS: dest=NIL_THRD, control=0x80 [~~~~~~~~~~],
>> >>> >> >> >>>> > usp=00000000, uip=00000000, uflags=00000000, uhandle=0
>> >>> >> >> >>>> > "
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > Is this normal? How do I fix this?
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > Thanks,
>> >>> >> >> >>>> > Ashish
>> >>> >> >> >>>> >
>> >>> >> >> >>>> >
>> >>> >> >> >>>> > On Sun, Oct 5, 2008 at 8:54 PM, Ashish Bijlani <ashish.bijlani at gmail.com> wrote:
>> >>> >> >> >>>> >>> showtcbext
>> >>> >> >> >>>> >> tcb/tid/name [current]: L2_1
>> >>> >> >> >>>> >> === L2_1 == TCB: f0030dc0 == ID: 0002c001 = e0801f00/e0801f00 ==
>> >>> >> >> >>>> >> APRIO/EPRIO: 0x62/0x62 ===
>> >>> >> >> >>>> >> UIP: 00800bd0   queues: Rb      space: f0104740/8   pager: L2_syscall
>> >>> >> >> >>>> >> USP: 01c26f30   tstate: RUNNING   ready: L2_1    :L2_1       pdir : f0105600
>> >>> >> >> >>>> >> sndhd : NIL_THRD  blocked : NIL_THRD:NIL_THRD   waiting_for : NIL_THRD
>> >>> >> >> >>>> >> ts length  :       0x2710 us, curr ts: 0x2710 us
>> >>> >> >> >>>> >> resources:    00000000 [ek], ARM [PID: 31, vspace: 0, domain: 7, dom_mask 4001]
>> >>> >> >> >>>> >> continuation: ffff0cf4   preemption_cont: 00000000
>> >>> >> >> >>>> >> scheduler: L2_sysca    exception_handler: L2_sysca
>> >>> >> >> >>>> >>  partner: NIL_THRD        saved partner: NIL_THRD      saved state: ABORTED
>> >>> >> >> >>>> >>  tcb_idx: a
>> >>> >> >> >>>> >> references: T f0101864
>> >>> >> >> >>>> >>
>> >>> >> >> >>>> >> user handle:          00000000  cop flags:           00
>> >>> >> >> >>>> >> preempt flags: 00 [~]
>> >>> >> >> >>>> >> incoming notify bits: 00000000  notify mask:         00000000
>> >>> >> >> >>>> >> last preempted_ip:    00000000  preempt_callback_ip: 00000000
>> >>> >> >> >>>> >>
>> >>> >> >> >>>> >> mr( 0): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> >>>> >> mr( 8): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> >>>> >> mr(16): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> >>>> >> mr(24): 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> >>> >> >> >>>> >> Message Tag: 0 untyped, label = 0, flags = -
>> >>> >> >> >>>> >>
>> >>> >> >> >>>> >> Acceptor: 00000000 (a)  Error code: 0
>> >>> >> >> >>>> >>
>> >>> >> >> >>>> >>
>> >>> >> >> >>>> >> On Sun, Oct 5, 2008 at 8:51 PM, Ashish Bijlani <ashish.bijlani at gmail.com> wrote:
>> >>> >> >> >>>> >>> Hi,
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> I'm running two wombats on emulated (skyeye) gumstix platform.
>> >>> >> >> >>>> >>> However, the wombat that boots up last doesn't prints any msgs on the
>> >>> >> >> >>>> >>> serial console. AFAIK, once linux starts "init" process msgs over
>> >>> >> >> >>>> >>> serial console appear through vserial server/client model and not
>> >>> >> >> >>>> >>> through L4KDB. However, the latter wombat either doesn't get serial
>> >>> >> >> >>>> >>> console to dump msgs or it is blocked on some event; I'm not sure
>> >>> >> >> >>>> >>> though. I've modified vserial server in iguana to make the latter
>> >>> >> >> >>>> >>> wombat's vserial client as the active_virtual client, but I don't see
>> >>> >> >> >>>> >>> any output. What could be the reason?
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> snippet from vserial to make the last wombat as active_virtual
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> "
>> >>> >> >> >>>> >>>    for (i = 0; i < 4; i++)
>> >>> >> >> >>>> >>>    {
>> >>> >> >> >>>> >>>        if (virtual_device_instance[i].valid_instance)
>> >>> >> >> >>>> >>>        {
>> >>> >> >> >>>> >>>            virtual_device_instance[i].serial_device = (void *)(serial_device);
>> >>> >> >> >>>> >>>            // XXX virtual_device_instance[i].thread = *thread;
>> >>> >> >> >>>> >>>            // XXX virtual_device_instance[i].mask = mask;
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>            virtual_device_instance[i].si_start =
>> >>> >> >> >>>> >>> virtual_device_instance[i].si_end = NULL;
>> >>> >> >> >>>> >>>            virtual_device_instance[i].si_comp_end =
>> >>> >> >> >>>> >>> virtual_device_instance[i].si_comp_start = NULL;
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>            if (serial_device->active_virtual == NULL)
>> >>> >> >> >>>> >>>            {
>> >>> >> >> >>>> >>>                serial_device->active_virtual    = &virtual_device_instance[i];
>> >>> >> >> >>>> >>>                serial_device->last_virtual      = &virtual_device_instance[i];
>> >>> >> >> >>>> >>>            }
>> >>> >> >> >>>> >>>            else
>> >>> >> >> >>>> >>>            {
>> >>> >> >> >>>> >>>                serial_device->active_virtual    = &virtual_device_instance[i];
>> >>> >> >> >>>> >>>                serial_device->last_virtual->next = &virtual_device_instance[i];
>> >>> >> >> >>>> >>>                serial_device->last_virtual       = &virtual_device_instance[i];
>> >>> >> >> >>>> >>>            }
>> >>> >> >> >>>> >>>        }
>> >>> >> >> >>>> >>>    }
>> >>> >> >> >>>> >>> "
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> Output snippet
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> "
>> >>> >> >> >>>> >>> NET: Registered protocol family 15
>> >>> >> >> >>>> >>> VFS: Mounted root (ext2 filesystem) readonly.
>> >>> >> >> >>>> >>> PXA FFUART IRQ: 33
>> >>> >> >> >>>> >>> vserial: init done (handle: 0, owner: 18001, mask: 2)
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>  Client:  0x0
>> >>> >> >> >>>> >>> io scheduler noop registered
>> >>> >> >> >>>> >>> io scheduler anticipatory registered
>> >>> >> >> >>>> >>> io scheduler deadline registered
>> >>> >> >> >>>> >>> io scheduler cfq registered (default)
>> >>> >> >> >>>> >>> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
>> >>> >> >> >>>> >>> loop: module loaded
>> >>> >> >> >>>> >>> tun: Universal TUN/TAP device driver, 1.6
>> >>> >> >> >>>> >>> tun: (C) 1999-2004 Max Krasnyansky <maxk at qualcomm.com>
>> >>> >> >> >>>> >>>  igms0: unknown partition table
>> >>> >> >> >>>> >>> Iguana ramdisk driver initialized
>> >>> >> >> >>>> >>> kobject_add failed for ttyS0 with -EEXIST, don't try to register
>> >>> >> >> >>>> >>> things with the same name in the same directory.
>> >>> >> >> >>>> >>> This architecture does not implement dump_stack()
>> >>> >> >> >>>> >>> Iguana virtual serial driver v1.0
>> >>> >> >> >>>> >>> TCP cubic registered
>> >>> >> >> >>>> >>> NET: Registered protocol family 1
>> >>> >> >> >>>> >>> NET: Registered protocol family 17
>> >>> >> >> >>>> >>> NET: Registered protocol family 15
>> >>> >> >> >>>> >>> VFS: Mounted root (ext2 filesystem) readonly.
>> >>> >> >> >>>> >>> vserial: init done (handle: 1, owner: 1c001, mask: 2)
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>  Client:  0x1c001
>> >>> >> >> >>>> >>> start_thread current = 8282bd60  pc = 800bd0, sp = 1c26f30
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>  Client:  0x1c001
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>  Client:  0x1c001
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>  Client:  0x1c001
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>  Client:  0x1c001
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> "
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> It doesn't prints anything after this. For the first "vserial: init
>> >>> >> >> >>>> >>> done (handle: 0, owner: 18001, mask: 2)" it shows Client as NULL.
>> >>> >> >> >>>> >>> Second time it shows the correct client.
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>>> showqueue
>> >>> >> >> >>>> >>> Key: (X) blocked, <X> on CPU, {X} halted, !X! aborted
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> [255]:
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>>  (roottask)
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> [240]:
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>>  (vtimer)
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>>  (vrtc)
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> [200]:
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>>  (event)
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> [110]:
>> >>> >> >> >>>> >>> RUNNING
>> >>> >> >> >>>> >>>  <vserial>
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> [100]:
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>> (L_timer)
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>> (L2_timer)
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> [ 99]:
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>> (L_syscal)
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>> (L2_sysca)
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> [ 98]:
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>> (L_1)
>> >>> >> >> >>>> >>> RUNNING
>> >>> >> >> >>>> >>> L2_1
>> >>> >> >> >>>> >>> WAIT_FOREVER
>> >>> >> >> >>>> >>> (L_49)
>> >>> >> >> >>>> >>> idle : idle_thread
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> L2_1 represents the init process in wombat 2. This always shows L2_1
>> >>> >> >> >>>> >>> as RUNNING. But doesn't prints it within "<" and ">".
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>> Thanks,
>> >>> >> >> >>>> >>> Ashish
>> >>> >> >> >>>> >>>
>> >>> >> >> >>>> >>
>> >>> >> >> >>>> >
>> >>> >> >> >>>>
>> >>> >> >> >>>> _______________________________________________
>> >>> >> >> >>>> Developer mailing list
>> >>> >> >> >>>> Developer at okl4.org
>> >>> >> >> >>>> https://lists.okl4.org/mailman/listinfo/developer
>> >>> >> >> >>>>
>> >>> >> >> >>>
>> >>> >> >> >>> --
>> >>> >> >> >>>
>> >>> >> >> >>>
>> >>> >> >> >>
>> >>> >> >> >
>> >>> >> >>
>> >>> >> >
>> >>> >> > --
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >
>> >>> > --
>> >>> >
>> >>> >
>> >>>
>> >>
>> >> --
>> >>
>> >>
>> >
>>
>> _______________________________________________
>> Developer mailing list
>> Developer at okl4.org
>> https://lists.okl4.org/mailman/listinfo/developer
>>
>
> --
>
>



More information about the Developer mailing list