RTnet splash with current next and stable

Jan Kiszka jan.kiszka at siemens.com
Thu Dec 13 17:21:07 CET 2018


On 13.12.18 10:55, Pintu Agarwal wrote:
> On Tue, Dec 4, 2018 at 10:30 PM Jan Kiszka via Xenomai
> <xenomai at xenomai.org> wrote:
>>
>> On 31.10.18 18:10, Philippe Gerum wrote:
>>> On 10/30/18 11:28 AM, Jan Kiszka wrote:
>>>> Hi all,
>>>>
>>>> just testing new kernels with smokey, and one of them had RTnet on. This
>>>> triggered a bug with the net_packat_dgram test:
>>>>
>>>> [   50.610997] initializing loopback...
>>>> [   50.613799] RTnet: registered rtlo
>>>> [   50.692154] ------------[ cut here ]------------
>>>> [   50.693577] WARNING: CPU: 1 PID: 1119 at ../lib/list_debug.c:29 __list_add+0x62/0xb0
>>>> [   50.696832] list_add corruption. next->prev should be prev (ffffffffa0007d20), but was           (null). (next=ffff88003a8bb700).
>>>> [   50.700751] Modules linked in: rtpacket rtipv4 rt_loopback rt_e1000e rtnet
>>>> [   50.702518] CPU: 1 PID: 1119 Comm: smokey Not tainted 4.9.135+ #26
>>>> [   50.704188] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014
>>>> [   50.707861] I-pipe domain: Linux
>>>> [   50.709295]  ffffc90002943c10 ffffffff8146a31a ffffc90002943c60 0000000000000000
>>>> [   50.710335]  ffffc90002943c50 ffffffff810e9441 0000001da0007ca8 ffff88003a8bb700
>>>> [   50.710335]  ffffffffa0007d20 ffff88003a8bb700 000000000001d230 ffff88003a8bb640
>>>> [   50.710335] Call Trace:
>>>> [   50.710335]  [<ffffffff8146a31a>] dump_stack+0xa2/0xc8
>>>> [   50.710335]  [<ffffffff810e9441>] __warn+0xe1/0x100
>>>> [   50.710335]  [<ffffffff810e94af>] warn_slowpath_fmt+0x4f/0x60
>>>> [   50.710335]  [<ffffffff812b0b61>] ? __slab_alloc.isra.88+0xa1/0xd0
>>>> [   50.710335]  [<ffffffffa0003edb>] ? rtskb_pool_extend+0xbb/0x220 [rtnet]
>>>> [   50.710335]  [<ffffffff81498862>] __list_add+0x62/0xb0
>>>> [   50.710335]  [<ffffffffa000160a>] rtdev_map_rtskb+0x7a/0xa0 [rtnet]
>>>> [   50.710335]  [<ffffffffa0003f12>] rtskb_pool_extend+0xf2/0x220 [rtnet]
>>>> [   50.710335]  [<ffffffffa0004072>] rtskb_pool_init+0x32/0x70 [rtnet]
>>>> [   50.710335]  [<ffffffffa00043d2>] __rt_bare_socket_init+0x42/0x90 [rtnet]
>>>> [   50.710335]  [<ffffffffa0004501>] __rt_socket_init+0x81/0xd0 [rtnet]
>>>> [   50.710335]  [<ffffffffa0054477>] rt_packet_socket+0x27/0xb0 [rtpacket]
>>>> [   50.710335]  [<ffffffff81219dd7>] ? create_instance+0x67/0x80
>>>> [   50.710335]  [<ffffffff8121a772>] __rtdm_dev_socket+0x112/0x440
>>>> [   50.710335]  [<ffffffff8113bb09>] ? lock_release+0x2c9/0x440
>>>> [   50.710335]  [<ffffffff8122b200>] ? CoBaLt_open+0x40/0x40
>>>> [   50.710335]  [<ffffffff8122b20e>] CoBaLt_socket+0xe/0x20
>>>> [   50.710335]  [<ffffffff812412ca>] ipipe_syscall_hook+0x19a/0x460
>>>> [   50.710335]  [<ffffffff811ad8e9>] __ipipe_notify_syscall+0x79/0x400
>>>> [   50.710335]  [<ffffffff811adc9a>] ipipe_handle_syscall+0x2a/0xd0
>>>> [   50.710335]  [<ffffffff81002d6c>] do_syscall_64+0x3c/0x1c0
>>>> [   50.710335]  [<ffffffff8184f2c3>] entry_SYSCALL_64_after_swapgs+0x5d/0xdb
>>>> [   50.761499] ---[ end trace 633f1ec8aecb0735 ]---
>>>> [   50.762893] ------------[ cut here ]------------
>>>>
>>>> Anyone who hacked on this recently have a feeling?
>>>>
>>>
>>> No idea. I'll have a look.
>>>
>>>
>>
>> I think this one is still open. At least I do not remember having merged
>> anything related to that since then.
>>
>> As everyone is busy right now, I only wonder if we have a regression here, or if
>> it's just a preexisting issue that we can safely ignore for some v3.0.8.
>>
>> Jan
>>
> 
> I think I already reported similar rtnet loopback issue around 6
> months ago with 3.0.6 itself.
> This kind of issues are visible on x86, Beagle Bone/Raspberry Pi
> (arm), Hikey (arm64) , even with SMAP disabled in Kernel 4.9.x
> However, I did not see this issue with Virtual Box (Ubuntu guest).
> 

Thanks for the hint - though I failed to find your concrete email in the archive 
so far. I'm planning to try this out soon and then decide in which order to 
proceed (release and fix later, or the other way around).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux



More information about the Xenomai mailing list