[PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Bryan Mayland]

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 (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 1984k of video ram,
when I actually have 2M.  This problem has been previously addressed by a patch
I sent (2 times) and has never made it into the kernel.

2)  When the vesafb goes to mtrr_add its range (with the incorrect 1984k size)
mtrr_add fails with -EINVAL.  The code in vesafb_init then goes into a while
loop with no exit, as each size mtrr fails.
                 while (mtrr_add(video_base, temp_size, MTRR_TYPE_WRCOMB,
1)==-EINVAL) {
                         temp_size >>= 1;
                 }
If the kernel messages were visible at this time (which they aren't) you'd see
messages like:
    mtrr: base(0xfd000000) is not aligned on a size(0x1f0000) boundary
and then
    mtrr: size and base must be multiples of 4 kiB

Below is a patch which both prevents the endless loop problem, and adds a mem=
option the the video=vesa kernel command line.  I know that Linus hates it when
2 things are combined like this, but I think that they're closely enough
related (but have to do with memory size detection problems) to warrant it.  I
can split them if requested.  I've also CCed him on this message since this
will be my third submission of this patch without any response from the
maintainer or linux-kernel.

Bry

diff -urN linux-orig/Documentation/fb/vesafb.txt
linux/Documentation/fb/vesafb.txt
--- linux-orig/Documentation/fb/vesafb.txt Fri Jul 28 15:50:51 2000
+++ linux/Documentation/fb/vesafb.txt Fri Jan  5 10:22:20 2001
@@ -146,6 +146,12 @@

 mtrr setup memory type range registers for the vesafb framebuffer.

+mem     Override the amount of memory reported by the VESA BIOS
+ INT 10h (AX=4f00h). Some VBE implementations misreport the
+ amount of video memory, causing a "black hole" when using ywrap
+ every time the end of the memory is reached. If you enter a
+ value here larger than you actually have, you will more than
+ likely lock your system so be careful! Syntax is mem=XXX[kKmM]

 Have fun!

@@ -156,3 +162,4 @@

 Minor (mostly typo) changes
 by Nico Schmoigl <schmoigl@rumms.uni-mannheim.de>
+mem option added by Bryan Mayland <bmayland@leonindev.com>
diff -urN linux-orig/drivers/video/vesafb.c linux/drivers/video/vesafb.c
--- linux-orig/drivers/video/vesafb.c Mon Oct 16 15:37:52 2000
+++ linux/drivers/video/vesafb.c Fri Jan  5 10:22:37 2001
@@ -453,6 +453,7 @@
  char *this_opt;

  fb_info.fontname[0] = '\0';
+ video_size = 0;

  if (!options || !*options)
   return 0;
@@ -476,6 +477,13 @@
    mtrr=1;
   else if (!strncmp(this_opt, "font:", 5))
    strcpy(fb_info.fontname, this_opt+5);
+  else if (!strncmp(this_opt, "mem=", 4)) {
+   video_size = simple_strtoul(this_opt + 4, &this_opt, 0);
+   if (*this_opt == 'K' || *this_opt == 'k')
+     video_size <<= 10;
+   else if (*this_opt=='M' || *this_opt=='m')
+    video_size <<= 20;
+  }
  }
  return 0;
 }
@@ -515,7 +523,9 @@
  video_width         = screen_info.lfb_width;
  video_height        = screen_info.lfb_height;
  video_linelength    = screen_info.lfb_linelength;
- video_size          = screen_info.lfb_size * 65536;
+    /* video_size may have been overriden by a command line option */
+  if (!video_size)
+    video_size = screen_info.lfb_size * 65536;
  video_visual = (video_bpp == 8) ?
   FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;

@@ -635,7 +645,7 @@

  if (mtrr) {
   int temp_size = video_size;
-  while (mtrr_add(video_base, temp_size, MTRR_TYPE_WRCOMB, 1)==-EINVAL) {
+  while (temp_size && (mtrr_add(video_base, temp_size, MTRR_TYPE_WRCOMB,
1)==-EINVAL)) {
    temp_size >>= 1;
   }
  }


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Alan Cox]

> 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 1984k of video ram,

You have 31. The last one is used for audio buffering

> 2)  When the vesafb goes to mtrr_add its range (with the incorrect 1984k size)
> mtrr_add fails with -EINVAL.  The code in vesafb_init then goes into a while
> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Chris Kloiber]

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 thinks that I've got 1984k of video ram,
> 
> You have 31. The last one is used for audio buffering
> 
> > 2)  When the vesafb goes to mtrr_add its range (with the incorrect 1984k size)
> > mtrr_add fails with -EINVAL.  The code in vesafb_init then goes into a while
> > 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.

Possibly related symptoms:

kernel 2.4.0-ac1 compiled with gcc version 2.96 20000731 (Red Hat Linux
7.0)

last 2 lines in dmesg output:
mtrr: 0xd8000000,0x2000000 overlaps existing 0xd8000000,0x1000000
mtrr: 0xd8000000,0x2000000 overlaps existing 0xd8000000,0x1000000

cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size= 256MB: write-back, count=1
reg01: base=0xd8000000 (3456MB), size=  16MB: write-combining, count=1
reg05: base=0xd0000000 (3328MB), size=  64MB: write-combining, count=1
 

My video card is Voodoo3/3000/AGP and my motherboard is an MSI-6330
(Athlon Tbird 800)
I am experiencing text console video corruption. In tdfxfb mode or
regular vesafb it looks like a horizontal line of color pixels that
grows, in 'regular' text mode I get flashing characters or the font
degrades into unreadable mess. X is fine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Bryan Mayland]

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 thinks that I've got 1984k of video ram,
>
> You have 31. The last one is used for audio buffering

    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 force the size of the video memory.
Does this mean that there's a problem with the display adapter that it wraps reads
of video memory at the 2048k boundary?  Is the 64k used by the Crystal 4232 and/or
OPL3?  If so, why doesn't listening to sounds screw with my fbcon?

Bry

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Alan Cox]

>     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 force the size of the video memory.
> Does this mean that there's a problem with the display adapter that it wraps reads
> of video memory at the 2048k boundary?  Is the 64k used by the Crystal 4232 and/or
> OPL3?  If so, why doesn't listening to sounds screw with my fbcon?

Its used on the chip for the onboard audio. See drivers/sound/nm256*. If you
have other sound chips then it is probably not needed.

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.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Gerd Knorr]

> 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 default:
no ywrap, no mtrr.  At least it was this way last time I touched it.

  Gerd

-- 
Get back there in front of the computer NOW. Christmas can wait.
	-- Linus "the Grinch" Torvalds,  24 Dec 2000 on linux-kernel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Steven Walter]

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 20000731 (Red Hat Linux
> 7.0)
> 
> last 2 lines in dmesg output:
> mtrr: 0xd8000000,0x2000000 overlaps existing 0xd8000000,0x1000000
> mtrr: 0xd8000000,0x2000000 overlaps existing 0xd8000000,0x1000000
> 
> cat /proc/mtrr
> reg00: base=0x00000000 (   0MB), size= 256MB: write-back, count=1
> reg01: base=0xd8000000 (3456MB), size=  16MB: write-combining, count=1
> reg05: base=0xd0000000 (3328MB), size=  64MB: write-combining, count=1
>  
> 
> My video card is Voodoo3/3000/AGP and my motherboard is an MSI-6330
> (Athlon Tbird 800)
> I am experiencing text console video corruption. In tdfxfb mode or
> regular vesafb it looks like a horizontal line of color pixels that
> grows, in 'regular' text mode I get flashing characters or the font
> degrades into unreadable mess. X is fine.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

I can confirm these symptoms on my system with a Voodoo3/3000/PCI and a
SiS530 motherboard (AMD K6/2).  I get both the "mtrr: ... overlaps
existing ..." message some extent of the text corruption.  With VESA fb,
I get the random lines of colored pixels.  With tdfxfb, the most
noticable problem is that the cursor is several times larger than it
should be (like 1"x1").  Additionally, with the standard console, upon
switching from X, 1 or 2 cells with have randomly colored letters in
them, and some letters ("h" particularly) always appear incorrectly.

-- 
-Steven
"Voters decide nothing.  Vote counters decide everything."
				-Joseph Stalin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Bryan Mayland]

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 XFree86 and SVGALib hard code the
amout of available video memory based on the PCI id of the neomagic device, which
tells me that there might not be a way to detect it properly.  What I'm suggesting is
that we "Avoid the probe!" (which is fun to say), and add a way for the user to
override the amount of memory detected by the VESA int 0x10 call.  There is only
about 10 lines of code requited to make the change, and it can't break anything if
you don't turn it on.

    I wish there was a way to detect that the code wrapped memory before the hardware
did, but that would be un-possible to probe (AFAIK).  You can detect that ywrap isn't
working properly by writing a magic number to offset 0, and attempt to read if from
offset [memsize], and see if you get the same value back.  This doesn't fix the
problem, it just assertains if it is working properly or not.

> That's why it has all may-have-problems features turned off by default:
> no ywrap, no mtrr.  At least it was this way last time I touched it.

    I was pretty suprised ywrap worked at all on my system.  The speed increased over
"redraw" is quite dramatic.

    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?

Bry

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Alan Cox]

>     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 ;)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Bryan Mayland]

Alan Cox wrote:

> >     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 ;)

Hee hee.  When I first saw this happening back in 1999, I tried to talk to Dell first but
after about an hour on the phone with the support guy trying to explain what VESA BIOS
Extensions were, and why running the Dell diagnostics disk would not solve my problem, I
decided I'd just fix it in software.  Can I get an amen for an open source operating
system?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[David Wragg]

Chris Kloiber <ckloiber@rochester.rr.com> writes:
> last 2 lines in dmesg output:
> mtrr: 0xd8000000,0x2000000 overlaps existing 0xd8000000,0x1000000
> mtrr: 0xd8000000,0x2000000 overlaps existing 0xd8000000,0x1000000

Are you running XFree86-4.0.x?

> cat /proc/mtrr
> reg00: base=0x00000000 (   0MB), size= 256MB: write-back, count=1
> reg01: base=0xd8000000 (3456MB), size=  16MB: write-combining, count=1
> reg05: base=0xd0000000 (3328MB), size=  64MB: write-combining, count=1
>  
> 
> My video card is Voodoo3/3000/AGP and my motherboard is an MSI-6330
> (Athlon Tbird 800)
> I am experiencing text console video corruption. In tdfxfb mode or
> regular vesafb it looks like a horizontal line of color pixels that
> grows, in 'regular' text mode I get flashing characters or the font
> degrades into unreadable mess. X is fine.

What does "lspci -v" give?


David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/MTRR locks 2.4.0 on init

[David Wragg]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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 obvious bug fixed, that code is strange.  "temp_size >>=
1" does little to improve the chances of the mtrr_add succeeding.
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_base, temp_size, MTRR_TYPE_WRCOMB, 1);
}


(But this is just a very crude way to work around the inflexibility of
the MTRRs.  Rather than cluttering up calls to mtrr_add, it would be
better to fix this properly, either by implementing PAT support
(Zoltán Böszörményi said he was working on that), or by having a
user-space helper program to make more intelligent MTRR allocations,
or both.)


David Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/ MTRR locks 2.4.0 on init

[Gerd Knorr]

> last 2 lines in dmesg output:
> mtrr: 0xd8000000,0x2000000 overlaps existing 0xd8000000,0x1000000
> mtrr: 0xd8000000,0x2000000 overlaps existing 0xd8000000,0x1000000

both *fb fbcon drivers and xfree 4 try to setup mtrr ranges, which
are the same for the video card => mtrr complains because the entry
is already there.

  Gerd

-- 
Get back there in front of the computer NOW. Christmas can wait.
	-- Linus "the Grinch" Torvalds,  24 Dec 2000 on linux-kernel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/MTRR locks 2.4.0 on init

[Bryan Mayland]

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_base, temp_size, MTRR_TYPE_WRCOMB, 1);
> }
> (But this is just a very crude way to work around the inflexibility of
> the MTRRs.  Rather than cluttering up calls to mtrr_add, it would be
> better to fix this properly

    I agree.  VesaFB is the only code (as far as I know) which attempts to grab
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 outputting success or
failure like:
#ifdef CONFIG_MTRR
if (mtrr)
  if (mtrr_add(video_base, video_size, MTRR_TYPE_WRCOMB, 1) == -EINVAL)
    printk(KERN_INFO "vesafb:  Could not allocate MTRR\n");
  else
    printk(KERN_INFO "vesafb:  MTRR Write-Combining enabled\n");
#endif  /* CONFIG_MTRR */

Bry

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Framebuffer as a module

[Bryan Mayland]

> I used to compile-in my framebuffer-device in the kernel
> then i just appended "video=tdfxfb:1024x768-32@70" in lilo.conf and it
> worked..
> now i compiled it as a module, and want modprobe to start it up for me..
> how can this be done?
> modprobe tdfxfb 1024x768-32@70

That's a very good question.  The tdfxfb module has no parameters.  It would be
ideal if the tdfxfb mainatiner would add some MODULE_PARM lines for all the
parameters and move the code from tdfxfb_setup that does work into tdfxfb_init.

I think a valid work-around for you is to use fbset after you load the module
to set the resolution.  Does that work?
Bry

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VESA framebuffer w/MTRR locks 2.4.0 on init

[Alan Cox]

> 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 outputting success or

Power of two shrinkage works for most cases


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Framebuffer as a module

[Bryan Mayland]

-=da TRoXX=- wrote:

> and i don't get it, who accepts these parameters in the kernel then? i mean
> if i put them in lilo.conf at least SOME thing uses them to set the
> framebuffer right...

    The tdfxfb code does.  When compiled into the kernel, there is a function
(tdfxfb_setup) which the kernel calls with the relevant kernel command-line
parameters.  When compiled as a module, this function is ifdef'ed out, as well
it should be, because I don't think that there is a function which is called to
pass the module parameters.  Modules use MODULE_PARM to 'import' their
parameters.  The code is incomplete, perhaps for a reason.  In theory, the
author should add the required MODULE_PARM macros to export the parameters and
then move the code which does anything besides saving the paramter values to
tdfxfb_init, which is called when the module is loaded /and/ after tdfxfb_setup
when compiled into the kernel.  I don't have the time to fix it myself, I don't
even have a machine with Linux and a Voodoo3 card.

> I know this parameter is for modules only that support modedb (modedb.c) but
> tdfxfb supports that(that's why it works in the kernel)...

    It does, but only when compiled into the kernel due to the way it does its's
setup.

Bry

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/