4M? That seems kind of high, but... hmm...

While that may be true for some things, there are settings that may matter when it comes to system stability. In particular, a Nokia tech noted that upping the buffer may reduce the occurrences of a kernel bug (9150), but was less helpful about where to find said documentation.

I understand it may not be wise to tweek some values, but please do share a link to documentation if you know of some. Just because most people don't have a reason to play with it doesn't mean nobody should know about it.

According to the texas instruments support the library list in the OMAP35xx are: (With Window system)
or maybe OMAP34xx too.
/usr/lib/libpvrPVR2D_BLITWSEGL.so /usr/lib/libpvrPVR2D_FLIPWSEGL.so /usr/lib/libpvrPVR2D_FRONTWSEGL.so /usr/lib/libpvrPVR2D_LINUXFBWSEGL.so
and for: (Originally from OMAP3xxx known issues(aka ARM Cortex A8 FAQ))
Vertical Tearing: Ensure that FLIP mode of operation is selected in powervr.ini in WindowSystem

To switch flip mode for the whole system:
Modify the powervr.ini file under the <your_target_file_system>/etc/init.d to select between the FrontEGL or FlipEGL mode.
To switch flip mode for a specific app:
instead of powervr.ini use <APPEXECNAME>.ini
You can also use fbset to configure ARGB mode for framebuffer memory
example using 8888:
target $fbset -rgba 8/16,8/8,8/0,8/24
These are also a list of driver bugs that are mentioned in texas instruments:
Artifacts/ Clipping issues/ Missing objects :This could potentially be due to an incorrect usage in the OpenGL application, or point to an issue in the driver. Note that the deferred rendering mode of the SGX HW, will cause different behaviour compared to the immediate renderers found on desktops.

Possible checks include increasing the "ParamBufferSize" in powervr.ini.

If this does not help, please contact TI through the Linux E2E forums (http://e2e.ti.com/)

Integration of xyz framework with PowerVR drivers do not work :Please ensure that the powervr.ini is configured to use the right plug-in. For example, Qt's powervr binary via the WindowSystem option "libpvrQWSWSEGL.so".

Because of the way software frameworks use the OpenGL ES backend, there will be differences in visual quality and could also result in missing/non-updating regions. Ensure that the corresponding framework is well tested with PowerVR drivers and that all the APIs and GL extensions expected to be available in the OpenGL driver are available.

Use "eglinfo" to confirm that the extensions expected by a framework are available in the SGX driver.

SGXPERF2 (a part of Xgxperf) can be used as a starting point to check all APIs.

Demos are not running at required speed :Typically, for performance measurements, it is expected to use "FRONT"mode of WindowSystem plugin (configured in powervr.ini) for measuring the run rate in fps. If in this mode, the demos are running slower than expected, check and ensure that the clock frequency set for the SGX driver is correct. This can be done by the following code in the KM kernel drivers,

rate = clk_get_rate(psSysSpecData->psSGX_FCK); //Get the functional clock
printk(KERN_DEBUG "Clock is %dMhz", HZ_TO_MHZ(rate));Depending on the TI platform used, this will vary from 96 to 200 MHz. Ensure that SGX is running at the right clock.

If this is right, it is needed to optimise the application, and its usage of OpenGL API.

High CPU load while using glTexImage2D, or when using OpenVG :
The SGX driver uses CPU for some of its tasks for the above mentioned APIs. This will cause an increase of CPU load.

It is recommended to reduce the size of the textures, or use simpler VG objects, to reduce CPU load.

GLES2 + VG or GLES2 + PVR2D for 2D configuration performance is poor: Since both GLES2 and VG and PVR2D are supported with the same core, due to synchronisation overheads, the performance will be poor. It is not recommended to use this approach on SGX devices.

These FAQ options are mentioned for the all OMAP 3xxx drivers.
(The first one too I think.)
Hope that helps.(Textas instruments wiki:http://processors.wiki.ti.com/index.php/Main_Page)

Sorry my friends,have checked the wrong folder(i.e /usr/libs instead of /usr/lib or vice versa ) for the list of libraries. somebody else should do it,also:
Tutorial for finding the extensions supported by SGX driver: A quick check of the extensions supported by the SGX driver can be done using "eglinfo" utility. A sample first few lines of this output are shown below.

EGL config number: 0
EGL vendor string: Imagination Technologies
EGL version string: 1.4 build 1.5.15.3130
EGL extensions: EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_vg_parent_image EGL
EGL client APIs are: OpenGL_ES OpenVG

EGL config Attributes:
EGL_CONFIG_ID = 0x1
EGL_BUFFER_SIZE = 0x10
EGL_RED_SIZE = 0x5
EGL_GREEN_SIZE = 0x6

...Extension (and other) information can be obtained at run-time with the eglQueryString() api. See the example C code below:

// The display needs to be set according to your platform
// EGLDisplay display;
char* extensions;
extensions = eglQueryString(display, EGL_EXTENSIONS);
printf("%s\n", extensions);
Testing the support for ARGB8888 in Frame Buffer Driver(For OMAP35xx only) as the TI said : (Maybe for OMAP 34xx?)
The bootargs need to be changed as given below.

OMAP3EVM # setenv bootargs 'console=ttyS0,115200n8=noinitrd=rw ip=dhcp
root=/dev/nfs nfsroot=<your nfs_path>,nolock, mem=128M omapfb.vram="4M"
omapfb.video_mode="640x480MR-24@60" omap-dss.def_disp="dvi"'Use fbset to configure ARGB8888 mode for framebuffer memory

target $fbset -rgba 8/16,8/8,8/0,8/24 Note that if you are switching to ARGB8888 mode after bootup it is mandatory to reload omaplfb.ko kernel module


For technical support please post your questions at http://e2e.ti.com.

I couldn't find any link to public documentation, so...

Either way, I keep my position that this stuff is mostly useful to system integrators. While there's some stuff that could potentially alter an application's behaviour, it would be a clear sign that the application is badly written.

What do you want to do?

Well, the issue isn't an apps behavior as much as it is how the system behaves. In the case of filling the param buffer, if that happens on the N900 in the right circumstances the kernel driver goes into a spin. It eats 100% cpu, and doesn't respond to requests, requiring a reboot to restore. If I can prevent that by changing a system parameter, I'm all about trying it.

And yes, if a single app is causing it, that's one thing. But it's more and more looking like it's an interaction of 2 or 3 kernel drivers (for GSM, GL, and maybe GPS) causing this, not a single app. And since the replies from the only Nokia rep on the bug thread has said there's probably not going to ever be a fix for this from Nokia, even a small tweek like this is better than nothing.

Are you sure it's not the Texas Instruments TMS320 failure? Anyway fell free to ask any questions from TI.
OMAP3xxx GIT:http://git.kernel.org/?p=linux/kerne....git;a=summary
TI is already providing wide range of support for the beagleboard(i.e OMAP34xx too or OMAP35xx.) yes the proccessor seems to be different but if you see the original Beagleboard C2 you will see the specifications and the drivers source codes are the same.That means searching inside the beagleboard support and expansions will fix many of your problems.
http://elinux.org/Main_Page Linux for embedded
http://elinux.org/BeagleBoard#Revision_C2 BeagleBoard main page

Don't you think it might be placebo effect?
But maybe you use Pre's driver, you're seeing different result?

Thanks for the links. From what we're seeing, it doesn't look like the same failure, though another bug reported by someone here looks like it may be what they're seeing. (They're seeing actualy watchdog resets.)

The issue we're seeing is the driver going into a spin because it can't reset the OMAP/GL into a sane state that it recognizes. And rather than eventually giving up, it continually tries to reset the chip... eating CPU and battery as it goes.

The real solution is to fix the driver's behavior. But until then, if something can prevent this behavior, using the settings to patch the run-time enough so the buffer is less likely to overflow may be a viable solution. (Since that seems to be a pre-cursor to this behavior.)

But the example you put is exactly... well. Usually, an application requiring so much space is clearly misbehaving. Potentially (as in the bug we're talking about) because of an external cause, like the one you can trigger if you prevent the driver from actually rendering and you just let it accumulate commands.

Increasing the command buffer queue will not help but only delay the inevitable...