Bug 427383 - xorg-x11-drv-vesa causes KDE 4 to crash (on some hardware)
xorg-x11-drv-vesa causes KDE 4 to crash (on some hardware)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pixman (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: Reopened
: 443866 (view as bug list)
Depends On:
Blocks: KDE4Live f9-x-blocker 443866
  Show dependency treegraph
 
Reported: 2008-01-03 12:15 EST by Kevin Kofler
Modified: 2008-05-01 08:54 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-01 08:54:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The xorg.conf file, just the default live CD configuration (735 bytes, text/plain)
2008-01-15 00:18 EST, Kevin Kofler
no flags Details
The Xorg.0.log logfile (20.00 KB, text/plain)
2008-01-15 00:19 EST, Kevin Kofler
no flags Details

  None (edit)
Description Kevin Kofler 2008-01-03 12:15:10 EST
Description of problem:
Using the xorg-x11-drv-vesa driver, KDE 4 crashes in a weird way:
KDE only gets as far as displaying the desktop background and panel, then X 
crashes (so it drops back to KDM, logging in again crashes it the same way). 
(The panel can't actually be used before it crashes.) Moreover, before 
crashing, KDE only actually uses the left ~2/3 of the screen (the vertical 
space is fully used) and there's vertical interference lines.

This is reproducible both in QEMU (which always uses vesa) and using 
xdriver=vesa on my old laptop (S3 Virge chipset, the s3virge driver doesn't 
work at all due to no pciaccess port, xdriver=vesa reproduces this crash).

My main machine with xorg-x11-drv-ati (Radeon 9200SE) works, so I believe this 
to be an X driver issue.

Version-Release number of selected component (if applicable):
xorg-x11-drv-vesa-1.3.0-11.20071113.fc9

How reproducible:
Always (at least on the machines I tried it on)

Steps to Reproduce:
1. Get the Rawhide KDE 4 live CD from 
http://www.fedoraforum.de/iso/test/rawhide-KDE4-i686-20071220/rawhide-KDE4-i686-20071220.iso
2. Try starting it in QEMU or by forcing xdriver=vesa.
  
Actual results:
Weird artefacts, crash, as described above.

Expected results:
KDE 4 starts up successfully.
Comment 1 Matěj Cepl 2008-01-10 07:44:27 EST
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 Kevin Kofler 2008-01-11 02:10:29 EST
X apparently just segfaults: there are no errors or anything in the Xorg.0.log 
until this:

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x79) [0x80bce59]
1: [0x130420]

Fatal server error:
Caught signal 11. Server aborting

Unfortunately, that backtrace appears to be entirely useless to me, as 0: is 
just the signal handler and there is no telling where 1: is in.
Comment 3 Matěj Cepl 2008-01-14 08:31:40 EST
Could I just get the files I asked you, please?
Comment 4 Kevin Kofler 2008-01-15 00:16:35 EST
Coaxing those files out of QEMU running the live CD was a PITA, but I have them 
now. Attaching...
Comment 5 Kevin Kofler 2008-01-15 00:18:22 EST
Created attachment 291682 [details]
The xorg.conf file, just the default live CD configuration
Comment 6 Kevin Kofler 2008-01-15 00:19:22 EST
Created attachment 291683 [details]
The Xorg.0.log logfile

And here's the complete log file, I don't think you'll find anything more
interesting than what I excerpted already though.
Comment 7 Kevin Kofler 2008-01-25 19:05:21 EST
Ping? Anything I can do to help debugging this? The logs I posted on Matej's 
request look really useless to me (in this case), is there any way to get more 
information?
Comment 8 Jesse Keating 2008-02-06 14:33:39 EST
Adam is at LCA/Vacation so not likely to respond for a few days yet.
Comment 9 Till Maas 2008-02-07 08:24:04 EST
(In reply to comment #7)
> Ping? Anything I can do to help debugging this? The logs I posted on Matej's 

I do not know whether it helps here, but installing the respective debuginfo
packages, e.g. with debuginfo-install xorg-x11-drv-vesa, and running the
programm in gdb (maybe "gdb startx", then "run" and then "bt" after it crashed)
should show   the line numbers, where X crashes.
Comment 10 Kevin Kofler 2008-02-07 20:50:01 EST
In QEMU, this can now be worked around by setting xdriver=cirrus (shouldn't 
that driver claim the QEMU PCI ID by default?), it is still a major problem for 
machines which have to use vesa though.
Comment 11 Kevin Kofler 2008-02-07 22:21:49 EST
Jeremy Katz says:
https://www.redhat.com/archives/fedora-devel-list/2008-February/msg00433.html
that current (post-alpha) Rawhide is already defaulting to cirrus in QEMU, the 
driver just wasn't ready (for libpciaccess) in time for the alpha.

So you may have to force xdriver=vesa to reproduce this bug in QEMU for current 
Rawhide.
Comment 12 Kevin Kofler 2008-02-11 05:33:07 EST
I'm marking this as F9Blocker because this is simply not going to be acceptable 
in a release.
Comment 13 Rex Dieter 2008-03-03 09:31:20 EST
confirmed now to be mm, mm, good.

(since I resorted to using vesa because of recent intel/i810 breakage).

Didn't test qemu usage tho.
Comment 14 Kevin Kofler 2008-03-04 04:52:32 EST
QEMU still crashes with Sebastian's latest live CD if I force xdriver=vesa (by 
default, I get cirrus, which works). I haven't tried on my laptop yet, but I 
suspect it's the same. This appears to be hardware-dependent, with only some 
VESA implementations causing the problems.
Comment 15 Kevin Kofler 2008-03-04 04:53:48 EST
(Sorry if I was unclear, QEMU itself doesn't crash, the KDE 4 inside it does.)
Comment 16 Rex Dieter 2008-04-18 14:01:45 EDT
dl'ing F9-Preview now.
Comment 17 Rex Dieter 2008-04-18 15:30:27 EDT
ugh, can't confirm using qemu.  passing xdriver=vesa on kernel command line ends
up locking my f9 host machine.
Comment 18 Kevin Kofler 2008-04-22 20:23:01 EDT
I just tried F9 Preview on my laptop with xdriver=vesa (s3virge is still 
completely broken, expect a bug report about that coming soon ;-) ).

Unfortunately, I can confirm that the bug is still happening.
Comment 19 Rodney Morris 2008-04-23 00:06:00 EDT
I can confirm that the bug still exists in the F9 Preview using virtual box.  

Incidentally, KDE does not crash when run from the F9 Preview live KDE cd;
however, after the live image is installed to the hard drive, KDE crashes when
Fedora 9 is booted from the hard drive.

I'll attach the output generated by "startx" later if it would be helpful.

Comment 20 Kevin Kofler 2008-04-23 04:20:33 EDT
On both my laptop and QEMU, booting the live image directly is enough to 
reproduce the crash.
Comment 21 Steven M. Parrish 2008-04-23 15:38:39 EDT
*** Bug 443866 has been marked as a duplicate of this bug. ***
Comment 22 Dave Airlie 2008-04-24 01:34:22 EDT
#0  0x00000000 in ?? ()
#1  0x00122cd7 in fbStore (pict=0x8a12dd8, x=818, y=<value optimized out>, 
    width=22, buffer=0xbfef8ac4) at pixman-compose.c:165
#2  0x001227e9 in pixman_composite_rect_general (data=0xbfefea6c, 
    scanline_buffer=0xbfef8a6c) at pixman-compose.c:452
#3  0x00126a06 in pixman_image_composite_rect (op=PIXMAN_OP_SRC, 
    src=0x8a284b0, mask=0x0, dest=0x8a12dd8, src_x=0, src_y=0, mask_x=0, 
    mask_y=0, dest_x=818, dest_y=733, width=22, height=22)
    at pixman-pict.c:1340
#4  0x0012668c in pixman_image_composite (op=PIXMAN_OP_SRC, pSrc=0x8a284b0, 
    pMask=0x0, pDst=0x8a12dd8, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=818, 
    yDst=733, width=<value optimized out>, height=<value optimized out>)
    at pixman-pict.c:1246
#5  0x0028ad82 in fbComposite () from /usr/lib/xorg/modules//libfb.so
#6  0x08175eb6 in ?? ()

backtrace points firmly as pixman .. so I'll reassign to ssp.
Comment 23 Søren Sandmann Pedersen 2008-04-24 18:03:20 EDT
I built some packages here that may point the finger at the problem:

http://www.daimi.au.dk/~sandmann/pixman-0.10.0-1.bug427383.fc9.i386.rpm
http://www.daimi.au.dk/~sandmann/pixman-debuginfo-0.10.0-1.bug427383.fc9.i386.rpm
                   
http://www.daimi.au.dk/~sandmann/pixman-devel-0.10.0-1.bug427383.fc9.i386.rpm  
                     

I would appreciate it if someone who can reproduce would try them and see if it
prints anything interesting before it crashes.

Thanks

Comment 24 Kevin Kofler 2008-04-24 18:07:58 EDT
"prints" where exactly?
Comment 25 Dave Airlie 2008-04-24 19:29:26 EDT
doesn't seem to print anything.. here is a copy of *pict at least..


#0  0x00000000 in ?? ()
#1  0x0012666b in fbStore (pict=0x8a85180, x=792, y=733, width=3, 
    buffer=0xbfe33cf4) at pixman-compose.c:165
#2  0x0012705e in pixman_composite_rect_general_no_accessors (data=0xbfe39ce8, 
    scanline_buffer=0xbfe33ce8) at pixman-compose.c:452
#3  0x00127162 in pixman_composite_rect_general (data=0xbfe39ce8, 
    scanline_buffer=0xbfe33ce8) at pixman-compose.c:483
#4  0x0012c326 in pixman_image_composite_rect (op=PIXMAN_OP_SRC, 
    src=0x8a84f80, mask=0x0, dest=0x8a85180, src_x=0, src_y=0, mask_x=0, 
    mask_y=0, dest_x=792, dest_y=733, width=3, height=22) at pixman-pict.c:1340
#5  0x0012c069 in pixman_walk_composite_region (op=PIXMAN_OP_SRC, 
    pSrc=0x8a84f80, pMask=0x0, pDst=0x8a85180, xSrc=0, ySrc=0, xMask=0, 
    yMask=0, xDst=792, yDst=733, width=22, height=22, srcRepeat=0, 
    maskRepeat=0, compositeRect=0x12c1b5 <pixman_image_composite_rect>)
    at pixman-pict.c:1246
#6  0x0012ca36 in pixman_image_composite (op=PIXMAN_OP_SRC, pSrc=0x8a84f80, 
    pMask=0x0, pDst=0x8a85180, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=792, 
    yDst=733, width=22, height=22) at pixman-pict.c:1748
#7  0x00294d82 in fbComposite (op=0 '\0', pSrc=0x8a85988, pMask=0x0, 
    pDst=0x8d96020, xSrc=0, ySrc=0, xMask=<value optimized out>, 
    yMask=<value optimized out>, xDst=0, yDst=0, width=22, height=22)
    at fbpict.c:185
#8  0x08175eb6 in ?? ()
---Type <return> to continue, or q <return> to quit---
#9  0x0815fbc6 in CompositePicture ()
#10 0x081419d0 in compWindowUpdate ()
#11 0x081417a8 in compWindowUpdate ()
#12 0x081417a8 in compWindowUpdate ()
#13 0x081417a8 in compWindowUpdate ()
#14 0x081417a8 in compWindowUpdate ()
#15 0x081417a8 in compWindowUpdate ()
#16 0x08140a72 in ?? ()
#17 0x08089668 in BlockHandler ()
#18 0x0812d18d in WaitForSomething ()
#19 0x0808576e in Dispatch ()
#20 0x0806b3bd in main ()
(gdb) up
#1  0x0012666b in fbStore (pict=0x8a85180, x=792, y=733, width=3, 
    buffer=0xbfe33cf4) at pixman-compose.c:165
165         store((pixman_image_t *)pict, bits, buffer, x, width, indexed);
(gdb) print *pict
$1 = {common = {type = BITS, ref_count = 1, full_region = {extents = {x1 = 0, 
        y1 = 0, x2 = 48, y2 = 22}, data = 0x0}, clip_region = {extents = {
        x1 = 792, y1 = 733, x2 = 795, y2 = 755}, data = 0x0}, 
    src_clip = 0x8a85194, has_client_clip = 1, transform = 0x0, 
    repeat = PIXMAN_REPEAT_NONE, filter = PIXMAN_FILTER_NEAREST, 
    filter_params = 0x0, n_filter_params = 0, alpha_map = 0x0, alpha_origin = {
      x = 532, y = 414}, component_alpha = 0, read_func = 0, write_func = 0}, 
  format = 402819208, indexed = 0x0, width = 48, height = 22, 
  bits = 0x87e10c8, free_me = 0x0, rowstride = 1024}
(gdb) print /x *pict
$2 = {common = {type = 0x0, ref_count = 0x1, full_region = {extents = {
        x1 = 0x0, y1 = 0x0, x2 = 0x30, y2 = 0x16}, data = 0x0}, clip_region = {
      extents = {x1 = 0x318, y1 = 0x2dd, x2 = 0x31b, y2 = 0x2f3}, data = 0x0}, 
    src_clip = 0x8a85194, has_client_clip = 0x1, transform = 0x0, 
    repeat = 0x0, filter = 0x3, filter_params = 0x0, n_filter_params = 0x0, 
    alpha_map = 0x0, alpha_origin = {x = 0x214, y = 0x19e}, 
    component_alpha = 0x0, read_func = 0x0, write_func = 0x0}, 
  format = 0x18028888, indexed = 0x0, width = 0x30, height = 0x16, 
  bits = 0x87e10c8, free_me = 0x0, rowstride = 0x400}

Comment 26 Mary Ellen Foster 2008-04-25 12:51:24 EDT
NB: it seems to work fine (I'm using qemu with -std-vga) if I remove my
xorg.conf entirely and let things happen automatically. I see the same symptoms
if I leave the generated xorg.conf in place.
Comment 27 Kevin Kofler 2008-04-25 12:58:27 EDT
That's interesting, because QEMU with the default cirrus chip emulation crashes 
the vesa driver (cirrus works, though).
Comment 28 Søren Sandmann Pedersen 2008-04-25 21:47:04 EDT
Ok, so the format in Dave's *pict has bpp 24 and depth 32, which is absurd.
Something is apparently creating images with bogus formats.

Here are some new test packages

http://www.fedorapeople.org/~ssp/pixman-0.10.0-1.bug427383.2.fc9.i386.rpm
http://www.fedorapeople.org/~ssp/pixman-debuginfo-0.10.0-1.bug427383.2.fc9.i386.rpm
http://www.fedorapeople.org/~ssp/pixman-devel-0.10.0-1.bug427383.2.fc9.i386.rpm

with an assert in create_image_bits() that will hopefully point to what's going on.
Comment 29 Kevin Kofler 2008-04-26 11:19:11 EDT
Plasma requests ARGB visuals, so that's what the 32 comes from. Somewhere along 
the line Plasma's request gets turned into something which makes no sense.
Comment 30 Søren Sandmann Pedersen 2008-04-26 17:34:08 EDT
Can you try the packages and see if it crashes in that assert?
Comment 31 Dave Airlie 2008-04-26 18:45:22 EDT
All I see is this... hmm I wonder how we can expose a 32-bit visual on a 24-bpp
display... vesa sets 24bpp, and I can see on the screen some sort of funky 3/4s
images... 

PIXMAN: Unhandled format 18028888 (pict type: 0)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7fae710 (LWP 9018)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x0056c66b in fbStore (pict=Could not find the frame base for "fbStore".
) at pixman-compose.c:165
#2  0x0056d05e in pixman_composite_rect_general_no_accessors (data=Could not
find the frame base for "pixman_composite_rect_general_no_accessors".
)
    at pixman-compose.c:452
#3  0x0056d162 in pixman_composite_rect_general (data=Could not find the frame
base for "pixman_composite_rect_general".
) at pixman-compose.c:483
#4  0x00572326 in pixman_image_composite_rect (op=Could not find the frame base
for "pixman_image_composite_rect".
) at pixman-pict.c:1340
Comment 32 Søren Sandmann Pedersen 2008-04-27 18:04:23 EDT
This message

   PIXMAN: Unhandled format 18028888 (pict type: 0)

is what the first set of packages (from comment 23) printed out. "0x18028888" is
an ARGB format with 24 bits per pixel and 32 bit depth. This is absurd; you
can't have a depth that is bigger than the number of bits per pixel.

If you could you try with the new packages I posted in comment 25, I'd
appreciate it. Those should trigger an assert when someone tries to create such
a format.
Comment 33 Dave Airlie 2008-04-27 20:05:27 EDT
I tried and nothing seemed to happen different...

I can hack around this in the vesa driver 

http://koji.fedoraproject.org/scratch/airlied/task_585186/

contains vesa builds that work for me 

diff -up xf86-video-vesa-20080404/src/vesa.c.makekdework
xf86-video-vesa-20080404/src/vesa.c
--- xf86-video-vesa-20080404/src/vesa.c.makekdework	2008-04-28
09:53:53.000000000 +1000
+++ xf86-video-vesa-20080404/src/vesa.c	2008-04-28 09:53:58.000000000 +1000
@@ -649,8 +649,8 @@ VESAPreInit(ScrnInfoPtr pScrn, int flags
 	flags24 = Support24bppFb;
 
     /* Prefer 24bpp for fb since it potentially allows larger modes. */
-    if (flags24 & Support24bppFb)
-	flags24 |= SupportConvert32to24 | PreferConvert32to24;
+    //if (flags24 & Support24bppFb)
+//	flags24 |= SupportConvert32to24 | PreferConvert32to24;
 
     if (!xf86SetDepthBpp(pScrn, defaultDepth, 0, 0, flags24)) {
         vbeFree(pVesa->pVbe);

Is the patch I used.

Looking at the composite code we always add the 32-bit visual even for 24bpp
screens, so I think either pixman/X is just missing support for this corner case
or KDE is requesting something which is crazy... either way no crashy is the answer.

This is easily testable in the kvm/QEMU with the vesa driver.

Hopefully ajax knows what actually should happen in this case.
Comment 34 Mary Ellen Foster 2008-04-28 06:53:28 EDT
For what it's worth, if I comment out the two "Depth" lines in my
(auto-generated) xorg.conf, KDE starts up just fine. (NB: Running F9 inside qemu
with the Vesa driver.) As previously, running without any xorg.conf at all also
works. This is probably redundant information, I realise ...
Comment 35 Adam Jackson 2008-04-29 13:30:07 EDT
Well, yes, we should add the synthetic visual all the time.  But clearly that
doesn't work so hot.

I propose a twofold solution.  vesa needs to use
SupportConvert32to24|PreferConvert24to32 instead of what it's currently doing,
which will give us 24+32 instead of 24+24 most of the time.  And Composite needs
to not add the synthetic visual for 24+24 screens until we figure out how to
make that not asplode.
Comment 36 Will Woods 2008-04-29 14:53:08 EDT
Thought to be fixed in xorg-x11-drv-vesa-1.3.0-15.20080404.fc9, which has been
tagged for inclusion in tomorrow's rawhide.

Please retest when that shows up on your local mirror.
Comment 37 Kevin Kofler 2008-05-01 08:54:52 EDT
Reported fixed on #fedora-kde:
<SMParrish> Looks like the fixed the VESA driver in X.  Rawhide works in 
virtualbox now

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