Created attachment 533073 [details]
Xorg.0.log

Created attachment 533074 [details]
messages

Created attachment 533075 [details]
rpm -qa output

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 add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* output of the dmesg command, and

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

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

Thanks in advance.

Created attachment 533086 [details]
dmesg with drm.debug=0x04

I have rebooted to a clean F16 RC installation and fully updated it. 3D accel works in there. But it still doesn't work for my F15->F16 upgraded system.

This is the output from glxinfo on the broken system from logged-in user. I found out it differs from root's output:

$ glxinfo | grep -E '(vendor|render)'
direct rendering: Yes
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe

$ ls -la /dev/dri/card*
crw-rw---- 1 root video 226, 0 Nov 11 15:53 /dev/dri/card0

airlied says this is to source of the problem, there should be ACL on that file

There is a suspicion that systemd should set that ACL.

michich found out that systemd-loginctl doesn't list my user session. That is probably caused by /etc/pam.d/system-auth not containing pam_systemd.so. My /etc/pam.d/system-auth is NOT a symlink to /etc/pam.d/system-auth-ac, which seems to be the default in F16. But I believe I did not "un-linked" those two files.

Created attachment 533099 [details]
system-auth

Created attachment 533100 [details]
system-auth-ac

I symlinked system-auth to system-auth-ac. Still no user session listed in systemd-loginctl. Gnome-shell started to work, but still using software rendering  (same output of glxinfo). I had to force fallback mode.

There is now some ACL on /dev/dri/card0, but they seem to be wrong (not contain current user):

$ ls -la /dev/dri/card*
crw-rw----+ 1 root video 226, 0 Nov 11 16:51 /dev/dri/card0
$ getfacl /dev/dri/card*
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card0
# owner: root
# group: video
user::rw-
group::rw-
mask::rw-
other::---

Created attachment 533103 [details]
password-auth

Created attachment 533104 [details]
password-auth-ac

The same problem for /etc/pam.d/password-auth{,-ac} .

After making /etc/pam.d/password-auth symlink to /etc/pam.d/password-auth-ac the whole problem is fixed, hardware acceleration works now.

I have looked into my F15 snapshot and I had password-auth{,-ac} and system-auth{,-ac} "un-linked" even on F15. I don't know how that happened, I didn't do it. But it worked in F15 and broke when upgrading to F15. Is that something authconfig maintainers want to deal with?

The systemd update is supposed to call authconfig that will put the pam_systemd to the system/password-auth-ac and the symlinks.

There was a %post script in the systemd package that did this.

Tomáš,
systemd's scriptlet adjusted Kamil's system-auth-ac as expected.
But for some reason he did not have /etc/pam.d/{system,password}-auth as symlinks, but distinct regular files.

That's weird as 'authconfig --update' or 'authconfig --updateall' that is called from the systemd %post will overwrite the system-auth and password-auth with symlinks. And I verified that this works fine with authconfig on Fedora 16.

OK, so the problem was that on the F15 the symlinks were already broken an the pam_systemd.so was already in system-auth-ac and password-auth-ac. As the systemd package postscript tests for the presence of pam_systemd in system-auth-ac / password-auth-ac it did not call authconfig.

I think the systemd should call authconfig also in case the system-auth and/or password-auth is not symlink. Here is the proposed change of the script snippet:

# Make sure pam_systemd is enabled
if ! /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac || ! [ -h /etc/pam.d/system-auth ] ; then
        /usr/sbin/authconfig --update --nostart >/dev/null 2>&1 || :

        # Try harder
        /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac || /usr/sbin/authconfig --updateall --nostart >/dev/null 2>&1 || :
fi

Is this still an issue on a fully updated release or can this bug be closed?

This still might be issue for anyone upgrading from F15 to F16. And probably even for future releases. So I would say this is generic problem and Tomas's suggestion from comment 22 should be applied. Re-assigning to Rawhide.

But this post script should be already in the current systemd packages if I am not mistaken.

It is 

# Make sure pam_systemd is enabled
if ! /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac >/dev/null 2>&1 || ! [ -h /etc/pam.d/system-auth ] ; then
        /usr/sbin/authconfig --update --nostart >/dev/null 2>&1 || :

        # Try harder
        /bin/grep -q pam_systemd /etc/pam.d/system-auth-ac >/dev/null 2>&1 || /usr/sbin/authconfig --updateall --nostart >/dev/null 2>&1 || :
fi

It got added [1] but this bug was never closed so I was not sure if it still was a problem or not...

1.Tue Nov 15 2011 Michal Schmidt <mschmidt> - 37-4
Run authconfig if /etc/pam.d/system-auth is not a symlink.
Resolves: #753160

I'm closing this as current release since it simply looks like this bug fell through the routine update process thus never was closed.

Just reopen it if it's still an issue.

Thanks