On May 9, 2014, at 7:05 PM, Hugo Mills <h...@carfax.org.uk> wrote: > On Fri, May 09, 2014 at 05:42:54PM -0700, Marc MERLIN wrote: >> On Sat, May 10, 2014 at 10:13:43AM +1000, Chris Samuel wrote: >>>> Right now, I do see: >>>> legolas:~# cat /proc/sys/kernel/tainted >>>> 512 >>> >>> IIUC that's an array of bit flags, and that value means you've had a >>> previous >>> kernel warning at that point according to: >>> >>> https://www.kernel.org/doc/Documentation/sysctl/kernel.txt >> >> Yep, I meant to say that I don't have the 'G' now. > > G is actually good, I think. IIRC, it's "everything we've had to > this point has been under a license where we have the source > available". It's when you load a proprietary module that you get the P > and the G goes away. > >> It's likely that vbox did 'G' even if I didn't successfully start it, >> and even if I haven't had problems with it 'till now, it's a possible >> culprit (more details below) > > I think G is actually a default state, and is "good".
The G just means it's not a proprietary kernel module, but it's still out of tree. So the kernel is in a state that we don't really know, without finding out what's causing it to be tainted. If it's a video or wireless driver (pretty likely) then it's probably sufficiently unrelated to fs to not matter. However, I have a recent case in VBox guest, with guest additions built. That cause the kernel to be tainted G because it's an out of tree kernel module for guest additions. I'm getting a bunch of Btrfs errors that aren't reproducible with an untainted kernel. So I'm not filing a bug against Btrfs, instead I've filed a bug against VirtualBox because I'm also getting a pile of read write errors with /dev/sda which is backed by a VDI. A virtual device producing hardware read write errors (as far as linux kernel is concerned). But only with guest additions loaded. And the sustained copy event that triggers it doesn't even involve sda. It's a shared folder copy as the source, to a raw device as destination. Yet I get dozens of read write errors on sda, and ensuing Btrfs complaints as well. But in this case Btrfs is behaving exactly as I'd expect. What's unexpected is the virtual sata device behaving wrong, but apparently only with guest additions loaded. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html