vesafb problem

DISCUSSION Walt H 4 participants 13 messages Mar 27, 2003 – Mar 30, 2003

Subsystems (2)

Documentation Framebuffer layer

lore

Share & tools

lore

Walt H

author

2003-03-27 16:30 UTC #0 lore raw

Hello all,

I've got a strange problem with my 760MPX system dual proc system. If I try to use vesafb to setup the video on boot, the system will boot fine, but will be unable to display anything on the console. The system appears to be largely unaffacted by any underlying problem, as it is stable after boot and seems to run fine. In looking through logs afterward, I find these suspect messages:

mtrr: your CPUs had inconsistent fixed MTRR settings
vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xe8000000

I've tried using the rivafb frame buffer, which also does not work. From what I could see in scanning the archives, this appears to possibly be a BIOS issue, however, I'm game to throw nearly anything at it to try and resolve it. Hardware is as follows:

Chaintech 7KDD 760MPX chipset motherboard
2 x AMD 2400MP
1 GB Ram
Nvidia GeForce 4600

I've tried a vanilla 2.4.20 linux kernel as well as my current 2.4.20-ck patched kernel, both with same result. I've also tried compiling as UP, which has no effect. I'm currently using acpi and apic, however, I've tried disabling both, to no avail. Any other ideas? Please CC me, as I'm not susbscribed. Thanks,

-Walt

PS. Maybe unrelated, but... I have to pass mem=nopentium as boot param, otherwise I system appears to get corrupted memory issues within short period of time after boot. ie: unable to launch apps, segfaults etc...

Jurriaan

2003-03-27 18:51 UTC #1 lore raw

From: Walt H <[email protected]>
Date: Thu, Mar 27, 2003 at 08:41:54AM -0800

Quoted 17 lines

Hello all,
I've got a strange problem with my 760MPX system dual proc system. If I try to use vesafb to setup the video on boot, the system will boot fine, but will be unable to display anything on the console. The system appears to be largely unaffacted by any underlying problem, as it is stable after boot and seems to run fine. In looking through logs afterward, I find these suspect messages:
mtrr: your CPUs had inconsistent fixed MTRR settings
vesafb: abort, cannot ioremap video memory 0x8000000 @ 0xe8000000
I've tried using the rivafb frame buffer, which also does not work. From what I could see in scanning the archives, this appears to possibly be a BIOS issue, however, I'm game to throw nearly anything at it to try and resolve it. Hardware is as follows:

Quoted 5 lines

Chaintech 7KDD 760MPX chipset motherboard
2 x AMD 2400MP
1 GB Ram
Nvidia GeForce 4600

I had a similar problem with 1 Gb Ram, and received this answer on the linux-kernel mailinglist:

======================================================
To: [email protected]
Cc: [email protected]
Subject: Re: 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb?
From: Roland Dreier <[email protected]>
Date: 14 Mar 2003 00:15:26 -0800

thunder7> Now I added some information to the printk, and I now thunder7> know:

thunder7> fb: Can't remap 3Dfx Voodoo5 register area. (start d0000000 length 8000000)

Length 0x8000000 means the driver is trying to ioremap a 128MB.

thunder7> If I boot my kernel with 'mem=512M' I can use the thunder7> framebuffer just fine (well, it doesn't work and writes thunder7> funky patters to the screen, but at least thunder7> ioremap_nocache() works fine).

thunder7> What is the reason ioremap_nocache() fails? Is this thunder7> something that can be prevented? I am not entirely clear thunder7> on what is happening anyway (real memory, virtual thunder7> memory, nocache-memory, io-memory - a little bit above thunder7> my head :-) ).

ioremap_nocache() uses "vmalloc space". The kernel has some address space it uses for kernel virtual memory mappings -- that is, for mapping vmalloc()'ed memory and ioremap()'ed memory.

On i386, the kernel uses whatever part of the top 1 GB of address space is not used for directly mapped RAM (aka lowmem). (There are a few other things that take some address space but that is approximately true).

This means with "mem=512M", you will probably have about 500M of vmalloc space, which is more than enough to ioremap the framebuffer.

With the full 1 GB of memory, you might think that there would be no vmalloc space available at all. However, <asm/page.h> defines a constant VMALLOC_RESERVE (which by default is 128 MB), and the kernel makes sure that there is at least this much vmalloc space available. However, by the time you load the module, at least some of this space has been consumed, so the ioremap fails. (If nothing else uses vmalloc space, just loading a module will call vmalloc() to get space for the module to be loaded into!)

One not very good way for you to proceed would be to change the definition of VMALLOC_RESERVE from (128 << 20) to something like (256 << 20), which should leave the driver room to ioremap the framebuffer. This is a little ugly. However, I don't see why a framebuffer driver would need to ioremap _all_ of a video card's memory -- so a better solution would be to fix the driver to only ioremap what it needs to.

Best,
Roland
======================================================

To see if this is it, booting with mem=512M would be a good test.

Kind regards,
Jurriaan

Signature · 3 lines

War does not determine who is right -- only who is left.
	Bertrand Russell
Debian (Unstable) GNU/Linux 2.5.65-mm3 4276 bogomips load av: 0.90 0.80 0.61

Walt H

author

2003-03-27 19:24 UTC #2 lore raw

Quoted 57 lines · Jurriaan

I had a similar problem with 1 Gb Ram, and received this answer on the linux-kernel mailinglist:
======================================================
To: [email protected]
Cc: [email protected]
Subject: Re: 2.5.64: ioremap_nocache() failes with 1 gigabyte memory, works with 512 Mb?
From: Roland Dreier <[email protected]>
Date: 14 Mar 2003 00:15:26 -0800
thunder7> Now I added some information to the printk, and I now thunder7> know:
thunder7> fb: Can't remap 3Dfx Voodoo5 register area. (start d0000000 length 8000000)
Length 0x8000000 means the driver is trying to ioremap a 128MB.
thunder7> If I boot my kernel with 'mem=512M' I can use the thunder7> framebuffer just fine (well, it doesn't work and writes thunder7> funky patters to the screen, but at least thunder7> ioremap_nocache() works fine).
thunder7> What is the reason ioremap_nocache() fails? Is this thunder7> something that can be prevented? I am not entirely clear thunder7> on what is happening anyway (real memory, virtual thunder7> memory, nocache-memory, io-memory - a little bit above thunder7> my head :-) ).
ioremap_nocache() uses "vmalloc space". The kernel has some address space it uses for kernel virtual memory mappings -- that is, for mapping vmalloc()'ed memory and ioremap()'ed memory.
On i386, the kernel uses whatever part of the top 1 GB of address space is not used for directly mapped RAM (aka lowmem). (There are a few other things that take some address space but that is approximately true).
This means with "mem=512M", you will probably have about 500M of vmalloc space, which is more than enough to ioremap the framebuffer.
With the full 1 GB of memory, you might think that there would be no vmalloc space available at all. However, <asm/page.h> defines a constant VMALLOC_RESERVE (which by default is 128 MB), and the kernel makes sure that there is at least this much vmalloc space available. However, by the time you load the module, at least some of this space has been consumed, so the ioremap fails. (If nothing else uses vmalloc space, just loading a module will call vmalloc() to get space for the module to be loaded into!)
One not very good way for you to proceed would be to change the definition of VMALLOC_RESERVE from (128 << 20) to something like (256 << 20), which should leave the driver room to ioremap the framebuffer. This is a little ugly. However, I don't see why a framebuffer driver would need to ioremap _all_ of a video card's memory -- so a better solution would be to fix the driver to only ioremap what it needs to.

Quoted 8 lines

Best,
Roland
======================================================
To see if this is it, booting with mem=512M would be a good test.
Kind regards,
Jurriaan

Thanks for the reply. That is indeed what is doing it. When I added mem=512M, I had two smiling penguins on boot :) My vid card does have 128MB Ram, but I also tend to agree that I'm not sure that the framebuffer needs to remap *all* of its memory. But, for now, I think I'll add the hack (256 << 20) to make it work. Any ideas if this might have unforseen bad effects? Might it screw up highmem I/O? Thanks again,

-Walt

Bongani Hlope

2003-03-27 21:28 UTC #3 lore raw

Quoted 5 lines · On Thu, 27 Mar 2003 11:34:25 -0800 Walt H <[email protected]> wrote:

Quoted 3 lines · Jurriaan
I had a similar problem with 1 Gb Ram, and received this answer on the linux-kernel mailinglist:

<sip>

Quoted 8 lines

Quoted 8 lines
thunder7> framebuffer just fine (well, it doesn't work and writes thunder7> funky patters to the screen, but at least thunder7> ioremap_nocache() works fine).
thunder7> What is the reason ioremap_nocache() fails? Is this thunder7> something that can be prevented? I am not entirely clear thunder7> on what is happening anyway (real memory, virtual thunder7> memory, nocache-memory, io-memory - a little bit above

<snip>

Quoted 3 lines

Quoted 3 lines
This means with "mem=512M", you will probably have about 500M of vmalloc space, which is more than enough to ioremap the framebuffer.

<snip>

Quoted 5 lines

Quoted 4 lines
To see if this is it, booting with mem=512M would be a good test.
Kind regards,
Jurriaan

Quoted 8 lines

Thanks for the reply. That is indeed what is doing it. When I added mem=512M, I had two smiling penguins on boot :) My vid card does have 128MB Ram, but I also tend to agree that I'm not sure that the framebuffer needs to remap *all* of its memory. But, for now, I think I'll add the hack (256 << 20) to make it work. Any ideas if this might have unforseen bad effects? Might it screw up highmem I/O? Thanks again,
-Walt

Strange I'm having the same problem, but I only have 256MB of memory and my GeForce 2 only has 32MB. This is what's on my messages file:

vesafb: framebuffer at 0xe0000000, mapped to 0xd0807000, size 32768k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: protected mode interface info at c000:c060
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Looking for splash picture.... found (800x600, 13683 bytes).
Console: switching to colour frame buffer device 82x30
fb0: VESA VGA frame buffer device

Walt H

author

2003-03-27 22:19 UTC #4 lore raw

Quoted 12 lines · Bongani Hlope

Strange I'm having the same problem, but I only have 256MB of memory and my GeForce 2 only has 32MB. This is what's on my messages file:
vesafb: framebuffer at 0xe0000000, mapped to 0xd0807000, size 32768k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: protected mode interface info at c000:c060
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Looking for splash picture.... found (800x600, 13683 bytes).
Console: switching to colour frame buffer device 82x30
fb0: VESA VGA frame buffer device

Hmmm. That's a different problem than I'm experiencing. Your system appears to be correctly remapping the framebuffer and switching to it. You don't get a graphical boot? Seems as if you should from the log snippet you posted.

-Walt

Bongani Hlope

2003-03-28 03:44 UTC #5 lore raw

Quoted 15 lines · On Thu, 27 Mar 2003 14:30:21 -0800 Walt H <[email protected]> wrote:

Quoted 12 lines · Bongani Hlope
Strange I'm having the same problem, but I only have 256MB of memory and my GeForce 2 only has 32MB. This is what's on my messages file:
vesafb: framebuffer at 0xe0000000, mapped to 0xd0807000, size 32768k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: protected mode interface info at c000:c060
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Looking for splash picture.... found (800x600, 13683 bytes).
Console: switching to colour frame buffer device 82x30
fb0: VESA VGA frame buffer device

Quoted 4 lines

Hmmm. That's a different problem than I'm experiencing. Your system appears to be correctly remapping the framebuffer and switching to it. You don't get a graphical boot? Seems as if you should from the log snippet you posted.

It is just black until X starts up, and if I try to switch to a virtual terminal I get a corrupt screen

Walt H

author

2003-03-27 22:16 UTC #6 lore raw

In reply to Jurriaan

Quoted 7 lines

One not very good way for you to proceed would be to change the definition of VMALLOC_RESERVE from (128 << 20) to something like (256 << 20), which should leave the driver room to ioremap the framebuffer. This is a little ugly. However, I don't see why a framebuffer driver would need to ioremap _all_ of a video card's memory -- so a better solution would be to fix the driver to only ioremap what it needs to.

Quoted 8 lines

Best,
Roland
======================================================
To see if this is it, booting with mem=512M would be a good test.
Kind regards,
Jurriaan

Well, I've answered my own question regarding highmem. Reserving 256MB ram causes high-mem mapped IO to fail. I can have penguins, but no filesystems or no penguins and a useable system. I'm guessing that I could probably turn off HIGHMEM and HIGHMEM-IO and might be able to get penguins back, but at the cost of reduced system performance. I'm not a kernel hacker, but I might just see how bad I can break vesafb to remap only the necessary memory for the requested video mode. Perhaps that would fix the whole thing?

-Walt

Walt H

author

2003-03-27 23:00 UTC #7 lore raw

Quoted 4 lines · Walt H

Well, I've answered my own question regarding highmem. Reserving 256MB ram causes high-mem mapped IO to fail. I can have penguins, but no filesystems or no penguins and a useable system. I'm guessing that I could probably turn off HIGHMEM and HIGHMEM-IO and might be able to get penguins back, but at the cost of reduced system performance. I'm not a kernel hacker, but I might just see how bad I can break vesafb to remap only the necessary memory for the requested video mode. Perhaps that would fix the whole thing?
-Walt

Well, here's what I've done. I've made a change in video/vesafb.c to change __init vesafb_init to only allocate the amount of memory required
for the requested framebuffer (I think). So far, it appears to work
fine. I haven't tried many modes yet, but it's worked with what I've thrown at it. Thanks again,

The trivial change I made was changing this:

video_size = screen_info.lfb_size * 65536;

to this:

video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp;

-Walt

Walt H

author

2003-03-28 21:00 UTC #8 lore raw

vesafb problem with 1GB Ram and possible fix

In reply to Walt H

I've got a Chaintech 7KDD dual processor 760MPX MB with 1 GB RAM. I had
problem getting vesafb or rivafb to work. I got ioremap errors during
nitialization, which appear to be because vesafb tries to ioremap the entire 128MB framebuffer of my video card. It's a GeForce 4 Ti4600 with 128MB Ram. Through correspondence on the general linux-kernel mailing list, I learned about changing the vmalloc reserved space from 128 to 256MB, but that didn't work for me as it evidently blows away high-mem IO.

Well, here's what I've done. I've made a change in video/vesafb.c to
change __init vesafb_init to only allocate the amount of memory required
for the requested video mode of the framebuffer (I think). So far, it
appears to work fine. I haven't tried many modes yet, but it's worked with what I've thrown at it. Thanks again,

The trivial change I made was changing this:

video_size = screen_info.lfb_size * 65536;

to this:

video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp;

I'm not a kernel hacker, so if I'm overlooking something please let me know. I've tested this a fair amount and it appears to be working on my end. Please CC me on any replies. Thanks,

-Walt

Antonino Daplas

2003-03-29 11:02 UTC #9 lore raw

Re: vesafb problem with 1GB Ram and possible fix

Quoted 20 lines · Walt H

I've got a Chaintech 7KDD dual processor 760MPX MB with 1 GB RAM. I had
problem getting vesafb or rivafb to work. I got ioremap errors during
nitialization, which appear to be because vesafb tries to ioremap the entire 128MB framebuffer of my video card. It's a GeForce 4 Ti4600 with 128MB Ram. Through correspondence on the general linux-kernel mailing list, I learned about changing the vmalloc reserved space from 128 to 256MB, but that didn't work for me as it evidently blows away high-mem IO.
Well, here's what I've done. I've made a change in video/vesafb.c to change __init vesafb_init to only allocate the amount of memory required
for the requested video mode of the framebuffer (I think). So far, it
appears to work fine. I haven't tried many modes yet, but it's worked with what I've thrown at it. Thanks again,
The trivial change I made was changing this:
video_size = screen_info.lfb_size * 65536;
to this:

Quoted 8 lines

video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp;
I'm not a kernel hacker, so if I'm overlooking something please let me know. I've tested this a fair amount and it appears to be working on my end. Please CC me on any replies. Thanks,
-Walt

I've submitted a similar patch to address problems such as the one you're encountering. It just adds an extra boot option to specify amount of memory to remap. Some applications will need more graphics memory than the minimum required to display a particular mode (such as for buffer flipping, offscreen caching, etc). Attached is the message I sent to the list a few days ago.

Tony

From [email protected] Thu Mar 27 15:41:09 2003
Return-Path: <[email protected]>
X-Sieve: cmu-sieve 2.0
Received: from sc8-sf-list2.sourceforge.net (lists.sourceforge.net

	[66.35.250.206]) by tom.po.com (8.12.8/8.12.2) with ESMTP id h2RKf9fP027806
	for <[email protected]>; Thu, 27 Mar 2003 15:41:09 -0500 (EST)
Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13]
	helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with
	esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 18yeA1-0003Q5-00; Thu, 27 Mar 2003
	12:39:41 -0800
Received: from pine.compass.com.ph ([202.70.96.37]) by
	sc8-sf-list1.sourceforge.net with smtp (Exim 3.31-VA-mm2 #1 (Debian)) id
	18ye9G-0003zY-00 for <[email protected]>; Thu, 27 Mar
	2003 12:38:54 -0800
Received: (qmail 78519 invoked from network); 27 Mar 2003 20:38:50 -0000
Received: from ap-202-70-105-57.compass.com.ph (202.70.105.57) by
	pine.compass.com.ph with SMTP; 27 Mar 2003 20:38:50 -0000

From: Antonino Daplas <[email protected]>
To: Linux Fbdev development list <[email protected]>
Content-Type: text/plain
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Subject: [Linux-fbdev-devel] [PATCH]: vesafb - vram option
Sender: [email protected]
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
List-Help:
<mailto:[email protected]?subject=help>
List-Post: <mailto:[email protected]> List-Subscribe:
<https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel>,
<mailto:[email protected]?subject=subscribe>
List-Id: <linux-fbdev-devel.lists.sourceforge.net>
List-Unsubscribe:
<https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel>,
<mailto:[email protected]?subject=unsubscribe>
List-Archive:
<http://sourceforge.net/mailarchive/forum.php?forum=linux-fbdev-devel>
X-Original-Date: 28 Mar 2003 04:20:12 +0800
Date: 28 Mar 2003 04:20:12 +0800
X-Evolution-Source: pop://[email protected]/inbox
Content-Transfer-Encoding: 8bit

Attached is a diff against linux-2.5.66.

- Added vesafb option to specify amount of video RAM to remap. This is perhaps useful for people with machines with large amounts of system and graphics RAM and vesafb fails to load due to failure to ioremap.

To use: to remap only 1MiB of ram, add the ff. in your boot option:

video=vesafb:vram:1,<your other options>

Tony

Documentation/fb/vesafb.txt +3 -1

diff -Naur linux-2.5.66-orig/Documentation/fb/vesafb.txt linux-2.5.66/Documentation/fb/vesafb.txt
@@ -146,7 +146,9 @@
 
 mtrr	setup memory type range registers for the vesafb framebuffer.
 
-
+vram:n  remap 'n' MiB of video RAM. If 0 or not specified, remap all
+	available video RAM. 
+  
 Have fun!
 
   Gerd

drivers/video/vesafb.c +5 -1

diff -Naur linux-2.5.66-orig/drivers/video/vesafb.c linux-2.5.66/drivers/video/vesafb.c
@@ -50,7 +50,7 @@
 
 static int             inverse   = 0;
 static int             mtrr      = 0;
-
+static int        vram __initdata = 0;
 static int             pmi_setpal = 0;	/* pmi for palette changes ??? */
 static int             ypan       = 0;  /* 0..nothing, 1..ypan, 2..ywrap */
 static unsigned short  *pmi_base  = 0;

@@ -206,6 +206,8 @@
 			pmi_setpal=1;
 		else if (! strcmp(this_opt, "mtrr"))
 			mtrr=1;
+		else if (! strncmp(this_opt, "vram:", 5))
+			vram = simple_strtoul(this_opt+5, NULL, 0);
 	}
 	return 0;
 }

@@ -226,6 +228,8 @@
 	vesafb_defined.yres = screen_info.lfb_height;
 	vesafb_fix.line_length = screen_info.lfb_linelength;
 	vesafb_fix.smem_len = screen_info.lfb_size * 65536;
+	if (vram && vram * 1024 * 1024 < vesafb_fix.smem_len)
+		vesafb_fix.smem_len = vram * 1024 * 1024;
 	vesafb_fix.visual   = (vesafb_defined.bits_per_pixel == 8) ?
 		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR;

-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Linux-fbdev-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Walt H

author

2003-03-29 20:24 UTC #10 lore raw

Re: vesafb problem with 1GB Ram and possible fix

Quoted 9 lines · Antonino Daplas

I've submitted a similar patch to address problems such as the one you're encountering. It just adds an extra boot option to specify amount of memory to remap. Some applications will need more graphics memory than the minimum required to display a particular mode (such as for buffer flipping, offscreen caching, etc). Attached is the message I sent to the list a few days ago.
Tony

One question I've been wondering about with either one of these approaches has to do with mode changes. I might be mistaken, but if I remember correctly, video mode changes aren't supported for vesa framebuffers. Would you ever need to allocate additional memory other than that allocated at startup? I'm thinking that in the small tweak that I did, you can perhaps not allocate enough memory for some unforseen future event, although I can't think of any off hand. Then again, I'm not a kernel programmer, I could be way off base here.

-Walt

Antonino Daplas

2003-03-29 21:40 UTC #11 lore raw

Re: vesafb problem with 1GB Ram and possible fix

Quoted 12 lines · Walt H

Quoted 1 line
<Patch snipped>
One question I've been wondering about with either one of these approaches has to do with mode changes. I might be mistaken, but if I remember correctly, video mode changes aren't supported for vesa framebuffers. Would you ever need to allocate additional memory other than that allocated at startup? I'm thinking that in the small tweak that I did, you can perhaps not allocate enough memory for some unforseen future event, although I can't think of any off hand. Then again, I'm not a kernel programmer, I could be way off base here.

True, vesafb does not support mode changes. However, the extra graphics memory is useful for some framebuffer-based applications that implement multi-buffering. DirectFB, for instance, takes advantage of this since it uses a frontbuffer and a backbuffer (display the frontbuffer, render to the backbuffer, swap the front and backbuffer pointers, then display the new frontbuffer). Xine and mplayer using the framebuffer backend are probably using similar setups.

Tony

Walt H

author

2003-03-30 23:16 UTC #12 lore raw

Re: vesafb problem with 1GB Ram and possible fix

Quoted 11 lines · Antonino Daplas

True, vesafb does not support mode changes. However, the extra graphics memory is useful for some framebuffer-based applications that implement multi-buffering. DirectFB, for instance, takes advantage of this since it uses a frontbuffer and a backbuffer (display the frontbuffer, render to the backbuffer, swap the front and backbuffer pointers, then display the new frontbuffer). Xine and mplayer using the framebuffer backend are probably using similar setups.
Tony

Thanks for the info Tony. Sounds like my setup wouldn't be ideal for mass consumption. I don't use vesafb for anything other than the graphical console with large number of columns and rows, so it shouldn't affect me. I just needed a quick hack for a fix since I got a new MP system with lots 'o ram and no penguins :( It's all good now though..

-Walt