Created attachment 25061 [details] syslog of btfrs kernel crash This bug hangs the kernel. I've experienced it twice now. See attached log. Both times the crash happened after I suspended with an external btrfs drive plugged in and resumed without it. The first time the crash happened before X's screen saver password entry screen could appear, the second time around six hours after resume. The second time I could see that the system thought the external drive was still mounted after resume (ie its icon was still on the desktop). Version info: Ubuntu 9.10, 2.6.33-rc8 amd64 Note: This might be the same as bug #15267 (which was reported against 2.6.32.5).
It doesn't require a suspend/resume; simply unplugging the drive while it's mounted can cause the crash. This last time the crash upset my Intel Wireless 4965 AGN card so badly that even several cold boots back into 2.6.33-rc8 wouldn't bring it up; I had to reboot into the 2.6.32.8 kernel to fix it.
Created attachment 25073 [details] syslog of btfrs kernel crash - NULL pointer dereference Actually the last crash due to the external drive being removed looks like something different (unable to handle kernel NULL pointer dereference at 0000000000000030) - see attached log.
This is consistently reproducible, eg with a btrfs USB key. Removing the drive causes a crash due to btrfs not being able to write to it. Could this be related to another problem with btrfs, ie that if you mount the drive on say /dev/sdb1, remove it, then mount another drive on /dev/sdb1 and reinsert the btrfs drive so it is assigned to /dev/sdc1, the system can't mount it (it tries still to mount it on /dev/sdb1 and fails to read the superblock)?
In 2.6.34-rc7, removing the external drive doesn't cause a complete kernel crash but does lock up bits of the kernel: eg opening gnome-terminal and doing "sudo -s" just hangs, and the next time you open a gnome-terminal it hangs; you can't ssh into the machine; gnome-panel becomes unresponsive.
Should be fixed in current kernels - the underlying block layer handling was fixed. If not please re-test with 3.3 or 3.4-rc and attach the updated failure reports
Created attachment 73300 [details] log of removing external btrfs drive and re-attaching it The kernel no longer crashes when I remove the drive (which is great!), but btrfs doesn't recover gracefully from the error condition. With 3.4-rc7 if I remove the drive I get a warning from btrfs (see log) and when I reattach the drive the system sees it, but btrfs cannot mount it. Attempts to mount via nautilus receive the error "An operation is already pending". Should I log a separate bug for this?