Red Hat Bugzilla – Bug 209062
fc6-pre BUG searching for fedora core installations while XFS filesystem exists
Last modified: 2007-11-30 17:11:45 EST
Description of problem:
Booted FC6-pre-dvd-i386 DVD with updates-fc6pre floppy:
boot: linux updates vga=791
After message about "Searching for Fedora Core Installations" appears
with an empty bargraph, screen goes black with just the pointer and the
circling blue dots. The last filesystem that gets mounted is on an SATAII
drive with XFS. The XFS filesystem only has three directories in it.
There is no installation on the XFS filesystem.
Attached is the syslog which has the BUG output.
After reformating the XFS filesytem to ext3, the install worked fine.
Then, reformating the filesystem back to XFS reproduced the install BUG again.
Version-Release number of selected component (if applicable):
Every time I try to install with or without updates floppy when there
is an XFS filesystem.
Steps to Reproduce:
1. create XFS filesystem on a partition
2. boot: linux updates
3. answer prompts with defaults till Searching for FC Installations
hangs with BUG and black screen with pointer
able to get to command prompt with CTRL-ALT-F2 to save syslog to floppy
install or upgrade screen should appear
This is a test box with many versions of FC4 thru FC6-test3 (both i386
and X86_64), Centos, and two WinXP's installed.
ASRock 939DUAL-VSTA with Athlon64, 1GB memory, Nvidia 6800 Ultra, two IDE
Seagate drives and one SATAII Seagate drive.
FC6T3 was successfully installed on SATAII sda3 before creating XFS
filesystem on sda5. Attempted to install FC6-pre onto sda6, but couldn't
get past "Searching for Fedora Core Installations" while XFS filesystem
existed. FC6-pre dvd passed mediacheck test.
Plus Bugzilla didn't have a Version for fc6-pre, so I used fc6test3.
Created attachment 137624 [details]
syslog with BUG output 33,772 bytes
Also happens with fc6-test3-dvd-i386 DVD.
Perhaps Eric has some clues (and maybe he needs a break from ext3 bugs :)
Looks like lockdep problems, I'll look into it.
xfs looks completely DOA w/ lockdep enabled at this point (and probably also w/
slab debugging) - a simple mount/unmount will oops. I'll look into it more
tomorrow, probably something straightforward.
We are blowing up in mark_lock because when it does:
if (likely(this->class->usage_mask & new_mask))
this->class is 0x6b6b6b6b, meaning freed memory.
This got assigned previously in __lock_acquire,
class = lock->class_cache;
but class_cache is freed (0x6b6b6b6b) at this point. I've not been able to
figure out where/why this happened yet...
Doing a little debugging in lock_release_non_nested:
lockdepth_depth 4 held_locks dde9cff4
testing i==3, hlock dde9d06c, hlock->instance d1400ea4
testing i==2, hlock dde9d044, hlock->instance d1400edc
testing i==1, hlock dde9d01c, hlock->instance d1691110
Matched lock at d1691110 (i==1)
curr lockdep_depth now 1
i==2, hlock dde9d044, hlock->instance d1400edc, our lock d1691110
lock map at d1400edc lock->class_cache 6b6b6b6b lock->key 6b6b6b6b lock->name
somehow locks 2 and 3 above are freed, and -that- is why we are oopsing, not due
to the mutex_unlock(&sb->s_lock);. Perhaps this means xfs has freed some locks
w/o unlocking them first....
Found out over the weekend that this is due to this code in xfs_ireclaim:
* Here we do a spurious inode lock in order to coordinate with
* xfs_sync(). This is because xfs_sync() references the inodes
* in the mount list without taking references on the corresponding
* vnodes. We make that OK here by ensuring that we wait until
* the inode is unlocked in xfs_sync() before we go ahead and
* free it. We get both the regular lock and the io lock because
* the xfs_sync() code may need to drop the regular one but will
* still hold the io lock.
xfs_ilock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL)
* Free all memory associated with the inode.
So, lock & free. This frees memory that lockdep is still pointing to.
Will huddle w/ the xfs guys when I get a chance to make sure unlocking the inode
just before freeing is acceptable. (it does seem to fix this problem at least).
Created attachment 138154 [details]
unlock xfs inode locks before freeing the inode
this fixes the problem and has been ACKed by the sgi xfs folks.
attached patch is in rawhide now.