So I'm NOT the only one?  I get this too, and I'm using 2.6.31.5-127.fc12.x86_64 with the default radeon driver.  The oops appears word for word on mine, except substitute "Tainted" for "Not tainted."  It happened seven times in the span of a second.  Not really sure if it's possible to reproduce, but I'll try doing what I did around the time of the crash and play with desktop options/background.

This is what the stuff above the oops itself says for me, by the way:

WARNING: at lib/list_debug.c:30__list_add+0x68/0x81() (Not tainted)
Hardware name: Satellite A215
list_add corruption. prev->next should be next (ffff880072fdcda0), but was
ffff88004fc13330. (prev=ffff8800285d4d30).
Modules linked in: fuse sunrpc ipt_LOG xt_comment iptable_mangle ip6t_REJECT
nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath uinput snd_hda_codec_realtek arc4 ecb snd_hda_intel snd_hda_codec snd_seq ath5k mac80211 ath sdhci_pci sdhci uvcvideo cfg80211 snd_usb_audio snd_usb_lib videodev amd64_edac_mod firewire_ohci v4l1_compat snd_pcm snd_rawmidi rfkill mmc_core v4l2_compat_ioctl32 snd_seq_device edac_core joydev ricoh_mmc firewire_core snd_hwdep snd_timer i2c_piix4 shpchp k8temp snd r8169 crc_itu_t soundcore snd_page_alloc mii cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt ata_generic video pata_acpi output pata_atiixp radeon ttm drm_kms_helper drm i2c_algo_bit irc_core [last unloaded: scsi_wait_scan]

I did not see this error happening to me for a while any more. Mical1884: do you still get those? If not, I think we can close this one..

Still happens here with 2.6.31.6-157.fc12.x86_64.

This is currently the 2nd most common bug found by kerneloops.org:
http://www.kerneloops.org/oops.php?number=664510

Reassigning to xorg-x11-drv-ati for Dave Airlie to look at.

*** Bug 537181 has been marked as a duplicate of this bug. ***

*** Bug 540200 has been marked as a duplicate of this bug. ***

Fix for that is in the big bo patch, to sumup we need to protect bo->list access with a mutex. Given the size of the patch i don't think it's ok to add it to F12. Will talk with Dave to see what we should do.

What's the word here?  Just had another crash today...

(In reply to comment #7)
> Fix for that is in the big bo patch, to sumup we need to protect bo->list
> access with a mutex. Given the size of the patch i don't think it's ok to add
> it to F12. Will talk with Dave to see what we should do.  

Where is the big bo patch? posting a reference, etc might be good.

(In reply to comment #1)
> So I'm NOT the only one?  I get this too, and I'm using
> 2.6.31.5-127.fc12.x86_64 with the default radeon driver.  The oops appears word
> for word on mine, except substitute "Tainted" for "Not tainted." ....

The first time an oops happens the kernel is "Not Tainted", but an oops taints the kernel, so the 2nd/3rd/4th will shows it as Tainted.

The oops seems to corrupt something in the kernel and make my system crash on suspend.

I'm seeing the oops as well, on kernel-2.6.31.6-166.fc12.x86_64.  It has no immediate effect; even suspend-to-RAM appears to be still working.  I'm just feeling very uneasy about its effects on system stability.

I guess the big bo patch is http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4c7886791264f03428d5424befb1b96f08fc90f4

Please test kernel you can download from:
http://koji.fedoraproject.org/koji/buildinfo?buildID=150696

It shouldn't be affected by this issue. Report if it works.

(In reply to comment #11)
> Please test kernel you can download from:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=150696
> 
> It shouldn't be affected by this issue. Report if it works.    

The upgrade is completely shit, and completely crippled my system as far as X is concerned - the x server segfault on start with the ati/redeon driver. I have to switch to use radeonhd (with nomodeset) now, as drv-ati no longer works at all, whether one reboot to the older kernel or use the new one.

The new kernel requires a new dracut, which in turns requires new plymouth and new libdrm, so in the end I had to install these
libdrm-2.4.17-1
plymouth-0.8.0-0.2009.29.09.19.1.fc12
dracut-003-2.fc12

After these, rebooting to the new kernel causes X to segfault on startx; rebooting to the older kernel also cause X to segfault; so likely libdrm is fucked; I then tried upgrading mesa* to 7.7-2.fc12, this does not help. I then thought of starting the vesa driver, which works, hence I current radeonhd usage.

I looked at David Airlie's recent activity and that's why I put mesa* on - 
http://koji.fedoraproject.org/koji/userinfo?userID=471
as I am up to date with xorg-x11-drv-ati, and I should have every relevant fc12 pieces built by David Airlie . 

In any case, drv-ati on my system is currently completely fucked.

This should be fixed in kernel 2.6.32.3-24.fc12 from koji. (the original bug)

not sure why you got wrong, try grabbing all of updates-testing maybe including the X server.

 if that doesn't work please but all the version of -ati/libdrm/mesa/xorg-x11-server in here.

*** Bug 546414 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> This should be fixed in kernel 2.6.32.3-24.fc12 from koji. (the original bug)
> 
> not sure why you got wrong, try grabbing all of updates-testing maybe including
> the X server.
> 
>  if that doesn't work please but all the version of
> -ati/libdrm/mesa/xorg-x11-server in here.    

I already mentioned all versions - my system is up to date + those mentioned, so they are:

The most recent installs:
mesa-libGLU-devel-7.7-2.fc12                  Thu 14 Jan 2010 06:54:05 GMT
mesa-libGL-devel-7.7-2.fc12                   Thu 14 Jan 2010 06:53:59 GMT
mesa-libGLU-7.7-2.fc12                        Thu 14 Jan 2010 06:53:55 GMT
mesa-libGL-7.7-2.fc12                         Thu 14 Jan 2010 06:53:52 GMT
mesa-libGLU-devel-7.7-2.fc12                  Thu 14 Jan 2010 06:53:49 GMT
mesa-libGL-devel-7.7-2.fc12                   Thu 14 Jan 2010 06:53:39 GMT
mesa-dri-drivers-7.7-2.fc12                   Thu 14 Jan 2010 06:53:27 GMT
mesa-libGLU-7.7-2.fc12                        Thu 14 Jan 2010 06:53:23 GMT
mesa-libGL-7.7-2.fc12                         Thu 14 Jan 2010 06:52:36 GMT
mesa-dri-drivers-7.7-2.fc12                   Thu 14 Jan 2010 06:52:30 GMT
kernel-headers-2.6.32.3-24.fc12               Thu 14 Jan 2010 04:03:11 GMT
kernel-devel-2.6.32.3-24.fc12                 Thu 14 Jan 2010 03:47:20 GMT
kernel-2.6.32.3-24.fc12                       Thu 14 Jan 2010 03:41:38 GMT
perf-2.6.32.3-24.fc12                         Thu 14 Jan 2010 03:40:50 GMT
kernel-doc-2.6.32.3-24.fc12                   Thu 14 Jan 2010 03:38:13 GMT
kernel-firmware-2.6.32.3-24.fc12              Thu 14 Jan 2010 03:36:14 GMT
libdrm-devel-2.4.17-1.fc12                    Thu 14 Jan 2010 03:22:49 GMT
libdrm-2.4.17-1.fc12                          Thu 14 Jan 2010 03:22:45 GMT
libdrm-devel-2.4.17-1.fc12                    Thu 14 Jan 2010 03:22:43 GMT
dracut-003-2.fc12                             Thu 14 Jan 2010 03:22:33 GMT
plymouth-gdm-hooks-0.8.0-0.2009.29.09.19.1.fc12 Thu 14 Jan 2010 03:22:30 GMT
plymouth-utils-0.8.0-0.2009.29.09.19.1.fc12   Thu 14 Jan 2010 03:22:27 GMT
plymouth-0.8.0-0.2009.29.09.19.1.fc12         Thu 14 Jan 2010 03:22:23 GMT
libdrm-2.4.17-1.fc12                          Thu 14 Jan 2010 03:19:04 GMT

# rpm -q xorg-x11-server-Xorg
xorg-x11-server-Xorg-1.7.4-1.fc12.x86_64
# rpm -q xorg-x11-drv-ati
xorg-x11-drv-ati-6.13.0-0.19.20091221git4b05c47ac.fc12.x86_64

So the only things not up-to-latest and grestest on koji is really
1.7.4-1 -> 1.7.4-3 for the x-server or if you are running mesa 7.8 from fc13, really.

I see xserver 1.7.4-2 has a 'Build with -z relro' entry... that looks like it might affect shared-library loading; I 'll give that a try, but other than that, the only remaining candidate is just mesa 7.8 .

Sorry i didn't expected that new libdrm would be needed:
yum --enablerepo=updates-testing install xorg-x11-drv-ati xorg-x11-server-Xorg libdrm
Which should install 
xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12
and the proper libdrm to no segfault

Note that libdrm-2.4.17-1.fc12 has gone missing from updates-testing for some reason ?

(In reply to comment #16)
> Sorry i didn't expected that new libdrm would be needed:
> yum --enablerepo=updates-testing install xorg-x11-drv-ati xorg-x11-server-Xorg
> libdrm
> Which should install 
> xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12
> and the proper libdrm to no segfault    

My system is still completely fucked, after 
yum --enablerepo=updates-testing upgrade kernel\* xorg-x11-\* libdrm\* mesa\*

This upgrade the xserver stuff to 1.7.4-4 and others - here is the additional installs:

xorg-x11-drv-ati-debuginfo-6.13.0-0.20.20091221git4b05c47ac.fc12 Fri 15 Jan 2010 04:54:39 GMT
xorg-x11-server-debuginfo-1.7.4-4.fc12        Fri 15 Jan 2010 04:54:16 GMT
mesa-libOSMesa-7.7-2.fc12                     Fri 15 Jan 2010 04:46:49 GMT
xorg-x11-drv-vesa-2.3.0-1.fc12                Fri 15 Jan 2010 04:44:23 GMT
xorg-x11-drv-wacom-0.10.3-2.fc12              Fri 15 Jan 2010 04:44:20 GMT
xorg-x11-drv-evdev-2.3.2-3.fc12               Fri 15 Jan 2010 04:44:17 GMT
xorg-x11-drv-ati-firmware-6.13.0-0.20.20091221git4b05c47ac.fc12 Fri 15 Jan 2010 04:44:14 GMT
xorg-x11-server-Xvfb-1.7.4-4.fc12             Fri 15 Jan 2010 04:29:32 GMT
xorg-x11-server-Xnest-1.7.4-4.fc12            Fri 15 Jan 2010 04:29:30 GMT
xorg-x11-server-Xephyr-1.7.4-4.fc12           Fri 15 Jan 2010 04:29:28 GMT
xorg-x11-server-devel-1.7.4-4.fc12            Fri 15 Jan 2010 04:29:25 GMT
xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12 Fri 15 Jan 2010 04:29:21 GMT
xorg-x11-server-Xorg-1.7.4-4.fc12             Fri 15 Jan 2010 04:29:18 GMT
xorg-x11-server-common-1.7.4-4.fc12           Fri 15 Jan 2010 04:29:16 GMT

Here is the backtrace:

Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x49eac8]
1: /usr/bin/Xorg (0x400000+0x61ae9) [0x461ae9]
2: /lib64/libpthread.so.0 (0x3bdbe00000+0xf0f0) [0x3bdbe0f0f0]
3: /usr/bin/Xorg (dixAllocatePrivate+0x78) [0x445d68]
4: /usr/bin/Xorg (dixLookupPrivate+0x35) [0x445f45]
5: /usr/bin/Xorg (xf86OutputSetEDID+0x47) [0x481897]
6: /usr/bin/Xorg (xf86ProbeOutputModes+0x977) [0x484ae7]
7: /usr/bin/Xorg (xf86InitialConfiguration+0x13c) [0x484d2c]
8: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f24ef425000+0xd7eb1) [0x7f24ef4fceb1]
9: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f24ef425000+0xd5aa7) [0x7f24ef4faaa7]
10: /usr/bin/Xorg (InitOutput+0x552) [0x46fcb2]
11: /usr/bin/Xorg (0x400000+0x21c5a) [0x421c5a]
12: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3bdb21eb1d]
13: /usr/bin/Xorg (0x400000+0x219a9) [0x4219a9]
Segmentation fault at address 0x290

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

did you get libdrm 2.4.17 from somewhere? isnce updates-testing is broken.

if not get it and install it, but that is wierd can you put the whole Xorg log file up?

its almost like an API breakage or something.

Created attachment 384524 [details]
Xorg.* tar gz'ed except the current vesa one.

Xorg.* tar gz'ed except the current vesa one.

(In reply to comment #19)
> did you get libdrm 2.4.17 from somewhere? isnce updates-testing is broken.
> 
> if not get it and install it, but that is wierd can you put the whole Xorg log
> file up?
> 
> its almost like an API breakage or something.    

I got libdrm 2.4.17 from koji . In any case, the new kernel requires new dracut and new plymouth, and new plymouth requires new libdrm . 

Since vesa and radeonhd continues to work, some radeon-specific pieces are broken.

After going at it for hours - at one point, even radeonhd segfaulted - upgrading libdrm, mesa (to 7.7 or 7.8), X server, xorg-x11-drv-ati, kernel, dracut, plymouth, etc, I have finally settled into a configuration which is not broken...

It appear that the kernel package's dependencies is wrong: it requires a recent dracut which in term requires a recent plymonth which in term requires a recent libdrm, then all hell breaks. I downgraded all the packages back to up-to-date updates (and *nothing* from updates-testing nor rawhide), and just the kernel, and ignore the updates-testing dracut->plymouth->libdrm requirement, and it seems to work alright.

In any case, it appears that most combinations of related packages (mesa/libdrm/x-server/xorg-x11-drv-ati) from updates-testing is deeply broken, most probably libdrm.

Thats wierd, Ive tested this on every thing and haven't seen this, have you got a clean distro install? it really sounds like something else is tripping it up that isn't installed here.

(In reply to comment #23)
> Thats wierd, Ive tested this on every thing and haven't seen this, have you got
> a clean distro install? it really sounds like something else is tripping it up
> that isn't installed here.    

I don't have any manually compiled/installed X-related stuff ; the system was upgraded from fc8 progressively onwards, but all the X-related bits are from fc12.
I'll attach my 'rpm -qa --last' next. My current config compared to pre-brokenness is simple a newer kernel kernel-2.6.32.3-26.fc12.x86_64 , and ignoring the dracut/plymouth/libdrm dependency requirements; and my system was broken with the newer dracut/plymouth/libdrm dependency brought in, before the newer mesa (see comment 12); so it looks like libdrm-2.4.17 is bad.

Created attachment 384730 [details]
my current working 'rpm -qa --last' list.

Here is my current 'rpm -qa --last' list, which works alright. It seems that it is important *not* to take anything (dracut/plymouth/libdrm) from updates-testing.

I've put libdrm 2.4.17 on a couple machines without trouble.

armed with the segfault message in xorg.0.log and the debug packages, it should be possible for the determined to work out what's causing the segfault?
(ideally even with api change, it should do something more sensible or at least write a sensible error message instead of segfault...)

We won't work around this breakage, history is that libdrm-radeon didn't have a stable api and we break it before freezing it. Thus there is no version check that we could (or are willing to do). That being said if everythings is properly update in sync it works properly, of course dev box always behave properly while sadly some user experience trouble.

(In reply to comment #28)
> We won't work around this breakage, history is that libdrm-radeon didn't have a
> stable api and we break it before freezing it. Thus there is no version check
> that we could (or are willing to do). That being said if everythings is
> properly update in sync it works properly, of course dev box always behave
> properly while sadly some user experience trouble.    

My problem is that in my case, 'properly update in sync' (follows what the packages say about what their requirements/dependencies are) results in a broken system, and I had to downgrade and explicitly violate the dependencies to get a working system back... so currently my system is *not* in sync but operational.

What's the recommended action here now?  Just grab the latest F12 kernel from koji?

I'm seeing what appears to be the same kernel backtrace fairly frequently, though the machine still appears to function well.

------------[ cut here ]------------
WARNING: at lib/list_debug.c:30 __list_add+0x68/0x81() (Not tainted)
Hardware name: GA-MA74GM-S2
list_add corruption. prev->next should be next (ffff8801289cdda0), but was ffff88009ecdc930. (prev=ffff8800b910fd30).
Modules linked in: fuse bridge stp llc xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_MARK xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_CONNMARK xt_connmark xt_CLASSIFY ipt_LOG iptable_nat nf_nat iptable_mangle nfnetlink autofs4 hwmon_vid tun sunrpc cpufreq_ondemand powernow_k8 freq_table ipv6 dm_multipath kvm_amd kvm uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec ppdev snd_hwdep snd_seq snd_seq_device parport_pc snd_pcm usblp gspca_ov519 gspca_main videodev v4l1_compat v4l2_compat_ioctl32 k8temp amd64_edac_mod snd_timer snd soundcore snd_page_alloc edac_core i2c_piix4 parport shpchp r8169 mii raid1 ata_generic pata_acpi pata_pdc2027x pata_atiixp floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 2776, comm: Xorg Not tainted 2.6.31.12-174.2.3.fc12.x86_64 #1
Call Trace:
 [<ffffffff81051710>] warn_slowpath_common+0x84/0x9c
 [<ffffffff8105177f>] warn_slowpath_fmt+0x41/0x43
 [<ffffffffa004df78>] ? ttm_buffer_object_init+0x338/0x361 [ttm]
 [<ffffffff81207f33>] __list_add+0x68/0x81
 [<ffffffffa007ab3d>] radeon_object_create+0x1cb/0x1de [radeon]
 [<ffffffffa007a925>] ? radeon_ttm_object_object_destroy+0x0/0x4d [radeon]
 [<ffffffffa0085865>] radeon_gem_object_create+0x90/0xfe [radeon]
 [<ffffffffa00858d3>] ? radeon_gem_create_ioctl+0x0/0xdf [radeon]
 [<ffffffffa008592d>] radeon_gem_create_ioctl+0x5a/0xdf [radeon]
 [<ffffffffa001521f>] drm_ioctl+0x237/0x2f4 [drm]
 [<ffffffff81108dd1>] vfs_ioctl+0x6f/0x87
 [<ffffffff8104907d>] ? finish_task_switch+0xc3/0xe6
 [<ffffffff811092e0>] do_vfs_ioctl+0x47b/0x4c1
 [<ffffffff8110937c>] sys_ioctl+0x56/0x79
 [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b
---[ end trace e1037c313043496e ]---

still here as of kernel-2.6.31.12-174.2.22.fc12 (x86_64)

seemed to occur at random soon after got this version of kernel:


WARNING: at lib/list_debug.c:30 __list_add+0x68/0x81() (Not tainted)
Hardware name: Satellite L355D
list_add corruption. prev->next should be next (ffff8800a97d7da0), but was ffff880026945330. (prev=ffff880026945330).
Modules linked in: fuse bluetooth sunrpc cpufreq_ondemand powernow_k8 freq_table ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 microcode uinput snd_hda_codec_realtek uvcvideo snd_hda_intel snd_hda_codec arc4 videodev ecb snd_hwdep v4l1_compat v4l2_compat_ioctl32 snd_seq snd_seq_device snd_pcm r8169 mii ath5k mac80211 ath cfg80211 rfkill snd_timer snd soundcore snd_page_alloc amd64_edac_mod shpchp edac_core i2c_piix4 joydev cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt ata_generic pata_acpi dm_multipath pata_atiixp video output usb_storage radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 1653, comm: Xorg Not tainted 2.6.31.12-174.2.22.fc12.x86_64 #1
Call Trace:
[<ffffffff81051710>] warn_slowpath_common+0x84/0x9c
[<ffffffff8105177f>] warn_slowpath_fmt+0x41/0x43
[<ffffffffa004df78>] ? ttm_buffer_object_init+0x338/0x361 [ttm]
[<ffffffff81207f43>] __list_add+0x68/0x81
[<ffffffffa007ab3d>] radeon_object_create+0x1cb/0x1de [radeon]
[<ffffffffa007a925>] ? radeon_ttm_object_object_destroy+0x0/0x4d [radeon]
[<ffffffffa008586d>] radeon_gem_object_create+0x90/0xfe [radeon]
[<ffffffffa00858db>] ? radeon_gem_create_ioctl+0x0/0xdf [radeon]
[<ffffffffa0085935>] radeon_gem_create_ioctl+0x5a/0xdf [radeon]
[<ffffffffa00854d5>] ? radeon_gem_wait_idle_ioctl+0x59/0x63 [radeon]
[<ffffffffa001521f>] drm_ioctl+0x237/0x2f4 [drm]
[<ffffffff81108e31>] vfs_ioctl+0x6f/0x87
[<ffffffff81109340>] do_vfs_ioctl+0x47b/0x4c1
[<ffffffff811093dc>] sys_ioctl+0x56/0x79
[<ffffffff81011d32>] system_call_fastpath+0x16/0x1b

please get 2.6.32 kernel from F12 updates-testing.

I should comment that since the events leading up to my comment 29, I left my system not-up-to-date for a while, and then do yum update again - the strange dependencies and other issues seem to have resolved themselves by skipping a few of the intemediate components. So currently I am using 2.6.32.8-58.fc12.x86_64 from koji and the rest of the system simply from normal regular weekly yum update.

kernel-2.6.32.8-58.fc12.x86_64 from updates-testing is working fine for me so far.  It does not require the update of any user-space package on my fully updated F12 system.

Reporter, could you confirm please that this issue has been fixed in kernel-2.6.32.8-58.fc12.x86_64 ???

Thank you

Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

The bug has never occurred since my upgrade to 2.6.32.8-58 two months ago, while it did occur several times when running the 2.6.31.x kernels.  Since 2.6.32 is supposed to contain the fix, I think it indeed fixes this bug.

It appears fixed to me. I'm currently running Fedora 13 with 
kernel-2.6.33.3-72.fc13.x86_64 and I haven't seen this crash for a very long time (certainly not after I upgraded to F13)

Closing based on Comment 37 & Comment 38

Please re-open this bug if you continue experiencing this issue after applying the latest updates.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

*** Bug 544112 has been marked as a duplicate of this bug. ***