On 18/12/17 07:33, Jan Kiszka wrote: > On 2017-12-15 21:42, Philippe Gerum wrote: >> On 12/15/2017 02:48 PM, Philippe Gerum wrote: >>> On 12/15/2017 02:40 PM, Jan Kiszka wrote: >>>> On 2017-12-15 14:29, Philippe Gerum wrote: >>>>> On 12/15/2017 02:20 PM, Jan Kiszka wrote: >>>>>> On 2017-12-15 13:25, Leopold Palomo-Avellaneda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I forgot something more: >>>>>>> >>>>>>> On 15/12/17 12:04, Philippe Gerum wrote: >>>>>>> >>>>>>> [...] >>>>>>>>> >>>>>>>>> I guess that there's something in the kernel config or somewhere in >>>>>>>>> 3.x that >>>>>>>>> affects the PCI cards. In 2.6.x worked. >>>>>>>> >>>>>>>> On x86, I'd dare to say that it worked mostly by accident, as revealed >>>>>>>> by SMAP later on. RTnet was out of the Xenomai tree in 2.6.x, some >>>>>>>> changes introduced during the merge into 3.x might have caused >>>>>>>> regressions, or maybe some latent issues started to bite when >>>>>>>> transposed >>>>>>>> in a different environment, just like the SMAP problem on x86, >>>>>>>> revealing >>>>>>>> an ancient Rnet bug. I genuinely don't know when things started to hit >>>>>>>> the fan. >>>>>>> >>>>>>> I don't know if it's relevant or not, or I didn't understand it, but I >>>>>>> think >>>>>>> that I still have problems with SMAP. If I activate it, I got: >>>>>> >>>>>> You must leave SMAP off until someone develops patches to convert the >>>>>> complete RTnet userspace API over to rtdm_copy_to/from_user. >>>>>> >>>>> >>>>> The patches in wip/rtnet-fixes address this issue, this is the patch >>>>> series I was referring to in this discussion. >>>>> >>>> >>>> Hmm, for the protocol core. I suspect you are missing further cases in >>>> RTmac and RTcfg (provided anyone needs them). >>>> >>> >>> The author of ioctl* support in both cases used copy_from_user directly, >>> maybe that is a problem with the calling mode. Ok, I'll check whether >>> rtnet_ioctls dispatcher actually routes from ioctl_nrt. Thanks. >>> >> >> RTcfg and RTmac are fine in the wip/rtnet-fixes branch. The rtnet_ioctls >> dispatcher runs over a regular ioctl_unlocked context from a chrdev, so >> there is no mode issue. All user memory is accessed via copy_to/from >> routines. I see no sendmsg/recvmsg which could raise the SMAP issue there. >> >> Do you have any hint about those missing cases? >> > > Nope, those two indeed seem to be fine. I didn't remember that we wrote > them with proper copy_to/from, also for the RT part (tdma_dev.c). The > core has a different, longer history, lacking any usercopy from day #1. >
Hi, I have pulled wip/rtnet-fixes branch with the last commit of Philippe from Sun Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type I have created the packages and new kernel with the same configuration that I had. I run my application, that it's a POSIX application Wrapped and I still have the same error when I activate SMAP: #######################################################3 Dec 18 14:58:13 bmm3 kernel: [ 118.545908] [Xenomai] switching slaveinfo_rt to secondary mode after exception #14 in kernel-space at 0xffffffffc0743981 (pid 1742) Dec 18 14:58:13 bmm3 kernel: [ 118.545924] BUG: unable to handle kernel paging request at 00007ffcc7389470 Dec 18 14:58:13 bmm3 kernel: [ 118.546586] IP: [<ffffffffc0743981>] rt_packet_ioctl+0x1a1/0x380 [rtpacket] Dec 18 14:58:13 bmm3 kernel: [ 118.547264] PGD 458a90067 Dec 18 14:58:13 bmm3 kernel: [ 118.547273] PUD 45a127067 Dec 18 14:58:13 bmm3 kernel: [ 118.547941] PMD 4584fe067 Dec 18 14:58:13 bmm3 kernel: [ 118.547946] PTE 8000000452fcb067 Dec 18 14:58:13 bmm3 kernel: [ 118.548626] Dec 18 14:58:13 bmm3 kernel: [ 118.549302] Oops: 0001 [#1] SMP Dec 18 14:58:13 bmm3 kernel: [ 118.549979] Modules linked in: rt_e1000e rt_loopback rtcfg rtudp rtipv4 rtmac rtpacket cdc_acm snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp nls_ascii coretemp nls_cp437 crct10dif_pclmul crc32_pclmul vfat ghash_clmulni_intel arc4 fat ppdev aesni_intel ath9k i915 aes_x86_64 ath9k_common lrw ath9k_hw gf128mul glue_helper pcan(O) ablk_helper ath cryptd mac80211 pcmcia pcmcia_core intel_cstate drm_kms_helper efi_pstore intel_uncore drm rtnet cfg80211 i2c_algo_bit fb_sys_fops intel_rapl_perf snd_hda_intel xeno_can_peak_pci syscopyarea sysfillrect iTCO_wdt xeno_can_sja1000 snd_hda_codec sysimgblt xeno_can iTCO_vendor_support sg snd_hda_core snd_hwdep mei_me snd_pcm snd_timer mei shpchp snd soundcore evdev pcspkr serio_raw efivars Dec 18 14:58:13 bmm3 kernel: [ 118.554017] battery hci_uart btbcm parport_pc btqca parport btintel bluetooth wmi video rfkill intel_lpss_acpi intel_lpss tpm_crb acpi_als kfifo_buf button industrialio sunrpc efivarfs ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto mbcache sd_mod crc32c_intel i2c_i801 i2c_smbus ahci libahci xhci_pci libata xhci_hcd scsi_mod usbcore fan i2c_hid hid fjes [last unloaded: rt_e1000e] Dec 18 14:58:13 bmm3 kernel: [ 118.556765] CPU: 5 PID: 1742 Comm: slaveinfo_rt Tainted: G O 4.9.51-xenomai-3.0.6-ipipe #1 Dec 18 14:58:13 bmm3 kernel: [ 118.557688] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Q170M-D3H, BIOS F2 01/11/2016 Dec 18 14:58:13 bmm3 kernel: [ 118.558628] I-pipe domain: Linux Dec 18 14:58:13 bmm3 kernel: [ 118.559567] task: ffff8d711868b140 task.stack: ffffa6a8409d4000 Dec 18 14:58:13 bmm3 kernel: [ 118.560518] RIP: 0010:[<ffffffffc0743981>] [<ffffffffc0743981>] rt_packet_ioctl+0x1a1/0x380 [rtpacket] Dec 18 14:58:13 bmm3 kernel: [ 118.561505] RSP: 0018:ffffa6a8409d7df8 EFLAGS: 00010202 Dec 18 14:58:13 bmm3 kernel: [ 118.562483] RAX: ffffa6a8409d7df8 RBX: ffff8d7118f10800 RCX: 0000000000000000 Dec 18 14:58:13 bmm3 kernel: [ 118.563471] RDX: 0000000000000000 RSI: 00007ffcc7389410 RDI: ffffa6a8409d7e08 Dec 18 14:58:13 bmm3 kernel: [ 118.564472] RBP: ffffa6a8409d7ec0 R08: 26009bc300000014 R09: 000000000000005d Dec 18 14:58:13 bmm3 kernel: [ 118.565473] R10: 00000000000000e4 R11: 00000000ffff4ebc R12: 0000000000000003 Dec 18 14:58:13 bmm3 kernel: [ 118.566477] R13: ffff8d7118f10940 R14: ffffa6a8402de040 R15: 00007ffcc7389470 Dec 18 14:58:13 bmm3 kernel: [ 118.567485] FS: 00007f4db6a00b80(0000) GS:ffff8d7120300000(0000) knlGS:0000000000000000 Dec 18 14:58:13 bmm3 kernel: [ 118.568516] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Dec 18 14:58:13 bmm3 kernel: [ 118.569560] CR2: 00007ffcc7389470 CR3: 000000045c362000 CR4: 00000000003406e0 Dec 18 14:58:13 bmm3 kernel: [ 118.570617] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Dec 18 14:58:13 bmm3 kernel: [ 118.571671] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Dec 18 14:58:13 bmm3 kernel: [ 118.572733] Stack: Dec 18 14:58:13 bmm3 kernel: [ 118.573799] 00007ffcc7389470 26009bc300000014 ffff8d7118f10800 ffffa6a8409d7ec0 Dec 18 14:58:13 bmm3 kernel: [ 118.574892] 0000000000000003 ffff8d711868b140 ffffa6a8402de040 0000000000011ba0 Dec 18 14:58:13 bmm3 kernel: [ 118.575987] ffffffff9476b9a8 00007ffcc7389400 401000221868b738 0000000000000010 Dec 18 14:58:13 bmm3 kernel: [ 118.577088] Call Trace: Dec 18 14:58:13 bmm3 kernel: [ 118.578180] [<ffffffff9476b9a8>] ? rtdm_fd_ioctl+0xa8/0x1e0 Dec 18 14:58:13 bmm3 kernel: [ 118.579278] [<ffffffff94770b20>] ? CoBaLt_fcntl+0x10/0x10 Dec 18 14:58:13 bmm3 kernel: [ 118.580377] [<ffffffff9468298d>] ? __ipipe_migrate_head+0x4d/0xb0 Dec 18 14:58:13 bmm3 kernel: [ 118.581452] [<ffffffff94770b20>] ? CoBaLt_fcntl+0x10/0x10 Dec 18 14:58:13 bmm3 kernel: [ 118.582541] [<ffffffff94770b2a>] ? CoBaLt_ioctl+0xa/0x10 Dec 18 14:58:13 bmm3 kernel: [ 118.583625] [<ffffffff947807ac>] ? ipipe_syscall_hook+0xfc/0x2b0 Dec 18 14:58:13 bmm3 kernel: [ 118.584698] [<ffffffff946fad9a>] ? __ipipe_notify_syscall+0xba/0x170 Dec 18 14:58:13 bmm3 kernel: [ 118.585774] [<ffffffff94b868af>] ? pipeline_syscall+0x8/0x1b Dec 18 14:58:13 bmm3 kernel: [ 118.586836] Code: 5f c3 b9 10 00 00 00 48 89 e6 e8 7b 36 14 00 48 3d 00 f0 ff ff 77 d8 83 78 08 13 4c 8b 38 4c 8d ab 40 01 00 00 0f 86 73 01 00 00 <66> 41 83 3f 11 0f 85 68 01 00 00 41 0f b7 6f 02 66 85 ed 0f 84 Dec 18 14:58:13 bmm3 kernel: [ 118.589196] RIP [<ffffffffc0743981>] rt_packet_ioctl+0x1a1/0x380 [rtpacket] Dec 18 14:58:13 bmm3 kernel: [ 118.590308] RSP <ffffa6a8409d7df8> Dec 18 14:58:13 bmm3 kernel: [ 118.591414] CR2: 00007ffcc7389470 Dec 18 14:58:13 bmm3 kernel: [ 118.592528] ---[ end trace 7e353ae197f2ee95 ]--- #######################################################3 So, I'm sorry, but it still fails. And about the addr2line for this case, some help for dummies will be helpful. 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? _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
