| Summary: | garbled screen contents for LibreOffice on Geode LX800 using xf86-video-geode 2.11.14 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Ada <xf86radeon.20.Tux_friend> | ||||||
| Component: | Driver/geode | Assignee: | X.org Geode Mailing List <xorg-driver-geode> | ||||||
| Status: | RESOLVED MOVED | QA Contact: | X.org Geode Mailing List <xorg-driver-geode> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | unspecified | ||||||||
| Hardware: | x86 (IA32) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
First the random notes as answers to your comments, not really relating to this bug: KMS is available in prototype form on top of an old kernel somewhere, but you can't run Xorg on top of that (and I'm not sure anyone has tried it besides the author as of yet). I'm not sure if all your -fno* stuff in CFLAGS aren't really counterproductive to your intent, but that's that, up to you, shouldn't cause the rendering corruption. First off, perhaps you could at the very least capture a screenshot with the corruption. Often your typical screenshotting tools (e.g imagemagick import or the print screen utils of desktop envs) are able to capture such rendering corruptions? Secondly, I don't think I would be able to get LibreOffice on my already rather out of date Geode (gentoo) system anytime soon, so a cairo-trace of this would be useful - if the rendering corruption is drawn via cairo (nothing to blame on cairo; just then we can capture the drawing commands to reproduce without LO). Launching LO with something like "cairo-trace lowriter", doing the minimum to reproduce the corruption and exiting; then if compressing the resulting trace file is small enough to attach here, it might be useful, as we can replay the drawing commands without LibreOffice then. Keep in mind that anything drawn by the application via captureable methods would also be seen in trace replay, so no secret documents please :) Other than that, it would be useful to check with 16bit depth - iirc the default, you set to 24bit in your config, which is then less tested. Also, does the corruption go away if you disable any hardware acceleration by turning "NoAccel" to True? What are you trying to achieve with the ExaScratch option? I'm not sure such an option exists in the first place, but if it does, it might be doing something bad there. I try to do the suggested ASAP but I am out of state during Fri/Sat/Sun/Mon. On the CFLAGS: I used the ones that were given in the Gentoo wiki and thought to be "safe". If neccessary I can recompile involved libs and programs with something generic like march=i585 and -O1. It would take a weekend however since it is a productive system. screenshot I hope I can capture that corruption with a screenshot. Also 16bpp should be a quickly tested thing. Furthermore I can delete the ExaScratch option from xorg.conf and check the results. (I think I took this from the VIA CN700/CLE266 openchrome config that I used.) The cairo render trace might need some more time then. (In reply to comment #3) > I try to do the suggested ASAP but I am out of state during Fri/Sat/Sun/Mon. > > On the CFLAGS: > I used the ones that were given in the Gentoo wiki and thought to be "safe". > If neccessary I can recompile involved libs and programs with something > generic like march=i585 and -O1. > It would take a weekend however since it is a productive system. No, you don't need to change them for this bug. They don't affect the corruption almost surely, and if it did, we should fix it anyway (but I'm 99.99999% sure they wouldn't affect). It was just a general wondering as a Gentoo user/developer myself. Sorry it took so long but I got back with a nasty cold. I took out ExaScratch from xorg.conf and took screenshots after a fresh boot. 16 bpp still needs to be done, so does any cairo tracing. No recompiles or updates yet. Screenshots are here (sorry for the nasty compression). http://s24.postimg.org/70gdlum79/geode_bug_70730_attach01.jpg http://s21.postimg.org/z4sjauy5z/geode_bug_70730_attach02.jpg Here is a rarer occasion with non black boxes but still messy and after scrolling back up. http://s10.postimg.org/8haellmll/geode_bug_70730_attach03.jpg There are more screen captures if needed. 16 bpp looks exactly the same, otherwise same configuration. The black bar changes a bit when you scroll further up/down or alt-tab and alt-tab back, so the window is redrawn. Created attachment 89603 [details]
cairo_trace_logs
Sorry for the delay, I got horrbily suck and stressed at work at the same time. So I tried to take a cairo-trace yesterday. I started (as user) with cairo-trace lowriter and gave lowriter the file location to open. With or without file given, however, lowriter was started (splash) and even opened the file (or not if none was given) but immediately went down just right after finishing to load an be there for user input. There is a trace log but that won't include any scrolling. In dmesg I found [ 372.829957] soffice.bin[2011]: segfault at ac15d9dc ip b4cdde5b sp bfd09420 error 4 in libbfd-2.23.1.so[b4c99000+d0000] Ouch. Starting lowriter alone (no cairotrace) from xterm worked without a flaw (besides later the corruption when scrolling down). (So as far as I found out (equery belongs didn't tell me) this libbfd belongs to binutils? Maybe I should recompile these with "failsafest" possible CFLAGS?) I also did emerge --info / eix on x11-libs/cairo x11-libs/cairo-1.12.14-r4 was built with the following: USE="X glib opengl openvg svg xcb (-aqua) -debug -directfb -doc (-drm) (-gallium) (-gles2) -legacy-drivers (-qt4) -static-libs -valgrind -xlib-xcb" Does any of the use flags interfere? I guess the chip is not capable of actually doing neither opengl nor openvg. Should I try to rebuild without them? Next I tried running cairo-trace as root, and that went slightly better. LO started and I could type and scroll (plain start w. empty sheet). 2 logs were created (after it seemed to start and immerdiately crash but instantly restart again): cairo-trace: Recording cairo trace data to //soffice.bin.2355.trace (short, proably from the insta-crash session) cairo-trace: Recording cairo trace data to //soffice.bin.2363.trace (600 K of log data) I'll attach them here. So I tried the same with my example file but got the segfaults of libbfd again, leaving a 52K trace file each try. It did not start up again then, just crashed instantly. (B.t.w. after that crash even xterm suddenly segfaulted when it Shift-PgUped. Does not happen normally.) Any suggestions about the cairo-trace how to do it without segfaults? Hello I updated parts of the system. Still the same problem with lo writer. I found the time to do a cairo-trace, should be a good one this time. version info app-office/libreoffice-bin-4.1.4.2 (no self compiled LibO this time here for better reproducability) x11-libs/cairo 1.12.14-r4 x11-drivers/xf86-video-geode-2.11.15 kernel is 3.12.6 (gentoo) kernel command line ist just root=/dev/sda3 8250.nr_uarts=2 net.ifnames=0 no framebuffer console used, just plain text mode geode is in xorg.conf without any specific options, just to make sure xf86-video-geode is used instead of vesa Everything else seems to work fine. Libreoffice writer works fine with VESA driver. Attached is a hopefully good trace log, just starting writer, loading a file, scrolling up and down, clicking and marking text w. cursors and exit. Created attachment 94595 [details]
better trace log(s) without segfaults
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-geode/issues/5. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
This is not my first bugreport ever but probably my first on an X.org related project. Furthermore I am a user and chemist (I try to hack molecules not code ;) ) so please bear with me. libs and progs used: xf86-video-geode-2.11.14-r1 / 2.11.14 current main xorg-server package on my system is 1.13.4 Kernel different versions, between 3.9.x and 3.11.x (gentoo-sources, this should be basially a vanilla kernel with minimum patching) graphical console on or off doesn't seem to influence my problem problem: Libreoffice (v 4.x.x) Writer gets garbled screen output when scrolling down. (and scrolling back up again brings same result) It seems only to affect writer not the other parts of LibO. Mainly it is black, a few times coloured. Actual content is unreadable. Other programs e.g. okular, kwrite pdf reader work fine, even things like zsnes do (yes, it actually run... ehm, walks on the geode). It might be related to writer itself but switching 2d accel on and off did not really seem to help, it was consistent through 4.x.x versions of LibO that I tried and it does not happen with xf86-video-vesa instead of xf86-video-geode. So I was tempted to blame it on the geode driver. :) Since it is gentoo I have to admit that everything is compiled (or compiled using chroot on the CF card in my big AMD quad core). (at least for packages that support custom cflags) CXX/CFLAGS="-march=geode -Os -mmmx -m3dnow -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer" xf86-video-geode is built without ztv support. # excerpt from xorg.conf Section "Module" Load "dri" # probably doesn't really help that much, but I took the base config from an old VIA C3 machine End Section ... Driver "geode" Option "NoAccel" "false" Option "AccelMEthod" "EXA" # Option "NoCompression" "false" Option "SWCursor" "false" # Option "ExaScratch" "8388608" # ex 16777216 Option "ExaScratch" "16777216" # both sizes didn't really show difference Screen Section has DefaultDepth 24 Should I try with XAA or no accel at all (would be sad)? In the BIOS I set 16 MB for the GPU. other conditions: 24bpp at 1024x786 60Hz (an old iiyama TFT) attached to a FSC/FTC Futro A2xx (nice little device) bearing a TECO TR2350 with the latest BIOS I could obtain (Jun, 15th 2006 ?). Featuring Geode LX800 (500 MHz) incl. its companion graphics. Fam 5 Mdl 10 step 2 flags: fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow 00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 31) 00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video (if you need lspci -vv tell me) XFCE4 DE (meta package is v 4.10). (I could also try e17 since it is installed on that box also. Plus I pulled in some of my favourite kde apps.) Everything else seems to work nicely, or at least I did not discover problems yet. qt-core is 4.8.4-r5 (was lower some days ago, but iirc. LibO is gtk based), gtk+:2 is 2.24.17 gtk+:3 is 3.4.4 (might have seen updates inbetween but problem was always the same) cairo is 1.12.14-r4. If you need more config settings etc. just tell me and I'll try to find them. :) If you tell me how to dump portions of memory with standard tools during runtime I can try that also. I also missed something like man geode with a summary of geode xorg.conf options. I think one can find it somewhere as a .bz2 file but it would be more convenient to have a "man geode" than searching your directory structure on the root fs for some hints. If KMS is possible with this cute little chip it would be awesome. I think I saw it somewhere on the roadmap. (I know you are probably limited on time/manpower. And AMD officials probably care more for their recent chips and APUs at the moment (which I can also understand).)