Re: Rtai Digest, Vol 99, Issue 34
Francescodario Cuzzocrea <[email protected]>
| Newsgroups | gmane.linux.real-time.rtai |
|---|---|
| Message-ID | <CADnVkj97n4a70=q=ifgTmv9f_6PmoVF77cU6m1rh-pT3jNsaNA@mail.gmail.com> |
If you want to try rtai5 please try to use the sched.c and the config(adjust it for your needs) file of my previous email on kernel 3.18 and let us know if it fix the problem. Thank You. Il sab 19 mar 2016, 08:21 <[email protected]> ha scritto: > Send Rtai mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rtai digest..." > > > Today's Topics: > > 1. Re: general protection fault on RTAI 4.0 (JB) > 2. Re: Rtai Digest, Vol 99, Issue 31 (JB) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 18 Mar 2016 17:27:54 -0600 > From: JB <[email protected]> > To: "[email protected]" <[email protected]> > Subject: Re: [Rtai] general protection fault on RTAI 4.0 > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8; format=flowed > > More info....this only shows up on the i5-3470 CPU. > I've tested it with some i3 processors and other quad core i5-4590's and > some older E7500 core 2 duo's. All those work fine, but the rtai > testsuite crashes on the i5-3470 within the first two iterations of output. > > JB > > > On 3/18/2016 11:57, JB wrote: > > Hello again :) > > > > The reason I was attempting to get RTAI 5.0 test1 working is because I > > ran into a problem using RTAI 4.0 on one particular CPU/motherboard > > and I'm having a really hard time figuring out what the problem is. > > Here is what I'm seeing with RTAI 4.0 on a 3.8.13 kernel which I've > > been successfully using on other systems for months. I attached my > > kernel config and rtai config. Here is what I get when I try to run > > the latency test: > > > > Mar 18 03:55:45 localhost kernel: [ 91.508079] > > Mar 18 03:55:45 localhost kernel: [ 91.508079] LXRT CHANGED MODE > > (TRAP), PID = 1021, VEC = 13, SIGNO = 11. > > Mar 18 03:55:45 localhost kernel: [ 91.508101] general protection > > fault: 0000 [#1] PREEMPT SMP > > Mar 18 03:55:45 localhost kernel: [ 91.508157] Modules linked in: > > rtai_msg(OF) rtai_mbx(OF) rtai_sem(OF) rtai_sched(OF) rtai_malloc(POF) > > rtai_hal(OF) snd_hda_codec_realtek snd_hda_intel snd_hda_codec > > snd_hwdep snd_seq snd_seq_device snd_pcm e1000e iTCO_wdt > > iTCO_vendor_support snd_page_alloc snd_timer snd mei tpm_tis tpm > > coretemp crc32c_intel ghash_clmulni_intel microcode nfsd tpm_bios > > pcspkr i2c_i801 lpc_ich shpchp mfd_core soundcore auth_rpcgss nfs_acl > > lockd sunrpc i915 i2c_algo_bit drm_kms_helper drm video > > Mar 18 03:55:45 localhost kernel: [ 91.508339] CPU 0 > > Mar 18 03:55:45 localhost kernel: [ 91.508348] Pid: 1021, comm: > > latency Tainted: PF O 3.8.13-ds #6 /DQ77MK > > Mar 18 03:55:45 localhost kernel: [ 91.508374] RIP: > > 0010:[<ffffffff8102b43b>] [<ffffffff8102b43b>] > > native_apic_msr_write+0x2b/0x30 > > Mar 18 03:55:45 localhost kernel: [ 91.508404] RSP: > > 0018:ffff88006aeabde8 EFLAGS: 00010246 > > Mar 18 03:55:45 localhost kernel: [ 91.508420] RAX: 0000000002000000 > > RBX: 0000000000000001 RCX: 0000000000000831 > > Mar 18 03:55:45 localhost kernel: [ 91.508440] RDX: 0000000000000000 > > RSI: 0000000002000000 RDI: 0000000000000031 > > Mar 18 03:55:45 localhost kernel: [ 91.508460] RBP: ffff88006aeabde8 > > R08: 0000000000000001 R09: 0000000000000045 > > Mar 18 03:55:45 localhost kernel: [ 91.508481] R10: ffffffffa02b8d90 > > R11: 0000000000003246 R12: 0000000000000201 > > Mar 18 03:55:45 localhost kernel: [ 91.508501] R13: 0000000000051820 > > R14: ffffffffa02c4450 R15: fffffffffffffa1e > > Mar 18 03:55:45 localhost kernel: [ 91.508522] FS: > > 00007f5613b34740(0000) GS:ffff880100200000(0000) knlGS:0000000000000000 > > Mar 18 03:55:45 localhost kernel: [ 91.508545] CS: 0010 DS: 0000 > > ES: 0000 CR0: 0000000080050033 > > Mar 18 03:55:45 localhost kernel: [ 91.508562] CR2: 000000000042fad0 > > CR3: 000000006ae66000 CR4: 00000000001407f0 > > Mar 18 03:55:45 localhost kernel: [ 91.508582] DR0: 0000000000000000 > > DR1: 0000000000000000 DR2: 0000000000000000 > > Mar 18 03:55:45 localhost kernel: [ 91.508603] DR3: 0000000000000000 > > DR6: 00000000ffff0ff0 DR7: 0000000000000400 > > Mar 18 03:55:45 localhost kernel: [ 91.508623] I-pipe domain Linux > > Mar 18 03:55:45 localhost kernel: [ 91.508633] Process latency (pid: > > 1021, threadinfo ffff88006aea8000, task ffff88006b3d9770) > > Mar 18 03:55:45 localhost kernel: [ 91.508657] Stack: > > Mar 18 03:55:45 localhost kernel: [ 91.508664] ffff88006aeabe18 > > ffffffffa02c3876 00007fff3e178bc0 0000000000051820 > > Mar 18 03:55:45 localhost kernel: [ 91.508690] ffffc900046a1230 > > 00007fff3e178bc0 ffff88006aeabe58 ffffffffa02c45a1 > > Mar 18 03:55:45 localhost kernel: [ 91.508716] 00007fff3e178b90 > > 00007fff3e178bb8 0000000000000200 000000000000004b > > Mar 18 03:55:45 localhost kernel: [ 91.508742] Call Trace: > > Mar 18 03:55:45 localhost kernel: [ 91.508754] [<ffffffffa02c3876>] > > mbx_signal.isra.4+0x1f6/0x290 [rtai_mbx] > > Mar 18 03:55:45 localhost kernel: [ 91.508775] [<ffffffffa02c45a1>] > > _rt_mbx_send_if+0x151/0x1f0 [rtai_mbx] > > Mar 18 03:55:45 localhost kernel: [ 91.508798] [<ffffffffa02ad6a8>] > > rtai_lxrt_invoke+0x108/0x1160 [rtai_sched] > > Mar 18 03:55:45 localhost kernel: [ 91.508821] [<ffffffffa02acb95>] > > lxrt_intercept_syscall+0x95/0x130 [rtai_sched] > > Mar 18 03:55:45 localhost kernel: [ 91.508844] [<ffffffff810e01d8>] > > __ipipe_notify_kevent+0x18/0x20 > > Mar 18 03:55:45 localhost kernel: [ 91.508863] [<ffffffff8102585a>] > > __ipipe_syscall_root+0x3a/0xe0 > > Mar 18 03:55:45 localhost kernel: [ 91.508883] [<ffffffff812deada>] > > __ipipe_syscall_root_thunk+0x35/0x67 > > Mar 18 03:55:45 localhost kernel: [ 91.508904] [<ffffffff815c7327>] > > ? system_call_after_swapgs+0x54/0x6d > > Mar 18 03:55:45 localhost kernel: [ 91.508923] Code: 55 81 ff e0 00 > > 00 00 48 89 e5 74 21 89 f8 83 e0 ef 83 f8 20 74 17 81 ff d0 00 00 00 > > 74 0f c1 ef 04 31 d2 89 f0 8d 8f 00 08 00 00 <0f> 30 5d c3 90 55 81 ff > > e0 00 00 00 b8 ff ff ff ff 48 89 e5 74 > > Mar 18 03:55:45 localhost kernel: [ 91.509073] RIP > > [<ffffffff8102b43b>] native_apic_msr_write+0x2b/0x30 > > Mar 18 03:55:45 localhost kernel: [ 91.509094] RSP <ffff88006aeabde8> > > Mar 18 03:55:45 localhost kernel: [ 91.530153] ---[ end trace > > 4ad3f2f6dc4cb6a7 ]--- > > Mar 18 03:55:45 localhost kernel: > > LXRT CHANGED MODE (TRAP), PID = 1021, VEC = 13, SIGNO = 11. > > Mar 18 03:55:45 localhost kernel: [ 91.531685] LXRT releases PID > > 1021 (ID: latency). > > Mar 18 03:55:45 localhost kernel: general protection fault: 0000 [#1] > > PREEMPT SMP > > Mar 18 03:55:45 localhost kernel: Modules linked in: rtai_msg(OF) > > rtai_mbx(OF) rtai_sem(OF) rtai_sched(OF) rtai_malloc(POF) rtai_hal(OF) > > snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq > > snd_seq_device snd_pcm e1000e iTCO_wdt iTCO_vendor_support > > snd_page_alloc snd_timer snd mei tpm_tis tpm coretemp crc32c_intel > > ghash_clmulni_intel microcode nfsd tpm_bios pcspkr i2c_i801 lpc_ich > > shpchp mfd_core soundcore auth_rpcgss nfs_acl lockd sunrpc i915 > > i2c_algo_bit drm_kms_helper drm video > > > > > ================================================================================ > > > > > > > > Some of the CPUs we use are 4 cores but have 2 disabled so we can > > maintain backward compatibility and this is from /proc/cpuinfo: > > > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 58 > > model name : Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz > > stepping : 9 > > microcode : 0x1b > > cpu MHz : 3192.803 > > cache size : 6144 KB > > physical id : 0 > > siblings : 2 > > core id : 0 > > cpu cores : 2 > > apicid : 0 > > initial apicid : 0 > > fpu : yes > > fpu_exception : yes > > cpuid level : 13 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > > syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl > > xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl > > vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt > > tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt > > pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms > > bogomips : 6385.60 > > clflush size : 64 > > cache_alignment : 64 > > address sizes : 36 bits physical, 48 bits virtual > > power management: > > > > processor : 1 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 58 > > model name : Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz > > stepping : 9 > > microcode : 0x1b > > cpu MHz : 3192.803 > > cache size : 6144 KB > > physical id : 0 > > siblings : 2 > > core id : 1 > > cpu cores : 2 > > apicid : 2 > > initial apicid : 2 > > fpu : yes > > fpu_exception : yes > > cpuid level : 13 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > > syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl > > xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl > > vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt > > tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm arat epb xsaveopt > > pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms > > bogomips : 6385.60 > > clflush size : 64 > > cache_alignment : 64 > > address sizes : 36 bits physical, 48 bits virtual > > power management: > > > ======================================================================================= > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > Message: 2 > Date: Sat, 19 Mar 2016 01:21:08 -0600 > From: JB <[email protected]> > To: Francescodario Cuzzocrea > <[email protected]>, [email protected] > Subject: Re: [Rtai] Rtai Digest, Vol 99, Issue 31 > Message-ID: <[email protected]> > Content-Type: text/plain; charset="windows-1252"; Format="flowed" > > Thank you!!!!! I don't know if it was something with my kernel config > (which I'm happy to share if needed) or what but your kernel config > combined with probably the same sched.c that Paulo sent me a couple days > ago as well has in fact done the trick! The behavior now very closely > resembles the prior behavior. > > > On 3/18/2016 14:36, Francescodario Cuzzocrea wrote: > > [Call for Testing ] > > > > I also had these kind of problems on my machines with RTAI 5.0-test1. > > Today I tried the modified sched.c that Paolo sent to me a couple of > > days ago and now everything works fine (at least on my machines, for > > my applications (primary simulink applications generated by real time > > workshop with rtai target)). > > I'm using kernel 3.18 on arch linux. > > I'm attacching to this mail the modified sched.c and my kernel .config > > file as reference in order to enable more people to test the changes. > > Thank You. > > > > Il giorno mer 16 mar 2016 alle ore 13:38 <[email protected] > > <mailto:[email protected]>> ha scritto: > > > > Send Rtai mailing list submissions to > > [email protected] <mailto:[email protected]> > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > or, via email, send a message with subject or body 'help' to > > [email protected] <mailto:[email protected]> > > > > You can reach the person managing the list at > > [email protected] <mailto:[email protected]> > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Rtai digest..." > > > > > > Today's Topics: > > > > 1. Re: rtai task causes rcu problems on exit (JB) > > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 15 Mar 2016 20:23:59 -0600 > > From: JB <[email protected] <mailto:[email protected]>> > > To: "[email protected] <mailto:[email protected]>" <[email protected] > > <mailto:[email protected]>> > > Subject: Re: [Rtai] rtai task causes rcu problems on exit > > Message-ID: <[email protected] > > <mailto:[email protected]>> > > Content-Type: text/plain; charset=windows-1252; format=flowed > > > > I don't think it's the kernel. I think it's changes to RTAI. I'm > going > > to need to spend some time with a simplified RTAI application to > > see if > > I can execute it hard real time without causing the problem. > > > > Under RTAI 5.0-test with kernel 3.10.32 I get slightly different > > behavior, but essentially the same problem. The hard realtime task > > essentially hangs the system. If I run the exact same task with > > identical code using RTAI 4.0 on kernel 3.8.13, it works perfectly. > > > > > > > > On 3/13/2016 20:59, JB wrote: > > > Interesting, it sounds very very similar to what I'm seeing. > > > Everything works great after starting the task and synchronizing > the > > > tasks/processes, but either the first time or the time after that, > I > > > lose system responsiveness and get the warnings. So do I understand > > > you correctly in that you are saying we have a bug in our shutdown > > > sequence? It has worked flawlessly for years. Did something > > change in > > > how realtime is stopped? If so, what is the appropriate shutdown > > > sequence? > > > > > > When I have my system back I will look into that and try kernel > > 3.10. > > > > > > JB > > > > > > > > > On 3/13/2016 17:24, Paolo Mantegazza wrote: > > >> Perhaps, I've been able to reproduce your problem. It did not > > appear > > >> under heavy RTAI load. My PC was barely usable, but once at the > > >> closing of the tasks. > > >> I tried a few other times but everything was OK. Since some of the > > >> many example I launched start-stop the hard timer, while a few > > other > > >> check if that has to be done or not, it is then likely that I > > closed > > >> one that stopped the timer., so that the remaining timed task > began > > >> seeing overruns and looped without a pause, making the RCU > messages > > >> appear. > > >> I do not know if something like that could happen in you case > also, > > >> just my try to help. > > >> > > >> Paolo > > >> > > >> ________________________________________ > > >> From: JB [[email protected] <mailto:[email protected]>] > > >> Sent: Sunday, March 13, 2016 9:40 PM > > >> To: Paolo Mantegazza; [email protected] <mailto:[email protected]> > > >> Subject: Re: [Rtai] rtai task causes rcu problems on exit > > >> > > >> Indeed, I'll see what I can do and report back. > > >> > > >> > > >> On 3/13/2016 14:19, Paolo Mantegazza wrote: > > >>> BTW, RTAI 5 supports 3.10 also, which is closer (in time) to 3.8. > > >>> Maybe that the RCU diagnosis trouble you is not there yet. > > >>> A nice chance to contribute a checking for it also. > > >>> Paolo > > >>> > > >>> ________________________________________ > > >>> From: Rtai [[email protected] > > <mailto:[email protected]>] on behalf of JB [[email protected] > > <mailto:[email protected]>] > > >>> Sent: Sunday, March 13, 2016 7:21 PM > > >>> To: [email protected] <mailto:[email protected]> > > >>> Subject: Re: [Rtai] rtai task causes rcu problems on exit > > >>> > > >>> Thanks Paolo! Unfortunately, it definitely has to do with the > > >>> combination of upgrade to 3.18.22 and rtai-5.0-test1. > > >>> > > >>> Previously I was running RTAI 4.0 on a 3.8.13 kernel and prior > > to that > > >>> it was earlier 3.x and 2.6.x and 2.4.x kernels. The real-time > > >>> processing > > >>> components of the application have remained largely unchanged > > beyond > > >>> the > > >>> minor changes to move off deprecated things (like better SMP > > support in > > >>> the application when moving from 2.4 to 2.6 and migrating from > > rtai > > >>> fifos to rtai mailboxes in later version of 2.6. Other > > applications > > >>> have > > >>> always been very responsive! Just as soon as I tried to go to > > 3.18.22 > > >>> and rtai-5.0-test1 did this start happening. > > >>> > > >>> I had already read the documentation at the URL you gave me. > > However, > > >>> while it does talk about settings to disable RCU, those > > settings appear > > >>> to be ignored. I attempted to enable the suppression of RCU > > and the > > >>> setting was completely ignored. The RTAI application we use is > > running > > >>> at 2.4kHz and never overruns. It's nothing too aggressive and > > certainly > > >>> shouldn't be causing this. > > >>> > > >>> I upgraded because I was getting a crash on some CPUs with > > rtai-4.0 and > > >>> 3.8.13. However, I've spent quite a bit of time on trying to > > figure out > > >>> what's wrong and without busting out all the kernel debugging and > > >>> hacking tools and climbing into it's guts I'm unable to > > determine the > > >>> cause. So, I think I'll go back to 3.8.13 and see if I can > > make that > > >>> work again. > > >>> > > >>> > > >>> > > >>> > > >>> On 3/13/2016 04:50, Paolo Mantegazza wrote: > > >>>> My assumption is that your task steals too much time too Linux > > >>>> somewhere, at least to annoy the some read-copy-update stuff. > > >>>> Somewhere on the net I found: > > >>>> "You probably have a real time application that is consuming all > > >>>> cpu (some bad implementation) and because of its realtime > > >>>> scheduling priority the system doesn't have enough resources > > >>>> available for other tasks.". Nothe that (s)hewas not talking of > > >>>> hard real time but simple of the real time oprion available to a > > >>>> super user under standard Linux POSIX. > > >>>> I do not know if I and the guy on the net are right but if your > > >>>> RTAI task is running fine, since RTAI very hardly locks out any > > >>>> LINUX activity what above might be even a truer justification > > for a > > >>>> CPU stall, in LINUX view. After all RTAI is a LINUX staller. > > >>>> Maybe the following can help: > > >>>> shttps://www.kernel.org/doc/Documentation/RCU/stallwarn.txt > > <http://www.kernel.org/doc/Documentation/RCU/stallwarn.txt> > > >>>> Paolo > > >>>> ________________________________________ > > >>>> From: Rtai [[email protected] > > <mailto:[email protected]>] on behalf of JB [[email protected] > > <mailto:[email protected]>] > > >>>> Sent: Sunday, March 13, 2016 4:02 AM > > >>>> To: [email protected] <mailto:[email protected]> > > >>>> Subject: Re: [Rtai] rtai task causes rcu problems on exit > > >>>> > > >>>> Correction, they occur the entire time the real time task is > > >>>> running. Is > > >>>> there a way to disable this somehow or configure it so it is > > >>>> ignored. It > > >>>> is cause multi-second delays in the execution of other programs > > >>>> running > > >>>> on the same system as the real-time task. > > >>>> > > >>>> > > >>>> On 3/12/2016 19:52, JB wrote: > > >>>>> Hi, > > >>>>> I'm a little confused about some behavior I'm currently > > seeing after > > >>>>> upgrading to kernel 3.18.22 and RTAI 5.0-test1. After my > > real-time > > >>>>> task ends the first, time all seems fine. However, if I > > start it up a > > >>>>> second time, then stop it, it doesn't stop for a while. After a > > >>>>> while, > > >>>>> it stops and the messages below show up in the logs. Is RTAI > > >>>>> conflicting in some way with this new RCU feature of the > kernel? > > >>>>> > > >>>>> > > >>>>> Mar 12 11:56:00 localhost kernel: [ 249.450228] INFO: > > rcu_preempt > > >>>>> detected stalls on CPUs/tasks: {} (detected by 0, t=21104 > > jiffies, > > >>>>> g=11573, c=11572, q=30 > > >>>>> Mar 12 11:56:00 localhost kernel: [ 249.450234] INFO: Stall > > ended > > >>>>> before state dump start > > >>>>> Mar 12 11:56:00 localhost kernel: INFO: rcu_preempt detected > > >>>>> stalls on > > >>>>> CPUs/tasks: {} (detected by 0, t=21104 jiffies, g=11573, > > c=11572, > > >>>>> q=3068) > > >>>>> Mar 12 11:56:00 localhost kernel: INFO: Stall ended before > > state dump > > >>>>> start > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625505] INFO: > > rcu_preempt > > >>>>> detected stalls on CPUs/tasks: { 1} (detected by 0, t=21524 > > jiffies, > > >>>>> g=11575, c=11574, q= > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625511] Task dump > > for CPU 1: > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625512] swapper/1 > > R > > >>>>> running task 12624 0 1 0x00200000 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625516] > ffff880077417d00 > > >>>>> 0000000000000082 0000000000000000 0000000000000000 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625519] > ffff880037096300 > > >>>>> ffff880079fcda00 00000000fffffffa ffffc90004704230 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625521] > ffffffffa0170e80 > > >>>>> ffffffffa0170e80 0000000000000001 ffffffffa01b5708 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625524] Call Trace: > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625530] > > [<ffffffffa015ed27>] > > >>>>> rt_timer_handler+0x477/0x7e0 [rtai_sched] > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625532] > > [<ffffffffa015da1a>] > > >>>>> rtai_hirq_dispatcher+0x6a/0x1c0 [rtai_sched] > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625536] > > [<ffffffff810d63f3>] > > >>>>> __ipipe_dispatch_irq+0xd3/0x1b0 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625539] > > [<ffffffff81031503>] > > >>>>> __ipipe_handle_irq+0x73/0x190 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625542] > > [<ffffffff816a16c0>] > > >>>>> apic_timer_interrupt+0x60/0x90 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625544] > > [<ffffffff813192f3>] > > >>>>> ? __this_cpu_preempt_check+0x13/0x20 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625593] > > [<ffffffffa180cd60>] > > >>>>> ? _nv008584rm+0x90/0x3e0 [nvidia] > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625596] > > [<ffffffff810919d0>] > > >>>>> ? rcu_eqs_enter_common.isra.43+0x60/0x120 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625598] > > [<ffffffff813192d7>] > > >>>>> ? debug_smp_processor_id+0x17/0x20 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625601] > > [<ffffffff8100c540>] > > >>>>> ? mwait_idle+0x60/0xa0 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625603] > > [<ffffffff8100d0ba>] > > >>>>> arch_cpu_idle+0xa/0x10 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625606] > > [<ffffffff810826a9>] > > >>>>> cpu_startup_entry+0x319/0x470 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625609] > > [<ffffffff810a5807>] > > >>>>> ? clockevents_config_and_register+0x27/0x30 > > >>>>> Mar 12 11:56:22 localhost kernel: [ 271.625611] > > [<ffffffff81032473>] > > >>>>> start_secondary+0x143/0x150 > > >>>>> Mar 12 11:56:22 localhost kernel: INFO: rcu_preempt detected > > >>>>> stalls on > > >>>>> CPUs/tasks: { 1} (detected by 0, t=21524 jiffies, g=11575, > > c=11574, > > >>>>> q=1230) > > >>>>> Mar 12 11:56:22 localhost kernel: Task dump for CPU 1: > > >>>>> Mar 12 11:56:22 localhost kernel: swapper/1 R running > task > > >>>>> 12624 0 1 0x00200000 > > >>>>> Mar 12 11:56:22 localhost kernel: ffff880077417d00 > > 0000000000000082 > > >>>>> 0000000000000000 0000000000000000 > > >>>>> Mar 12 11:56:22 localhost kernel: ffff880037096300 > > ffff880079fcda00 > > >>>>> 00000000fffffffa ffffc90004704230 > > >>>>> Mar 12 11:56:22 localhost kernel: ffffffffa0170e80 > > ffffffffa0170e80 > > >>>>> 0000000000000001 ffffffffa01b5708 > > >>>>> Mar 12 11:56:22 localhost kernel: Call Trace: > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffffa015ed27>] > > >>>>> rt_timer_handler+0x477/0x7e0 [rtai_sched] > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffffa015da1a>] > > >>>>> rtai_hirq_dispatcher+0x6a/0x1c0 [rtai_sched] > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff810d63f3>] > > >>>>> __ipipe_dispatch_irq+0xd3/0x1b0 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff81031503>] > > >>>>> __ipipe_handle_irq+0x73/0x190 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff816a16c0>] > > >>>>> apic_timer_interrupt+0x60/0x90 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff813192f3>] ? > > >>>>> __this_cpu_preempt_check+0x13/0x20 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffffa180cd60>] ? > > >>>>> _nv008584rm+0x90/0x3e0 [nvidia] > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff810919d0>] ? > > >>>>> rcu_eqs_enter_common.isra.43+0x60/0x120 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff813192d7>] ? > > >>>>> debug_smp_processor_id+0x17/0x20 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff8100c540>] ? > > >>>>> mwait_idle+0x60/0xa0 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff8100d0ba>] > > >>>>> arch_cpu_idle+0xa/0x10 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff810826a9>] > > >>>>> cpu_startup_entry+0x319/0x470 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff810a5807>] ? > > >>>>> clockevents_config_and_register+0x27/0x30 > > >>>>> Mar 12 11:56:22 localhost kernel: [<ffffffff81032473>] > > >>>>> start_secondary+0x143/0x150 > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Rtai mailing list > > >>>>> [email protected] <mailto:[email protected]> > > >>>>> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > >>>> _______________________________________________ > > >>>> Rtai mailing list > > >>>> [email protected] <mailto:[email protected]> > > >>>> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > >>> _______________________________________________ > > >>> Rtai mailing list > > >>> [email protected] <mailto:[email protected]> > > >>> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > > > > > _______________________________________________ > > > Rtai mailing list > > > [email protected] <mailto:[email protected]> > > > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > Rtai mailing list > > [email protected] <mailto:[email protected]> > > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > > > ------------------------------ > > > > End of Rtai Digest, Vol 99, Issue 31 > > ************************************ > > > > > > > > _______________________________________________ > > Rtai mailing list > > [email protected] > > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mail.rtai.org/pipermail/rtai/attachments/20160319/ab2c6f31/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Rtai mailing list > [email protected] > https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai > > ------------------------------ > > End of Rtai Digest, Vol 99, Issue 34 > ************************************ > _______________________________________________ Rtai mailing list [email protected] https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai