Bug 732572 - ext4_evict_inode lockdep trace.
ext4_evict_inode lockdep trace.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 736813 736941 737098 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-22 20:23 EDT by Mads Kiilerich
Modified: 2011-09-13 09:36 EDT (History)
13 users (show)

See Also:
Fixed In Version: kernel-3.1.0-0.rc5.git0.0.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-09-11 23:42:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/var/log/messages (172.06 KB, text/plain)
2011-08-22 20:23 EDT, Mads Kiilerich
no flags Details

  None (edit)
Description Mads Kiilerich 2011-08-22 20:23:07 EDT
Created attachment 519374 [details]
/var/log/messages

kernel-3.1.0-0.rc3.git0.0.fc16.x86_64 gave

 [   31.792968] 
 [   31.792970] =======================================================
 [   31.792975] [ INFO: possible circular locking dependency detected ]
 [   31.792978] 3.1.0-0.rc3.git0.0.fc16.x86_64 #1
 [   31.792980] -------------------------------------------------------
 [   31.792983] gnome-settings-/1093 is trying to acquire lock:
 [   31.792986]  (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c
 [   31.792997] 
 [   31.792998] but task is already holding lock:
 [   31.793000]  (&mm->mmap_sem){++++++}, at: [<ffffffff81116f9a>] sys_munmap+0x3b/0x60
 [   31.793008] 
 [   31.793009] which lock already depends on the new lock.
 [   31.793010] 
 [   31.793012] 
 [   31.793013] the existing dependency chain (in reverse order) is:
 [   31.793016] 
 [   31.793016] -> #1 (&mm->mmap_sem){++++++}:
 [   31.793021]        [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e
 [   31.793027]        [<ffffffff8110fbd7>] might_fault+0x89/0xac
 [   31.793032]        [<ffffffff81151bfb>] filldir+0x6f/0xc7
 [   31.793038]        [<ffffffff811a5347>] call_filldir+0x96/0xc0
 [   31.793043]        [<ffffffff811a5680>] ext4_readdir+0x1bd/0x548
 [   31.793048]        [<ffffffff81151e50>] vfs_readdir+0x7b/0xb4
 [   31.793052]        [<ffffffff81151f6f>] sys_getdents+0x7e/0xd1
 [   31.793056]        [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b
 [   31.793062] 
 [   31.793063] -> #0 (&sb->s_type->i_mutex_key#15){+.+.+.}:
 [   31.793069]        [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7
 [   31.793073]        [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e
 [   31.793077]        [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a
 [   31.793082]        [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45
 [   31.793087]        [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c
 [   31.793091]        [<ffffffff81157cf2>] evict+0x99/0x153
 [   31.793096]        [<ffffffff81157f3d>] iput+0x191/0x19a
 [   31.793100]        [<ffffffff81154bf5>] dentry_kill+0x123/0x145
 [   31.793105]        [<ffffffff81155004>] dput+0xf7/0x107
 [   31.793109]        [<ffffffff811440db>] fput+0x1dd/0x1f5
 [   31.793114]        [<ffffffff811158ee>] remove_vma+0x56/0x87
 [   31.793118]        [<ffffffff81116afd>] do_munmap+0x2f2/0x30b
 [   31.793122]        [<ffffffff81116fa8>] sys_munmap+0x49/0x60
 [   31.793126]        [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b
 [   31.793130] 
 [   31.793131] other info that might help us debug this:
 [   31.793132] 
 [   31.793134]  Possible unsafe locking scenario:
 [   31.793135] 
 [   31.793137]        CPU0                    CPU1
 [   31.793139]        ----                    ----
 [   31.793141]   lock(&mm->mmap_sem);
 [   31.793145]                                lock(&sb->s_type->i_mutex_key);
 [   31.793149]                                lock(&mm->mmap_sem);
 [   31.793153]   lock(&sb->s_type->i_mutex_key);
 [   31.793157] 
 [   31.793158]  *** DEADLOCK ***
 [   31.793158] 
 [   31.793161] 1 lock held by gnome-settings-/1093:
 [   31.793163]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff81116f9a>] sys_munmap+0x3b/0x60
 [   31.793170] 
 [   31.793171] stack backtrace:
 [   31.793175] Pid: 1093, comm: gnome-settings- Not tainted 3.1.0-0.rc3.git0.0.fc16.x86_64 #1
 [   31.793177] Call Trace:
 [   31.793182]  [<ffffffff814f9b74>] print_circular_bug+0x1f8/0x209
 [   31.793187]  [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7
 [   31.793191]  [<ffffffff8108be17>] ? register_lock_class+0x1e/0x2d3
 [   31.793195]  [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c
 [   31.793200]  [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e
 [   31.793203]  [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c
 [   31.793208]  [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c
 [   31.793212]  [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a
 [   31.793216]  [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c
 [   31.793221]  [<ffffffff810152af>] ? native_sched_clock+0x34/0x36
 [   31.793225]  [<ffffffff810152ba>] ? sched_clock+0x9/0xd
 [   31.793229]  [<ffffffff8108b885>] ? trace_hardirqs_off+0xd/0xf
 [   31.793233]  [<ffffffff8108bdf0>] ? lock_release_holdtime.part.9+0x59/0x62
 [   31.793238]  [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45
 [   31.793242]  [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c
 [   31.793246]  [<ffffffff81157cf2>] evict+0x99/0x153
 [   31.793250]  [<ffffffff81157f3d>] iput+0x191/0x19a
 [   31.793254]  [<ffffffff81154bf5>] dentry_kill+0x123/0x145
 [   31.793259]  [<ffffffff81155004>] dput+0xf7/0x107
 [   31.793263]  [<ffffffff811440db>] fput+0x1dd/0x1f5
 [   31.793267]  [<ffffffff811158ee>] remove_vma+0x56/0x87
 [   31.793270]  [<ffffffff81116afd>] do_munmap+0x2f2/0x30b
 [   31.793275]  [<ffffffff81116fa8>] sys_munmap+0x49/0x60
 [   31.793279]  [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b
 [   32.068002] gsettings-data-[1091] trap int3 ip:7f86d4ea96b3 sp:7fff54722050 error:0
Aug 22 23:54:43 localhost abrt[1107]: saved core dump of pid 1091 (/usr/bin/gsettings-data-convert) to /var/spool/abrt/ccpp-2011-08-22-23:54:43-1091.new/coredump (18001920 bytes)
Aug 22 23:54:43 localhost abrtd: Directory 'ccpp-2011-08-22-23:54:43-1091' creation detected
Aug 22 23:54:43 localhost gnome-session[1031]: WARNING: Application 'gsettings-data-convert.desktop' killed by signal
Aug 22 23:54:43 localhost dbus[798]: [system] Activating service name='org.freedesktop.UPower' (using servicehelper)
Aug 22 23:54:44 localhost kernel: [   32.428962] gsettings-data-[1108] trap int3 ip:7fa1362d36b3 sp:7fff7cebbe80 error:0
Aug 22 23:54:44 localhost abrt[1114]: not dumping repeating crash in '/usr/bin/gsettings-data-convert'
Aug 22 23:54:44 localhost gnome-session[1031]: WARNING: Application 'gsettings-data-convert.desktop' killed by signal
Aug 22 23:54:44 localhost gnome-session[1031]: WARNING: App 'gsettings-data-convert.desktop' respawning too quickly
Aug 22 23:54:44 localhost gnome-session[1031]: WARNING: Error on restarting session managed app: Component 'gsettings-data-convert.desktop' crashing too quickly

I notice that the crash looks a bit like Bug 709797
Comment 1 Josh Boyer 2011-08-22 20:28:29 EDT
This was reported upstream:

https://lkml.org/lkml/2011/8/21/163

waiting on Ted to comment.
Comment 2 Jurgen Kramer 2011-08-23 12:21:11 EDT
I've got the same error for a different proces dconf-service/1625. But strangely was not caught by abrtd.

[   72.355146] 
[   72.355148] =======================================================
[   72.355152] [ INFO: possible circular locking dependency detected ]
[   72.355154] 3.1.0-0.rc3.git0.0.fc16.x86_64 #1
[   72.355155] -------------------------------------------------------
[   72.355157] dconf-service/1625 is trying to acquire lock:
[   72.355159]  (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c
[   72.355168] 
[   72.355168] but task is already holding lock:
[   72.355170]  (&mm->mmap_sem){++++++}, at: [<ffffffff81116f9a>] sys_munmap+0x3b/0x60
[   72.355175] 
[   72.355175] which lock already depends on the new lock.
[   72.355176] 
[   72.355177] 
[   72.355177] the existing dependency chain (in reverse order) is:
[   72.355179] 
[   72.355179] -> #1 (&mm->mmap_sem){++++++}:
[   72.355182]        [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e
[   72.355186]        [<ffffffff8110fbd7>] might_fault+0x89/0xac
[   72.355190]        [<ffffffff81151bfb>] filldir+0x6f/0xc7
[   72.355194]        [<ffffffff811a5347>] call_filldir+0x96/0xc0
[   72.355198]        [<ffffffff811a5680>] ext4_readdir+0x1bd/0x548
[   72.355201]        [<ffffffff81151e50>] vfs_readdir+0x7b/0xb4
[   72.355204]        [<ffffffff81151f6f>] sys_getdents+0x7e/0xd1
[   72.355206]        [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b
[   72.355210] 
[   72.355211] -> #0 (&sb->s_type->i_mutex_key#13){+.+.+.}:
[   72.355214]        [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7
[   72.355216]        [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e
[   72.355219]        [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a
[   72.355222]        [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45
[   72.355225]        [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c
[   72.355228]        [<ffffffff81157cf2>] evict+0x99/0x153
[   72.355230]        [<ffffffff81157f3d>] iput+0x191/0x19a
[   72.355232]        [<ffffffff81154bf5>] dentry_kill+0x123/0x145
[   72.355236]        [<ffffffff81155004>] dput+0xf7/0x107
[   72.355238]        [<ffffffff811440db>] fput+0x1dd/0x1f5
[   72.355242]        [<ffffffff811158ee>] remove_vma+0x56/0x87
[   72.355245]        [<ffffffff81116afd>] do_munmap+0x2f2/0x30b
[   72.355248]        [<ffffffff81116fa8>] sys_munmap+0x49/0x60
[   72.355250]        [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b
[   72.355253] 
[   72.355253] other info that might help us debug this:
[   72.355254] 
[   72.355255]  Possible unsafe locking scenario:
[   72.355256] 
[   72.355257]        CPU0                    CPU1
[   72.355258]        ----                    ----
[   72.355259]   lock(&mm->mmap_sem);
[   72.355261]                                lock(&sb->s_type->i_mutex_key);
[   72.355264]                                lock(&mm->mmap_sem);
[   72.355266]   lock(&sb->s_type->i_mutex_key);
[   72.355268] 
[   72.355269]  *** DEADLOCK ***
[   72.355269] 
[   72.355271] 1 lock held by dconf-service/1625:
[   72.355272]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff81116f9a>] sys_munmap+0x3b/0x60
[   72.355277] 
[   72.355277] stack backtrace:
[   72.355279] Pid: 1625, comm: dconf-service Not tainted 3.1.0-0.rc3.git0.0.fc16.x86_64 #1
[   72.355281] Call Trace:
[   72.355286]  [<ffffffff814f9b74>] print_circular_bug+0x1f8/0x209
[   72.355289]  [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7
[   72.355292]  [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c
[   72.355295]  [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e
[   72.355297]  [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c
[   72.355300]  [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c
[   72.355304]  [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a
[   72.355308]  [<ffffffff811ae562>] ? ext4_evict_inode+0x76/0x33c
[   72.355313]  [<ffffffff810152af>] ? native_sched_clock+0x34/0x36
[   72.355317]  [<ffffffff810152ba>] ? sched_clock+0x9/0xd
[   72.355320]  [<ffffffff8108b885>] ? trace_hardirqs_off+0xd/0xf
[   72.355324]  [<ffffffff8108bdf0>] ? lock_release_holdtime.part.9+0x59/0x62
[   72.355327]  [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45
[   72.355330]  [<ffffffff811ae562>] ext4_evict_inode+0x76/0x33c
[   72.355332]  [<ffffffff81157cf2>] evict+0x99/0x153
[   72.355334]  [<ffffffff81157f3d>] iput+0x191/0x19a
[   72.355337]  [<ffffffff81154bf5>] dentry_kill+0x123/0x145
[   72.355340]  [<ffffffff81155004>] dput+0xf7/0x107
[   72.355342]  [<ffffffff811440db>] fput+0x1dd/0x1f5
[   72.355344]  [<ffffffff811158ee>] remove_vma+0x56/0x87
[   72.355346]  [<ffffffff81116afd>] do_munmap+0x2f2/0x30b
[   72.355349]  [<ffffffff81116fa8>] sys_munmap+0x49/0x60
[   72.355352]  [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b
[   74.661594] lp: driver loaded but no devices found
[   74.716604] ppdev: user-space parallel port driver
[  118.943458] DMA-API: debugging out of memory - disabling
Comment 3 Jurgen Kramer 2011-08-28 10:05:38 EDT
For completeness, not fixed with 3.1.0-0.rc3.git5.1.fc16.x86_64.

[   56.988971] =======================================================
[   56.988976] [ INFO: possible circular locking dependency detected ]
[   56.988980] 3.1.0-0.rc3.git5.1.fc16.x86_64 #1
[   56.988982] -------------------------------------------------------
[   56.988985] dconf-service/1489 is trying to acquire lock:
[   56.988988]  (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff811ae9a6>] ext4_evict_inode+0x76/0x33c
[   56.989001] 
[   56.989001] but task is already holding lock:
[   56.989004]  (&mm->mmap_sem){++++++}, at: [<ffffffff811173be>] sys_munmap+0x3b/0x60
[   56.989011] 
[   56.989012] which lock already depends on the new lock.
[   56.989013] 
[   56.989015] 
[   56.989016] the existing dependency chain (in reverse order) is:
[   56.989018] 
[   56.989019] -> #1 (&mm->mmap_sem){++++++}:
[   56.989024]        [<ffffffff8108f143>] lock_acquire+0xf3/0x13e
[   56.989030]        [<ffffffff8110fffb>] might_fault+0x89/0xac
[   56.989035]        [<ffffffff81152027>] filldir+0x6f/0xc7
[   56.989041]        [<ffffffff811a578b>] call_filldir+0x96/0xc0
[   56.989047]        [<ffffffff811a5ac4>] ext4_readdir+0x1bd/0x548
[   56.989052]        [<ffffffff8115227c>] vfs_readdir+0x7b/0xb4
[   56.989057]        [<ffffffff8115239b>] sys_getdents+0x7e/0xd1
[   56.989061]        [<ffffffff8150b582>] system_call_fastpath+0x16/0x1b
[   56.989067] 
[   56.989068] -> #0 (&sb->s_type->i_mutex_key#13){+.+.+.}:
[   56.989074]        [<ffffffff8108e963>] __lock_acquire+0xa2f/0xd0c
[   56.989078]        [<ffffffff8108f143>] lock_acquire+0xf3/0x13e
[   56.989082]        [<ffffffff81502abb>] __mutex_lock_common+0x5d/0x39a
[   56.989088]        [<ffffffff81502f07>] mutex_lock_nested+0x40/0x45
[   56.989092]        [<ffffffff811ae9a6>] ext4_evict_inode+0x76/0x33c
[   56.989096]        [<ffffffff81158134>] evict+0x98/0x152
[   56.989101]        [<ffffffff8115837f>] iput+0x191/0x199
[   56.989104]        [<ffffffff81155021>] dentry_kill+0x123/0x145
[   56.989110]        [<ffffffff81155430>] dput+0xf7/0x107
[   56.989115]        [<ffffffff81144507>] fput+0x1dd/0x1f5
[   56.989120]        [<ffffffff81115d12>] remove_vma+0x56/0x87
[   56.989124]        [<ffffffff81116f21>] do_munmap+0x2f2/0x30b
[   56.989128]        [<ffffffff811173cc>] sys_munmap+0x49/0x60
[   56.989132]        [<ffffffff8150b582>] system_call_fastpath+0x16/0x1b
[   56.989137] 
[   56.989137] other info that might help us debug this:
[   56.989138] 
[   56.989140]  Possible unsafe locking scenario:
[   56.989141] 
[   56.989143]        CPU0                    CPU1
[   56.989145]        ----                    ----
[   56.989147]   lock(&mm->mmap_sem);
[   56.989151]                                lock(&sb->s_type->i_mutex_key);
[   56.989155]                                lock(&mm->mmap_sem);
[   56.989159]   lock(&sb->s_type->i_mutex_key);
[   56.989162] 
[   56.989163]  *** DEADLOCK ***
[   56.989164] 
[   56.989167] 1 lock held by dconf-service/1489:
[   56.989169]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff811173be>] sys_munmap+0x3b/0x60
[   56.989176] 
[   56.989176] stack backtrace:
[   56.989180] Pid: 1489, comm: dconf-service Not tainted 3.1.0-0.rc3.git5.1.fc16.x86_64 #1
[   56.989183] Call Trace:
[   56.989189]  [<ffffffff814fa054>] print_circular_bug+0x1f8/0x209
[   56.989194]  [<ffffffff8108e963>] __lock_acquire+0xa2f/0xd0c
[   56.989199]  [<ffffffff811ae9a6>] ? ext4_evict_inode+0x76/0x33c
[   56.989203]  [<ffffffff8108f143>] lock_acquire+0xf3/0x13e
[   56.989207]  [<ffffffff811ae9a6>] ? ext4_evict_inode+0x76/0x33c
[   56.989211]  [<ffffffff811ae9a6>] ? ext4_evict_inode+0x76/0x33c
[   56.989216]  [<ffffffff81502abb>] __mutex_lock_common+0x5d/0x39a
[   56.989220]  [<ffffffff811ae9a6>] ? ext4_evict_inode+0x76/0x33c
[   56.989225]  [<ffffffff810152b7>] ? native_sched_clock+0x34/0x36
[   56.989229]  [<ffffffff810152c2>] ? sched_clock+0x9/0xd
[   56.989233]  [<ffffffff8108b9b5>] ? trace_hardirqs_off+0xd/0xf
[   56.989237]  [<ffffffff8108bf20>] ? lock_release_holdtime.part.9+0x59/0x62
[   56.989242]  [<ffffffff81502f07>] mutex_lock_nested+0x40/0x45
[   56.989246]  [<ffffffff811ae9a6>] ext4_evict_inode+0x76/0x33c
[   56.989250]  [<ffffffff81158134>] evict+0x98/0x152
[   56.989254]  [<ffffffff8115837f>] iput+0x191/0x199
[   56.989259]  [<ffffffff81155021>] dentry_kill+0x123/0x145
[   56.989264]  [<ffffffff81155430>] dput+0xf7/0x107
[   56.989268]  [<ffffffff81144507>] fput+0x1dd/0x1f5
[   56.989272]  [<ffffffff81115d12>] remove_vma+0x56/0x87
[   56.989275]  [<ffffffff81116f21>] do_munmap+0x2f2/0x30b
[   56.989279]  [<ffffffff811173cc>] sys_munmap+0x49/0x60
[   56.989284]  [<ffffffff8150b582>] system_call_fastpath+0x16/0x1b
[   62.676076] lp: driver loaded but no devices found
[   63.786823] ppdev: user-space parallel port driver
[   85.989448] DMA-API: debugging out of memory - disabling
Comment 4 Josh Boyer 2011-08-28 10:11:10 EDT
Yeah, that won't be fixed until either someone from the ext4 development actually bothers to comment, or the MM folks fixup remove_vma to not call fput.  It's somewhat of a stalemate.
Comment 5 Josh Boyer 2011-08-28 10:14:33 EDT
The latest discussion:

https://lkml.org/lkml/2011/8/24/434
Comment 6 Josh Boyer 2011-08-30 08:34:18 EDT
There's a related thread on the ext4 mailing list now:

http://www.spinics.net/lists/linux-ext4/msg27301.html

Looks like a small revert might be happening as a temporary fix, with some larger rework later.
Comment 7 Josh Boyer 2011-09-08 15:10:31 EDT
*** Bug 736813 has been marked as a duplicate of this bug. ***
Comment 8 Chuck Ebbert 2011-09-09 04:25:50 EDT
*** Bug 736941 has been marked as a duplicate of this bug. ***
Comment 9 Fedora Update System 2011-09-09 11:43:21 EDT
kernel-3.1.0-0.rc5.git0.0.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kernel-3.1.0-0.rc5.git0.0.fc16
Comment 10 Fedora Update System 2011-09-10 14:56:56 EDT
Package kernel-3.1.0-0.rc5.git0.0.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.1.0-0.rc5.git0.0.fc16'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/kernel-3.1.0-0.rc5.git0.0.fc16
then log in and leave karma (feedback).
Comment 11 Fedora Update System 2011-09-11 23:42:19 EDT
kernel-3.1.0-0.rc5.git0.0.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Josh Boyer 2011-09-13 09:36:30 EDT
*** Bug 737098 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.