Bug 909473 - llvmpipe on x86 requires SSE2
Summary: llvmpipe on x86 requires SSE2
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker AcceptedFreezeExcepti...
: 919743 (view as bug list)
Depends On:
Blocks: F19Alpha-accepted, F19AlphaFreezeException F19Beta, F19BetaBlocker
TreeView+ depends on / blocked
Reported: 2013-02-08 21:06 UTC by Bruno Wolff III
Modified: 2013-06-09 05:41 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-04-19 05:46:07 UTC
Type: Bug
awilliam: fedora_requires_release_note+

Attachments (Terms of Use)
strace output (42.96 KB, text/plain)
2013-04-02 19:35 UTC, Bruno Wolff III
no flags Details
glxinfo output (19.37 KB, text/plain)
2013-04-03 14:52 UTC, Bruno Wolff III
no flags Details
blacklist output (773 bytes, text/plain)
2013-04-03 14:55 UTC, Bruno Wolff III
no flags Details
cpuinfo (1.03 KB, text/plain)
2013-04-03 14:58 UTC, Bruno Wolff III
no flags Details
glxinfo from pentium M machine (8.76 KB, text/plain)
2013-04-12 22:24 UTC, Bruno Wolff III
no flags Details
cpuinfo for pentium M machine (539 bytes, text/plain)
2013-04-12 22:26 UTC, Bruno Wolff III
no flags Details
is-accel.t from pentium M machine (33.34 KB, text/plain)
2013-04-12 22:28 UTC, Bruno Wolff III
no flags Details
hardware-compatibility from pentium M machine (773 bytes, text/plain)
2013-04-12 22:30 UTC, Bruno Wolff III
no flags Details

Description Bruno Wolff III 2013-02-08 21:06:45 UTC
Description of problem:
After I login with gdm, I get a notice covering the lower half of my screen with the Oh no somethings gone wrong notice. This started with 3.7.5 and had been working with 3.7.4.

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

How reproducible:
Happens all of the time.

Additional info:
I have a radeon 9200 (based on an rv280).
I have forced fallback mode set, so I am probably getting a different window manager now.

Comment 1 Bruno Wolff III 2013-02-09 00:10:50 UTC
I turned off forced fallback (in both gdm and gnome) and see the same behavior.
I had gdm using forced fallback, because there was a period when gdm was failing and using gdm-fallback worked around the problem.

Comment 2 Bruno Wolff III 2013-02-23 23:02:40 UTC
I am now seeing the fail whale message instead of a background image with gdm (now at gdm-3.7.90-1.fc19.i686). However gdm still works and I can use it to login to xfce.

Comment 3 Bruno Wolff III 2013-02-24 15:05:20 UTC
r200 based cards are blacklisted. I tried removing the blacklist entry, but things failed harder (I no longer saw the login window). It looks like there is supposed to be a fallback to llvmpipe, but that doesn't appear to work correctly.

Comment 4 Bruno Wolff III 2013-03-09 19:59:03 UTC
The fail whale page is showing up in gdm again, except now I can't login. I am using kdm as a work around now to do graphical logins.

Comment 5 Adam Williamson 2013-03-13 17:50:42 UTC
*** Bug 919743 has been marked as a duplicate of this bug. ***

Comment 6 Adam Williamson 2013-03-13 17:57:19 UTC
CCing ajax for his expert input here.

So really the bug here is that when your mesa driver is blacklisted, llvmpipe should be used as a fallback to do software rendering of GDM and Shell, but it isn't. ajax writes:

"it's somewhat icky to fix. libGL has a wart where it doesn't cope like you'd hope if you suddenly set LIBGL_ALWAYS_SOFTWARE=1 while your process is running. so you kinda need to run session-check-is-accelerated-helper-helper-helper twice, once with and without, and pass knowledge of which one succeeded back up the chain"

so I assign it to gnome-session.

Discussed at 2013-03-13 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-13/f19alpha-blocker-review-1.2013-03-13-17.02.log.txt . Whether this is a blocker is a judgement call based on how much hardware is affected. The amount of blacklisted hardware likely still to be in use is relatively small, so we decided it's appropriate to make it a Beta blocker, and a freeze exception for Alpha. The criterion is "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied" (current criteria) or "After firstboot is completed and on subsequent boots, a graphical install must boot to a log in screen where it is possible to log in to a working desktop as the user created during firstboot." (adamw's pending rewrite).

Comment 7 Adam Williamson 2013-03-13 17:58:21 UTC
The reason this becomes more urgent in F19 is that GNOME 3.8 drops the non-accelerated 'fallback' sessions for GDM and GNOME.

Comment 8 Bruno Wolff III 2013-03-27 19:08:58 UTC
If you see this you can use the following work around.

CA-F2 to get a vt.

Login as root.

Install kdm if it is not already installed (yum install -y kdm).

Stop gdm. This may switch which vt is showing on the console.
systemctl stop gdm

Start kdm. This may leave a root session open on the vt which you'll wan to close.

systemctl start kdm

Make the change persist.
systemctl disable gdm
systemctl enable kdm

Then switch back to kdm. Usually it we be on 1, but if not try others.

Comment 9 Bruno Wolff III 2013-03-27 19:12:14 UTC
Another note about the work around. This won't let you use gnome. You will need to choose some other desktop in kdm before logging in. If you don't have any already installed you can use yum groupinstall xfce-desktop to install xfce.

Comment 10 Bruno Wolff III 2013-03-27 19:44:39 UTC
I tried this with gnome-session-3.8.0-1.fc20.i686 and got:
Mar 27 14:31:43 bruno gdm[2262]: GLib: g_variant_compare: assertion `!g_variant_is_container (a)' failed
Mar 27 14:31:43 bruno gdm[2262]: GLib: g_variant_compare: assertion `!g_variant_is_container (a)' failed
Mar 27 14:31:47 bruno /usr/bin/dbus-launch[2380]: gnome-session-is-accelerated: No hardware 3D support.
Mar 27 14:31:47 bruno /usr/bin/dbus-launch[2380]: gnome-session-check-accelerated: Helper exited with code 256
Mar 27 14:31:53 bruno /usr/bin/dbus-launch[2380]: gnome-session-is-accelerated: No hardware 3D support.
Mar 27 14:31:54 bruno /usr/bin/dbus-launch[2380]: gnome-session-check-accelerated: Helper exited with code 256
Mar 27 14:31:54 bruno /usr/bin/dbus-launch[2380]: ** (process:2380): WARNING **: software acceleration check failed: Child process exited with code 1
Mar 27 14:32:19 bruno systemd[1]: Stopping GNOME Display Manager...
Mar 27 14:32:19 bruno systemd-logind[992]: Removed session c1.
Mar 27 14:32:19 bruno gdm[2262]: GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed
Mar 27 14:32:19 bruno gdm[2262]: GLib-GObject: g_object_unref: assertion `object->ref_count > 0' failed
Mar 27 14:32:19 bruno systemd[1]: Stopped GNOME Display Manager.

Comment 11 Adam Jackson 2013-04-02 17:17:13 UTC
(In reply to comment #10)

> gnome-session-check-accelerated: Helper exited with code 256

Seeing this twice is pretty weird.  Please attach the output (is-accel.t) from running:

$ LIBGL_ALWAYS_SOFTWARE=1 strace -o is-accel.t /usr/libexec/gnome-session-check-accelerated-helper

Comment 12 Bruno Wolff III 2013-04-02 19:35:54 UTC
Created attachment 730940 [details]
strace output

Comment 13 Adam Jackson 2013-04-03 12:50:40 UTC
(In reply to comment #12)
> Created attachment 730940 [details]
> strace output

The part where the failure kicks in is:

open("/usr/share/gnome-session/hardware-compatibility", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=773, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77f4000
read(4, "##\n## This file contains a list "..., 4096) = 773
close(4)                                = 0
munmap(0xb77f4000, 4096)                = 0

After that we go start tearing everything down, so it _appears_ that you're hitting the renderer blacklist.  That could happen if the llvm part of llvmpipe failed to init (in which case it would claim to be softpipe), or if the blacklist file doesn't contain what we think it contains.

Please attach the output from 'LIBGL_ALWAYS_SOFTWARE=1 glxinfo', and /usr/share/gnome-session/hardware-compatibility and /proc/cpuinfo from the affected machine.

Comment 14 Bruno Wolff III 2013-04-03 14:52:10 UTC
Created attachment 731210 [details]
glxinfo output

Comment 15 Bruno Wolff III 2013-04-03 14:55:25 UTC
Created attachment 731212 [details]
blacklist output

Comment 16 Bruno Wolff III 2013-04-03 14:58:24 UTC
Created attachment 731213 [details]

Comment 17 Adam Jackson 2013-04-03 16:43:42 UTC
There we go:

(In reply to comment #14)
> Created attachment 731210 [details]
> glxinfo output

OpenGL renderer string: Gallium 0.4 on softpipe

(In reply to comment #16)
> Created attachment 731213 [details]
> cpuinfo

flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow

llvmpipe requires SSE2 at the moment, so, that's unfortunate.  I'm not sure whether that's justified; I'll bring up a 32-bit vm and mask off sse2+ and see if I can get things going.  I'll also try to find a 3dnow-but-not-sse2 machine and see whether there's any performance increase to be had from using 3dnow.

Comment 18 Adam Jackson 2013-04-04 21:22:33 UTC
(In reply to comment #17)

> llvmpipe requires SSE2 at the moment, so, that's unfortunate.  I'm not sure
> whether that's justified; I'll bring up a 32-bit vm and mask off sse2+ and
> see if I can get things going.

Seems to work for me on an Athlon XP 2600+, which is approximately as featureful as what you've got.  New Mesa build with the fix to follow shortly.

Comment 19 Bruno Wolff III 2013-04-04 21:28:02 UTC
I'm going out tonight so I'll either test it pretty late tonight or tomorrow morning. I'll also test it on a pentium M laptop that I think has roughly the same issue.

Comment 20 Bruno Wolff III 2013-04-05 05:54:19 UTC
I tested mesa-9.1-5.fc20 a little tonight and I get a functioning (if slow) gnome shell desktop working. I only tried this on the rv280 machine. Tomorrow I'll look at the intel machine and try out gdm on both.

Comment 21 Bruno Wolff III 2013-04-05 14:36:02 UTC
I did some more testing on the rawhide / Althon / rv280 system. I had a crash in gnome-classic. gdm only sort of works. When the background image showed I couldn't see the login menu except very briefly if I clicked with the mouse in the right place. When the background image didn't show (which is more likely a gdm issue) then I could see and use the login menu. There was also odd color stuff that may or may not be the driver. Things would mostly be grayscale (except for the background image) but occasionally clicking on things (such as scroll bars) would get an object to be colored (usually a blue). That may be just the look though. I haven't been able to use gnome for a while and was using fallback when I did. gnome and gnome classic were hard to use because of slow response, but that is probably expected given the cpu is being used for graphics. I also saw a problem logging into xfce from gdm. I eventually gave up and stopped gdm, started kdm and logged in. Logging into gnome from kdm worked better and gnome seemed to have less issues (like having more color) when I did it that way. I did see the fail whale page once logging into gnome, but there might have been a mix of xfce and gnome stuff running at the time.

I'll try to get some testing of f19 / pentium M laptop today, but I need to do some other stuff first.

Comment 22 Bruno Wolff III 2013-04-06 15:38:28 UTC
So I found some partial answer on why testing gdm was hard. gnome-initial-setup is running. The graphics for it aren't really usable on my athlon system, but it does reasonable on the pentium M laptop. Once I figure out how to not trigger gnome-initial-setup when using gdm instead of kdm, I'll try it again.
gnome-classic looks OK on the pentium M machine. gnome logins result in the fail whale page, but I can't easily tell if this is from graphics or something else.

Comment 23 Fedora Update System 2013-04-11 17:39:08 UTC
xorg-x11-drv-ati-7.1.0-4.20130408git6e74aacc5.fc19, mesa-9.1-6.fc19, xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19 has been submitted as an update for Fedora 19.

Comment 24 Fedora Update System 2013-04-12 15:17:17 UTC
Package mesa-9.1-6.fc19, xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19, xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mesa-9.1-6.fc19 xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19 xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 25 Ray Strode [halfline] 2013-04-12 19:15:44 UTC
sudo rm -f /var/lib/gdm/run-initial-setup should stop initial-setup from running

Comment 26 Adam Williamson 2013-04-12 20:03:47 UTC
can we get some testing on the update so it can potentially be in the next alpha build? Thanks!

Comment 27 Bruno Wolff III 2013-04-12 22:08:27 UTC
On current (synced this morning) rawhide on the Athlon MP with ATI 9200 (rv280) machine gdm is mostly gray scale with one button turning blue at some point. After authenticating X eventually stops before I get a graphics session (neither Gnome nor XFCE worked) and the console output is displayed again.

On f19 + updates-testing (synced this afternoon) on a Pentium M with motherboard video I can now use gdm to login to gnome-classic. I didn't do testing in gnome-classic once I got the desktop displayed. Redraws were not happening in gdm properly. The background was initially console output. When I used menus, the menu display didn't go away when it should. The color looked normal. I also got the old gdm display rather than the new one. When I tried to login to a gnome session I got the fail whale page. But logging into gnome-classic got me a normal looking desktop.

So while this is better than it was, I wouldn't recommend pulling it just for this fix. On the other hand it didn't seem to make things worse for KDM + XFCE.

Comment 28 Bruno Wolff III 2013-04-12 22:24:54 UTC
Created attachment 735017 [details]
glxinfo from pentium M machine

Comment 29 Bruno Wolff III 2013-04-12 22:26:16 UTC
Created attachment 735018 [details]
cpuinfo for pentium  M machine

Comment 30 Bruno Wolff III 2013-04-12 22:28:03 UTC
Created attachment 735020 [details]
is-accel.t from pentium M machine

Comment 31 Bruno Wolff III 2013-04-12 22:30:17 UTC
Created attachment 735021 [details]
hardware-compatibility from pentium M machine

Comment 32 Adam Jackson 2013-04-15 16:02:41 UTC
(In reply to comment #26)
> can we get some testing on the update so it can potentially be in the next
> alpha build? Thanks!

The testing I did in comment #12 was against Xvnc on a non-SSE2 machine.  It's probably worth testing the Xvnc and Xorg paths separately here though.

Comment 33 Fedora Update System 2013-04-19 05:46:11 UTC
mesa-9.1-6.fc19, xorg-x11-glamor-0.5.0-5.20130401git81aadb8.fc19, xorg-x11-drv-ati-7.1.0-5.20130408git6e74aacc5.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 34 Adam Williamson 2013-04-19 22:32:46 UTC
ajax: given Bruno's feedback in c#27, should we re-open this? Or ask him to file a new one?

Comment 35 Alex Villacís Lasso 2013-05-21 17:01:46 UTC
Related: https://bugzilla.redhat.com/show_bug.cgi?id=917726 for Fedora 18.

Comment 36 Adam Williamson 2013-05-27 07:56:24 UTC
Bruno: at a QA meeting a couple of weeks back you said you'd check this again with Beta, did you do so? Is it working better now? Thanks!

Comment 37 Adam Williamson 2013-05-28 00:22:13 UTC
I tried to test this in a VM but the virt-manager CPU feature configuration stuff seems kinda screwed ATM so I couldn't get it to fly...

Comment 38 Bruno Wolff III 2013-05-28 04:30:02 UTC
Tonight I check this is rawhide (as that's what my machine with the ATI 9200 runs) and both gdm and gnome failed with the Oh No! screens. kdm and xfce work fine. About a week ago I had tried the intel machine with a live games image and it seemed to work OK.

Comment 39 Adam Williamson 2013-05-28 23:53:20 UTC
can you test it with an F19 Beta live image? rawhide is somewhat diverged from F19 at this point, so it would be more useful. thanks!

Comment 40 Bruno Wolff III 2013-05-30 02:52:36 UTC
I tested this with Fedora-Live-Desktop-i686-19-Beta-1.iso on a DVD (can't boot with USB on this machine). In less than a second after clicking on try Fedora I got the Oh no somethings gone wrong screen.

I doubt this is affecting enough people on final to make it a blocker. Probably gnome will be too slow anyway. A common bug or something suggesting xfce is probably a good enough solution.

Comment 41 Adam Williamson 2013-06-04 01:33:44 UTC
Marking as requiring a release note: docs team, the release note here should be broadly what Bruno said in comment #40. If you have a system with a CPU old enough that it doesn't have SSE2 extensions (so, I think, pre-Pentium 4 or pre-Athlon 64) and a graphics card old enough that it is not capable of hardware accelerating Shell (so, Intel older than 9xx, Radeon older than R300 (Radeon 9500), NVIDIA older than NV30 (GeForce FX5xxx)), then you're very likely not to be able to get a working Shell at all. And as Bruno points out, even if it worked, the experience would probably be a bit painful. So we recommend you use another desktop instead; KDE is the most strongly supported, Xfce or MATE would be closest to the GNOME 2 / GNOME 3.6 "fallback" environment.

Comment 42 Pete Travis 2013-06-09 05:41:12 UTC
I've added a note to the Hardware Overview section of the release notes. Thanks Adam!

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