[Top][All Lists]

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

Re: VirtualBox Hangs Pre-Init Due To Ext2FS Fault

From: Richard Braun
Subject: Re: VirtualBox Hangs Pre-Init Due To Ext2FS Fault
Date: Sat, 27 Jun 2015 19:34:46 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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 long 
> addr_per_block = EXT2_ADDR_PER_BLOCK (sblock);) in ext2_getblk. It faults 
> because sblock is NULL.
> I have traced the execution with debugging statements, and what seems to 
> happen is as follows:
> 1. diskfs_remount is called (because root is remounted as rw)
> 2. RPCs are inhibited
> 3. diskfs_reload_global_state is called
> 4. sblock is set to NULL
> 5. While this is happening, ext2_getblk is called
> If you’re lucky, the superblock is read and sblock is set to point to this 
> data before 5 (or at least before it gets to dereferencing sblock). If not, 
> sblock is still NULL and thus a page fault is raised, causing the system to 
> be stuck.
> Does anyone have an idea how this situation could be occurring?

My initial thought would be "how could it not happen ?".

Despite diskfs_remount calling ports_inhibit_class_rpcs, other threads
can very well be running to process previously received messages. There
seems to be no other form of access synchronization such as locks in

Can you get the call trace leading to ext2_getblk ? I'm not sure about
backtrace(3) in static executables but it might be worth trying.

Richard Braun

reply via email to

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