Re: Per-cpu IDT patch
s ymgch <[email protected]> Thu, 9 Jul 2020 17:56:44 +0900
| Newsgroups | gmane.os.netbsd.ports.x86-64,gmane.os.netbsd.ports.i386 |
|---|---|
| Message-ID | <CAPnD6HqE6y7drg17Z94F1yXVqaZiTv7HTdqHd_fHg9g23UCqmQ@mail.gmail.com> |
Hi, I'm going to commit this in the beginning of next week if there are no other problems or worries. Best regards, -- yamaguchi On Thu, Jul 9, 2020 at 5:32 AM Frank Kardel <[email protected]> wrote: > > Great - works now - Thanks! > > Frank > > > On 07/08/20 13:13, Jaromír Doleček wrote: > > I've just committed a fix for sys/arch/xen/x86/cpu.c to avoid > > triggering the KASSERT(). It was just missing initialization for the > > Xen variant, overlooked when the fpu_kern_enter() API was added in > > November 2019. > > > > Jaromir > > > > Le mer. 8 juil. 2020 à 12:31, Frank Kardel <[email protected]> a écrit : > >> The patched GENERIC kernel booted fine directly. > >> > >> A patches XEN3_DOM0 kernel with Xen 4.11 hypervisor paniced. That's why > >> > >> I am suspecting Xen/AES changes. > >> > >> Frank > >> > >> > >> > >> On 07/08/20 12:10, s ymgch wrote: > >>> On Mon, Jul 6, 2020 at 10:45 PM Frank Kardel <[email protected]> wrote: > >>>> Nice progress here: > >>>> > >>>> On bare metal 9.99.69 GENERIC boots sees all ixl, wm and nvme devices > >>>> with all their interrupts initialized - great. > >>>> > >>>> BUT... 9.99.69-XEN3_DOM0 digs out following panic: > >>>> > >>>> [ 2.0100519] panic: kernel diagnostic assertion "ci->ci_kfpu_spl == > >>>> -1" failed: file "/src/NetBSD/cur/src/sys/arch/x86/x86/fpu.c", line 389 > >>>> [ 2.0100519] cpu3: Begin traceback... > >>>> [ 2.0100519] vpanic() at netbsd:vpanic+0x146 > >>>> [ 2.0100519] kern_assert() at netbsd:kern_assert+0x48 > >>>> [ 2.0100519] fpu_kern_enter() at netbsd:fpu_kern_enter+0x190 > >>>> [ 2.0100519] cpu3: Begin traceback... > >>>> [ 2.0100519] vpanic() at netbsd:vpanic+0x146 > >>>> [ 2.0100519] kern_assert() at netbsd:kern_assert+0x48 > >>>> [ 2.0100519] fpu_kern_enter() at netbsd:fpu_kern_enter+0x190 > >>>> [ 2.0100519] aesni_probe() at netbsd:aesni_probe+0x28 > >>>> [ 2.0100519] aes_selftest() at netbsd:aes_selftest+0x13 > >>>> [ 2.0100519] aes_modcmd() at netbsd:aes_modcmd+0xff > >>>> [ 2.0100519] module_do_builtin() at netbsd:module_do_builtin+0x173 > >>>> [ 2.0100519] module_do_builtin() at netbsd:module_do_builtin+0x12e > >>>> [ 2.0100519] module_init_class() at netbsd:module_init_class+0x145 > >>>> [ 2.0100519] main() at netbsd:main+0x472 > >>>> [ 2.0100519] cpu3: End traceback... > >>>> [ 2.0100519] fatal breakpoint trap in supervisor mode > >>>> [ 2.0100519] trap type 1 code 0 rip 0xffffffff8023c93d cs 0xe030 > >>>> rflags 0x202 cr2 0 ilevel 0x8 rsp 0xffffffff81981af0 > >>>> [ 2.0100519] curlwp 0xffffffff80e5c6c0 pid 0.0 lowest kstack > >>>> 0xffffffff8197d2c0 > >>>> Stopped in pid 0.0 (system) at netbsd:breakpoint+0x5: leave > >>> Did it only appear when you applied my patch? > >>> It seems that the assertion happens not in IDT but fpu. > >>> > >>> -- yamaguchi >