bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tmpfs replacement


From: Roland McGrath
Subject: Re: tmpfs replacement
Date: Wed, 13 Aug 2003 17:07:20 -0400 (EDT)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]