> an MTRR more than once. The restrictions on MTRR size and alignment are too
> numerous to attempt a logical resizing in a small amount of code-- especially
> since the retrictions are different depending on the processor. Might I suggest
> that the looping code be taken out entirely, perhaps o
David Wragg wrote:
> Something like this would be better:
> if (mtrr_add(video_base, temp_size, MTRR_TYPE_WRCOMB, 1) == -EINVAL) {
> /* Find the largest power-of-two */
> while (temp_size & (temp_size - 1))
> temp_sze &= (temp_size - 1);
> mtrr_add(video_ba
> last 2 lines in dmesg output:
> mtrr: 0xd800,0x200 overlaps existing 0xd800,0x100
> mtrr: 0xd800,0x200 overlaps existing 0xd800,0x100
both *fb fbcon drivers and xfree 4 try to setup mtrr ranges, which
are the same for the video card => mtrr complains because the
Alan Cox <[EMAIL PROTECTED]> writes:
> > loop with no exit, as each size mtrr fails.
> > while (mtrr_add(video_base, temp_size, MTRR_TYPE_WRCOMB,
> > 1)==-EINVAL) {
> > temp_size >>= 1;
> > }
>
> Ok that one is the bug.
Even with the obv
Chris Kloiber <[EMAIL PROTECTED]> writes:
> last 2 lines in dmesg output:
> mtrr: 0xd800,0x200 overlaps existing 0xd800,0x100
> mtrr: 0xd800,0x200 overlaps existing 0xd800,0x100
Are you running XFree86-4.0.x?
> cat /proc/mtrr
> reg00: base=0x ( 0MB), siz
> So what do you say. Can we use my patch to allow the user to override the VESA
> detected memory size... or does anyone else have a better plan?
It seems a passable solution. The mtrr bug is real either way and wants a fix.
If the 2Mb reporting is wrong perhaps they will fix the bios ;)
-
Gerd Knorr wrote:
> Well, vesafb really depends on what the vesa bios says...
Exactly my problem. In my laptop, I have a NeoMagic 2160 which does not have use
the last 64k of video for sound buffer like the NeoMagic 256es do yet it still
reports that the memory is not video memory. Both XF
On Fri, Jan 05, 2001 at 11:31:23AM -0500, Chris Kloiber wrote:
>
> Possibly related symptoms:
>
> kernel 2.4.0-ac1 compiled with gcc version 2.96 2731 (Red Hat Linux
> 7.0)
>
> last 2 lines in dmesg output:
> mtrr: 0xd800,0x200 overlaps existing 0xd800,0x100
> mtrr: 0xd8
> yywrap is a hack rather than generally safe feature and its not guaranteed that
> your videoram wraps neatly. Really the driver should have spotted the hole I
> guess.
Well, vesafb really depends on what the vesa bios says...
That's why it has all may-have-problems features turned off by defau
> Dough! I normally use ywrap scrolling, the memory thing means that I get a big
> "black hole" every time I get down to that last 64k of memory, and before the
> pointer to the console's display resets back to "top" of the memory region. The
> only way I've found to get around this is to fo
Alan Cox wrote:
> > 1) The amount of video memory is being incorrectly reported my the VESA call
> > used in arch/i386/video.S (INT 10h AX=4f00h). My Dell Inspiron 3200 (NeoMagic
> > video) returns that it has 31 64k blocks of video memory, instead of the
> > correct 32. This means that vesafb
Alan Cox wrote:
>
> > 1) The amount of video memory is being incorrectly reported my the VESA call
> > used in arch/i386/video.S (INT 10h AX=4f00h). My Dell Inspiron 3200 (NeoMagic
> > video) returns that it has 31 64k blocks of video memory, instead of the
> > correct 32. This means that vesa
> 1) The amount of video memory is being incorrectly reported my the VESA call
> used in arch/i386/video.S (INT 10h AX=4f00h). My Dell Inspiron 3200 (NeoMagic
> video) returns that it has 31 64k blocks of video memory, instead of the
> correct 32. This means that vesafb thinks that I've got 198
On startup of a 2.4.0 kernel with VESA frambuffer console and MTRRs enabled, my
kernel hard locks before I can ever see anything displayed on my screen. I
tracked the trouble down to 2 things:
1) The amount of video memory is being incorrectly reported my the VESA call
used in arch/i386/video.S
14 matches
Mail list logo
