[haiku-bugs] Re: [Haiku] #7787: VESA regression: 640x480 no longer works at boot (but works in Screen prefs!)
- From: "ttcoder" <trac@xxxxxxxxxxxx>
- Date: Fri, 15 Jul 2011 15:56:17 -0000
#7787: VESA regression: 640x480 no longer works at boot (but works in Screen
prefs!)
----------------------------------+-----------------------
Reporter: ttcoder | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: System/Boot Loader | Version: R1/alpha3
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: x86
----------------------------------+-----------------------
Comment (by ttcoder):
@devs:[[BR]]
It still looks like a memory corruption. Been reviewing video.cpp side-by-
side with the syslog, and I understand better the code flow: it turns out
that the bootloader ''does'' select 800x600 when initializing, it is smart
enough to pick that one over the smaller resolutions. But that choice gets
lost along the way to kernel-land, AND the other choices get corrupted;
explanation:
- platform_switch_to_text_mode() is ok
- platform_init_video() is ok (it does select '''800x600''' in
vesa_init())
- platform_switch_to_logo() oddly dprintf()s that
gKernelArgs.frame_buffer.height='''640''' (x480) instead of 800x600 !
You can check the 'syslog-failure' file I have posted, it does log what I
describe: the loader [http://dev.haiku-
os.org/browser/haiku/trunk/src/system/boot/platform/bios_ia32/video.cpp#L529
TRACE()ing] 0x115 (that is, '''800x600'''), and then asking the kernel to
use '''640x480x32''' ([http://dev.haiku-
os.org/browser/haiku/trunk/src/system/boot/platform/bios_ia32/video.cpp#L859
dprintf()])..
So it seems that 'gKernelArgs' gets corrupted (part of it gets clobbered)
inbetween the user menu and kernel loading. And thus when the kernel kicks
in, it is passed the wrong arguments; additionally, the parameters for
640x480 maybe get corrupted too (since there is also the bug that this
resolution does not work since alpha3).. Additionally, it also corrupts
the nVidia driver depending on the situation?
The last few days I was thinking about building the loader from source..
Maybe I will still do that: as experimented before, reverting to an older
revision of 'haiku_loader' fixes the corruption, so this hints at the
memory corruption occuring insider the loader, not in the kernel.
NOTE on video.cpp:50 :
{{{
static video_mode *sMode, *sDefaultMode;
}}}
'sMode' is not initialized to NULL on construction, and only gets affected
at the end of platform_init_video() though that's probably not the source
of my problems.
--
Ticket URL: <http://dev.haiku-os.org/ticket/7787#comment:8>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
