Re: [Xenomai] Target frozen with rtcan_virt

[Thierry Bultel <thierry.bultel@wanadoo.fr>]

Hi, I would like to re-open this thread

I have reproduced the same target freeze, on another configuration.
linux-3.2.21+ipipe-core-3.2.21-x86-1.patch

running on kvm (only one core)

rtcan0 and rtcan1 are devices of the unmodifed "rtcan_virt" rtdm driver.

The test sample is the unmodified 
"xenomai-2.6.1/examples/rtdm/profiles/can/rtcan_rtt.c"

[root@buildroot ~]# ./rtcan_rtt rtcan0 rtcan1
1 3
RX rxsock=896, ifr_name=rtcan1
TX txsock=897, ifr_name=rtcan0
Round-Trip-Time test rtcan0 -> rtcan1 with CAN ID 0x1
Cycle time: 10000 us
All RTT timing figures are in us.


---> FROZEN

#


Here's my backtrace, with gdb on qemu's gdbserver:

(gdb) l
58
59        for (;;) {
60            if (inc.head == inc.tail)
61                break;
62            cpu_relax();
63            inc.head = ACCESS_ONCE(lock->tickets.head);
64        }
65        barrier();        /* make sure nothing creeps before the lock 
is taken */
66    }
67
(gdb) bt
#0  __ticket_spin_lock (lock=<optimized out>) at 
/home/thierry/workspace/Buildroot/output/build/linux-3.2.21/arch/x86/include/asm/spinlock.h:63
#1  arch_spin_lock (lock=<optimized out>) at 
/home/thierry/workspace/Buildroot/output/build/linux-3.2.21/arch/x86/include/asm/spinlock.h:129
#2  rtcan_raw_recvmsg (context=0xc7ff0000, user_info=0xd00b2290, 
msg=0xd796df04, flags=<optimized out>) at 
drivers/xenomai/can/rtcan_raw.c:655
#3  0xc111f205 in __rt_dev_recvmsg (user_info=<optimized out>, 
fd=<optimized out>,
     msg=<error reading variable: DWARF-2 expression error: DW_OP_reg 
operations must be used either alone or in conjunction with DW_OP_piece 
or DW_OP_bit_piece.>, flags=0) at kernel/xenomai/skins/rtdm/core.c:575
#4  0xc11241e7 in sys_rtdm_recvmsg (regs=0xd796dfb4) at 
kernel/xenomai/skins/rtdm/syscall.c:91
#5  0xc10d6dfb in do_hisyscall_event (data=<optimized out>, 
stage=<optimized out>, event=<optimized out>) at 
kernel/xenomai/nucleus/shadow.c:2342
#6  hisyscall_event (event=<optimized out>, ipd=<optimized out>, 
data=<optimized out>) at kernel/xenomai/nucleus/shadow.c:2454
#7  0xc109ced6 in ipipe_syscall_hook (ipd=<optimized out>, 
regs=<optimized out>) at kernel/ipipe/compat.c:237
#8  0xc109b51f in __ipipe_notify_syscall (regs=<optimized out>) at 
kernel/ipipe/core.c:972
#9  0xc101afb4 in __ipipe_syscall_root (regs=0xd796dfb4) at 
arch/x86/kernel/ipipe.c:556
#10 0xc1684738 in ?? () at arch/x86/kernel/entry_32.S:479
#11 0xb76ea424 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


In my previous configuration, disabling CONFIG_SMP was enough to 
workaround it, but in that new case
I have other bad side-effects (console and X server frozen at startup) 
that prevent me to work correctly.

Regards
Thierry

Le 23/09/2012 15:23, Gilles Chanteperdrix a écrit :
> On 09/23/2012 09:42 AM, Thierry Bultel wrote:
>
>> Hi,
>>
>> My configuration is linux-3.2.21+ipipe-core-3.2.21-arm-1.patch,
>> running in qemu 1.2.0 for versatile express. I have CONFIG_SMP but
>> qemu is launched with 1 core only (else it does not boot, keeps hung
>> just after "booting the kernel", but that is not the point here).
>
> Basically, versatile express is not a board supported by the I-pipe
> patch, so, the first thing is to check that the I-pipe port is working
> correctly. For instance, I would run tsc -w first to see if the tsc
> emulation is working correctly. Then you can use this document:
>
> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
>
> As a check list.
>
> Also, some modifications would be needed to get it working in SMP mode.
> This should be much easier to start with the I-pipe kernel for 3.4,
> except for the "global timer" which seems not to be present on versatile
> express, so, some code would be needed to skip the initialization in
> gt_setup when we detect a processor that does not have a global timer.
>