After the recent vesa changes haiku hangs at boot

[ddew]

After the recent EDID changes in vesa it fails to set a video mode to draw the desktop. When I take it to KDL manually and do a bt it seems picasso has hung doing something involving vesa_set_display_mode. Attaching a photo of the bt.

[ddew]

Photo of the bt

[ddew]

Forgot to add the specs of the machine.

Core2Duo 3.0ghz 5GB ram NVidia GeForce 9800GTX

[axeld]

Can you provide a syslog from before that change?

[ddew]

Unfortunatly not, i have no way to capture a serial log atm. I'll try to pick up a cable tomorrow.

[axeld]

Then you could just use the current revision, though :-) The syslog is saved in /var/log/syslog when running Haiku - you can then secure this file via FTP or whatever means. You just cannot access it if Haiku crashes before.

[ddew]

Excellent idea, i'll set up another haiku partition here and give it a go :)

[ddew]

Tried setting up another partition with a working revision and mounted the broken one to see if anything had been saved to syslog but unfortunatly the file hadn't been synced to disk when it hung.

[axeld]

Sometimes it seems to be hard to understand me :-) If Haiku KDLs, you cannot expect to found a useful syslog (because it might not have been written back yet). Therefore, I suggested to run a previous revision that is known to work, and save the syslog from that run - this will give at least some information about the EDID info that was received on your system, and which resolution should be set.

[ddew]

Attached the syslog of a bootable install before the EDID changes. Don't have a build revision since i had to wipe that partition and i forgot to check the version.

Hope it helps

[ddew]

Syslog from working haiku

[pieterpan]

I have the same problem with my laptop as well. Attached a similar backtrace. If I tell it to go into safe mode, it starts fine. (but no graphics of course) See #2083 for my lspci.

[pieterpan]

Update on this: Actually, after about 5 minutes it does switch to the resolution and boot normally as if nothing happened. Then you can change the resolution in the screen preflet, and it takes another 5 minutes. (After which Deskbar hangs and needs to be killed+restarted, but that's another matter) I have a fairly fast laptop, so your delay may vary.

Perhaps it would be an idea to assign this to Jan Klötzke? He wasn't aware of this problem when I emailed him. He said it might have something to do with timing. I will attach my syslog, though nothing useful seems to be in it. It's the first time I got the usb stick working under Haiku, so I could copy it to the stick! Great work btw!

[pieterpan]

Syslog compal laptop

[bonefish]

Similar behavior here (Lenovo T61 with nVidia gfx): Switching the screen mode took roughly 2 mins. hrev26325 fixes this problem. Works as expected, now.

[PieterPanman]

For some reason my old account didn't work anymore and password recovery didn't help. I created a new account.

The problem for me is solved with regarding the vesa mode changes. Thank you!

[korli]

thanks for the update!

[Stef]

Unfortunately, I still seem to be running into a similar issue on my laptop using the most recent revisions (tested hrev26489 most recently). All icons light up on the boot screen, but then nothing happens. The 'running' command in KDL shows only picasso, but a bt on this thread doesn't seem to show anything besides the stuff caused by pressing F12. I left the laptop on for up to two hours on the boot screen, as comments above show the mode change might just need more time, but it did not continue booting during that time. I am attaching a syslog of hrev25679, which seems to be the last revision to successfully boot on this hardware. The laptop is a Toshiba Satellite Pro 4600 with Trident Cyberblade XP graphics.

[Stef]

syslog from hrev25679, on the Toshiba laptop

[Stef]

photo of 'bt' output on the Toshiba laptop

[Stef]

As the problem with my laptop still exists on the latest builds (hrev27655), I've been digging into this a bit more. By adding some dprintfs I traced the problem to vm86_do_int, which is called from vbe_get_mode_info. I enabled TRACE_VM86 in src/system/kernel/arch/x86/vm86.cpp and added some additional TRACEs in the emulate function. This resulted in the output seen in the next attachment (sorry, I don't have a serial cable).

Perhaps this will be some help to someone who knows more about how this is supposed to work? If more information is needed I'd be happy to help.

As a work-around, I'm currently commenting out the for loop in vesa_set_display_mode (src/add-ons/accelerants/vesa/mode.cpp), which allows Haiku to boot without any problems.

[Stef]

output of vm86.cpp trace (+extras)

[scottmc]

Since the original issue reported has been reported as fixed, I am closing this ticket. @Stef, please try again with a fresher build of Haiku and if you are still having trouble please open a new ticket, and include your specific hardware details.

[diver]

​max_v user from qube.ru recently ran into this bug with his ​Toshiba Satellite 1800–804 which uses Trident CyberBlade 8620.

Normal boot hangs at the last rocket icon.
With "Enable on screen debug output" option Haiku hangs on boot after "register_domain" phrase. Maybe it deserves its own ticket?

"Display syslog from previous session" menu entry almost never available in the boot loader after "reboot" from either kdl or via Ctrl+Alt+Del. Again, is it ok?

The only way to boot Haiku is to enable "Use fail-safe video mode" option in the bootloader.
Later we workarounded it by commenting out the for loop in vesa_set_display_mode (src/add-ons/accelerants/vesa/mode.cpp) as mentioned in comment:15.
BTW, Apply button in Screen preflet freezes the system unmodified vesa driver.

We also tried to copy trident, trident.accelerant and link to trident from BeOS R5, but it didn't work.
Should it work at all?

BIOS is updated to the latest available version (which is from 10.08.2007)

The following 2 syslogs were captured using serial port with enabled TRACE_MODE in src/add-ons/accelerants/vesa/mode.cpp and TRACE_VM86 in src/system/kernel/arch/x86/vm86.cpp

[diver]

listdev output

[diver]

Syslog from working haiku (with "Use fail-safe video mode" option enabled)

[diver]

bt, ints, running, threads and sems after hang with unmodified vesa driver

[lispy]

Hi everyone, I can verify this issue on my Toshiba Portege 3110ct. If I boot with failsafe option it works flawlessly. Setting the vesa file on 800 600 32 (wich screen applet reports after successful boot) it stops at the rocket icon. The card is a Trident Cyber 9525. Working Vesa would be fine for it, as it runs quite smoothly. any hints?

[diver]

Try to replace vesa.accelerant from ​this archive and see if you are able to boot without failsafe option. Note, this is GCC2 binary.

[lispy]

Ok, my russian is a bit rusty and I don´t get the best feeling by downloading random binaries from the web. Nevertheless I gave it a try. But sorry, it´s even worse. Now I can´t even boot with the safe mode options from the menu. What´s the difference to the regular vesa.accelerant? Do I have to replace the vesa file included in the zip, too? Thanks.

[diver]

I've just tested this binary using hrev38978 in VirtualBox and it works as expected. Did you try to boot without using any options from the bootloader? The difference is disabled vesa_set_display_mode loop. No, you don't need to replace vesa kernel file as it just enables additional tracing you don't need.

[diver]

workaround patch

[lispy]

Great! That did the trick. Many, many thanks... In case I have to reinstall, is there an officiall repository for this file / binary workaround?

[diver]

patched vesa.accelerant from hrev39000 for GCC2/GCC4 builds

[diver]

I'm glad it worked for you. You can use vesa_accelerant_r39000.zip attached to this ticket for the time being.

[Disreali]

No significant activity for 12 months. Is this issue still occurring for people?

[luroh]

Anyone able to test this with R1 Alpha 4.1?

[luroh]

Closing due to lack of feedback.