kern/38293: panic: fp_save ipi didn't

[Christoph_Egger%gmx.de@localhost]

>Number:         38293
>Category:       kern
>Synopsis:       panic: fp_save ipi didn't
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 25 11:35:00 +0000 2008
>Originator:     Christoph Egger
>Release:        4.99.48
>Organization:
>Environment:
NetBSD 4.99.48 (GENERIC) #0: Mon Jan 7 21:47:09 PST 2008 
builds@wb28:/home/builds/ab/HEAD/amd64/200801070002Z-obj/home/builds/ab/HEAD/src/sys/arch/amd64/compile/GENERC
 amd64
>Description:

The kernel panics in src/sys/arch/amd64/amd64/fpu.c
with "panic: fp_save ipi didn't"

In all panics I have got so far, the backtrace is always the same:

fpusave_lwp() at netbsd:fpusave_lwp+0x7b
cpu_lwp_free() at netbsd:cpu_lwp_free+0x2c
exit1() at netbsd:exit1+0x5f1
sys_exit() at netbsd:sys_exit+0x67
syscall() at netbsd:syscall+0xa9


To get this panic, a simple command is enough:

dmesg | less

However, the important thing here is the pipe. And the panic
always happens when the command _after_ the pipe ("less" in the
above example) does the exit syscall.

The panic does not always happen, but it is reproducable in an
non-interactive way:

while true; dmesg | fgrep "something"; done

Then wait for the panic and when it happens, then always when
fgrep does the exit syscall.


Joerg Sonnenberger told me, this (or similar) panics
has been seen on non-x86 hardware so I assign this to
category "kern" instead to "port-amd64".

>How-To-Repeat:

Set up a Xen environment with Xen 3.3-unstable,
changeset 17264. You can get the sources
from

hg clone http://xenbits.xensource.com/staging/xen-unstable.hg/

Older Xen versions don't have the necessary bugfixes to run
NetBSD/amd64 as HVM guest.

It doesn't matter if you run NetBSD or Linux as Dom0.

Then install NetBSD/amd64 in a HVM guest and after you have
a NetBSD disk image.

Very important is, that you assign more virtual VCPUs to
the HVM guest than physical CPUs are present (I use twice VCPUs
as physical CPUs are available). And you must have two physical
CPUs at a minimum (=> 4 VPUs for the guest at a miminum).
Then boot NetBSD/amd64.

Login and run

while true; dmesg | fgrep "something"; done

Sometimes the panic even happens during boot when the
boot shell scripts runs.


>Fix: