Opened 14 years ago

Closed 13 years ago

#6601 closed bug (fixed)

boot problem

Reported by: czeidler Owned by: bonefish
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/alpha2
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by tqh)

Haiku does not boot after hrev37679 on my desktop pc. I build haiku gcc2 on linux 64, completely fresh checkout and build, hrev37677 works hrev37679 not.

I add return -1 at the top of the _start kernel function. In hrev37677 my pc reboots in hrev37679 just a black screen. So not even reach _start.

Change History (10)

comment:1 by tqh, 14 years ago

Description: modified (diff)

Added a 'r' before revisions so they get linked.

in reply to:  description comment:2 by bonefish, 14 years ago

Replying to czeidler:

I add return -1 at the top of the _start kernel function. In hrev37677 my pc reboots in hrev37679 just a black screen. So not even reach _start.

That pretty much rules out that the referred to change sets are to blame. One of the things secondary things that change when adding something to the kernel is the size of the kernel. We used to have boot problems from time to time due to a limited amount of space the boot loader reserved for the kernel. Since we bumped the size only a bit each time, the problem recurred with the ever-growing kernel size. But in hrev35726 I increased the reservation dramatically, so that we should be safe for a few years (unless something doesn't work as it is suppose to).

Anyway without debug output this might be a bit hard to debug. Things you could try:

  • Check whether you can enter the boot loader menu. If not, narrowing down the exact place of the hang or panic via bisecting (platform_exit() can be inserted to reset the machine). The (C part of the) control flow starts _start() in src/system/boot/platform/bios_ia32/start.cpp. main() is in src/system/boot/loader/main.cpp.
  • Best start by resetting in panic() (.../platform/bios_ia32/debug.cpp). If it actually is a panic, you might want to find a way to bring it on screen to save the time for bisecting.
  • Test whether the nightlies have the same problem. Just to rule out an obscure build problem.

comment:3 by czeidler, 14 years ago

A small status update maybe you have an idea, for me it still makes no sense. At least I tackle it down to the point where it hangs:

src/system/boot/platform/bios_ia32/video.cpp in vesa_set_mode at call_bios (line 560)

I can boot when I select a resolution in the boot menu. So somehow a bad mode is chosen automatically...

Yes same problem with the nightlies.

comment:4 by czeidler, 14 years ago

What makes a problem is the native monitor 1280x1024@32bit failsafe video mode. 16 bit or lower resolution are ok. How it is connected to the kernel size!?

in reply to:  4 comment:5 by bonefish, 14 years ago

Replying to czeidler:

What makes a problem is the native monitor 1280x1024@32bit failsafe video mode. 16 bit or lower resolution are ok. How it is connected to the kernel size!?

I can only guess, but the fact that a mere change of the kernel affects unrelated functionality in the boot loader suggests that the loading code or code used by it is buggy. If you can analyze the code that selects the VESA mode and find out what exactly causes the different decision (e.g. a different value in a certain memory location) in the newer revisions, it might be possible to track the cause back to the actual origin.

comment:6 by rudolfc, 14 years ago

Hi there,

This is actually not a new bug: it exists 'for ages' already. Also seen when using Matrox and n Vidia cards, especially older ones. The problem is always the highest supported mode or colordepth or so if using vesa mode. While using the nvidia driver for instance, you will mostly only encounter the black screen during boot, and then the screen comes alive again after the dedicated driver kicks in. (Not so for vesa mode though). Sometimes the wrong set mode during boot messes up the card's settings in such a way that even the nVidia driver is not able to restore the card to life.

I'll try to hunt down the bug as I reported it which describes this same problem.

Bye!

Rudolf.

comment:7 by rudolfc, 14 years ago

Here it is: http://dev.haiku-os.org/ticket/3850

Bye!

Rudolf.

in reply to:  7 comment:8 by bonefish, 14 years ago

Replying to rudolfc:

Here it is: http://dev.haiku-os.org/ticket/3850

Doesn't sound like Clemens' problem. In his case it's not just that the screen stays black. The CPU doesn't even enter the kernel.

comment:9 by czeidler, 14 years ago

But maybe related. Have a intel card and maybe this one hangs the system when hitting the bug. Rudolf thanks for looking into it maybe it solve also my problem.

comment:10 by czeidler, 13 years ago

Resolution: fixed
Status: newclosed

Can boot in default resolution since hrev40078.

Note: See TracTickets for help on using tickets.