All of lore.kernel.org
 help / color / mirror / Atom feed
* FPU warn on ipipe 4.9.146-8 i386
@ 2019-01-11  8:57 Mauro Salvini
  2019-01-11  9:40 ` Henning Schild
  0 siblings, 1 reply; 8+ messages in thread
From: Mauro Salvini @ 2019-01-11  8:57 UTC (permalink / raw)
  To: xenomai

Hi all,

I'm testing same hardware of [1], with kernel 4.9.146 from ipipe-4.9.y
with [2] applied, compiled with ARCH=i386 and Xenomai 3.0.7.

Launching

xeno-test -l "dohell -s xxx -p yyy -m xxx 90000" -T 90000

I got this dump in dmesg, sometimes just after latency starts,
sometimes after few seconds (side effect is a max latency value
increase):

[  167.914184] ------------[ cut here ]------------
[  167.914208] WARNING: CPU: 0 PID: 606 at /home/build-ws/develop/linux-4.9.146/arch/x86/include/asm/fpu/internal.h:511 fpu__restore+0x1eb/0x2b0
[  167.914216] Modules linked in: intel_rapl intel_powerclamp iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm irqbypass crc32_pclmul aesni_intel xts aes_i586 lrw gf128mul ablk_helper cryptd snd_pcm intel_cstate snd_timer evdev snd soundcore i915 pcspkr drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt shpchp video lpc_ich mfd_core button ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto mbcache hid_generic usbhid hid mmc_block crc32c_intel i2c_i801 i2c_smbus igb i2c_algo_bit xhci_pci ptp pps_core xhci_hcd sdhci_pci sdhci usbcore mmc_core fjes [last unloaded: rtnet]
[  167.914768] CPU: 0 PID: 606 Comm: dohell Not tainted 4.9.146+ #1
[  167.914772] Hardware name: Default string Default string/Q7-BW, BIOS V1.20#KW050220A 03/16/2018
[  167.914775] I-pipe domain: Linux
[  167.914778]  f42e5e44 daeffa2d 00000000 db335030 dac1ff3b f42e5e74 dac59dea db34504c
[  167.914800]  00000000 0000025e db335030 000001ff dac1ff3b 000001ff f4291bc0 00000246
[  167.914822]  f4291c00 f42e5e88 dac59efb 00000009 00000000 00000000 f42e5ea4 dac1ff3b
[  167.914843] Call Trace:
[  167.914846]  [<daeffa2d>] dump_stack+0x9f/0xc2
[  167.914849]  [<dac1ff3b>] ? fpu__restore+0x1eb/0x2b0
[  167.914865]  [<dac59dea>] __warn+0xea/0x110
[  167.914868]  [<dac1ff3b>] ? fpu__restore+0x1eb/0x2b0
[  167.914871]  [<dac59efb>] warn_slowpath_null+0x2b/0x30
[  167.914874]  [<dac1ff3b>] fpu__restore+0x1eb/0x2b0
[  167.914877]  [<dac21b0a>] __fpu__restore_sig+0x2ba/0x680
[  167.914879]  [<dac22141>] fpu__restore_sig+0x31/0x50
[  167.914882]  [<dac13f52>] restore_sigcontext.isra.9+0xf2/0x110
[  167.914885]  [<dac149b9>] sys_sigreturn+0xa9/0xc0
[  167.914888]  [<dac019f5>] do_int80_syscall_32+0x85/0x190
[  167.914891]  [<db1a56d5>] entry_INT80_32+0x31/0x31
[  167.914898] ---[ end trace e57344f10f300a76 ]---

I found discussion at [3], and applied patch at [4] that comes from it,
but result is the same.

Starting xeno-test without -l argument result is the same.
Launching dohell alone (with same arguments as when launched from xeno-
test -l), dump does not appear.

Could be a Xenomai-related problem (though the stack seems not concern
Xenomai) or it is better to post it on LKML?

Thanks in advance, regards

Mauro

[1] https://xenomai.org/pipermail/xenomai/2018-December/040142.html
[2] https://xenomai.org/pipermail/xenomai/2019-January/040172.html
[3] https://lore.kernel.org/lkml/20181120102635.ddv3fvavxajjlfqk@linutr
onix.de/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/co
mmit/?h=linux-4.9.y&id=d3741e0390287056011950493a641524f49fa05a



^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: FPU warn on ipipe 4.9.146-8 i386
  2019-01-11  8:57 FPU warn on ipipe 4.9.146-8 i386 Mauro Salvini
@ 2019-01-11  9:40 ` Henning Schild
  2019-01-11  9:53   ` limingyu
  2019-01-11 13:47   ` Mauro Salvini
  0 siblings, 2 replies; 8+ messages in thread
From: Henning Schild @ 2019-01-11  9:40 UTC (permalink / raw)
  To: Mauro Salvini via Xenomai

Am Fri, 11 Jan 2019 09:57:50 +0100
schrieb Mauro Salvini via Xenomai <xenomai@xenomai.org>:

> Hi all,
> 
> I'm testing same hardware of [1], with kernel 4.9.146 from ipipe-4.9.y
> with [2] applied, compiled with ARCH=i386 and Xenomai 3.0.7.

To be honest i386 is not really tested anymore, in fact in 4.14 not
even supported at the moment. If you can you should go for x86_64.

> Launching
> 
> xeno-test -l "dohell -s xxx -p yyy -m xxx 90000" -T 90000
> 
> I got this dump in dmesg, sometimes just after latency starts,
> sometimes after few seconds (side effect is a max latency value
> increase):
> 
> [  167.914184] ------------[ cut here ]------------
> [  167.914208] WARNING: CPU: 0 PID: 606
> at /home/build-ws/develop/linux-4.9.146/arch/x86/include/asm/fpu/internal.h:511
> fpu__restore+0x1eb/0x2b0 [  167.914216] Modules linked in: intel_rapl
> intel_powerclamp iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm
> irqbypass crc32_pclmul aesni_intel xts aes_i586 lrw gf128mul
> ablk_helper cryptd snd_pcm intel_cstate snd_timer evdev snd soundcore
> i915 pcspkr drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect
> sysimgblt shpchp video lpc_ich mfd_core button ip_tables x_tables
> autofs4 ext4 crc16 jbd2 fscrypto mbcache hid_generic usbhid hid
> mmc_block crc32c_intel i2c_i801 i2c_smbus igb i2c_algo_bit xhci_pci
> ptp pps_core xhci_hcd sdhci_pci sdhci usbcore mmc_core fjes [last
> unloaded: rtnet] [  167.914768] CPU: 0 PID: 606 Comm: dohell Not
> tainted 4.9.146+ #1 [  167.914772] Hardware name: Default string
> Default string/Q7-BW, BIOS V1.20#KW050220A 03/16/2018 [  167.914775]
> I-pipe domain: Linux [  167.914778]  f42e5e44 daeffa2d 00000000
> db335030 dac1ff3b f42e5e74 dac59dea db34504c [  167.914800]  00000000
> 0000025e db335030 000001ff dac1ff3b 000001ff f4291bc0 00000246
> [  167.914822]  f4291c00 f42e5e88 dac59efb 00000009 00000000 00000000
> f42e5ea4 dac1ff3b [  167.914843] Call Trace:
> [  167.914846]  [<daeffa2d>] dump_stack+0x9f/0xc2
> [  167.914849]  [<dac1ff3b>] ? fpu__restore+0x1eb/0x2b0
> [  167.914865]  [<dac59dea>] __warn+0xea/0x110
> [  167.914868]  [<dac1ff3b>] ? fpu__restore+0x1eb/0x2b0
> [  167.914871]  [<dac59efb>] warn_slowpath_null+0x2b/0x30
> [  167.914874]  [<dac1ff3b>] fpu__restore+0x1eb/0x2b0
> [  167.914877]  [<dac21b0a>] __fpu__restore_sig+0x2ba/0x680
> [  167.914879]  [<dac22141>] fpu__restore_sig+0x31/0x50
> [  167.914882]  [<dac13f52>] restore_sigcontext.isra.9+0xf2/0x110
> [  167.914885]  [<dac149b9>] sys_sigreturn+0xa9/0xc0
> [  167.914888]  [<dac019f5>] do_int80_syscall_32+0x85/0x190
> [  167.914891]  [<db1a56d5>] entry_INT80_32+0x31/0x31 [  167.914898]
> ---[ end trace e57344f10f300a76 ]---

I am not sure which path leads you there. But it could well be a state
that was caused by the ipipe patch.

could you try this:

--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -426,6 +426,10 @@ void fpu__restore(struct fpu *fpu)
        /* Avoid __kernel_fpu_begin() right after fpregs_activate() */
        kernel_fpu_disable();
        trace_x86_fpu_before_restore(fpu);
+       if (fpregs_activate(fpu)) {
+               WARN_ON_FPU(fpu !=
this_cpu_read_stable(fpu_fpregs_owner_ctx));
+               fpregs_deactivate(fpu);
+       }
        fpregs_activate(fpu);
        copy_kernel_to_fpregs(&fpu->state);
        trace_x86_fpu_after_restore(fpu);

This would not be a proper fix, especially if you end up seeing that
warning ...

Henning

> I found discussion at [3], and applied patch at [4] that comes from
> it, but result is the same.
> 
> Starting xeno-test without -l argument result is the same.
> Launching dohell alone (with same arguments as when launched from
> xeno- test -l), dump does not appear.
> 
> Could be a Xenomai-related problem (though the stack seems not concern
> Xenomai) or it is better to post it on LKML?
> 
> Thanks in advance, regards
> 
> Mauro
> 
> [1] https://xenomai.org/pipermail/xenomai/2018-December/040142.html
> [2] https://xenomai.org/pipermail/xenomai/2019-January/040172.html
> [3]
> https://lore.kernel.org/lkml/20181120102635.ddv3fvavxajjlfqk@linutr
> onix.de/ [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/co
> mmit/?h=linux-4.9.y&id=d3741e0390287056011950493a641524f49fa05a
> 
> 



^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: FPU warn on ipipe 4.9.146-8 i386
  2019-01-11  9:40 ` Henning Schild
@ 2019-01-11  9:53   ` limingyu
  2019-01-11 13:51     ` Mauro Salvini
  2019-01-11 13:47   ` Mauro Salvini
  1 sibling, 1 reply; 8+ messages in thread
From: limingyu @ 2019-01-11  9:53 UTC (permalink / raw)
  To: xenomai

Hi, Mauro

Maybe you could refer to this disscusion below, and try the latesst 
stable xenomai code branch

v3.0.x/stable. 
https://xenomai.org/pipermail/xenomai/2018-December/040086.html

And the lasted xenomai code is here: 
https://gitlab.denx.de/Xenomai/xenomai/tree/stable/v3.0.x

On 1/11/19 5:40 PM, Henning Schild via Xenomai wrote:
> I got this dump in dmesg, sometimes just after latency starts,

-- 
Linx Software Co. Ltd. Sichuan Branch
E-mail: myli@linx-info.com


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: FPU warn on ipipe 4.9.146-8 i386
  2019-01-11  9:40 ` Henning Schild
  2019-01-11  9:53   ` limingyu
@ 2019-01-11 13:47   ` Mauro Salvini
  2019-01-14  9:39     ` Henning Schild
  1 sibling, 1 reply; 8+ messages in thread
From: Mauro Salvini @ 2019-01-11 13:47 UTC (permalink / raw)
  To: Henning Schild, Mauro Salvini via Xenomai

On Fri, 2019-01-11 at 10:40 +0100, Henning Schild wrote:
> Am Fri, 11 Jan 2019 09:57:50 +0100
> schrieb Mauro Salvini via Xenomai <xenomai@xenomai.org>:
> 
> > Hi all,
> > 
> > I'm testing same hardware of [1], with kernel 4.9.146 from ipipe-
> > 4.9.y
> > with [2] applied, compiled with ARCH=i386 and Xenomai 3.0.7.
> 
> To be honest i386 is not really tested anymore, in fact in 4.14 not
> even supported at the moment. If you can you should go for x86_64.
> 

Hi Henning,

Thank you. I'm trying i386 version due to legacy 32bit code that uses
rtnet (which cannot be used with mixed ABI).

> > Launching
> > 
> > xeno-test -l "dohell -s xxx -p yyy -m xxx 90000" -T 90000
> > 
> > I got this dump in dmesg, sometimes just after latency starts,
> > sometimes after few seconds (side effect is a max latency value
> > increase):
> > 
> > [  167.914184] ------------[ cut here ]------------
> > [  167.914208] WARNING: CPU: 0 PID: 606
> > at /home/build-ws/develop/linux-
> > 4.9.146/arch/x86/include/asm/fpu/internal.h:511
> > fpu__restore+0x1eb/0x2b0 [  167.914216] Modules linked in:
> > intel_rapl
> > intel_powerclamp iTCO_wdt iTCO_vendor_support coretemp kvm_intel
> > kvm
> > irqbypass crc32_pclmul aesni_intel xts aes_i586 lrw gf128mul
> > ablk_helper cryptd snd_pcm intel_cstate snd_timer evdev snd
> > soundcore
> > i915 pcspkr drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect
> > sysimgblt shpchp video lpc_ich mfd_core button ip_tables x_tables
> > autofs4 ext4 crc16 jbd2 fscrypto mbcache hid_generic usbhid hid
> > mmc_block crc32c_intel i2c_i801 i2c_smbus igb i2c_algo_bit xhci_pci
> > ptp pps_core xhci_hcd sdhci_pci sdhci usbcore mmc_core fjes [last
> > unloaded: rtnet] [  167.914768] CPU: 0 PID: 606 Comm: dohell Not
> > tainted 4.9.146+ #1 [  167.914772] Hardware name: Default string
> > Default string/Q7-BW, BIOS V1.20#KW050220A 03/16/2018
> > [  167.914775]
> > I-pipe domain: Linux [  167.914778]  f42e5e44 daeffa2d 00000000
> > db335030 dac1ff3b f42e5e74 dac59dea db34504c
> > [  167.914800]  00000000
> > 0000025e db335030 000001ff dac1ff3b 000001ff f4291bc0 00000246
> > [  167.914822]  f4291c00 f42e5e88 dac59efb 00000009 00000000
> > 00000000
> > f42e5ea4 dac1ff3b [  167.914843] Call Trace:
> > [  167.914846]  [<daeffa2d>] dump_stack+0x9f/0xc2
> > [  167.914849]  [<dac1ff3b>] ? fpu__restore+0x1eb/0x2b0
> > [  167.914865]  [<dac59dea>] __warn+0xea/0x110
> > [  167.914868]  [<dac1ff3b>] ? fpu__restore+0x1eb/0x2b0
> > [  167.914871]  [<dac59efb>] warn_slowpath_null+0x2b/0x30
> > [  167.914874]  [<dac1ff3b>] fpu__restore+0x1eb/0x2b0
> > [  167.914877]  [<dac21b0a>] __fpu__restore_sig+0x2ba/0x680
> > [  167.914879]  [<dac22141>] fpu__restore_sig+0x31/0x50
> > [  167.914882]  [<dac13f52>] restore_sigcontext.isra.9+0xf2/0x110
> > [  167.914885]  [<dac149b9>] sys_sigreturn+0xa9/0xc0
> > [  167.914888]  [<dac019f5>] do_int80_syscall_32+0x85/0x190
> > [  167.914891]  [<db1a56d5>] entry_INT80_32+0x31/0x31
> > [  167.914898]
> > ---[ end trace e57344f10f300a76 ]---
> 
> I am not sure which path leads you there. But it could well be a
> state
> that was caused by the ipipe patch.
> 
> could you try this:
> 
> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -426,6 +426,10 @@ void fpu__restore(struct fpu *fpu)
>         /* Avoid __kernel_fpu_begin() right after fpregs_activate()
> */
>         kernel_fpu_disable();
>         trace_x86_fpu_before_restore(fpu);
> +       if (fpregs_activate(fpu)) {

This instruction does not compile due to fpregs_activate() returns
void, perhaps did you mean "if (fpregs_active(fpu))"?
Given that fpregs_active() have no args, I tried with this:

if (fpu->fpregs_active)

and warning does not raise (even warning added with this patch).

> +               WARN_ON_FPU(fpu !=
> this_cpu_read_stable(fpu_fpregs_owner_ctx));
> +               fpregs_deactivate(fpu);
> +       }
>         fpregs_activate(fpu);
>         copy_kernel_to_fpregs(&fpu->state);
>         trace_x86_fpu_after_restore(fpu);
> 
> This would not be a proper fix, especially if you end up seeing that
> warning ...
> 
> Henning
> 
> > I found discussion at [3], and applied patch at [4] that comes from
> > it, but result is the same.
> > 
> > Starting xeno-test without -l argument result is the same.
> > Launching dohell alone (with same arguments as when launched from
> > xeno- test -l), dump does not appear.
> > 
> > Could be a Xenomai-related problem (though the stack seems not
> > concern
> > Xenomai) or it is better to post it on LKML?
> > 
> > Thanks in advance, regards
> > 
> > Mauro
> > 
> > [1] https://xenomai.org/pipermail/xenomai/2018-December/040142.html
> > [2] https://xenomai.org/pipermail/xenomai/2019-January/040172.html
> > [3]
> > https://lore.kernel.org/lkml/20181120102635.ddv3fvavxajjlfqk@linutr
> > onix.de/ [4]
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/co
> > mmit/?h=linux-4.9.y&id=d3741e0390287056011950493a641524f49fa05a
> > 
> > 
> 
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: FPU warn on ipipe 4.9.146-8 i386
  2019-01-11  9:53   ` limingyu
@ 2019-01-11 13:51     ` Mauro Salvini
  2019-01-14  3:36       ` limingyu
  0 siblings, 1 reply; 8+ messages in thread
From: Mauro Salvini @ 2019-01-11 13:51 UTC (permalink / raw)
  To: limingyu, xenomai

On Fri, 2019-01-11 at 17:53 +0800, limingyu via Xenomai wrote:
> Hi, Mauro
> 
> Maybe you could refer to this disscusion below, and try the latesst 
> stable xenomai code branch
> 
> v3.0.x/stable. 
> https://xenomai.org/pipermail/xenomai/2018-December/040086.html
> 
> And the lasted xenomai code is here: 
> https://gitlab.denx.de/Xenomai/xenomai/tree/stable/v3.0.x
> 
> On 1/11/19 5:40 PM, Henning Schild via Xenomai wrote:
> > I got this dump in dmesg, sometimes just after latency starts,
> 
> 

Hi Limingyu,

Thank you, but I already am on top of v3.0.x/stable (I'm on same
version used at https://xenomai.org/pipermail/xenomai/2018-December/040
142.html)

Regards

Mauro



^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: FPU warn on ipipe 4.9.146-8 i386
  2019-01-11 13:51     ` Mauro Salvini
@ 2019-01-14  3:36       ` limingyu
  0 siblings, 0 replies; 8+ messages in thread
From: limingyu @ 2019-01-14  3:36 UTC (permalink / raw)
  To: Mauro Salvini, xenomai

Hi, Mauro

Thanks for your explanation, I will keeping tracing on this issue and 
related code changes too.

Regards

Limingyu

On 1/11/19 9:51 PM, Mauro Salvini wrote:
> On Fri, 2019-01-11 at 17:53 +0800, limingyu via Xenomai wrote:
>> Hi, Mauro
>>
>> Maybe you could refer to this disscusion below, and try the latesst
>> stable xenomai code branch
>>
>> v3.0.x/stable.
>> https://xenomai.org/pipermail/xenomai/2018-December/040086.html
>>
>> And the lasted xenomai code is here:
>> https://gitlab.denx.de/Xenomai/xenomai/tree/stable/v3.0.x
>>
>> On 1/11/19 5:40 PM, Henning Schild via Xenomai wrote:
>>> I got this dump in dmesg, sometimes just after latency starts,
>>
> Hi Limingyu,
>
> Thank you, but I already am on top of v3.0.x/stable (I'm on same
> version used at https://xenomai.org/pipermail/xenomai/2018-December/040
> 142.html)
>
> Regards
>
> Mauro
>
-- 
Linx Software Co. Ltd. Sichuan Branch
E-mail: myli@linx-info.com



^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: FPU warn on ipipe 4.9.146-8 i386
  2019-01-11 13:47   ` Mauro Salvini
@ 2019-01-14  9:39     ` Henning Schild
  2019-01-15  7:23       ` Mauro Salvini
  0 siblings, 1 reply; 8+ messages in thread
From: Henning Schild @ 2019-01-14  9:39 UTC (permalink / raw)
  To: Mauro Salvini; +Cc: Mauro Salvini via Xenomai

Am Fri, 11 Jan 2019 14:47:13 +0100
schrieb Mauro Salvini <mauro.salvini@smigroup.net>:

> On Fri, 2019-01-11 at 10:40 +0100, Henning Schild wrote:
> > Am Fri, 11 Jan 2019 09:57:50 +0100
> > schrieb Mauro Salvini via Xenomai <xenomai@xenomai.org>:
> >   
> > > Hi all,
> > > 
> > > I'm testing same hardware of [1], with kernel 4.9.146 from ipipe-
> > > 4.9.y
> > > with [2] applied, compiled with ARCH=i386 and Xenomai 3.0.7.  
> > 
> > To be honest i386 is not really tested anymore, in fact in 4.14 not
> > even supported at the moment. If you can you should go for x86_64.
> >   
> 
> Hi Henning,
> 
> Thank you. I'm trying i386 version due to legacy 32bit code that uses
> rtnet (which cannot be used with mixed ABI).

Ok, maybe something you might want to fix for the future.

> > > Launching
> > > 
> > > xeno-test -l "dohell -s xxx -p yyy -m xxx 90000" -T 90000
> > > 
> > > I got this dump in dmesg, sometimes just after latency starts,
> > > sometimes after few seconds (side effect is a max latency value
> > > increase):
> > > 
> > > [  167.914184] ------------[ cut here ]------------
> > > [  167.914208] WARNING: CPU: 0 PID: 606
> > > at /home/build-ws/develop/linux-
> > > 4.9.146/arch/x86/include/asm/fpu/internal.h:511
> > > fpu__restore+0x1eb/0x2b0 [  167.914216] Modules linked in:
> > > intel_rapl
> > > intel_powerclamp iTCO_wdt iTCO_vendor_support coretemp kvm_intel
> > > kvm
> > > irqbypass crc32_pclmul aesni_intel xts aes_i586 lrw gf128mul
> > > ablk_helper cryptd snd_pcm intel_cstate snd_timer evdev snd
> > > soundcore
> > > i915 pcspkr drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect
> > > sysimgblt shpchp video lpc_ich mfd_core button ip_tables x_tables
> > > autofs4 ext4 crc16 jbd2 fscrypto mbcache hid_generic usbhid hid
> > > mmc_block crc32c_intel i2c_i801 i2c_smbus igb i2c_algo_bit
> > > xhci_pci ptp pps_core xhci_hcd sdhci_pci sdhci usbcore mmc_core
> > > fjes [last unloaded: rtnet] [  167.914768] CPU: 0 PID: 606 Comm:
> > > dohell Not tainted 4.9.146+ #1 [  167.914772] Hardware name:
> > > Default string Default string/Q7-BW, BIOS V1.20#KW050220A
> > > 03/16/2018 [  167.914775]
> > > I-pipe domain: Linux [  167.914778]  f42e5e44 daeffa2d 00000000
> > > db335030 dac1ff3b f42e5e74 dac59dea db34504c
> > > [  167.914800]  00000000
> > > 0000025e db335030 000001ff dac1ff3b 000001ff f4291bc0 00000246
> > > [  167.914822]  f4291c00 f42e5e88 dac59efb 00000009 00000000
> > > 00000000
> > > f42e5ea4 dac1ff3b [  167.914843] Call Trace:
> > > [  167.914846]  [<daeffa2d>] dump_stack+0x9f/0xc2
> > > [  167.914849]  [<dac1ff3b>] ? fpu__restore+0x1eb/0x2b0
> > > [  167.914865]  [<dac59dea>] __warn+0xea/0x110
> > > [  167.914868]  [<dac1ff3b>] ? fpu__restore+0x1eb/0x2b0
> > > [  167.914871]  [<dac59efb>] warn_slowpath_null+0x2b/0x30
> > > [  167.914874]  [<dac1ff3b>] fpu__restore+0x1eb/0x2b0
> > > [  167.914877]  [<dac21b0a>] __fpu__restore_sig+0x2ba/0x680
> > > [  167.914879]  [<dac22141>] fpu__restore_sig+0x31/0x50
> > > [  167.914882]  [<dac13f52>] restore_sigcontext.isra.9+0xf2/0x110
> > > [  167.914885]  [<dac149b9>] sys_sigreturn+0xa9/0xc0
> > > [  167.914888]  [<dac019f5>] do_int80_syscall_32+0x85/0x190
> > > [  167.914891]  [<db1a56d5>] entry_INT80_32+0x31/0x31
> > > [  167.914898]
> > > ---[ end trace e57344f10f300a76 ]---  
> > 
> > I am not sure which path leads you there. But it could well be a
> > state
> > that was caused by the ipipe patch.
> > 
> > could you try this:
> > 
> > --- a/arch/x86/kernel/fpu/core.c
> > +++ b/arch/x86/kernel/fpu/core.c
> > @@ -426,6 +426,10 @@ void fpu__restore(struct fpu *fpu)
> >         /* Avoid __kernel_fpu_begin() right after fpregs_activate()
> > */
> >         kernel_fpu_disable();
> >         trace_x86_fpu_before_restore(fpu);
> > +       if (fpregs_activate(fpu)) {  
> 
> This instruction does not compile due to fpregs_activate() returns
> void, perhaps did you mean "if (fpregs_active(fpu))"?
> Given that fpregs_active() have no args, I tried with this:
> 
> if (fpu->fpregs_active)

I did not test what i wrote there, and your fix is what i meant.

> and warning does not raise (even warning added with this patch).

In that case a similar patch should probably be included upstream. I
will prepare a patch for that.

Henning

> > +               WARN_ON_FPU(fpu !=
> > this_cpu_read_stable(fpu_fpregs_owner_ctx));
> > +               fpregs_deactivate(fpu);
> > +       }
> >         fpregs_activate(fpu);
> >         copy_kernel_to_fpregs(&fpu->state);
> >         trace_x86_fpu_after_restore(fpu);
> > 
> > This would not be a proper fix, especially if you end up seeing that
> > warning ...
> > 
> > Henning
> >   
> > > I found discussion at [3], and applied patch at [4] that comes
> > > from it, but result is the same.
> > > 
> > > Starting xeno-test without -l argument result is the same.
> > > Launching dohell alone (with same arguments as when launched from
> > > xeno- test -l), dump does not appear.
> > > 
> > > Could be a Xenomai-related problem (though the stack seems not
> > > concern
> > > Xenomai) or it is better to post it on LKML?
> > > 
> > > Thanks in advance, regards
> > > 
> > > Mauro
> > > 
> > > [1]
> > > https://xenomai.org/pipermail/xenomai/2018-December/040142.html
> > > [2]
> > > https://xenomai.org/pipermail/xenomai/2019-January/040172.html
> > > [3]
> > > https://lore.kernel.org/lkml/20181120102635.ddv3fvavxajjlfqk@linutr
> > > onix.de/ [4]
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/co
> > > mmit/?h=linux-4.9.y&id=d3741e0390287056011950493a641524f49fa05a
> > > 
> > >   
> > 
> >   



^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: FPU warn on ipipe 4.9.146-8 i386
  2019-01-14  9:39     ` Henning Schild
@ 2019-01-15  7:23       ` Mauro Salvini
  0 siblings, 0 replies; 8+ messages in thread
From: Mauro Salvini @ 2019-01-15  7:23 UTC (permalink / raw)
  To: Henning Schild; +Cc: Mauro Salvini via Xenomai

On Mon, 2019-01-14 at 10:39 +0100, Henning Schild wrote:
> Am Fri, 11 Jan 2019 14:47:13 +0100
> schrieb Mauro Salvini <mauro.salvini@smigroup.net>:
> 
> > On Fri, 2019-01-11 at 10:40 +0100, Henning Schild wrote:
> > > Am Fri, 11 Jan 2019 09:57:50 +0100
> > > schrieb Mauro Salvini via Xenomai <xenomai@xenomai.org>:
> > >   
> > > > Hi all,
> > > > 
> > > > I'm testing same hardware of [1], with kernel 4.9.146 from
> > > > ipipe-
> > > > 4.9.y
> > > > with [2] applied, compiled with ARCH=i386 and Xenomai 3.0.7.  
> > > 
> > > To be honest i386 is not really tested anymore, in fact in 4.14
> > > not
> > > even supported at the moment. If you can you should go for
> > > x86_64.
> > >   
> > 
> > Hi Henning,
> > 
> > Thank you. I'm trying i386 version due to legacy 32bit code that
> > uses
> > rtnet (which cannot be used with mixed ABI).
> 
> Ok, maybe something you might want to fix for the future.
> 
..snip..
> > > > 
> > > could you try this:
> > > 
> > > --- a/arch/x86/kernel/fpu/core.c
> > > +++ b/arch/x86/kernel/fpu/core.c
> > > @@ -426,6 +426,10 @@ void fpu__restore(struct fpu *fpu)
> > >         /* Avoid __kernel_fpu_begin() right after
> > > fpregs_activate()
> > > */
> > >         kernel_fpu_disable();
> > >         trace_x86_fpu_before_restore(fpu);
> > > +       if (fpregs_activate(fpu)) {  
> > 
> > This instruction does not compile due to fpregs_activate() returns
> > void, perhaps did you mean "if (fpregs_active(fpu))"?
> > Given that fpregs_active() have no args, I tried with this:
> > 
> > if (fpu->fpregs_active)
> 
> I did not test what i wrote there, and your fix is what i meant.
> 
> > and warning does not raise (even warning added with this patch).
> 
> In that case a similar patch should probably be included upstream. I
> will prepare a patch for that.
> 
> Henning

Hi Henning,

I don't know if it concerns about FPU and this discussion, but I did
some tests and also with last fixes the system freezes after a variable
time (from few seconds to few hours) since latency test start.
No logs/warns in /var/log/messages, and hard reset is needed.

I'm investigating if it freezes also with latency running alone.

Tell me if it's worth to continue testing or not (considering that i386
is going to be not supported anymore).

Thanks
Mauro

> 
> > > +               WARN_ON_FPU(fpu !=
> > > this_cpu_read_stable(fpu_fpregs_owner_ctx));
> > > +               fpregs_deactivate(fpu);
> > > +       }
> > >         fpregs_activate(fpu);
> > >         copy_kernel_to_fpregs(&fpu->state);
> > >         trace_x86_fpu_after_restore(fpu);
> > > 
> > > This would not be a proper fix, especially if you end up seeing
> > > that
> > > warning ...
> > > 
> > > Henning
> > >   
> > > > 
> > > > 
> > > >   
> > > 
> > >   
> 
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-01-15  7:23 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-11  8:57 FPU warn on ipipe 4.9.146-8 i386 Mauro Salvini
2019-01-11  9:40 ` Henning Schild
2019-01-11  9:53   ` limingyu
2019-01-11 13:51     ` Mauro Salvini
2019-01-14  3:36       ` limingyu
2019-01-11 13:47   ` Mauro Salvini
2019-01-14  9:39     ` Henning Schild
2019-01-15  7:23       ` Mauro Salvini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.