> I mustly see one that looks like this:
> #3 0xa0119018 in kern_do_signal (oldset=0xa2738464, error=0x0, again_out=0x0)
> at signal_kern.c:204
> #4 0xa0119348 in do_signal (error=0x0, again_out=0x0) at signal_kern.c:307
This is a UML bug of some kind. Can you see what signal it's delivering?
If it's SIGRTMIN, then it's a known bug that I haven't bothered tracking
> A few times, I've seen this as well:
> #0 0xa0002091 in __munmap ()
> #1 0xa0113c59 in fix_range (mm=0xa67a6bc0, start_addr=1081712640,
> end_addr=1081716736, force=0) at tlb.c:61
> #2 0xa0113f3a in flush_tlb_range (mm=0xa67a6bc0, start=1081712640,
> end=1081716736) at tlb.c:169
This is normal.
> Am I hitting something for which performance improvements are planned
> or is something going totally wrong?
The first is a bug, the second is something for which we have improvements
> BTW, I tried compiling with gprof support, but then it panics during
> boot. I can provide a backtrace if neccesary.
Try turning removing -DUM_FASTCALL from CFLAGS in arch/um/Makefile-i386.