[haiku-development] Re: Anyone seen this - Vesa delay
- From: Jan Klötzke <jan.kloetzke@xxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 9 Jul 2008 23:25:38 +0200
Bruno Albuquerque <bga@xxxxxxxxxxxxx> wrote:
> Jan Klötzke escreveu:
> > Bruno Albuquerque <bga@xxxxxxxxxxxxx> wrote:
> >> KERN: vm_soft_fault: va 0x10ffc not covered by area in address space
> >> KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault
> >> at 0x10ffc, ip 0x4cab, write 1, user 1, thread 0xed
> >> KERN: vm_page_fault: sending team "app_server" 0x60 SIGSEGV, ip 0x4cab
> >> ("???" +0x4cab)
> >> KERN: vesa: vbe_get_mode_info(326): vm86 failed
> >> KERN: vesa: vesa_set_display_mode(): cannot get mode info
> >
> > This looks like something else. I don't know why but the BIOS code seems
> > to touch an address which it shouldn't access. Maybe another error in the
> > emulation part but you could also change the following line in
> > src/add-ons/kernel/drivers/graphics/vesa/vesa.cpp from:
> > status_t status = vm86_prepare(&vmState, 0x2000);
> > to...
> > status_t status = vm86_prepare(&vmState, 0x20000);
> > .
> >
> > This will cover the location where the page fault happened. Maybe it
> > helps for the time being...
>
> Yep, this worked like a charm. Ut booted straight to the highest
> supported VESA mode in my monitor (1400x1050) and I was able to change
> resolutions on the fly. What are the drawbacks of this change?
Well, the change itself has no drawback but the root cause remains unknown
which gives me a bit of a headache. The VESA BIOS should not access address
0x10ffc. And that it's a write access makes it even more suspicious.
I did not have the time yet to look into this more deeply. OTOH applying the
change doesn't harm and apparently improves things...
BTW: Stephan, does it also help in your case?
/Jan
Other related posts:
