Use MTRRs by default for vesafb on x86-64
diff mbox series

Message ID 20030515145640.GA19152@averell
State New, archived
Headers show
Series
  • Use MTRRs by default for vesafb on x86-64
Related show

Commit Message

Andi Kleen May 15, 2003, 2:56 p.m. UTC
x86-64 cannot call the 32bit VESA BIOS. This means when vesafb is active
it does software copying in the vesa frame buffer. This is insanely slow
when the frame buffer is not marked for write combining. 

Some discussion showed that the use_mtrr flag was only off for some 
old broken ET4000 ISA card. x86-64 has no ISA, so this is no concern.
Make the default depend on CONFIG_ISA. 

Patch for 2.5.69.  Originally suggested by Gerd Knorr.

-Andi





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

Comments

Dave Jones May 15, 2003, 3:16 p.m. UTC | #1
On Thu, May 15, 2003 at 04:56:40PM +0200, Andi Kleen wrote:

 > x86-64 cannot call the 32bit VESA BIOS. This means when vesafb is active
 > it does software copying in the vesa frame buffer. This is insanely slow
 > when the frame buffer is not marked for write combining. 
 > 
 > Some discussion showed that the use_mtrr flag was only off for some 
 > old broken ET4000 ISA card. x86-64 has no ISA, so this is no concern.
 > Make the default depend on CONFIG_ISA. 

There are PCI ET4000's too.  Though if we can get the PCI IDs for those,
we can work around them with a quirk.  I have one *somewhere*, but it'll
take me a while to dig it out.

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Andi Kleen May 15, 2003, 3:20 p.m. UTC | #2
On Thu, May 15, 2003 at 05:16:33PM +0200, Dave Jones wrote:
> On Thu, May 15, 2003 at 04:56:40PM +0200, Andi Kleen wrote:
> 
>  > x86-64 cannot call the 32bit VESA BIOS. This means when vesafb is active
>  > it does software copying in the vesa frame buffer. This is insanely slow
>  > when the frame buffer is not marked for write combining. 
>  > 
>  > Some discussion showed that the use_mtrr flag was only off for some 
>  > old broken ET4000 ISA card. x86-64 has no ISA, so this is no concern.
>  > Make the default depend on CONFIG_ISA. 
> 
> There are PCI ET4000's too.  Though if we can get the PCI IDs for those,
> we can work around them with a quirk.  I have one *somewhere*, but it'll
> take me a while to dig it out.

To make all 0.001 users left of them happy yes. I think the patch should
be applied anyways.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Dave Jones May 15, 2003, 3:25 p.m. UTC | #3
On Thu, May 15, 2003 at 05:20:11PM +0200, Andi Kleen wrote:

 > > There are PCI ET4000's too.  Though if we can get the PCI IDs for those,
 > > we can work around them with a quirk.  I have one *somewhere*, but it'll
 > > take me a while to dig it out.
 > 
 > To make all 0.001 users left of them happy yes. I think the patch should
 > be applied anyways.

Agreed.

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alan Cox May 16, 2003, 8:51 p.m. UTC | #4
On Iau, 2003-05-15 at 16:16, Dave Jones wrote:
> There are PCI ET4000's too.  Though if we can get the PCI IDs for those,
> we can work around them with a quirk.  I have one *somewhere*, but it'll
> take me a while to dig it out.

Some older SiS cards have problems too. I have a 6326 that doesn't work
with sisfb (too old) and vesafb with mtrr fails.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Eric W. Biederman May 16, 2003, 10:58 p.m. UTC | #5
Andi Kleen <ak@muc.de> writes:

> x86-64 cannot call the 32bit VESA BIOS. This means when vesafb is active
> it does software copying in the vesa frame buffer. This is insanely slow
> when the frame buffer is not marked for write combining. 
> 
> Some discussion showed that the use_mtrr flag was only off for some 
> old broken ET4000 ISA card. x86-64 has no ISA, so this is no concern.
> Make the default depend on CONFIG_ISA. 
> 
> Patch for 2.5.69.  Originally suggested by Gerd Knorr.

I don't know if this affects the frame buffers per se.

But often BIOS's on systems with large amounts of memory configure
overlapping mtrrs (where an uncacheable mtrr would override a larger
cacheable range).  To date this has confused the linux mtrr code when
it tries to modify things, and you cannot properly setup mtrrs.    I
believe this applies to both the fb case as well as X.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Andi Kleen May 18, 2003, 5:39 a.m. UTC | #6
On Fri, May 16, 2003 at 10:51:36PM +0200, Alan Cox wrote:
> On Iau, 2003-05-15 at 16:16, Dave Jones wrote:
> > There are PCI ET4000's too.  Though if we can get the PCI IDs for those,
> > we can work around them with a quirk.  I have one *somewhere*, but it'll
> > take me a while to dig it out.
> 
> Some older SiS cards have problems too. I have a 6326 that doesn't work
> with sisfb (too old) and vesafb with mtrr fails.

Can you provide PCI info for them to add a quirk ? 

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jamie Lokier May 18, 2003, 4:11 p.m. UTC | #7
Andi Kleen wrote:
> On Fri, May 16, 2003 at 10:51:36PM +0200, Alan Cox wrote:
> > On Iau, 2003-05-15 at 16:16, Dave Jones wrote:
> > > There are PCI ET4000's too.  Though if we can get the PCI IDs for those,
> > > we can work around them with a quirk.  I have one *somewhere*, but it'll
> > > take me a while to dig it out.
> > 
> > Some older SiS cards have problems too. I have a 6326 that doesn't work
> > with sisfb (too old) and vesafb with mtrr fails.
> 
> Can you provide PCI info for them to add a quirk ? 

What exactly "doesn't work" with these cards?

I'm thinking that the only way write-combining MTRRs could possibly
break a framebuffer is if part of the address range is used as a
register bank - otherwise, to the card, it just looks like well
written rendering code.

If this is so, then it might be possible to set write-combining MTRRs
while the framebuffer is operating, but to temporarily disable those
MTRRs while calling into the VESA BIOS code, for these cards.

And if that does work, then it might even be reasonable to temporarily
disable the MTRRs while calling the BIOS for all vesafb cards, thus
removing the need for a blacklist -- which is a headache for something
that needs to be as portable to unknown cards as vesafb.

-- Jamie


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alan Cox May 18, 2003, 8:40 p.m. UTC | #8
On Sul, 2003-05-18 at 17:11, Jamie Lokier wrote:
> > Can you provide PCI info for them to add a quirk ? 
> 
> What exactly "doesn't work" with these cards?

If you sent an MTRR you get crap on the display. I'm not sure if that is
registers being covered (seems dubious) or other PCI problems perhaps
with bursts

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jamie Lokier May 18, 2003, 10:34 p.m. UTC | #9
Alan Cox wrote:
> > What exactly "doesn't work" with these cards?
> 
> If you sent an MTRR you get crap on the display. I'm not sure if that is
> registers being covered (seems dubious) or other PCI problems perhaps
> with bursts

Is it consistently bad, or is it just an occasional glitch, pixel here
or there that goes wrong?

I like your suggestion of PCI bursts - perhaps the card's FIFO to
video RAM overflows due to RAM being too slow or too busy for display
reads.  It seems quite plausible.  It might even depend on the video mode.

If that's the problem, a test which writes a data pattern to a
significant chunk of video RAM in sequence, as fast as possible, and
then reads it would be practically guaranteed to spot this and
indicate that MTRRs aren't suitable for this card in this mode.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Dave Jones May 18, 2003, 10:52 p.m. UTC | #10
On Sun, May 18, 2003 at 11:34:46PM +0100, Jamie Lokier wrote:

 > If that's the problem, a test which writes a data pattern to a
 > significant chunk of video RAM in sequence, as fast as possible, and
 > then reads it would be practically guaranteed to spot this and
 > indicate that MTRRs aren't suitable for this card in this mode.

Or you could just add the PCI ID to the quirks list..

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jamie Lokier May 18, 2003, 11:33 p.m. UTC | #11
Dave Jones wrote:
>  > If that's the problem, a test which writes a data pattern to a
>  > significant chunk of video RAM in sequence, as fast as possible, and
>  > then reads it would be practically guaranteed to spot this and
>  > indicate that MTRRs aren't suitable for this card in this mode.
> 
> Or you could just add the PCI ID to the quirks list..

My point being that vesafb is used for maximum compatibility, when you
have no other way to drive an unknown framebuffer.  It's the emergency
backup driver.  Shouldn't it be robust when faced with an unknown
framebuffer type, new or old?

Granted if there are only two cards with this problem and we are
confident that no other cards have the problem, a PCI ID would do it.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Dave Jones May 19, 2003, 12:02 a.m. UTC | #12
On Mon, May 19, 2003 at 12:33:25AM +0100, Jamie Lokier wrote:

 > My point being that vesafb is used for maximum compatibility, when you
 > have no other way to drive an unknown framebuffer.  It's the emergency
 > backup driver.  Shouldn't it be robust when faced with an unknown
 > framebuffer type, new or old?

It works just fine. Just you can't enable MTRRs for framebuffer memory.
Losing a bit of performance for what is (by todays standards) a crap
performing card anyways, is no big deal.

		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jamie Lokier May 19, 2003, 12:28 a.m. UTC | #13
Dave Jones wrote:
>  > My point being that vesafb is used for maximum compatibility, when you
>  > have no other way to drive an unknown framebuffer.  It's the emergency
>  > backup driver.  Shouldn't it be robust when faced with an unknown
>  > framebuffer type, new or old?
> 
> It works just fine. Just you can't enable MTRRs for framebuffer memory.
> Losing a bit of performance for what is (by todays standards) a crap
> performing card anyways, is no big deal.

How do you know the blacklist is complete?

That's my point: with most drivers we accept a few surprises and
change the code, but vesafb is supposed to handle any old crap card
that's thrown at it, as robustly as possible.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Dave Jones May 19, 2003, 1:24 a.m. UTC | #14
On Mon, May 19, 2003 at 01:28:20AM +0100, Jamie Lokier wrote:

 > > It works just fine. Just you can't enable MTRRs for framebuffer memory.
 > > Losing a bit of performance for what is (by todays standards) a crap
 > > performing card anyways, is no big deal.
 > 
 > How do you know the blacklist is complete?

no-one complains that they see random crap on their screens any more.
 
		Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Andi Kleen May 19, 2003, 10:37 a.m. UTC | #15
On Sat, May 17, 2003 at 12:58:39AM +0200, Eric W. Biederman wrote:
> I don't know if this affects the frame buffers per se.
> 
> But often BIOS's on systems with large amounts of memory configure
> overlapping mtrrs (where an uncacheable mtrr would override a larger
> cacheable range).  To date this has confused the linux mtrr code when
> it tries to modify things, and you cannot properly setup mtrrs.    I
> believe this applies to both the fb case as well as X.

Interesting. Perhaps it would be really better to use change_page_attr()
with PAT for this. It would avoid these problems.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Eric W. Biederman May 19, 2003, 12:26 p.m. UTC | #16
Andi Kleen <ak@muc.de> writes:

> On Sat, May 17, 2003 at 12:58:39AM +0200, Eric W. Biederman wrote:
> > I don't know if this affects the frame buffers per se.
> > 
> > But often BIOS's on systems with large amounts of memory configure
> > overlapping mtrrs (where an uncacheable mtrr would override a larger
> > cacheable range).  To date this has confused the linux mtrr code when
> > it tries to modify things, and you cannot properly setup mtrrs.    I
> > believe this applies to both the fb case as well as X.
> 
> Interesting. Perhaps it would be really better to use change_page_attr()
> with PAT for this. It would avoid these problems.

At least for x86-64 I would recommend that, as you can count on it existing.

For normal x86 it is more interesting.  But you are less likely to run with 
lots of memory so this case is less likely to show up. I have already heard
people seriously discussing 16GB on an off the shelf on an x86-64
system.  Getting 2GB PC2700 DIMMs is still a bit of a challenge, but
the practical memory size barrier (3GB per task) is finally gone.

For x86-64 a software ``mtrr'' that maps everything the e820 map says
is memory as write-back and everything else as uncacheable by default would
be nice.  As the mtrr interface is already understood by things like X.  And
there needs to be some data structure that remembers what the page
cache-ability attributes should be.

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

Patch
diff mbox series

--- linux/drivers/video/vesafb.c	2003-05-08 04:52:58.000000000 +0200
+++ linux-2.5.69-amd64/drivers/video/vesafb.c	2003-05-15 16:55:51.000000000 +0200
@@ -51,7 +51,11 @@ 
 static u32 pseudo_palette[17];
 
 static int             inverse   = 0;
+#ifndef CONFIG_ISA 
+static int 	      mtrr	 = 1;
+#else
 static int             mtrr      = 0;
+#endif
 
 static int             pmi_setpal = 0;	/* pmi for palette changes ??? */
 static int             ypan       = 0;  /* 0..nothing, 1..ypan, 2..ywrap */