Opened 11 years ago

Closed 5 years ago

Last modified 14 months ago

#2337 closed bug (invalid)

After the recent vesa changes haiku hangs at boot

Reported by: ddew Owned by: axeld
Priority: normal Milestone: R1
Component: Drivers/Graphics Version: R1/Development
Keywords: Cc: pieterpan, Stef
Blocked By: Blocking:
Has a Patch: yes Platform: x86

Description

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.

Attachments (12)

bt.jpg (69.6 KB ) - added by ddew 11 years ago.
Photo of the bt
syslog (232.5 KB ) - added by ddew 11 years ago.
Syslog from working haiku
vesa_troubles.JPG (163.0 KB ) - added by pieterpan 11 years ago.
syslog.txt (72.5 KB ) - added by pieterpan 11 years ago.
Syslog compal laptop
syslog_25679_toshiba.txt (47.3 KB ) - added by Stef 11 years ago.
syslog from hrev25679, on the Toshiba laptop
stacktrace_26489_toshiba.jpg (191.3 KB ) - added by Stef 11 years ago.
photo of 'bt' output on the Toshiba laptop
vm86_do_int.jpg (312.3 KB ) - added by Stef 11 years ago.
output of vm86.cpp trace (+extras)
listdev.txt (1.6 KB ) - added by diver 9 years ago.
listdev output
syslog2.txt (58.4 KB ) - added by diver 9 years ago.
Syslog from working haiku (with "Use fail-safe video mode" option enabled)
kdl_session.log (77.3 KB ) - added by diver 9 years ago.
bt, ints, running, threads and sems after hang with unmodified vesa driver
vesa.accelerant.diff (727 bytes ) - added by diver 9 years ago.
workaround patch
vesa_accelerant_r39000.zip (20.9 KB ) - added by diver 9 years ago.
patched vesa.accelerant from hrev39000 for GCC2/GCC4 builds

Download all attachments as: .zip

Change History (42)

by ddew, 11 years ago

Attachment: bt.jpg added

Photo of the bt

comment:1 by ddew, 11 years ago

Forgot to add the specs of the machine.

Core2Duo 3.0ghz 5GB ram NVidia GeForce 9800GTX

comment:2 by axeld, 11 years ago

Can you provide a syslog from before that change?

comment:3 by ddew, 11 years ago

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

comment:4 by axeld, 11 years ago

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.

comment:5 by ddew, 11 years ago

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

comment:6 by ddew, 11 years ago

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.

comment:7 by axeld, 11 years ago

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.

comment:8 by ddew, 11 years ago

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

by ddew, 11 years ago

Attachment: syslog added

Syslog from working haiku

comment:9 by pieterpan, 11 years ago

Cc: pieter@… added
Component: - GeneralDrivers/Graphics

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.

by pieterpan, 11 years ago

Attachment: vesa_troubles.JPG added

comment:10 by pieterpan, 11 years ago

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!

by pieterpan, 11 years ago

Attachment: syslog.txt added

Syslog compal laptop

comment:11 by bonefish, 11 years ago

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

comment:12 by PieterPanman, 11 years ago

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!

comment:13 by korli, 11 years ago

Resolution: fixed
Status: newclosed

thanks for the update!

comment:14 by Stef, 11 years ago

Cc: stef.busking@… added
Platform: Allx86
Resolution: fixed
Status: closedreopened

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.

by Stef, 11 years ago

Attachment: syslog_25679_toshiba.txt added

syslog from hrev25679, on the Toshiba laptop

by Stef, 11 years ago

photo of 'bt' output on the Toshiba laptop

comment:15 by Stef, 11 years ago

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.

by Stef, 11 years ago

Attachment: vm86_do_int.jpg added

output of vm86.cpp trace (+extras)

comment:16 by scottmc, 9 years ago

Resolution: fixed
Status: reopenedclosed

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.

comment:17 by diver, 9 years ago

Resolution: fixed
Status: closedreopened
Version: R1/pre-alpha1R1/Development

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 with 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

Last edited 9 years ago by diver (previous) (diff)

by diver, 9 years ago

Attachment: listdev.txt added

listdev output

by diver, 9 years ago

Attachment: syslog2.txt added

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

by diver, 9 years ago

Attachment: kdl_session.log added

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

comment:18 by lispy, 9 years ago

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?

comment:19 by diver, 9 years ago

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

comment:20 by lispy, 9 years ago

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.

comment:21 by diver, 9 years ago

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.

by diver, 9 years ago

Attachment: vesa.accelerant.diff added

workaround patch

comment:22 by diver, 9 years ago

Has a Patch: set

comment:23 by lispy, 9 years ago

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

by diver, 9 years ago

Attachment: vesa_accelerant_r39000.zip added

patched vesa.accelerant from hrev39000 for GCC2/GCC4 builds

comment:24 by diver, 9 years ago

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

comment:25 by scottmc, 8 years ago

Blocking: 7665 added

comment:26 by Disreali, 8 years ago

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

comment:27 by diver, 8 years ago

Cc: pieterpan Stef added; pieter@… stef.busking@… removed

comment:28 by luroh, 7 years ago

Anyone able to test this with R1 Alpha 4.1?

comment:29 by luroh, 5 years ago

Resolution: invalid
Status: reopenedclosed

Closing due to lack of feedback.

comment:30 by waddlesplash, 14 months ago

Blocking: 7665 removed
Note: See TracTickets for help on using tickets.