Re: [Xenomai] Xenomai 3.0.3 is broken in my system (was Regarding Xenomai and RTNET)

[Leopold Palomo-Avellaneda <leo@alaxarxa.net>]

El Dilluns, 3 d'octubre de 2016, a les 18:12:12, Leopold Palomo-Avellaneda va 
escriure:
> Hi,
> 
> I have been making some tests and I have arrived to the conclusion that the
> PC that I would like to install Xenomai and RTNET doesn't like it.
> 
> It's a PC with a motherboard Gigabyte Q170M-D3H-CF. I'm running 4.1.18 with
> xenomai 3.0.3. AFAIK, the xenomai tests works. However, when I try to run
> RTNET, I got crashes:
> 
> BUG: unable to handle kernel paging request at 00007f47ea0ef878
>  IP: [<ffffffffa0231580>] rt_udp_ioctl+0x50/0x74 [rtudp]
>  PGD 458887067 PUD 4590a1067 PMD 45921f067 PTE 8000000438863867
>  Oops: 0001 [#1] PREEMPT SMP
>  Modules linked in: rt_igb rt_loopback rtcfg rtudp rtipv4 rtmac rtpacket
> rtnet e100 mii ctr ccm binfmt_misc nfsd
>  CPU: 4 PID: 6773 Comm: LWRJointPositio Not tainted 4.1.18-xenomai-3.0.3 #1
>  Hardware name: Gigabyte Technology Co., Ltd. To be filled by
> O.E.M./Q170M-D3H- CF, BIOS F1 10/13/2015
>  task: ffff880459a26010 ti: ffff880459a38000 task.ti: ffff880459a38000
>  RIP: 0010:[<ffffffffa0231580>]  [<ffffffffa0231580>] rt_udp_ioctl+0x50/0x74
> [rtudp]
>  RSP: 0018:ffff880459a3be08  EFLAGS: 00010246
>  RAX: 00007f47ea0ef870 RBX: ffff880458d59400 RCX: ffff880458d59440
>  RDX: 0000000000000000 RSI: 0000000040100022 RDI: ffff880458d59400
>  RBP: 0000000000000003 R08: ffff880460297420 R09: 000000000000004e
>  R10: 00000000000000dc R11: ffff880459a3bdc0 R12: ffff880459a26010
>  R13: ffffc90001f05008 R14: 0000000040100022 R15: ffffffff81b85ec0
>  FS:  00007f47ea0f0700(0000) GS:ffff880460200000(0000)
> knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>  CR2: 00007f47ea0ef878 CR3: 000000045890c000 CR4: 00000000003406e0
>  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>  I-pipe domain Linux
>  Stack:
>   ffffffffa0231535 ffffffff8116fb70 ffff880459a265c0 00007f47ea0ef870
>   ffff8804599975d0 0000000000000010 ffff880459a3beb8 ffff880459a3be48
>   0000000000000002 ffff880459a26010 00007f47ea0ef870 ffff880459a26010
>  Call Trace:
>   [<ffffffffa0231535>] ? rt_udp_ioctl+0x5/0x74 [rtudp]
>   [<ffffffff8116fb70>] ? rtdm_fd_ioctl+0x100/0x270
>   [<ffffffff81174b40>] ? CoBaLt_fcntl+0x20/0x20
>   [<ffffffff81174b40>] ? CoBaLt_fcntl+0x20/0x20
>   [<ffffffff81174b50>] ? CoBaLt_ioctl+0x10/0x20
>   [<ffffffff81174b45>] ? CoBaLt_ioctl+0x5/0x20
>   [<ffffffff8118450a>] ? ipipe_syscall_hook+0x11a/0x360
>   [<ffffffff81108da7>] ? __ipipe_notify_syscall+0xe7/0x1d0
>   [<ffffffff81107185>] ? __ipipe_restore_root_nosync+0x5/0x30
>   [<ffffffff8158fb34>] ? pipeline_syscall+0x9/0x16
>  Code: 23 00 10 40 75 15 8b 50 08 48 8b 30 48 89 cf 48 83 c4 08 e9 a3 fd ff
> ff 0f 1f 00 48 89 c2 48 83 c4 08 e9 5
>  RIP  [<ffffffffa0231580>] rt_udp_ioctl+0x50/0x74 [rtudp]
>   RSP <ffff880459a3be08>
>  CR2: 00007f47ea0ef878
>  ---[ end trace 085d23e71de3ae4b ]---
> 
> 
> The funny (or ugly thing) is that, same kernel (I'm using debian packages)
> and almost the same Xenomai (compiled in each machine but with the same
> configure options) works in another similar box, with the same network
> cards (rt_igb). My application doesn't crash.
> 
> I also have tested another network card (rt_e1000_new) with the same core
> dump.
> 
> So, any idea how can I find some light in this? I don't know if it's a rtnet
> issue of a combination of kernel and hardware issue.

digging more in this I have found some interesting data. Although I though 
that previous message was equal to all the crashes is not true. I have much 
more messages with this error:


 BUG: unable to handle kernel paging request at 00007ffda8577680
 IP: [<ffffffff812fe5c8>] strncmp+0x8/0x50
 PGD 4589e3067 PUD 45c719067 PMD 459a88067 PTE 8000000453c52867
 Oops: 0001 [#1] SMP 
 Modules linked in: rt_loopback rtcfg rtudp rtipv4 rtmac rtpacket ctr ccm 
binfmt_misc nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache 
sunrpc joydev rt_e1000e rt_e1000 hid_generic usbhid nls_utf8 nls_cp437 
snd_hda_codec_hdmi vfat fat ppdev snd_hda_codec_realtek snd_hda_codec_generic 
x86_pkg_temp_thermal rt_e1000_new coretemp rt_igb rt_eepro100 kvm_intel rtnet 
kvm crct10dif_pclmul crc32_pclmul arc4 snd_hda_intel aesni_intel 
snd_hda_controller aes_x86_64 snd_hda_codec lrw snd_hda_core gf128mul 
snd_hwdep glue_helper snd_pcm ablk_helper cryptd snd_timer i915 snd evdev 
soundcore pcspkr efivars serio_raw i2c_i801 drm_kms_helper drm wmi battery 
i2c_algo_bit parport_pc video parport shpchp tpm_infineon tpm_tis tpm button 
ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 rfkill fuse
  autofs4 ext4 crc16 mbcache jbd2 sg sd_mod crc32c_intel ahci libahci xhci_pci 
libata xhci_hcd e100 mii scsi_mod usbcore usb_common fan thermal_sys i2c_hid 
hid i2c_core
 CPU: 7 PID: 1047 Comm: slaveinfo_rt Not tainted 4.1.18-xenomai-3.0.3 #2
 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Q170M-D3H-
CF, BIOS F1 10/13/2015
 task: ffff88045b0faaa0 ti: ffff88045b44c000 task.ti: ffff88045b44c000
 RIP: 0010:[<ffffffff812fe5c8>]  [<ffffffff812fe5c8>] strncmp+0x8/0x50
 RSP: 0018:ffff88045b44fda0  EFLAGS: 00010202
 RAX: ffffc90001f07008 RBX: ffffffffa0366740 RCX: 0000000000000072
 RDX: 0000000000000010 RSI: 00007ffda8577680 RDI: ffff880459aaa004
 RBP: ffff880459aaa000 R08: ffff880460597420 R09: 0000000000000056
 R10: 00000000000000dc R11: ffff88045b44fdc0 R12: 00007ffda8577680
 R13: 00007ffda8577680 R14: 0000000040180021 R15: ffffffff81b832c0
 FS:  00007f3094175740(0000) GS:ffff880460500000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 00007ffda8577680 CR3: 000000045a12a000 CR4: 00000000003406e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 I-pipe domain Linux
 Stack:
  ffffffffa035f151 0000000000052f08 0000000000000000 00007ffda8577680
  ffffffffa035f621 ffff880459a17000 0000000040180021 ffff88045b0faaa0
  ffffffffa03627be ffff880459a17000 0000000000000003 ffff88045b0faaa0
 Call Trace:
  [<ffffffffa035f151>] ? __rtdev_get_by_name+0x31/0x60 [rtnet]
  [<ffffffffa035f621>] ? rtdev_get_by_name+0x51/0xd0 [rtnet]
  [<ffffffffa03627be>] ? rt_socket_if_ioctl+0x2e/0x2f0 [rtnet]
  [<ffffffff8116505c>] ? rtdm_fd_ioctl+0xfc/0x220
  [<ffffffff81169d10>] ? CoBaLt_fcntl+0x20/0x20
  [<ffffffff81169d10>] ? CoBaLt_fcntl+0x20/0x20
  [<ffffffff81169d20>] ? CoBaLt_ioctl+0x10/0x20
  [<ffffffff81169d15>] ? CoBaLt_ioctl+0x5/0x20
  [<ffffffff8117932a>] ? ipipe_syscall_hook+0x25a/0x330
  [<ffffffff81100097>] ? __ipipe_notify_syscall+0xe7/0x1d0
  [<ffffffff811e7845>] ? fput+0x5/0x90
  [<ffffffff81567cf4>] ? pipeline_syscall+0x9/0x16


it shows that the crash is produced by __rtdev_get_by_name called from 
rtdev_get_by_name called from rt_socket_if_ioctl ... with a strncmp

that function is defined kernel/drivers/net/stack/rtdev.c

static struct rtnet_device *__rtdev_get_by_name(const char *name)
{
    int                 i;   
    struct rtnet_device *rtdev;
 

    for (i = 0; i < MAX_RT_DEVICES; i++) {
        rtdev = rtnet_devices[i];
        if ((rtdev != NULL) && (strncmp(rtdev->name, name, IFNAMSIZ) == 0))
            return rtdev;
    }
    return NULL;
}

however I couldn't understand why this function crashes in this box and not in 
the other box that I have tested. I will update BIOS and see what happen.

In any case, any help will be appreciated.

Best regards,

Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?