Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Missed the steps filling in de fields above. Sorry...
After formatting a logical volume with the xfs filesystem I tried to mount using
the command mount -a.
In /etc/fstab there was a setting to enable quoata.
The system stopped and rebooted immediately.
/var/log/messages contains the following lines:
Apr 11 20:14:20 minnie kernel: Filesystem "dm-12": Disabling barriers, not suppo
rted by the underlying device
Apr 11 20:14:20 minnie kernel: XFS mounting filesystem dm-12
Apr 11 20:14:20 minnie kernel: XFS quotacheck dm-12: Please wait.
Apr 11 20:14:20 minnie kernel: BUG: sleeping function called from invalid contex
t at include/asm/semaphore.h:99
Apr 11 20:14:20 minnie kernel: in_atomic():1, irqs_disabled():0
Apr 11 20:14:20 minnie kernel: [<c04056ff>] dump_trace+0x69/0x1b6
Apr 11 20:14:20 minnie kernel: [<c0405864>] show_trace_log_lvl+0x18/0x2c
Apr 11 20:14:20 minnie kernel: [<c0405e4b>] show_trace+0xf/0x11
Apr 11 20:14:20 minnie kernel: [<c0405e7a>] dump_stack+0x15/0x17
After the reboot everything works fine. Can not reproduce the problem
the BUG was in the kernel....
This is almost certainly due to a stack overflow - mount+quotacheck goes very
deep - it's one of the codepaths I tried to slim down for the F8 test kernel.
Having blown the stack, the thread_info struct gets corrupted, and can cause
these sorts of errors.
The stack reductions I did for F8 will go upstream and eventually find their way
back to F6 via that path, and hopefully it will look a bit better.
Honestly for now (and even the foreseeable future) xfs on 4k stacks on x86 is a
bit dangerous, made moreso by running over dm (or any manager, vs. just running
on a plain partition) and the quota paths can go deeper too.
Thanks Eric for the work you've put into this issue.
Apart from the onetime experience when the kernel panic occurred the system
seems to be running very stable.
I understand that there is a risc involved running xfs. Currently I've got it
running on top of logical volumes who are running on top of a software raid,
level 1 system.
Some volumes are SATA based, others are external USB storage devices.
I'll take my chances with the 4k stacks on a x86 machine. I just love the speed
of xfs with large files.
closing as RAWHIDE... F8 devel kernels have this issue under better control...
*hopefully* the stack-lightening change will make it into 2.6.23, and from there