I'm not finding much about this. http://www.spinics.net/lists/linux-btrfs/msg46537.html http://www.spinics.net/lists/linux-btrfs/msg46279.html The last one Anand Jain (developer) replied: http://www.spinics.net/lists/linux-btrfs/msg46303.html So I'm not sure if this problem is the same, and if the cause is known. Best I can suggest is to try a newer kernel. Even 4.4.0rc8 is stable enough to try; but there were quite a few btrfs patches for 4.3.3 as well. I would try 4.4.0 first to see if it reproduces. If not, then try 4.3.3. >4.3.0-040300rc7-generic #201510260712 SMP Mon Oct 26 >11:27:59 UTC 2015 i686 i686 i686 GNU/Linux I think the other two cases are x86-64 so I don't think i686 is related. There are quite a few messages: swapper/6: page allocation failure: order:0, mode:0x20 [1129393.648245] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G W OE 4.3.0-040300rc7-generic #201510260712 So the kernel is in a tainted state, I can't tell if that's related. And also usb 4-1.2: reset high-speed USB device number 7 using ehci-pci One happens less than a minute before the first btrfs call trace. I've had these messages also with USB drives, and they usually don't cause a problem, and in my research it seems they can usually be ignored except when there's subsequent problems. I ended up getting a powered hub to put all the USB drives on and now I don't get these messages anymore (so far anyway) and I also haven't had any Btrfs errors, which I did rarely have happen prior to moving to the USB 3 powered hub; even though the power shouldn't have been a factor since the drives want 900mA at most (usually just spinning up), and standard USB 3 supplies 900mA. Anyway, easiest is to move to a newer kernel to try to reproduce and then start looking at hardware issues. What specific drive is /dev/sdd? I'd make a note of that particular drive and see if it's the same drive (not drive letter) if the problem happens again. --- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
