[haiku-commits] Re: boot problem Re: r37678 - in haiku/trunk: headers/os/drivers src/add-ons/kernel/file_systems/userlandfs/kernel_add_on src/add-ons/kernel/file_systems/userlandfs/server src/add-ons/kernel/file_systems/userlandfs/server/haiku src/system/kernel/device_manager
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 13 Sep 2010 18:53:29 +0200
On 2010-09-13 at 08:45:11 [+0200], Clemens Zeidler
<clemens.zeidler@xxxxxxxxxxxxxx> wrote:
> I have a boot problem on my desktop machine after r37678 / r37679. Just a
> black screen before the boot icons should appear, not able to enter KDL.
> Really have no clue whats going on here could you please take a look? Have
> intel core 2.
Have you verified that r37678+r37679 is does indeed introduce the problem?
Like with clean builds (without local changes) of r37677 and r37679?
I'm asking because I somewhat doubt that these changes can have any such
effect. The kernel part only introduces a new function that isn't used, and
the userlandfs (should you have installed it at all) isn't really used until
one actively mounts a volume with it. At boot time the module is loaded and
unloaded a few times, but that doesn't have anything to do with these
changes. Besides that from your description the problem seems to happen way
earlier in the boot process.
> Whats else is interesting for you?
* A Trac ticket, if you haven't already created one.
* Verification that those changesets are to blame.
* A (debug) syslog.
* If you can do serial debugging, checking that could be helpful, since
panic()s before the initialization of the blue screen console only end up
there.
* If you can't get any useful output, narrowing the point of the problem down
would help. You can do that by bisecting the early kernel _start() (until
int_init()) using a triple fault (*(int*)0 = 0). Later you should be able to
somehow capture dprintf()s -- in the debug syslog at least.
CU, Ingo
Other related posts:
