Kernel Bug Tracker – Bug 42953
kernel BUG at fs/btrfs/transaction.c:1349 btrfs_commit_transaction+0x928/0x930 [btrfs]()
Last modified: 2013-04-30 16:53:23 UTC
Created attachment 72640 [details]
btrfs crash log
I have an external USB drive formatted as btrfs and two external USB ext4 drives attached. Whenever I try to suspend the laptop, the kernel always crashes while trying to umount the btrfs drive, ie before suspend succeeds. The drives are *not* disconnected or powered down during the process. The btrfs drive and one ext4 drive are attached via a USB hub.
If I umount the drive manually first, the laptop suspends without a problem.
I also have a btrfs partition on the laptop's internal drive but this does not cause a crash during suspend.
The crash is especially annoying because it can cause my ext4 home drive to lose settings...
Note: the attached log says WARNING instead of BUG because I built a kernel with the BUG_ONs changed to WARNINGs in fs/btrfs/transaction.c in order to get the crash recorded in the syslog without having to set up a serial console to catch the error.
An update: I had in /etc/config.d/suspend:
so during suspend the USB driver was being removed.
Commenting this out stops the bug from happening, so the problem appears to be that btrfs does not gracefully handle loss of access to the underlying block device.
Unplugging the external btrfs drive causes a similar crash in btrfs_commit_transaction.
Unplugging the external btrfs drive while the laptop is suspended and then resuming the laptop also crashes it! I guess btrfs isn't quite production-ready yet.
Have this bug in 3.3 final as well. I have a btrfs partition on an external USB-HDD. When i unplug it without unmounting, my machine crashs. I originally filed this bug in the Ubuntu bugtracker with linux 3.2. There you can find several logs as well: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/963107
3.4-rc1 and 2 handle this better. Instead of a crash and complete lockup, I get some warn_slowpath_common messages (eg btrfs_put_block_group / btrfs_free_block_groups / close_ctree ... sys_umount).
It doesn't handle it brilliantly, though. After removing the drive, the CPU cores scale up to their highest frequency and if I plug the drive back in, btrfs fails to recognise it.
Closing, if this is still affecting you on a newer kernel please reopen.