This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 533879 - X fails when using vesa driver in qemu (kvm/libvirt virtualization)
X fails when using vesa driver in qemu (kvm/libvirt virtualization)
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-09 10:56 EST by James Laska
Modified: 2013-09-02 02:42 EDT (History)
14 users (show)

See Also:
Fixed In Version: xorg-x11-drv-vesa-2.3.0-2.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-03 22:26:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/etc/X11/xorg.conf (68 bytes, text/plain)
2009-11-09 10:56 EST, James Laska
no flags Details
/var/log/Xorg.1.log (23.07 KB, text/plain)
2009-11-09 10:59 EST, James Laska
no flags Details
My Xorg.0.log file showing the VESA driver failure. (7.37 KB, text/plain)
2010-01-27 09:08 EST, William M. Quarles
no flags Details

  None (edit)
Description James Laska 2009-11-09 10:56:54 EST
Created attachment 368245 [details]
/etc/X11/xorg.conf

Description of problem:

The vesa driver seems to be failing.

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

 * kernel-2.6.31.5-127.fc12.x86_64
 * xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64
 * xorg-x11-drv-vesa-2.2.1-1.fc12.x86_64

How reproducible:

 * 100% on virt hardware

Steps to Reproduce:
1. Boot installer
2. Select "Install system with basic video driver"
3. Complete install accepting all defaults
4. Boot installed system, and honor firstboot questions
5. Attempt to login
  
Actual results:

X crashes constantly while trying to display GDM

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
Current language:  auto
The current source language is "auto; currently asm".
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007fd7fc24d289 in bits_image_fetch_untransformed_repeat_none (image=0x1c23750, 
    wide=0, x=0, y=0, width=36, buffer=0x7fffa1392360) at pixman-bits-image.c:497
#2  0x00007fd7fc247a5b in general_composite_rect (imp=<value optimized out>, 
    op=<value optimized out>, src=<value optimized out>, mask=<value optimized out>, 
    dest=<value optimized out>, src_x=<value optimized out>, src_y=<value optimized out>, 
    mask_x=<value optimized out>, mask_y=<value optimized out>, 
    dest_x=<value optimized out>, dest_y=<value optimized out>, 
    width=<value optimized out>, height=<value optimized out>) at pixman-general.c:211
#3  0x00007fd7fc24f6e2 in walk_region_internal (imp=<value optimized out>, 
    op=<value optimized out>, src_image=<value optimized out>, 
    mask_image=<value optimized out>, dst_image=<value optimized out>, 
    src_x=<value optimized out>, src_y=<value optimized out>, mask_x=<value optimized out>, 
    mask_y=<value optimized out>, dest_x=<value optimized out>, 
    dest_y=<value optimized out>, width=<value optimized out>, 
    height=<value optimized out>, src_repeat=<value optimized out>, 
    mask_repeat=<value optimized out>, region=<value optimized out>, 
    composite_rect=<value optimized out>) at pixman-utils.c:447
#4  0x00007fd7fc250a50 in _pixman_walk_composite_region (imp=<value optimized out>, 
    op=<value optimized out>, src_image=<value optimized out>, 
    mask_image=<value optimized out>, dst_image=<value optimized out>, 
    src_x=<value optimized out>, src_y=<value optimized out>, mask_x=<value optimized out>, 
    mask_y=<value optimized out>, dest_x=<value optimized out>, 
    dest_y=<value optimized out>, width=<value optimized out>, 
    height=<value optimized out>, composite_rect=<value optimized out>)
    at pixman-utils.c:493
#5  0x00007fd7fc24775a in general_composite (imp=<value optimized out>, 
    op=<value optimized out>, src=<value optimized out>, mask=<value optimized out>, 
    dest=<value optimized out>, src_x=<value optimized out>, src_y=<value optimized out>, 
    mask_x=<value optimized out>, mask_y=<value optimized out>, 
    dest_x=<value optimized out>, dest_y=<value optimized out>, 
    width=<value optimized out>, height=<value optimized out>) at pixman-general.c:270
#6  0x00007fd7fc2484ec in pixman_image_composite (op=PIXMAN_OP_OVER, src=0x1c23750, 
    mask=0x0, dest=0x1c2b300, src_x=<value optimized out>, src_y=<value optimized out>, 
    mask_x=<value optimized out>, mask_y=<value optimized out>, 
    dest_x=<value optimized out>, dest_y=<value optimized out>, 
    width=<value optimized out>, height=<value optimized out>) at pixman.c:204
#7  0x00007fd7f7284ce0 in fbComposite (op=<value optimized out>, pSrc=0x1c23680, pMask=0x0, 
    pDst=<value optimized out>, xSrc=<value optimized out>, ySrc=<value optimized out>, 
    xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, 
    yDst=<value optimized out>, width=<value optimized out>, height=<value optimized out>)
    at fbpict.c:172
#8  0x00000000004d1c80 in damageComposite (op=<value optimized out>, 
    pSrc=<value optimized out>, pMask=<value optimized out>, pDst=0x1c22f10, 
    xSrc=<value optimized out>, ySrc=<value optimized out>, xMask=<value optimized out>, 
    yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, 
    width=<value optimized out>, height=<value optimized out>) at damage.c:643
#9  0x00000000004cb80e in ProcRenderComposite (client=<value optimized out>) at render.c:723
#10 0x000000000042c69c in Dispatch () at dispatch.c:445
#11 0x0000000000421cfa in main (argc=<value optimized out>, argv=<value optimized out>, 
    envp=<value optimized out>) at main.c:285

Expected results:

X shouldn't crash

Additional info:
Comment 1 James Laska 2009-11-09 10:58:40 EST
Program received signal SIGABRT, Aborted.
0x00007fd7fa3986b5 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Comment 2 James Laska 2009-11-09 10:59:22 EST
Created attachment 368246 [details]
/var/log/Xorg.1.log
Comment 3 Adam Williamson 2009-11-09 11:06:25 EST
I tested on real hardware - an NVIDA 9400 GT - and, after I hacked it up enough to make sure the nouveau module didn't load, it worked and got through gdm. That was not a clean install or live boot test, it was my day-to-day working install. I was able to reproduce jlaska's crashes in a KVM using a live image, so I will test the exact same procedure on the same real hardware and another test machine shortly.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Matěj Cepl 2009-11-09 12:18:41 EST
Yeah, attachment in the comment 2 has this backtrace:

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x49e8d8]
1: /usr/bin/X (0x400000+0x619c9) [0x4619c9]
2: /lib64/libpthread.so.0 (0x7fd7fbbab000+0xefa0) [0x7fd7fbbb9fa0]
Segmentation fault at address (nil)

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting
Comment 5 James Laska 2009-11-09 12:24:09 EST
Still determining the blocker worthiness of this issue.  In the meantime, moving this under the appropriate X blocker bug.
Comment 6 James Laska 2009-11-09 12:25:47 EST
(In reply to comment #5)
> Still determining the blocker worthiness of this issue.  In the meantime,
> moving this under the appropriate X blocker bug.  

Let's try that again, but with the correct bug#
Comment 7 Adam Williamson 2009-11-09 12:32:20 EST
tested on three real hardware systems now - NVIDIA 9400 GT, Radeon 4770, Vaio P (Intel Poulsbo) - vesa comes up fine on all of 'em. I'm feeling happier that this is restricted to qemu.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 8 Adam Williamson 2009-11-09 12:33:40 EST
for completeness, if this is qemu-only, it's not a blocker and well into 'doctor-it-hurts' territory. there's no reason to use the vesa driver within qemu.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 Adam Jackson 2009-11-10 11:16:45 EST
There's definitely something weird at work here.  We're crashing here:

(gdb) bt 1
#0  0x0014f6ff in bits_image_fetch_untransformed_repeat_none (image=0x9955878, 
    wide=<value optimized out>, x=<value optimized out>, 
    y=<value optimized out>, width=<value optimized out>, 
    buffer=<value optimized out>) at pixman-bits-image.c:497

which looks like:

if (x < image->width)
{
    w = MIN (width, image->width - x);

    if (wide)
        image->fetch_scanline_raw_64 ((pixman_image_t *)image, x, y, w, buffer, NULL, 0);
    else
        image->fetch_scanline_raw_32 ((pixman_image_t *)image, x, y, w, buffer, NULL, 0);
    width -= w;
    buffer += w * (wide? 2 : 1);
    x += w;
}

we're not in wide mode here, so this is fetch_scanline_raw_32.  But:

(gdb) print *image
$19 = {common = {type = BITS, ref_count = 1, clip_region = {extents = {x1 = 0, 
        y1 = 0, x2 = 0, y2 = 0}, data = 0x166e20}, have_clip_region = 0, 
    client_clip = 0, clip_sources = 1, dirty = 0, need_workaround = 0, 
    transform = 0x0, repeat = PIXMAN_REPEAT_NONE, 
    filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, n_filter_params = 0, 
    alpha_map = 0x0, alpha_origin_x = 8519915, alpha_origin_y = 10223880, 
    component_alpha = 0, classify = 0, 
    property_changed = 0x14f440 <bits_image_property_changed>, 
    get_scanline_32 = 0x14f750 <bits_image_fetch_untransformed_32>, 
    get_scanline_64 = 0x14f7b0 <bits_image_fetch_untransformed_64>, 
    destroy_func = 0x32d570 <destroy_drawable>, destroy_data = 0x9957218}, 
  format = 402819208, indexed = 0x0, width = 38, height = 34, 
  bits = 0x9957248, free_me = 0x0, rowstride = 38, fetch_pixel_raw_32 = 0, 
  fetch_pixel_raw_64 = 0, fetch_pixel_32 = 0, fetch_pixel_64 = 0xdd, 
  fetch_scanline_raw_32 = 0x9955fb0, fetch_scanline_raw_64 = 0, 
  store_scanline_raw_32 = 0, store_scanline_raw_64 = 0, 
  store_scanline_32 = 0x14ef50 <bits_image_store_scanline_32>, 
  store_scanline_64 = 0x14efb0 <bits_image_store_scanline_64>, read_func = 0, 
  write_func = 0}

fetch_scanline_raw_32 looks like it's something other than a function pointer.  pmap says that's backed by an anonymous mmap, and 'image' itself is:

(gdb) print image
$20 = (bits_image_t *) 0x9955878

so it sure does look like it's pointing into the malloc arena for some reason.
Comment 10 Adam Williamson 2009-11-10 11:38:05 EST
probably a dumb question, but does 'wide mode' have anything to do with the resolution of the display? because it occurs to me that all the systems I tested VESA works okay on have widescreen displays, whereas qemu is a square one (1024x768).

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 11 Adam Jackson 2009-11-12 13:10:35 EST
No, wide mode means more than 32bpp here.
Comment 12 Bug Zapper 2009-11-16 10:21:07 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Søren Sandmann Pedersen 2010-01-17 15:22:26 EST
Decoding the image format (402819208 = 0x18028888) we get

   bpp:   24 bit
   type:  ARGB
   a:     8
   r:     8
   g:     8
   b:     8

which is meaningless since there is more depth than there is bpp.

Pixman should certainly fail more graciously when people use unsupported formats, but the bug here is with whoever (presumably the vesa driver) created a picture with that combination.
Comment 14 Søren Sandmann Pedersen 2010-01-17 15:37:16 EST
Or rather, the render initialization code ends up adding a depth 32 bit format with a 24 bpp.
Comment 15 Søren Sandmann Pedersen 2010-01-17 15:44:07 EST
*** Bug 555221 has been marked as a duplicate of this bug. ***
Comment 16 William M. Quarles 2010-01-20 07:52:07 EST
Also fails on ATI Radeon 7200 on PowerPC. My computer is an Apple Power Mac G4 with AGP Graphics.
Comment 17 William M. Quarles 2010-01-20 07:52:52 EST
Problem exists on Fedora 11 as well.
Comment 18 Adam Williamson 2010-01-20 14:06:17 EST
william: what exactly do you mean? Are you using the vesa driver? seeing the same failure as the above? If not, please file a new bug. Thanks.
Comment 19 William M. Quarles 2010-01-20 15:38:25 EST
Yes, someone reccomended that I try to use the VESA driver to circumvent problems with the Radeon driver in Fedora 11 (and 12). X refuses to start with the VESA driver when used with my video card. I'd have to look more closely at the output, but I filed my comments based on the basic description of the bug. There are so many log files and output readings above that it's hard to compare, especially when the bug was originally reported against virtual hardware, but then others are testing it on actual hardware. When I get home tonight I will try to reproduce and post some output.
Comment 20 William M. Quarles 2010-01-22 21:08:28 EST
Uh, Adam:

I unintentionally deleted the mini x.conf file that started X in VESA mode. I remember that the file only had like three lines in it, but I can't remember what it said. If you could tell me what little bit needs to be in there to get this to load in VESA mode again, I can post my output.

Thanks,
William
Comment 21 Adam Williamson 2010-01-26 01:08:24 EST
Take a look at:

https://fedoraproject.org/wiki/How_to_create_xorg.conf
Comment 22 William M. Quarles 2010-01-26 21:07:29 EST
Thanks. Yeah, I've even read that article before, I don't know why I couldn't think of that. Here is my output. Please let me know if this looks like an entirely different bug to you or if it actually fits in here.

------------------------

[William@localhost ~]$startx
xauth:  creating new authority file /home/William/.serverauth.1566


X.Org X Server 1.6.3.901 (1.6.4 RC 1)
Release Date 2009-8-25
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-164.el5 ppc
Current Operating System: Linux localhost.localdomain 2.6.30.10-105.fc11.ppc #1
 Thu Dec 24 16:28:20 UTC 2009 ppc
Kernel Command line: root=/dev/mapper/VolGroup-lv_root ro rhgb quiet
Build Date: 09 September 2009 11:36:55AM
Build ID: xorg-x11-server 1.6.4-0.1.fc11
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implememented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 11 10:37:12 1976
(==) Using config file: "/etc/X11/xorg.conf"

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x50) [0x101014e0]
1: /usr/bin/X(xf86SigHandler+0xd8) [0x10085fc8]
2: [0x100364]
3: /usr/lib/xorg/modules//libint10.so(LockLegacyVGA+0x50) [0xf241c30]
4: /usr/lib/xorg/modules//libint10.so(xf86ExtendedInitInt10+0x1e0) [0xf245f30]
5: /usr/lib/xorg/modules//libvbe.so(VBEExtendedInit+0x320) [0xf281760]
6: /usr/lib/xorg/modules/drivers//vesa_drv.so [0xf2a9f24]
7: /usr/bin.X(InitOutput+0x5bc) [0x1006a6cc]
8: /usr/bin/X(main+0x224) [0x10021bb4]
9: /lib/libc.so.6 [0xf7f343c]
10: /lib/libc.so.6 [0xf7f35e0]

Fatal server error:
Caught signal 7. Server aborting


Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
Please also check the log file at "/var/log/Xorg.o.log" for additional
 information.

giving up.
xinit:  No such file or directory (errno 2):  unable to connect to X server
xinit:  No such process (errno 3):  Server error.

------------------------------

And yes, I see that my year on my clock is at 1976. If anybody could shoot me an e-mail as to how to fix that without XWindows and without Mac OS installed on a Power Mac G4, I would appreciate it. Please don't post the response here, as it is probably not relevant to the bug. I don't have good access to the mailing list now since apparently the postmaster for the Fedora Project doesn't like GMANE. If anyone wants to argue about that, please shoot me an e-mail about that, too, don't write about it here.

As for the log file, that is going to take some difficult maneuverings with my home networking and mini-server programs to get up here if you need it, I can't type that whole thing out like I did with this screen output.
Comment 23 William M. Quarles 2010-01-27 09:08:20 EST
Created attachment 387081 [details]
My Xorg.0.log file showing the VESA driver failure.
Comment 24 Søren Sandmann Pedersen 2010-01-27 10:43:54 EST
William, that crash is almost certainly unrelated to this bug. Please file a new bug against the vesa driver.
Comment 25 William M. Quarles 2010-01-27 13:09:26 EST
Done.

Bug 559317
Comment 26 Matěj Cepl 2010-09-22 06:27:24 EDT
changing the title to emphasize virtual nature of this bug
Comment 27 Fedora Update System 2010-10-11 15:42:13 EDT
xorg-x11-drv-vesa-2.3.0-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/xorg-x11-drv-vesa-2.3.0-2.fc14
Comment 28 Fedora Update System 2010-10-11 22:38:28 EDT
xorg-x11-drv-vesa-2.3.0-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-vesa'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xorg-x11-drv-vesa-2.3.0-2.fc14
Comment 29 Paul Howarth 2010-10-28 10:11:07 EDT
(In reply to comment #8)
> for completeness, if this is qemu-only, it's not a blocker and well into
> 'doctor-it-hurts' territory. there's no reason to use the vesa driver within
> qemu.

The vesa driver offers a much better range of guest screen resolutions than the cirrus one, or at least it did in F12 when it worked well. In F13 it was unbearably slow (Bug #589447) and with an F14 guest on an F13 host I can't get it to work at all at the moment.
Comment 30 Bug Zapper 2010-11-04 02:38:33 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 31 Bug Zapper 2010-12-03 22:26:02 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 32 Fedora Update System 2011-04-15 16:49:57 EDT
xorg-x11-drv-vesa-2.3.0-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

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