freebsd.org reference box panics

[Peter Wemm]

beast.freebsd.org does a daily buildworld.  Its been panicing or locking up
for the last few days.  The most recent was:

fatal kernel trap:

    trap entry     = 0x2 (memory management fault)
    cpuid          = 1
    faulting va    = 0xfffffe0033e04030
    type           = access violation
    cause          = load instructon
    pc             = 0xfffffc00003c4e58
    ra             = 0xfffffc00003c4ee4
    sp             = 0xfffffe003b925770
    usp            = 0x11ffee10
    curthread      = 0xfffffc005ef51280
        pid = 69599, comm = groff

Stopped at      elf64_load_file+0x328:  ldl     t0,0(t1) <0xfffffe0033e04030>   <t0=0x3fe,t1=0xfffffe0033e04030>
db> trace
elf64_load_file() at elf64_load_file+0x328
exec_elf64_imgact() at exec_elf64_imgact+0x494
kern_execve() at kern_execve+0x3d4
execve() at execve+0x28
syscall() at syscall+0x3ac
XentSys() at XentSys+0x64
--- syscall (59, FreeBSD ELF64, execve) ---
--- user mode ---

This has been happening regularly for a while.

Recall that groff is the strange executable that gcc/binutils produce
with only one elf PT_LOAD section.

Some of the other outstanding problems...

- longjmp(3) still uses the OLD OLD sigreturn format and still depends on
COMPAT_43 in the kernel.
- it still lacks working kenrel threads (neither KSE nor THR)
- it gets pipe(2) data corruption when building packages (ask Kris)
- it still blows up if ithread preemption is enabled

lesser missing things:
- gdb -k

At the developer summit, it was sugguested that since alpha is already
defacto tier-2 status, we should formally say so.  Several people said
they'd do the work, but nothing has happened.  There isn't much time left
folks.  If it is to avoid tier-2 status, it has to have a turnaround Real
Soon Now (as in, within only a few weeks).

Cheers,
-Peter
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5