Bug 1128573 - [FJ6.5 Bug] Resizing screen size on Matrox MGA causes CPU Fatal Error
Summary: [FJ6.5 Bug] Resizing screen size on Matrox MGA causes CPU Fatal Error
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-drv-mga
Version: 6.5
Hardware: All
OS: Linux
Target Milestone: rc
: 6.7
Assignee: Adam Jackson
QA Contact: Desktop QE
Whiteboard: QJ140804-001/66Z
Depends On:
Blocks: 1011600 1075802 1130943 1159931
TreeView+ depends on / blocked
Reported: 2014-08-11 06:46 UTC by soft-linux-drv@ml.css.fujitsu.com
Modified: 2015-02-18 17:10 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-02-18 17:10:32 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description soft-linux-drv@ml.css.fujitsu.com 2014-08-11 06:46:42 UTC
Customer Contact Name:
  Koki Sanagi

Description of Problem:

  Putting a landscape display (we used 1680x1050) on a server and resizing the 
  screen size from 1024x768 to 1280x1024 causes CPU Fatal Error.

  According to our investigation, this is due to underestimating of memory size
  which is used for ShadowFB by MGA driver. Following is where MGA allocates
>    height = pScrn->virtualY;
>     if(pMga->ShadowFB) {
>         /*
>          * I don't really feel like faffing about with resizing the
>          * shadow buffer when the front buffer grows in RANDR, so I'm
>          * just going to allocate enough up front and let the upload hook
>          * correct for width.
>          */
>         if (pMga->randr12)
>             pMga->ShadowPitch = BitmapBytePad(pScrn->bitsPerPixel * 2048);
>         else
>             pMga->ShadowPitch = BitmapBytePad(pScrn->bitsPerPixel * width);
>         displayWidth = pMga->ShadowPitch / (pScrn->bitsPerPixel >> 3);
>         FBStart = pMga->ShadowPtr = malloc(pMga->ShadowPitch * height);
>     } else {

  Here, MGA assumes that width is 2048 whatever display is put. But as for
  height it uses a value from somewhere. If you put a 1680x1050 display, height
  becomes 900 because 1440x900 is possible. In that case 2048x900x3 bytes is
  allocated for ShadowFB.  But this display also can project a 1280x1024
  screen. Even if you change to that size, Xserver will not change that memory
  size but Xserver uses 2048x1024x3 bytes memory which is more than allocated. 
  Unluckily, /dev/mem is mapped right after this shadowFB memory. So this
  overflow write access results in CPU Fatal Error when it trespasses the
  reserved area for BIOS.

# pmap -x 4801
4801:   /usr/bin/Xorg :0 -nr -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-ulXrQ0/database -nolisten tcp vt1
00007f883a521000    5496    5408    5408 rw---    [ anon ]   * for shadowFB
00007f883aa7f000     256       0       0 rw-s-  mem
00007f883aabf000     128       0       0 rw-s-  mem
00007f883aadf000     964     208     208 rw---    [ anon ]

Version-Release number of selected component:

  Red Hat Enterprise Linux Version Number:6
  Release Number:5
  Kernel Version:2.6.32-431.el6.x86_64
  Related Package Version:
  Related Middleware/Application:

Drivers or hardware or architecture dependency:
  MGA driver and MGA G200e VGA controller

How reproducible:

Step to Reproduce:

  1. Put a 1680x1050 display.
  2. Resize the screen size from 1024x768 to 1280x1024.

Actual Results:
  The machine falls into CPU Fatal Error.

Expected Results:
  The screen size changes normally.

Summary of actions taken to resolve issue:

Location of diagnostic data:

Hardware configuration:

  Model/Hypervisor:PRIMEQUEST 2800E
  CPU Info:Xeon X5660 2sockets
  Memory Info:64GB
  Hardware Component Information:none
  Configuration Info:none
  Guest Configuration Info:none

Business Impact:


  Target Release:6.6

  Errata Request:None

Additional Info:
  The displays we used are Fujitsu VL-22WB1G and DELL 2209WA. Both of them
  have 1680x1050 resolution.

  We made this bug as public by following reasons.
  This bug occurred at a customer who purchased a PRIMEQUEST 2800E.
  Customer thought that this was a HW issue, and he had FJ investigate it.

  FJ HW & SW team investigated this issue, and we reached the above conclusion.
  Customer purchased the RHEL support from Red Hat directly.
  So FJ filed this bug to share our analysis with customer and Red Hat.
  Therefore, FJ keeps this bug as public.
  I think customer would file support case by pointing this bug. Fujitsu are
  not sure whether this customer wants async errata or not.
  Of course Fujitsu believes that this issue will be resolved sometime since
  this issue might bother other our customers.

Comment 3 Fujitsu kernel engineers 2014-08-11 07:12:43 UTC
Dear Oguma-san,

As we wrote in "Additional Info", please keep this bug as public.

Hironobu Ishii

Comment 4 Yoko Oguma 2014-08-11 07:25:51 UTC
(In reply to Fujitsu kernel engineers from comment #3)
OK. Sorry, I had overlooked the information.

Comment 7 Yoko Oguma 2014-08-12 01:49:51 UTC

Would you be able to test the issue with a fixed package when available?

Best Regards,
Yoko Oguma

Comment 8 soft-linux-drv@ml.css.fujitsu.com 2014-08-12 02:21:42 UTC
Dear Oguma-san,

>Would you be able to test the issue with a fixed package when available?

Yes we can.

Best Regards,
Koki Sanagi

Comment 9 Yoko Oguma 2014-08-12 02:24:11 UTC
(In reply to soft-linux-drv@ml.css.fujitsu.com from comment #8)
Thank you!

Comment 10 Larry Troan 2014-10-09 00:45:05 UTC
In talking with the Partner today, the proposed patch checks for this specific adapter and sets the color depth to 24. For maximum resolution, this needs an option of 26 which degrades the color depth. Another Linux distro provided a kernel parameter for the customer to decide "best color depth" or "maximum resolution". The Partner requests the same from Red Hat.

Comment 14 Adam Jackson 2015-02-18 17:10:32 UTC
The shadow framebuffer height issue described here appears to already be addressed in 6.6, so I'm marking this as resolved.  Please reopen if this crash still occurs with xorg-x11-drv-mga-1.6.3-5.el6 or newer.

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