Graphics trouble, avoidable by entering boot menu

[andreasf]

Since at least r35321, now at r35361, Haiku does not properly boot up anymore. It does not show the boot splash image but text output, and after entering the kernel it shows weird "color blocks" or artifacts from the last shutdown.

Entering the boot menu (on each boot) is sufficient to resolve the issue, I do not need to change any video-related options...

Graphics card is Nvidia GeForce FX 5700 (NV36). Monitor is 4:3, DVI-connected, with or without KVM switch. Same issue using a different, VGA-connected 4:3 monitor.

r35356 was a clean gcc4 hybrid build with prior rm -rf objects/.

[andreasf]

git-bisect log

[andreasf]

Bisection shows r35050 as first bad commit. Any ideas?

[jackburton]

Which text output do you get ? Is it the boot loader debug info ? I have a similar problem since r35050 too, since I use need to hit ESC to enter the GRUB boot menu, then select to boot Haiku. I guess that the ESC state is not resetted, and it gets detected by the Haiku bootloader, thus showing the boot loader debug info. By entering the haiku bootloader menu I can bypass the issue.

[andreasf]

Replying to jackburton:

Which text output do you get ? Is it the boot loader debug info ?

I guess so.

I guess that the ESC state is not resetted, and it gets detected by the Haiku bootloader, thus showing the boot loader debug info.

That may explain the lack of splash screen, but does it also explain not getting a working desktop afterwards?

Not knowing x86 too well, I have reverted the offending commit in my tree. HEAD then boots but has broken icons/Tracker, with or without boot menu.

[andreasf]

workaround: revert r35050

[Grey]

Replying to jackburton:

I have a similar problem since r35050 too, since I use need to hit ESC to enter the GRUB boot menu, then select to boot Haiku. I guess that the ESC state is not resetted, and it gets detected by the Haiku bootloader, thus showing the boot loader debug info. By entering the haiku bootloader menu I can bypass the issue.

How is configured GRUB. Why you need to hit ESC to enter the GRUB boot menu? As for me, I see GRUB menu (in graphic mode) immediate after turn on computer. If I press ESC, GRUB switch to text mode menu. You guess right. The patch http://dev.haiku-os.org/ticket/5163 look in keyboard buffer for hot-key codes (F8, F12, holding RShift or holding LShift for boot menu. ESC for debug output). Boot menu hot-keys have more priority. So try to press F8 or Shift before select to boot Haiku. We can make more complex algorithm for this search...

[jackburton]

Replying to Grey:

Replying to jackburton:

I have a similar problem since r35050 too, since I use need to hit ESC to enter the GRUB boot menu, then select to boot Haiku. I guess that the ESC state is not resetted, and it gets detected by the Haiku bootloader, thus showing the boot loader debug info. By entering the haiku bootloader menu I can bypass the issue.

How is configured GRUB. Why you need to hit ESC to enter the GRUB boot menu? As for me, I see GRUB menu (in graphic mode) immediate after turn on computer. If I press ESC, GRUB switch to text mode menu.

Grub is configured to boot Ubuntu by default, without showing the menu. By hitting ESC I enter the boot menu (in text mode).

[prushik14]

I also have the same problem, I also took pictures, but I can't upload without modifying them as they are too big.

[prushik14]

Garbage on the screen

[prushik14]

The text on the bootloader screen

[koki]

FWIW, I have exactly the same problem in two different computers, one with an NVidia video card (working in accelerated mode) and another with Intel integrated video (working in VESA mode). No GRUB here, btw; using bootman to select the boot partition instead.

[prushik14]

This bug may be difficult to track down and difficult to reproduce. It seems to occur only on certain hardware. I have two laptops: An HP Pavilion 8000zd (something in the 8 thousands) and a System 76 Pangolin (panp6) I installed Haiku from the exact same CD on both computers. My HP fails to boot normally, but my System 76 works wonderfully. Hope this helps.

[Grey]

About garbage on the screen. It's problem of incorrect video mode setting when KDL activated. On my notebook Lenovo ThinkPad T400 it's possible to setup in BIOS graphics to "Integrated" or "Discrete". In first case Haiku I can't see Haiku logo on screen, but loading ok, and I see Haiku desktop. If KDL called on early (for example: if kernel panic), I see garbage on top of screen. In case of "Discrete", I see Haiku logo on screen and then I see Haiku desktop and KDL output ok.

[Grey]

Replying to jackburton: Try this patch, plese. ESC searched only at last and prev to last keys codes.

[andreasf]

Replying to jackburton:

Grub is configured to boot Ubuntu by default, without showing the menu. By hitting ESC I enter the boot menu (in text mode).

Same configuration here.

[andreasf]

The patch works for me, thanks!

[Grey]

Replying to andreasf: Try new patch, please. It's optimized patch.

[jackburton]

Replying to andreasf:

The patch works for me, thanks!

Works for me too, with the esc2.patch. Thanks!

[jackburton]

Replying to jackburton:

Replying to andreasf:

The patch works for me, thanks!

Works for me too, with the esc2.patch. Thanks!

Applied in r35441. I'd close this one. andreasf ?

[andreasf]

Replying to jackburton:

Replying to jackburton:

Works for me too, with the esc2.patch.

I'd close this one. andreasf ?

esc2.patch at r35440 shows me the splash screen and gets me to the desktop, too.

I am currently seeing weird graphics problems on the desktop though (what looks like a gdb screen in a KDL-like black-on-white-manner on the whole desktop but mouse still works, revealing the desktop, and windows can be moved but nothing else works). I'd assume it's unrelated and suggest to close this ticket.

[mmlr]

I am currently seeing weird graphics problems on the desktop though (what looks like a gdb screen in a KDL-like black-on-white-manner on the whole desktop but mouse still works, revealing the desktop, and windows can be moved but nothing else works).

That'd be consoled running GDB because one of the GUI servers crashed/invoked the debugger (in that case most likely the app_server). Capturing the stack trace and opening a new ticket would make sense, yes.

Closing this one, thanks for the fix and the feedback.