UP load_up_fpu crash (2.6.8-rc2)

[Paul Mackerras]

Nathan Lynch writes:

> We seem to be broken with CONFIG_SMP=n on 2.6.8-rc2 and 2.6.8-rc1-mm1:
>
> Freeing unused kernel memory: 280k freed
> INIT: version 2.85 booting
> Vector: 300 (Data Access) at [c00000003f043bb0]
>     pc: c00000000000bab0: .load_up_fpu+0xb0/0x16c
>     lr: 00000000400272b8
>     sp: c00000003f043e30
>    msr: 8000000000003032
>    dar: 108
>  dsisr: 40000000
>   current = 0xc00000003f03d440
>   paca    = 0xc0000000003cc000
>     pid   = 327, comm = hotplug
> enter ? for help
> mon> t
> [c00000003f043e30] c00000000000b4d8 .handle_page_fault+0x20/0x40
> (unreliable)
> --- Exception: 801 (FPU Unavailable) at 000000004000b908
> SP (ffffe480) is in userspace

This is very puzzling.  It appears that we have taken a FPU
unavailable trap from userspace, which is fine, but then it looks like
we think some other task owns the FPU at the moment, and that task is
a kernel thread.

We are crashing because last_task_used_math->thread.regs is NULL.
That should only happen for a kernel thread, but last_task_used_math
should never point to a kernel thread.  The only place that
last_task_used_math gets set to a non-NULL value is in load_up_fpu,
and that should only be called if we get a FPU unavailable trap from
usermode.

It would be very useful to see what last_task_used_math contains at
the time of the crash, and see what last_task_used_math->comm is, so
we can work out whether the task that owns the FPU is in fact a kernel
thread - in which case we need to work out how last_task_used_math is
getting to point at it - or if it isn't a kernel thread, in which case
we need to work out why task->thread.regs is NULL for that task.

Paul.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/