#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: | ||
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)
Change History (42)
by , 17 years ago
comment:1 by , 17 years ago
Forgot to add the specs of the machine.
Core2Duo 3.0ghz 5GB ram NVidia GeForce 9800GTX
comment:3 by , 17 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 , 17 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 , 17 years ago
Excellent idea, i'll set up another haiku partition here and give it a go :)
comment:6 by , 17 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 , 17 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 , 17 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
comment:9 by , 17 years ago
Cc: | added |
---|---|
Component: | - General → Drivers/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 , 17 years ago
Attachment: | vesa_troubles.JPG added |
---|
comment:10 by , 17 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!
comment:11 by , 16 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 , 16 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:14 by , 16 years ago
Cc: | added |
---|---|
Platform: | All → x86 |
Resolution: | fixed |
Status: | closed → reopened |
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 , 16 years ago
Attachment: | syslog_25679_toshiba.txt added |
---|
syslog from hrev25679, on the Toshiba laptop
by , 16 years ago
Attachment: | stacktrace_26489_toshiba.jpg added |
---|
photo of 'bt' output on the Toshiba laptop
comment:15 by , 16 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.
comment:16 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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 , 14 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Version: | R1/pre-alpha1 → R1/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. Is it worth it's own trac ticket? See attachment:register_domain.png
"Display syslog from previous session" menu entry almost never available in the boot loader after "reboot" from either kdl or via Ctrl+Alt+Del. 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.
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
by , 14 years ago
Attachment: | syslog2.txt added |
---|
Syslog from working haiku (with "Use fail-safe video mode" option enabled)
by , 14 years ago
Attachment: | kdl_session.log added |
---|
bt, ints, running, threads and sems after hang with unmodified vesa driver
comment:18 by , 14 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 , 14 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 , 14 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 , 14 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.
comment:22 by , 14 years ago
patch: | 0 → 1 |
---|
comment:23 by , 14 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 , 14 years ago
Attachment: | vesa_accelerant_r39000.zip added |
---|
patched vesa.accelerant from hrev39000 for GCC2/GCC4 builds
comment:24 by , 14 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 , 14 years ago
Blocking: | 7665 added |
---|
comment:26 by , 13 years ago
No significant activity for 12 months. Is this issue still occurring for people?
comment:27 by , 13 years ago
Cc: | added; removed |
---|
comment:29 by , 11 years ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
Closing due to lack of feedback.
comment:30 by , 6 years ago
Blocking: | 7665 removed |
---|
Photo of the bt