VESA framebuffer w/ MTRR locks 2.4.0 on init

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

@@ -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 <[email protected]>
+mem option added by Bryan Mayland <[email protected]>

diff -urN linux-orig/drivers/video/vesafb.c linux/drivers/video/vesafb.c
@@ -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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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

Ok that one is the bug.

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

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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.

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Are you running XFree86-4.0.x?

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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.

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/