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.
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.
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.
Could I just get the files I asked you, please?
Coaxing those files out of QEMU running the live CD was a PITA, but I have them now. Attaching...
Created attachment 291682 [details] The xorg.conf file, just the default live CD configuration
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.
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?
Adam is at LCA/Vacation so not likely to respond for a few days yet.
(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.
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.
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.
I'm marking this as F9Blocker because this is simply not going to be acceptable in a release.
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.
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.
(Sorry if I was unclear, QEMU itself doesn't crash, the KDE 4 inside it does.)
dl'ing F9-Preview now.
ugh, can't confirm using qemu. passing xdriver=vesa on kernel command line ends up locking my f9 host machine.
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.
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.
On both my laptop and QEMU, booting the live image directly is enough to reproduce the crash.
*** Bug 443866 has been marked as a duplicate of this bug. ***
#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.
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
"prints" where exactly?
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}
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.
That's interesting, because QEMU with the default cirrus chip emulation crashes the vesa driver (cirrus works, though).
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.
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.
Can you try the packages and see if it crashes in that assert?
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
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.
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.
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 ...
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.
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.
Reported fixed on #fedora-kde: <SMParrish> Looks like the fixed the VESA driver in X. Rawhide works in virtualbox now