Re: kernel BUG at fs/buffer.c:1234!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/19/2013 11:55 AM, Theodore Ts'o wrote:
On Wed, Jun 19, 2013 at 09:41:36AM -0700, Dustin Lundquist wrote:
I've run into the following oops several times with the 3.10-rc3
through -rc6, and they have not occurred under 3.9. Originally they
only occurred when running Google Chrome, but this is the first time
it has happened in another application.

So this is very strange.  fs/buffer.c:1234 for 3.10-rc6 is this
BUG_ON:

static inline void check_irqs_on(void)
{
#ifdef irqs_disabled
	BUG_ON(irqs_disabled());
#endif
}

The only place where ext4 turns off irq's is very briefly in
fs/ext4/page-io.c, and it's pretty easy to visually inspect all of the
calls to spin_lock_irqsave() and spin_lock_irqrestore() and
lock_irq_save() and local_irq_restore() are properly bracketed --- and
the stack trace does not have any of the functions that are defined in
fs/ext4/page_io.c.

I notice from the dmesg file that one of the ext4 file systems is
mounted on a device mapper volume.  What kind of dm device is it?
This is an LVM volume on a single SSD. I've include fdisk, mount and lvm output at https://gist.github.com/dlundquist/1d94dd938f03c5d06a2b. Another clue might be that I'm using ecryptfs to encrypt my home directory.

Since the system is still half way responsive after this occurs, is there any other information I can gather after if occurs to aid in diagnosing this?

Thanks,


Dustin Lundquist

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux