[haiku-development] Re: Anyone seen this - Vesa delay
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 11 Jul 2008 11:18:56 +0200
Jan Klötzke wrote:
> 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?
As I wrote earlier, enlarging the space for vm86_prepare fixes the issue
for me that I cannot switch resolutions. However, the change also brings a
significant slowdown in graphics speed. I am assuming that without the
change, any call to vesa_set_display_mode() fails, and the MTRR setup is
not triggered. In that case, the original mapping is probably still active
(I assume) and my graphics speed is very high. With the patch, the MTRR
setup is also triggered, but something is wrong and the graphics speed
degrades considerably. So far my theory at least... :-)
Best regards,
-Stephan
Other related posts:
