The only interesting thread is the last one. The others are service threads waiting for something to do, which is normal. When showing cold backtraces, always include "x/i $pc" and "info regs" as well. It's annoying that the arguments are omitted from most of the frames from "bt full", like the pager_memcpy call. Anyway, we can suspect that getting that info would show that do_memcpy got a mapping and that memcpy is hung in the rep;stosl insn with esi/edi being the DATA argument to _diskfs_rdwr_internal (which should be the OTHER argument to pager_memcpy as well, not shown in the backtrace) and the page just got from vm_map. If that's so, it means the hang is in a page fault on that newly-mapped page. That means all the troubles are actually in the default pager (or kernel). After verifying that the above is what's happening and vm_map was happy, you need to start tracing the interactions of the default pager and the kernel.
If debugging the live default pager turns into a nightmare, it may be worthwhile to do a little hacking so you can run a hacked mach-defpager server that is not installed as the kernel's default pager, which you separately use for tmpfs's default_pager_object_create. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
