Port-i386 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Per-cpu IDT patch



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 <kardel%netbsd.org@localhost> 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 <kardel%netbsd.org@localhost> 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 <kardel%netbsd.org@localhost> 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
>


Home | Main Index | Thread Index | Old Index