[okl4-developer] second wombat
Geoffrey Lee
glee at ok-labs.com
Thu Oct 16 02:07:35 EST 2008
On Mon, Oct 13, 2008 at 12:18:09AM -0400, Ashish Bijlani wrote:
> It turns out that IPC is not being received by L_syscall in wombat2.
> also, while priting the thread ID I get L_syscall for syscall loop in
> wombat1 but 00024001 for syscall loop in wombat2. i've not been able
> to figure out why L_syscall is not able to receive IPC from pistachio.
> Any pointers?
One possible reason is you might have forgotten to set the thread name.
The thread name is set at runtime by OK Linux itself with L4_KDB_* functions.
however in the previous kdb output you have shown, such as this:
> >> >> >>> >> >> >>>> > tcb/tid/name [current]: L2_syscall
> >> >> >>> >> >> >>>> > === L2_syscall == TCB: f0030b00 == ID: 00024001
> >> >> >>> >> >> >>>> > = e0601e00/e0601e00 ==
> >> >> >>> >> >> >>>> > APRIO/EPRIO: 0x63/0x63 ==
shows that you were able to get a friendly name.
>
> Thanks,
> Ashish
-gl
>
> On Fri, Oct 10, 2008 at 6:30 AM, Geoffrey Lee <glee at ok-labs.com> wrote:
> > On Fri, Oct 10, 2008 at 02:10:02AM -0400, Ashish Bijlani wrote:
> >> The fault is due to external data abort on non-linefetch fault status
> >> = 10. how do i fix this?
> >
> > Unfortunately without further investigation I am not sure what exactly
> > needs to be done to fix this. The best advice is still to trace through
> > the execution to find out why the map failed and why it is continually
> > pagefaulting. L4_map_page() does the actual insert into the l4
> > pagetable so you may want to have a look at that.
> >
> > -gl
> >
> >>
> >> 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