Re: 2.2.16 SMP: mtrr errors
Alan Cox wrote: > > Petr, the Matrox card splits the memory between the two video screens > > when running in a multi-head configuration and "pretends" that it is two > > distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and > > for 8mb seperately when in this mode. > > That is a driver bug. The intel processors only support MTRR's on certain > power boundaries/sizes. The fall through is intended. > > in the latest couple of kernels because of all the mtrr work being done, > > waiting to see if there was resolution. > > The Matrox driver needs to register a single 32Mb MTRR The kernel VESA framebuffer has exactly the same problem. Sometimes VESA reports 2.5Mb video memory, and vesafb's attempt to register an MTRR fails. But should vesafb know about Intel-specific MTRR limitations, given that those limitations may change? -- Jamie - 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/
Re: 2.2.16 SMP: mtrr errors
Alan Cox wrote: Petr, the Matrox card splits the memory between the two video screens when running in a multi-head configuration and "pretends" that it is two distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and for 8mb seperately when in this mode. That is a driver bug. The intel processors only support MTRR's on certain power boundaries/sizes. The fall through is intended. in the latest couple of kernels because of all the mtrr work being done, waiting to see if there was resolution. The Matrox driver needs to register a single 32Mb MTRR The kernel VESA framebuffer has exactly the same problem. Sometimes VESA reports 2.5Mb video memory, and vesafb's attempt to register an MTRR fails. But should vesafb know about Intel-specific MTRR limitations, given that those limitations may change? -- Jamie - 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/
Re: 2.2.16 SMP: mtrr errors
On Tue, 12 Dec 2000, Petr Vandrovec wrote: > That's wrong. They must first register MTRR and then split it to > 24+8, as they cannot register 24MB range. They can split it > 16+16, or (16+8)+8, but at cost of 1 (or 2) additional MTRR entries - > and there is very limited number of possible MTRRs. > > Matroxfb also splits Matrox memory in 24:8, but it registers only one > region in mtrr. Of course, in X, as mtrr registration is done by map > videomemory, you must tell this function to not register mtrr... > > Best regards, > Petr Vandrovec > [EMAIL PROTECTED] NOW, I am really convinced that we need PAT support on top of the crappy MTRR driver. :-) I already started working on it... Regards, Zoltan Boszormenyi - 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/
Re: 2.2.16 SMP: mtrr errors
" Paul C. Nendick " <[EMAIL PROTECTED]> writes: > Shall I submit this to Matrox as a bug then? The "bug" is in the XFree86 core, so telling Matrox might not do a lot of good. The driver code just says "I want to map a framebuffer of this size at this physical address" (or actually "with these PCI details"), and the core code arranges the mapping, doing the MTRR stuff while it's at it. 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/
Re: 2.2.16 SMP: mtrr errors
Shall I submit this to Matrox as a bug then? /paul Alan Cox ([EMAIL PROTECTED]) said: > > Petr, the Matrox card splits the memory between the two video screens > > when running in a multi-head configuration and "pretends" that it is two > > distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and > > for 8mb seperately when in this mode. > > That is a driver bug. The intel processors only support MTRR's on certain > power boundaries/sizes. The fall through is intended. > > > to fall through, but is this correct? I've inserted a break at the end > > of the Intel switch before and have not had problems, but I left it out > > Lucky > > > in the latest couple of kernels because of all the mtrr work being done, > > waiting to see if there was resolution. > > The Matrox driver needs to register a single 32Mb MTRR > -- Paul C. Nendick - 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/
Re: 2.2.16 SMP: mtrr errors
Alan Cox wrote: > > to fall through, but is this correct? I've inserted a break at the end > > of the Intel switch before and have not had problems, but I left it out > > Lucky Wouldn't be the first time... - 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/
Re: 2.2.16 SMP: mtrr errors
> Petr, the Matrox card splits the memory between the two video screens > when running in a multi-head configuration and "pretends" that it is two > distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and > for 8mb seperately when in this mode. That is a driver bug. The intel processors only support MTRR's on certain power boundaries/sizes. The fall through is intended. > to fall through, but is this correct? I've inserted a break at the end > of the Intel switch before and have not had problems, but I left it out Lucky > in the latest couple of kernels because of all the mtrr work being done, > waiting to see if there was resolution. The Matrox driver needs to register a single 32Mb MTRR - 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/
Re: 2.2.16 SMP: mtrr errors
On 12 Dec 00 at 16:07, John Cavan wrote: > Petr Vandrovec wrote: > > > kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary > > > last message repeated 2 times > > > > For some strange reason X thinks that you have 24MB of memory on the G450. > > You can either create 32MB write-combining region at 0xd400, or > > teach X that your device occupies 32MB and not 24 (you should do it anyway, > > region size can be only power of two)... > > Petr, the Matrox card splits the memory between the two video screens > when running in a multi-head configuration and "pretends" that it is two > distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and > for 8mb seperately when in this mode. That's wrong. They must first register MTRR and then split it to 24+8, as they cannot register 24MB range. They can split it 16+16, or (16+8)+8, but at cost of 1 (or 2) additional MTRR entries - and there is very limited number of possible MTRRs. Matroxfb also splits Matrox memory in 24:8, but it registers only one region in mtrr. Of course, in X, as mtrr registration is done by map videomemory, you must tell this function to not register mtrr... Best regards, Petr Vandrovec [EMAIL PROTECTED] - 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/
Re: 2.2.16 SMP: mtrr errors
Petr Vandrovec wrote: > > kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary > > last message repeated 2 times > > For some strange reason X thinks that you have 24MB of memory on the G450. > You can either create 32MB write-combining region at 0xd400, or > teach X that your device occupies 32MB and not 24 (you should do it anyway, > region size can be only power of two)... Petr, the Matrox card splits the memory between the two video screens when running in a multi-head configuration and "pretends" that it is two distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and for 8mb seperately when in this mode. At line 1190 in arch/i386/kernel/mtrr.c the switch on Intel falls through hitting the error message for Centaur. I know the comment says to fall through, but is this correct? I've inserted a break at the end of the Intel switch before and have not had problems, but I left it out in the latest couple of kernels because of all the mtrr work being done, waiting to see if there was resolution. John - 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/
Re: 2.2.16 SMP: mtrr errors
On 11 Dec 00 at 14:00, Paul C. Nendick wrote: > -Matrox g450 32MB RAM dual-heal AGP video card w/ hand compiled X driver > from matrox Make sure you do not use either matroxfb or XFree's driver... Same chip ID, but different ramdac :-( > and immediately after starting X: > > kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary > last message repeated 2 times For some strange reason X thinks that you have 24MB of memory on the G450. You can either create 32MB write-combining region at 0xd400, or teach X that your device occupies 32MB and not 24 (you should do it anyway, region size can be only power of two)... > and finally: > > %cat /proc/mtrr > reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 > reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 > reg02: base=0xd580 (3416MB), size= 8MB: write-combining, count=1 + reg03: base=0xd400 (MB), size= 32MB: write-combining, count=1 Petr Vandrovec [EMAIL PROTECTED] - 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/
Re: 2.2.16 SMP: mtrr errors
See my answers inline below. /paul Mark Hahn ([EMAIL PROTECTED]) said: > > kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary > > X is trying to set an mtrr for the framebuffer. the odd thing > is that its trying to set a 24M mtrr, which is pretty strange. > what does /proc/pci look like for the G450? > % cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies Unknown device (rev 196). Vendor id=1106. Device id=691. Medium devsel. Master Capable. No bursts. Prefetchable 32 bit memory at 0xd000 [0xd008]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies VT 82C598 Apollo MVP3 AGP (rev 0). Medium devsel. Master Capable. No bursts. Min Gnt=12. Bus 0, device 7, function 0: ISA bridge: VIA Technologies VT 82C596 Apollo Pro (rev 35). Medium devsel. Master Capable. No bursts. Bus 0, device 7, function 1: IDE interface: VIA Technologies VT 82C586 Apollo IDE (rev 16). Medium devsel. Fast back-to-back capable. Master Capable. Latency=32. I/O at 0xe000 [0xe001]. Bus 0, device 7, function 2: USB Controller: VIA Technologies VT 82C586 Apollo USB (rev 17). Medium devsel. IRQ 9. Master Capable. Latency=32. I/O at 0xe400 [0xe401]. Bus 0, device 7, function 3: Host bridge: VIA Technologies Unknown device (rev 48). Vendor id=1106. Device id=3050. Medium devsel. Fast back-to-back capable. Bus 0, device 17, function 0: Multimedia audio controller: Ensoniq AudioPCI (rev 0). Slow devsel. IRQ 9. Master Capable. Latency=32. Min Gnt=12.Max Lat=128. I/O at 0xe800 [0xe801]. Bus 0, device 18, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xda10 [0xda10]. I/O at 0xec00 [0xec01]. Non-prefetchable 32 bit memory at 0xda00 [0xda00]. Bus 1, device 0, function 0: VGA compatible controller: Matrox Unknown device (rev 130). Vendor id=102b. Device id=525. Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Min Gnt=16.Max Lat=32. Prefetchable 32 bit memory at 0xd400 [0xd408]. Non-prefetchable 32 bit memory at 0xd600 [0xd600]. Non-prefetchable 32 bit memory at 0xd700 [0xd700]. > also, how do you like the G450? My first impressions of the g450 are spectacular. I know it's not supposed to be as fast as the dual Nvidia offerings, but I don't play games and Matrox has always been tops when it comes to text appearance. It's fast as can be driving two monitors at 1600x1200 and not too expensive to boot. I like it. > > I would like to know what, if anything, is wrong and what I can do about it. > > worst case is that X doesn't get to set the mtrr it wants. > this may have some performance effect, but no functionality effect. That's good enough for me! > regards, mark hahn. > - 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/
Re: 2.2.16 SMP: mtrr errors
> kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary > last message repeated 2 times > > and finally: > > %cat /proc/mtrr > reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 > reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 > reg02: base=0xd580 (3416MB), size= 8MB: write-combining, count=1 I'm seeing the same thing with the Matrox G400. John - 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/
2.2.16 SMP: mtrr errors
Please cc: any responses to my email address <[EMAIL PROTECTED]> My setup -A standard install of RedHat 7.0 with the 2.2.16smp w/ hand compiled X 4.0.1 to support xinerama -Tyan tiger 133 s1834 motherboard (VIA Apollo Pro133A Chipset) -256mb PC133 RAM -Two 800 Mhz PIII eb Slot-1 CPU's -Matrox g450 32MB RAM dual-heal AGP video card w/ hand compiled X driver from matrox My problem from /var/log/message at startup: mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) CPU0: Intel Pentium III (Coppermine) stepping 03 CPU1: Intel Pentium III (Coppermine) stepping 03 Total of 2 processors activated (3194.88 BogoMIPS). checking TSC synchronization across CPUs: passed. mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs and immediately after starting X: kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary last message repeated 2 times and finally: %cat /proc/mtrr reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 reg02: base=0xd580 (3416MB), size= 8MB: write-combining, count=1 I would like to know what, if anything, is wrong and what I can do about it. Cheers! /paul - 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/
2.2.16 SMP: mtrr errors
Please cc: any responses to my email address [EMAIL PROTECTED] My setup -A standard install of RedHat 7.0 with the 2.2.16smp w/ hand compiled X 4.0.1 to support xinerama -Tyan tiger 133 s1834 motherboard (VIA Apollo Pro133A Chipset) -256mb PC133 RAM -Two 800 Mhz PIII eb Slot-1 CPU's -Matrox g450 32MB RAM dual-heal AGP video card w/ hand compiled X driver from matrox My problem from /var/log/message at startup: mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) snip CPU0: Intel Pentium III (Coppermine) stepping 03 snip CPU1: Intel Pentium III (Coppermine) stepping 03 Total of 2 processors activated (3194.88 BogoMIPS). snip checking TSC synchronization across CPUs: passed. mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs and immediately after starting X: kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary last message repeated 2 times and finally: %cat /proc/mtrr reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 reg02: base=0xd580 (3416MB), size= 8MB: write-combining, count=1 I would like to know what, if anything, is wrong and what I can do about it. Cheers! /paul - 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/
Re: 2.2.16 SMP: mtrr errors
kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary last message repeated 2 times and finally: %cat /proc/mtrr reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 reg02: base=0xd580 (3416MB), size= 8MB: write-combining, count=1 I'm seeing the same thing with the Matrox G400. John - 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/
Re: 2.2.16 SMP: mtrr errors
See my answers inline below. /paul Mark Hahn ([EMAIL PROTECTED]) said: kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary X is trying to set an mtrr for the framebuffer. the odd thing is that its trying to set a 24M mtrr, which is pretty strange. what does /proc/pci look like for the G450? % cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies Unknown device (rev 196). Vendor id=1106. Device id=691. Medium devsel. Master Capable. No bursts. Prefetchable 32 bit memory at 0xd000 [0xd008]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies VT 82C598 Apollo MVP3 AGP (rev 0). Medium devsel. Master Capable. No bursts. Min Gnt=12. Bus 0, device 7, function 0: ISA bridge: VIA Technologies VT 82C596 Apollo Pro (rev 35). Medium devsel. Master Capable. No bursts. Bus 0, device 7, function 1: IDE interface: VIA Technologies VT 82C586 Apollo IDE (rev 16). Medium devsel. Fast back-to-back capable. Master Capable. Latency=32. I/O at 0xe000 [0xe001]. Bus 0, device 7, function 2: USB Controller: VIA Technologies VT 82C586 Apollo USB (rev 17). Medium devsel. IRQ 9. Master Capable. Latency=32. I/O at 0xe400 [0xe401]. Bus 0, device 7, function 3: Host bridge: VIA Technologies Unknown device (rev 48). Vendor id=1106. Device id=3050. Medium devsel. Fast back-to-back capable. Bus 0, device 17, function 0: Multimedia audio controller: Ensoniq AudioPCI (rev 0). Slow devsel. IRQ 9. Master Capable. Latency=32. Min Gnt=12.Max Lat=128. I/O at 0xe800 [0xe801]. Bus 0, device 18, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xda10 [0xda10]. I/O at 0xec00 [0xec01]. Non-prefetchable 32 bit memory at 0xda00 [0xda00]. Bus 1, device 0, function 0: VGA compatible controller: Matrox Unknown device (rev 130). Vendor id=102b. Device id=525. Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Min Gnt=16.Max Lat=32. Prefetchable 32 bit memory at 0xd400 [0xd408]. Non-prefetchable 32 bit memory at 0xd600 [0xd600]. Non-prefetchable 32 bit memory at 0xd700 [0xd700]. also, how do you like the G450? My first impressions of the g450 are spectacular. I know it's not supposed to be as fast as the dual Nvidia offerings, but I don't play games and Matrox has always been tops when it comes to text appearance. It's fast as can be driving two monitors at 1600x1200 and not too expensive to boot. I like it. I would like to know what, if anything, is wrong and what I can do about it. worst case is that X doesn't get to set the mtrr it wants. this may have some performance effect, but no functionality effect. That's good enough for me! regards, mark hahn. - 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/
Re: 2.2.16 SMP: mtrr errors
On 11 Dec 00 at 14:00, Paul C. Nendick wrote: -Matrox g450 32MB RAM dual-heal AGP video card w/ hand compiled X driver from matrox Make sure you do not use either matroxfb or XFree's driver... Same chip ID, but different ramdac :-( and immediately after starting X: kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary last message repeated 2 times For some strange reason X thinks that you have 24MB of memory on the G450. You can either create 32MB write-combining region at 0xd400, or teach X that your device occupies 32MB and not 24 (you should do it anyway, region size can be only power of two)... and finally: %cat /proc/mtrr reg00: base=0x ( 0MB), size= 256MB: write-back, count=1 reg01: base=0xd000 (3328MB), size= 64MB: write-combining, count=1 reg02: base=0xd580 (3416MB), size= 8MB: write-combining, count=1 + reg03: base=0xd400 (MB), size= 32MB: write-combining, count=1 Petr Vandrovec [EMAIL PROTECTED] - 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/
Re: 2.2.16 SMP: mtrr errors
Petr Vandrovec wrote: kernel: mtrr: base(0xd400) is not aligned on a size(0x180) boundary last message repeated 2 times For some strange reason X thinks that you have 24MB of memory on the G450. You can either create 32MB write-combining region at 0xd400, or teach X that your device occupies 32MB and not 24 (you should do it anyway, region size can be only power of two)... Petr, the Matrox card splits the memory between the two video screens when running in a multi-head configuration and "pretends" that it is two distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and for 8mb seperately when in this mode. At line 1190 in arch/i386/kernel/mtrr.c the switch on Intel falls through hitting the error message for Centaur. I know the comment says to fall through, but is this correct? I've inserted a break at the end of the Intel switch before and have not had problems, but I left it out in the latest couple of kernels because of all the mtrr work being done, waiting to see if there was resolution. John - 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/
Re: 2.2.16 SMP: mtrr errors
Petr, the Matrox card splits the memory between the two video screens when running in a multi-head configuration and "pretends" that it is two distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and for 8mb seperately when in this mode. That is a driver bug. The intel processors only support MTRR's on certain power boundaries/sizes. The fall through is intended. to fall through, but is this correct? I've inserted a break at the end of the Intel switch before and have not had problems, but I left it out Lucky in the latest couple of kernels because of all the mtrr work being done, waiting to see if there was resolution. The Matrox driver needs to register a single 32Mb MTRR - 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/
Re: 2.2.16 SMP: mtrr errors
Shall I submit this to Matrox as a bug then? /paul Alan Cox ([EMAIL PROTECTED]) said: Petr, the Matrox card splits the memory between the two video screens when running in a multi-head configuration and "pretends" that it is two distinct cards. Thus, a 32 mb card will register an mtrr for 24mb and for 8mb seperately when in this mode. That is a driver bug. The intel processors only support MTRR's on certain power boundaries/sizes. The fall through is intended. to fall through, but is this correct? I've inserted a break at the end of the Intel switch before and have not had problems, but I left it out Lucky in the latest couple of kernels because of all the mtrr work being done, waiting to see if there was resolution. The Matrox driver needs to register a single 32Mb MTRR -- Paul C. Nendick - 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/
Re: 2.2.16 SMP: mtrr errors
" Paul C. Nendick " [EMAIL PROTECTED] writes: Shall I submit this to Matrox as a bug then? The "bug" is in the XFree86 core, so telling Matrox might not do a lot of good. The driver code just says "I want to map a framebuffer of this size at this physical address" (or actually "with these PCI details"), and the core code arranges the mapping, doing the MTRR stuff while it's at it. 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/
Re: 2.2.16 SMP: mtrr errors
On Tue, 12 Dec 2000, Petr Vandrovec wrote: That's wrong. They must first register MTRR and then split it to 24+8, as they cannot register 24MB range. They can split it 16+16, or (16+8)+8, but at cost of 1 (or 2) additional MTRR entries - and there is very limited number of possible MTRRs. Matroxfb also splits Matrox memory in 24:8, but it registers only one region in mtrr. Of course, in X, as mtrr registration is done by map videomemory, you must tell this function to not register mtrr... Best regards, Petr Vandrovec [EMAIL PROTECTED] NOW, I am really convinced that we need PAT support on top of the crappy MTRR driver. :-) I already started working on it... Regards, Zoltan Boszormenyi - 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/
