Bug 537981 - WARNING in list_debug with radeon_object_create
WARNING in list_debug with radeon_object_create
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jérôme Glisse
Fedora Extras Quality Assurance
: Triaged
: 537181 540200 544112 546414 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-16 21:35 EST by Dawid Zamirski
Modified: 2010-05-09 23:00 EDT (History)
19 users (show)

See Also:
Fixed In Version: kernel-2.6.32.8-58
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-07 08:10:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.* tar gz'ed except the current vesa one. (7.32 KB, text/plain)
2010-01-15 01:59 EST, Hin-Tak Leung
no flags Details
my current working 'rpm -qa --last' list. (341.36 KB, text/plain)
2010-01-15 18:01 EST, Hin-Tak Leung
no flags Details

  None (edit)
Description Dawid Zamirski 2009-11-16 21:35:52 EST
ABRT detected following crash in my up-to-date Fedora 12:

Nov 16 21:28:15 phenom kernel: ------------[ cut here ]------------
Nov 16 21:28:15 phenom kernel: WARNING: at lib/list_debug.c:30 __list_add+0x68/0x81() (Not tainted)
Nov 16 21:28:15 phenom kernel: Hardware name: MS-7576
Nov 16 21:28:15 phenom kernel: list_add corruption. prev->next should be next (ffff88018659cda0), but was ffff8800374d0530. (prev=ffff8800374d0530).
Nov 16 21:28:15 phenom kernel: Modules linked in: fuse ipt_MASQUERADE iptable_nat nf_nat bridge stp llc vboxnetadp vboxnetflt vboxdrv nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc autofs4 ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath kvm_amd kvm uinput usblp snd_ice1724 snd_hda_codec_realtek snd_rawmidi snd_ice17xx_ak4xxx snd_hda_intel snd_ac97_codec snd_hda_codec ac97_bus snd_ak4xxx_adda snd_ak4114 snd_hwdep firewire_ohci snd_seq firewire_core snd_seq_device snd_pcm crc_itu_t snd_pt2258 shpchp amd64_edac_mod snd_i2c snd_timer edac_core r8169 snd i2c_piix4 soundcore mii snd_page_alloc serio_raw wmi joydev ata_generic pata_acpi pata_atiixp radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Nov 16 21:28:15 phenom kernel: Pid: 2435, comm: Xorg Not tainted 2.6.31.5-127.fc12.x86_64 #1
Nov 16 21:28:15 phenom kernel: Call Trace:
Nov 16 21:28:15 phenom kernel: [<ffffffff81051694>] warn_slowpath_common+0x84/0x9c
Nov 16 21:28:15 phenom kernel: [<ffffffff81051703>] warn_slowpath_fmt+0x41/0x43
Nov 16 21:28:15 phenom kernel: [<ffffffffa004bf78>] ? ttm_buffer_object_init+0x338/0x361 [ttm]
Nov 16 21:28:15 phenom kernel: [<ffffffff81205813>] __list_add+0x68/0x81
Nov 16 21:28:15 phenom kernel: [<ffffffffa0078021>] radeon_object_create+0x1cb/0x1de [radeon]
Nov 16 21:28:15 phenom kernel: [<ffffffffa0077e09>] ? radeon_ttm_object_object_destroy+0x0/0x4d [radeon]
Nov 16 21:28:15 phenom kernel: [<ffffffffa008273f>] radeon_gem_object_create+0x90/0xfe [radeon]
Nov 16 21:28:15 phenom kernel: [<ffffffffa00827ad>] ? radeon_gem_create_ioctl+0x0/0xdf [radeon]
Nov 16 21:28:15 phenom kernel: [<ffffffffa0082807>] radeon_gem_create_ioctl+0x5a/0xdf [radeon]
Nov 16 21:28:15 phenom kernel: [<ffffffffa0082438>] ? radeon_gem_wait_idle_ioctl+0x59/0x63 [radeon]
Nov 16 21:28:15 phenom kernel: [<ffffffffa001421f>] drm_ioctl+0x237/0x2f4 [drm]
Nov 16 21:28:15 phenom kernel: [<ffffffff81108a15>] vfs_ioctl+0x6f/0x87
Nov 16 21:28:15 phenom kernel: [<ffffffff81108f24>] do_vfs_ioctl+0x47b/0x4c1
Nov 16 21:28:15 phenom kernel: [<ffffffff81108fc0>] sys_ioctl+0x56/0x79
Nov 16 21:28:15 phenom kernel: [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b
Nov 16 21:28:15 phenom kernel: ---[ end trace 9c8e1f20a74c571e ]---

This issue happened several times already but, other than getting the oops, the system seems to function properly. I have filed this in BZ because ABRT submits it to kerneloops and there's no way to track where did it go and I'm not sure if any developer saw this. I hope you don't mind posting this to RedHat's Bugzilla.This seems to happen randomly to me so I can't provide exact steps to reproduce but I get to see it pretty often when I download using NNTPGrab.

I'm using the latest kernel which is kernel-2.6.31.5-117.fc12.x86_64 at the moment.
Comment 1 mica1884 2009-11-20 12:58:30 EST
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.
Comment 2 mica1884 2009-11-20 13:09:20 EST
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]
Comment 3 Dawid Zamirski 2009-12-01 09:59:57 EST
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..
Comment 4 Michal Schmidt 2009-12-02 06:55:21 EST
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.
Comment 5 Michal Schmidt 2009-12-02 07:00:31 EST
*** Bug 537181 has been marked as a duplicate of this bug. ***
Comment 6 Michal Schmidt 2009-12-02 07:00:44 EST
*** Bug 540200 has been marked as a duplicate of this bug. ***
Comment 7 Jérôme Glisse 2009-12-04 09:54:08 EST
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.
Comment 8 Orion Poplawski 2009-12-15 13:35:55 EST
What's the word here?  Just had another crash today...
Comment 9 Hin-Tak Leung 2009-12-15 14:34:11 EST
(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.
Comment 10 r6144 2009-12-25 03:21:58 EST
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
Comment 11 Jérôme Glisse 2010-01-13 11:52:12 EST
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.
Comment 12 Hin-Tak Leung 2010-01-14 02:34:33 EST
(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.
Comment 13 Dave Airlie 2010-01-14 03:09:41 EST
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.
Comment 14 Dave Airlie 2010-01-14 03:14:07 EST
*** Bug 546414 has been marked as a duplicate of this bug. ***
Comment 15 Hin-Tak Leung 2010-01-14 03:56:57 EST
(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 .
Comment 16 Jérôme Glisse 2010-01-14 06:24:53 EST
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
Comment 17 Terry Barnaby 2010-01-14 16:04:04 EST
Note that libdrm-2.4.17-1.fc12 has gone missing from updates-testing for some reason ?
Comment 18 Hin-Tak Leung 2010-01-15 00:07:06 EST
(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
Comment 19 Dave Airlie 2010-01-15 01:51:40 EST
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.
Comment 20 Hin-Tak Leung 2010-01-15 01:59:22 EST
Created attachment 384524 [details]
Xorg.* tar gz'ed except the current vesa one.

Xorg.* tar gz'ed except the current vesa one.
Comment 21 Hin-Tak Leung 2010-01-15 02:02:35 EST
(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.
Comment 22 Hin-Tak Leung 2010-01-15 05:14:15 EST
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.
Comment 23 Dave Airlie 2010-01-15 16:16:30 EST
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.
Comment 24 Hin-Tak Leung 2010-01-15 17:59:16 EST
(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.
Comment 25 Hin-Tak Leung 2010-01-15 18:01:58 EST
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.
Comment 26 Orion Poplawski 2010-01-15 18:04:10 EST
I've put libdrm 2.4.17 on a couple machines without trouble.
Comment 27 Hin-Tak Leung 2010-01-15 18:08:55 EST
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...)
Comment 28 Jérôme Glisse 2010-01-16 08:51:35 EST
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.
Comment 29 Hin-Tak Leung 2010-01-16 13:18:01 EST
(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.
Comment 30 David Rees 2010-01-28 04:21:45 EST
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 ]---
Comment 31 collura 2010-02-24 21:50:21 EST
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
Comment 32 Dave Airlie 2010-02-24 22:10:33 EST
please get 2.6.32 kernel from F12 updates-testing.
Comment 33 Hin-Tak Leung 2010-02-24 22:59:48 EST
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.
Comment 34 r6144 2010-03-01 02:10:57 EST
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.
Comment 35 Matěj Cepl 2010-03-01 11:06:25 EST
Reporter, could you confirm please that this issue has been fixed in kernel-2.6.32.8-58.fc12.x86_64 ???

Thank you
Comment 36 Jeff Raber 2010-05-05 03:41:30 EDT
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
Comment 37 r6144 2010-05-05 04:45:36 EDT
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.
Comment 38 Dawid Zamirski 2010-05-05 10:39:00 EDT
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)
Comment 39 Jeff Raber 2010-05-07 08:10:44 EDT
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
Comment 40 Jeff Raber 2010-05-09 23:00:04 EDT
*** Bug 544112 has been marked as a duplicate of this bug. ***

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