I have now got a patch that drains down the queue, and it does successfully
stop sblock from being dereferenced etc when we actually reload. However,
sometimes thread 5 (the same one that would dereference sblock) seems to get
stuck in vm_fault_continue (at least according to the kernel
Hello James :)
Quoting James Clarke (2015-07-15 22:20:57)
I had a look today at what's happening, and it's that the *file*
pager is trying to read from disk. Any thoughts?
There is another thing I forgot. libpager is special, it has its own
demuxer (see libpager/demuxer.c) that writes
Yeah, I tried inhibiting both buckets, but the paging RPCs still got through,
so my guess was that libports's inhibit/resume methods weren't able to deal
with libpager's own threads. The thing is I don't think we currently keep track
of any reference to the main/worker threads, as
On Sun, Jul 19, 2015 at 02:25:14PM +0100, James Clarke wrote:
Yeah, I tried inhibiting both buckets, but the paging RPCs still got through,
so my guess was that libports's inhibit/resume methods weren't able to deal
with libpager's own threads. The thing is I don't think we currently keep
As discussed in IRC, this successfully stopped the disk pager from
dereferencing sblock. However, it was still hanging at boot a lot of the time
(seemingly if and only if I booted in normal mode ie not recovery mode, but
that's probably just a timing thing).
I had a look today at what's
Quoting Richard Braun (2015-07-13 10:16:14)
On Sun, Jul 12, 2015 at 12:56:31PM +0100, James Clarke wrote:
That doesn’t seem to boot at all. I had tried changing it to inhibiting all
RPCs (it looks like you’ve inhibited an extra class?), but it seems that
paging is needed? Perhaps part of
Hi James :)
you found a long-standing bug in ext2fs. Fixing it allows us to get
rid of the ugly workaround in daemons/runsystem.sh (look for `XXX').
Quoting Richard Braun (2015-07-13 10:16:14)
On Sun, Jul 12, 2015 at 12:56:31PM +0100, James Clarke wrote:
That doesn’t seem to boot at all. I
On Sun, Jul 12, 2015 at 12:56:31PM +0100, James Clarke wrote:
That doesn’t seem to boot at all. I had tried changing it to inhibiting all
RPCs (it looks like you’ve inhibited an extra class?), but it seems that
paging is needed? Perhaps part of ext2fs gets paged out, and it needs to be
That doesn’t seem to boot at all. I had tried changing it to inhibiting all
RPCs (it looks like you’ve inhibited an extra class?), but it seems that paging
is needed? Perhaps part of ext2fs gets paged out, and it needs to be paged in
when remounting?
James
On 12 Jul 2015, at 00:27, Justus
Quoting James Clarke (2015-07-12 13:56:31)
That doesn’t seem to boot at all.
Indeed :/
db show all tasks
ID TASK NAME [THREADS]
0 f2745f00 gnumach [8]
1 f2745e40 ext2fs [12]
2 f2745d80 exec [5]
3 f2745cc0 (ext2fs) [1]
4 f2745c00 /hurd/proc [4]
5 f2745b40 /hurd/auth [5]
6 f2745a80 /bin/sh(1)
I did some more digging around today. I think what’s happening is that ext2fs
tries to handle a pager RPC while the disk is being remounted.
We do call ports_inhibit_class_rpcs, which will wait until all RPCs for that
class have finished. However, we call this with diskfs_protoid_class, which
Quoting James Clarke (2015-07-11 22:33:44)
I did some more digging around today. I think what’s happening is
that ext2fs tries to handle a pager RPC while the disk is being
remounted
Sounds plausible. Could you try:
http://darnassus.sceen.net/~teythoon/ext2fs.static
I'll send the patch as
Hi,
I have been suffering a lot from my Hurd system (running in VirtualBox) hanging
at startup, just after Hurd server bootstrap... but before INIT: version
2.88 booting.
I have been able to trace it back to getblk.c:248 (unsigned long addr_per_block
= EXT2_ADDR_PER_BLOCK (sblock);) in
On Sat, Jun 27, 2015 at 03:39:58PM +0100, James Clarke wrote:
I have been suffering a lot from my Hurd system (running in VirtualBox)
hanging at startup, just after Hurd server bootstrap... but before INIT:
version 2.88 booting.
I have been able to trace it back to getblk.c:248 (unsigned
14 matches
Mail list logo
