Date: Mon, 29 Oct 2007 08:24:16 -0500 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: freebsd-x11@freebsd.org Subject: More 7.3 issues Message-ID: <20071029132416.GA2474@over-yonder.net>
next in thread | raw e-mail | index | archive | help
Upgrading to 7.3 has caused me a number of issues that don't seem to be the same as others I've seen reported. A fair bit of googling with some likely keywords doesn't get me anything either. First, the obligatory system summary. This is an i386 machine, Saturday-vintage -CURRENT, AGP Matrox G450 video card. I don't think -CURRENT is directly to blame, since I ran the old 7.2 Xorg install I had after that upgrade, and it all worked just normal-like. My previous -CURRENT was post-gcc-4.2, but before the current 4.2.1 20070719 variant, though, so the compiler did change. CFLAGS are set to "-O2 -fno-strict-aliasing -fno-tree-vrp -pipe". The first major issue is that certain (rather simple) workloads would just make the server collapse. This was eventually tracked down to everybody's favorite stress-testing application, xclock. Running with -norender worked, but -render [default] would flat-out crash the server. This was eventually worked around, at least in part, by setting 'Option "AccelMethod" "EXA"' in my Device section. This lets xclock run with -render, video playing to work (but see below), and allowed Opera to begin working. However, I can still crash it with other things, like firefox, or pulling up a menu in gcalctool. I'm sure there are other programs I've not yet found that will do it, but will discover as soon as I'm deep in trying to get something done and need them. I've tried various perversions of the X config without making any further progress on this. I tried installing the rendercheck program to see if it said anything. It crashes the server as soon as it gets past "Beginning mask coords test" (via `rendercheck |& tee log`, since the X server crashes right off). Interestingly, it seems to be crashing on SIGILL, which seems a little surprising. My CPUTYPE is set appropriately, so I wouldn't expect a bad instruction to make it through compilation. Perhaps related to this is that switching from X to the console [in my main session; I've been unsuccessful at reproducing it with stripped-down .xinitrc's] also crashes it on SIGILL. This makes it really unpleasant to try testing things :( The second is some oddities in resolution. I've run 1280x1024 on this setup for years. Post-upgrade, I'm totally unable to convince it to _start up_ in 1280x1024; it keeps insisting on starting in 1152x864. xrandr lists up to 1280x1024 though, and I can `xrandr -s` it up to 1280x1024 just fine. Trying to use PreferredMode results in the X server just tight-looping the CPU; I let it run a few minutes to see if it accomplished anything, but it didn't. However, something in the rendering path really wants to be 1152x864. This is visible by playing a video with xine and full-screen'ing it; on doing so, the video [apparently] fills all the resolution, but outside of the upper-left 1152x864 of the screen, it's just solid blue, hiding the bottom and right of the video. I thought this was related to somehow using part of its space for the second head. Unlike every other mga-related issue I've seen with 7.3, I'm NOT trying to run dual-head, but the server insists on acting as if there were something running on the second port and setting a resolution it's allegedly running as. Kinda funny; everybody else is complaining that they want to run multihead and it won't let them, while I'm NOT trying to run multihead and it's forcing me. I jumped through some hoops in the xorg.conf and succeeded in getting it to stop trying to use the second port, but that didn't change anything in regards to the first; still starting in the lower resolution and won't render video larger. The second is at least is merely annoying; watching video is recreational, not necessary, and it doesn't crash out my X session. But the first gets pretty hard in my way (firefox would be one app that I rather need to use all day long, for instance), and will ruin all my context if I happen to run one of the [known, or indeterminate number of as-yet unknown] trigger apps. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071029132416.GA2474>