Stack dump on ipipe 4.9.135-7 x86_64

Henning Schild henning.schild at siemens.com
Fri Dec 21 14:51:53 CET 2018


Am Thu, 20 Dec 2018 10:10:29 +0100
schrieb Jan Kiszka <jan.kiszka at siemens.com>:

> On 20.12.18 09:28, Mauro Salvini via Xenomai wrote:
> > Hi all,
> > 
> > I'm testing Xenomai 3 on an Intel Braswell board (Atom x5-E8000).
> > I'm using ipipe kernel at last commit from [1], branch ipipe-4.9.y,
> > 64bit build on a Debian Stretch 9.6 64bit.
> > Xenomai library is from [2], branch stable/v3.0.x on commit
> > bc53d03f (I haven't two last commits but seems not related). I
> > tried both 32bit (mixed ABI) and 64bit builds with same following
> > result.
> > 
> > I launch:
> > 
> > xeno-test -l "dohell -s xxx -p yyy -m xxx 90000" -T 90000
> > 
> > After a variable time (from minutes to hours) from latency test
> > start I get a few overruns that I discovered are generated by a
> > kernel stack dump (attached to mail the dmesg tail). Latency test
> > doesn't stop, and after this stackdump never reports other overruns
> > or latency peaks (seems I need to reboot to reproduce stack).
> > 
> > I read in this mailing list that on last patches much work has done
> > on FPU part, should it be related?
> > 
> > Glad to give other infos if you need.  
> 
> Thanks for reporting. Maybe we need your config later on, but I'm
> first of all looking at the code, see below.
> 
> In general, it's better to run the kernel with frame-pointers enabled
> to get more reliable backtraces, at least when an error occurs.
> 
> > 
> > Thanks in advance, regards.
> > 
> > Mauro
> > 
> > [1] https://gitlab.denx.de/Xenomai/ipipe
> > [2] https://gitlab.denx.de/Xenomai/xenomai
> > -------------- next part --------------
> > [  233.205940] /home/build-user/develop/linux-ipipe-4.9.y/arch/x86/xenomai/include/asm/xenomai/fptest.h:43:
> > Warning: Linux is compiled to use FPU in kernel-space. For this
> > reason, switchtest can not test using FPU in Linux kernel-space.
> > [  295.660454] ------------[ cut here ]------------ [  295.660461]
> > WARNING: CPU: 0 PID: 139
> > at /home/build-user/develop/linux-ipipe-4.9.y/arch/x86/include/asm/fpu/internal.h:502
> > xnarch_leave_root+0x1a4/0x1b0  
> 
> Henning, the kernel checks fpu->fpregs_active here and finds it off
> while Xenomai looks at fpu.fpstate_active - intentionally or by
> accident?

That was by accident. In eager mode they should mostly be in sync,
unless when playing the nasty tricks ipipe has to play. I guess there
is a path where we tried to "unown" a task that we unowned shortly
before. I did not try to find that path, i just sent a patch.

Mauro, since you can reproduce the problem you can probably tell if the
patch fixes it.

Henning

> Jan
> 
> > [  295.660465] Modules linked in: binfmt_misc msr iTCO_wdt
> > iTCO_vendor_support coretemp kvm_intel kvm irqbypass
> > crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel
> > aes_x86_64 lrw snd_pcm gf128mul glue_helper i915 ablk_helper
> > snd_timer cryptd snd soundcore pcspkr drm_kms_helper drm evdev
> > lpc_ich mfd_core fb_sys_fops syscopyarea sysfillrect sysimgblt sg
> > shpchp video button ip_tables x_tables autofs4 ext4 crc16 jbd2
> > fscrypto mbcache sd_mod hid_generic usbhid hid crc32c_intel ahci
> > igb i2c_i801 libahci i2c_smbus i2c_algo_bit xhci_pci dca ptp
> > pps_core libata xhci_hcd sdhci_pci sdhci usbcore scsi_mod mmc_core
> > fjes [last unloaded: rtnet] [  295.660660] CPU: 0 PID: 139 Comm:
> > jbd2/sda1-8 Tainted: G        W       4.9.135+ #1 [  295.660663]
> > Hardware name: Default string Default string/Q7-BW, BIOS
> > V1.20#KW050220A 03/16/2018 [  295.660666] I-pipe domain: Xenomai
> > [  295.660668]  0000000000000000 ffffffff823402c2 0000000000000000
> > 0000000000000000 [  295.660680]  ffffffff829cd400 ffffffff8206cb68
> > ffff985636908040 ffff985636504080 [  295.660706]  0000000000099f50
> > 0000000000000000 ffffbc1580563040 ffff98567ac9b940 [  295.660718]
> > Call Trace: [  295.660721]  [<ffffffff823402c2>] ?
> > dump_stack+0xb5/0xd3 [  295.660724]  [<ffffffff8206cb68>] ?
> > __warn+0xc8/0xf0 [  295.660727]  [<ffffffff82068734>] ?
> > xnarch_leave_root+0x1a4/0x1b0 [  295.660729]
> > [<ffffffff82173b56>] ? ___xnsched_run+0x3f6/0x4b0 [  295.660732]
> > [<ffffffff8219fbf6>] ? timerfd_handler+0x36/0x50 [  295.660735]
> > [<ffffffff8217b075>] ? xntimerq_insert+0x5/0xa0 [  295.660738]
> > [<ffffffff8216a7c9>] ? xnclock_tick+0x1a9/0x2c0 [  295.660740]
> > [<ffffffff8216cd8a>] ? xnintr_core_clock_handler+0x2fa/0x310
> > [  295.660743]  [<ffffffff82119b1a>] ? dispatch_irq_head+0x8a/0x120
> > [  295.660746]  [<ffffffff8203ad75>] ?
> > __ipipe_handle_irq+0x85/0x1b0 [  295.660749]
> > [<ffffffff82605ba9>] ? apic_timer_interrupt+0x89/0xb0
> > [  295.660752]  [<ffffffffc01502a6>] ? continue_block+0x22/0x54
> > [crc32c_intel] [  295.660754]  [<ffffffffc0150233>] ?
> > crc32c_pcl_intel_update+0x53/0x60 [crc32c_intel] [  295.660757]
> > [<ffffffffc031fa90>] ? jbd2_journal_commit_transaction+0x9e0/0x1850
> > [jbd2] [  295.660760]  [<ffffffff82603d60>] ?
> > __switch_to_asm+0x40/0x70 [  295.660763]  [<ffffffff820d19af>] ?
> > try_to_del_timer_sync+0x4f/0x80 [  295.660766]
> > [<ffffffffc0324c92>] ? kjournald2+0xe2/0x290 [jbd2] [  295.660768]
> > [<ffffffff820b0320>] ? wake_up_atomic_t+0x30/0x30 [  295.660771]
> > [<ffffffffc0324bb0>] ? commit_timeout+0x10/0x10 [jbd2]
> > [  295.660774]  [<ffffffff8208df65>] ? kthread+0xf5/0x110
> > [  295.660776]  [<ffffffff82603d60>] ? __switch_to_asm+0x40/0x70
> > [  295.660779]  [<ffffffff8208de70>] ? kthread_park+0x60/0x60
> > [  295.660782]  [<ffffffff82603de5>] ? ret_from_fork+0x55/0x60
> > [  295.660785] ---[ end trace b1bfa97fc17a203c ]--- [  705.768058]
> > perf: interrupt took too long (2543 > 2500), lowering
> > kernel.perf_event_max_sample_rate to 78500 [  865.772646] perf:
> > interrupt took too long (3207 > 3178), lowering
> > kernel.perf_event_max_sample_rate to 62250 




More information about the Xenomai mailing list