Bug 508039 - Use 24bpp framebuffer on g200se to avoid bandwidth limit
Use 24bpp framebuffer on g200se to avoid bandwidth limit
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-mga (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Adam Jackson
: OtherQA, Patch
Depends On:
Blocks: 509914
  Show dependency treegraph
Reported: 2009-06-25 06:15 EDT by Olivier Fourdan
Modified: 2013-03-03 21:48 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 607093 (view as bug list)
Last Closed: 2009-09-02 07:55:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.log (52.92 KB, text/plain)
2009-06-25 06:15 EDT, Olivier Fourdan
no flags Details
Proposed Patch (1.32 KB, patch)
2009-06-25 06:17 EDT, Olivier Fourdan
no flags Details | Diff

  None (edit)
Description Olivier Fourdan 2009-06-25 06:15:45 EDT
Created attachment 349368 [details]

Description of problem:

The g200e SE chipset has a limited bandwidth, causing modes to be rejected in 24 bit depth when using a 32bpp framebuffer.

However, selecting a 24bpp packed framebuffer reduces the induced bandwith and allow the use of modes that were otherwise rejected.

Version-Release number of selected component (if applicable):


How reproducible:

100% reproducible

Steps to Reproduce:
1. Install el4 on a server with a g200se chipset
2. Make sure to use 24 depth
3. start the X server
Actual results:

The desired mode get rejected:

(**) MGA(0): Depth 24, (--) framebuffer bpp 32
(II) MGA(0): Not using default mode "1280x1024" (unknown)
(--) MGA(0): Virtual size is 1280x864 (pitch 1280)

Expected results:

The desired mode is not rejected:

(**) MGA(0): Depth 24, (--) framebuffer bpp 24
(--) MGA(0): Virtual size is 1280x1024 (pitch 1280)

Additional info:

The chipset used (G200e SE) has a limited bandwith and the mode are rejected because the bandwidths induced by these modes witgh frame buffer of 32bppp are too high.

The limitation in bandwidth was introduced by this commit upstream:


For example, with the first timings listed in the Xorg.log file:

Modeline "1280x1024" 108.00  1280 1328 1440 1688  1024 1025 1028 1066
                     ^^^^^^  ^^^^           ^^^^  ^^^^           ^^^^
                        |      |              |     |              |
mode->Clock/1000 -------'      |              |     |              |
mode->HDisplay   --------------'              |     |              |
mode->HTotal     ---------------------------- '     |              |
mode->VDisplay   -----------------------------------'              |
mode->VTotal     --------------------------------------------------'

With a 32bpp we have a bandwidth of:

   4 * (1280*1024) / (1688*1066) * 108.00 = 314.68

With a 32bpp the mode gets rejected as the resulting bandwith is greater than 256.

But with a 24bpp framebuffer (that this chipset supports):

   3 * (1280*1024) / (1688*1066) * 108.00 = 236.00
So the mode would be supported with a 24bpp.

I am attaching a patch for the xorg-x11-drv-mga-1.4.10 that does select a 24bpp packed framebuffer when using a g200e SE chipset by default.

The user can still change the framebuffer depth by using the "DefaultFbBpp" in xorg.conf, but the default is 24bpp for that particular chipset that is limited in bandwidth.
Comment 1 Olivier Fourdan 2009-06-25 06:17:45 EDT
Created attachment 349369 [details]
Proposed Patch

This patch prefers a 24bpp packed framebuffer by default for the G200e SE chipset to reduce the impact of the limited bandwidth on this hardware. 

The default of 32bpp remains unchanged for other chipsets.
Comment 5 Martin Wilck 2009-07-27 04:59:47 EDT
This patch is 100% correct for this chip set, and has almost no risk of introducing regressions. You can be certain that Fujitsu and FTS will retest thoroughly with the G200SE, which is the only chip set affected by that patch.

In fact, this patch is more appropriate for our problem (wrong resolutions with G200SE at depth 24) than the one proposed in bug #507536, which is more complex and has more potential for regressions with other chip sets. Applying the patch from 508039 will make the patch from 507536 unnecessary from our point of view.
Comment 7 RHEL Product and Program Management 2009-07-27 16:05:12 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 16 Adam Jackson 2009-07-28 15:03:38 EDT
Built 1.4.10-4.el5

Comment 19 Issue Tracker 2009-07-28 22:35:24 EDT
Event posted on 07-29-2009 11:12am JST by mfuruta@redhat.com

Hi Tatsukawa-san,

I'd like to inform test package at below, would you please verify it?


Also ,this is blocker for Snapshot 5.

Masaki Furuta

Internal Status set to 'Waiting on Customer'
Status set to: Waiting on Client

This event sent from IssueTracker by mfuruta@redhat.com 
 issue 309052
Comment 26 Larry Troan 2009-08-03 08:37:57 EDT
Per private comment #25, the UK TAM installed and tested package xorg-x11-drv-mga-1.4.10-4.el5.jx2.x86_64.rpm on a RHEL5.4snap3 machine using the Kronos1 1.7MB chipset and X came up fine on reboot at 1024x768 16bpp. Additionally, he installed xorg-x11-drv-mga-1.4.10-4.el5.jx2.x86_64.rpm on a RHEL5.4snap3 machine using the Kronos2 8MB chipset. The original resolution post-install didn't fit the screen properly but was readable, but using this test package it came up correctly at 1280x1024 24bpp on restarting X. He attached logs for engineering review.

Kevin M. reviewed the *.after logs and they are correctly shrinking the virtual
fb size to allow 1024x768 @ 16bpp.  He will have Adam double check his
findings tomorrow (Monday), and assuming they both agree, they will provide a
recommendation to PM about how best to include the updated patch.

Setting to NEEDINFO ajax.  

Do we have this driver on a people.page so partners may test it as well?
Comment 28 Larry Troan 2009-08-03 10:42:42 EDT
> Do we have this driver on a people.page so partners may test it as well?  
Comment 29 Chris Ward 2009-08-03 11:47:16 EDT
~~ Attention Partners - RHEL 5.4 Snapshot 5 Released! ~~

RHEL 5.4 Snapshot 5 is the FINAL snapshot to be release before RC. It has been 
released on partners.redhat.com. If you have already reported your test results, 
you can safely ignore this request. Otherwise, please notice that there should be 
a fix available now that addresses this particular issue. Please test and report 
back your results here, at your earliest convenience.

If you encounter any issues while testing Beta, please describe the 
issues you have encountered and set the bug into NEED_INFO. If you 
encounter new issues, please clone this bug to open a new issue and 
request it be reviewed for inclusion in RHEL 5.4 or a later update, if it 
is not of urgent severity. If it is urgent, escalate the issue to your partner manager as soon as possible. There is /very/ little time left to get additional code into 5.4 before GA.

Partners, after you have verified, do not flip the bug status to VERIFIED. Instead, please set your Partner ID in the Verified field above if you have successfully verified the resolution of this issue. 

Further questions can be directed to your Red Hat Partner Manager or other 
appropriate customer representative.
Comment 35 Adam Jackson 2009-08-04 12:02:57 EDT
1916307 build (dist-5E-qu-candidate, RHEL-5:xorg-x11-drv-mga-1_4_10-5_el5): open (x86-004.build.bos.redhat.com) -> closed

Comment 37 Chris Ward 2009-08-11 06:02:42 EDT
Fujitsu, please test using the latest RC1 test build for this package. This is the candidate build for RC1.

Comment 39 Takeshi Suzuki 2009-08-12 02:02:15 EDT
Chris, xorg-x11-drv-mga-1.4.10-5.el5 has been verified
for both Kronos1 1.7MB chipset and Kronos2 8MB chipset.
Comment 42 errata-xmlrpc 2009-09-02 07:55:03 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

Comment 45 Kosuke TATSUKAWA 2010-04-07 20:19:37 EDT
Requested information was provided in IssueTracker.
This is just to clear the needinfo flag.

Note You need to log in before you can comment on or make changes to this bug.