Messages in this thread | | | Subject | Re: [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a | From | Thomas Meyer <> | Date | Fri, 02 Jun 2017 15:18:02 +0200 |
| |
Am Freitag, den 02.06.2017, 10:30 +0200 schrieb Richard Weinberger: > Thomas, > > Am 02.06.2017 um 10:04 schrieb Thomas Meyer: > > Am Donnerstag, den 01.06.2017, 22:49 -0700 schrieb Florian > > Fainelli: > > I see this in the kernel log: > > > > [ 0.000000] ------------[ cut here ]------------ > > [ 0.000000] WARNING: CPU: 0 PID: 0 at > > arch/x86/kernel/fpu/xstate.c:595 > > fpu__init_system_xstate+0x4d0/0x877 > > [ 0.000000] XSAVE consistency problem, dumping leaves > > [ 0.000000] Modules linked in: > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.10.15- > > 200.fc25.x86_64 #1 > > [ 0.000000] Call Trace: > > [ 0.000000] dump_stack+0x63/0x86 > > [ 0.000000] __warn+0xcb/0xf0 > > [ 0.000000] warn_slowpath_fmt+0x5f/0x80 > > [ 0.000000] ? xfeature_size+0x5a/0x78 > > [ 0.000000] fpu__init_system_xstate+0x4d0/0x877 > > [ 0.000000] ? msr_clear_bit+0x3a/0xa0 > > [ 0.000000] ? 0xffffffffa3000000 > > [ 0.000000] fpu__init_system+0x194/0x1be > > [ 0.000000] early_cpu_init+0xf7/0xf9 > > [ 0.000000] setup_arch+0xba/0xcf0 > > [ 0.000000] ? printk+0x57/0x73 > > [ 0.000000] ? early_idt_handler_array+0x120/0x120 > > [ 0.000000] start_kernel+0xb2/0x48a > > [ 0.000000] ? early_idt_handler_array+0x120/0x120 > > [ 0.000000] x86_64_start_reservations+0x24/0x26 > > [ 0.000000] x86_64_start_kernel+0x14d/0x170 > > [ 0.000000] start_cpu+0x14/0x14 > > [ 0.000000] ---[ end trace d5213d72358dda94 ]--- > > [ 0.000000] CPUID[0d, 00]: eax=00000007 ebx=00000440 > > ecx=00000440 edx=00000000 > > Does this also happen with a mainline kernel?
Yes, same error on current master on bare metal:
[ 5.300000] Key type encrypted registered [ 5.300000] This architecture does not have kernel memory protection. [ 5.300000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
* master 3b1e342be265 Merge tag 'nfsd-4.12-1' of git://linux-nfs.org/~bfields/linux
> Also on KVM or bare metal? > Not that UML fails because of this and we're hunting a ghost... > > Thanks, > //richard >
| |