On 9/22/16 8:18 AM, Rich Freeman wrote: > I have been getting panics consistently after doing a btrfs replace > operation on a raid1 and rebooting. I linked a photo of the panic; I > haven't been able to get a text capture of it. > > https://ibin.co/2vx0HhDeViu3.jpg > > I'm getting this error on the latest 4.4, 4.1, and even on an old > 3.18.26 kernel I had lying around. > > I tried the remove root_log_ctx from ctx list before btrfs_sync_log > returns patch on 4.1 and that did not solve my problem either. > > I'm able to boot into single-user mode and if I don't start any > processes the system seems fairly stable. I am also able to start a > btrfs balance and run that for several hours without issue. If I > start launching services the system will tend to panic, though how > many processes I can launch will vary. I don't think that it is a > particular file being accessed that is triggering the issue since the > point where it fails varies. I suspect it may be load-related. > > Mounting with compress=no doesn't seem to help either. Granted, I see > lzo_decompress in the backtrace and that is probably a read operation. > > Any suggestions? Google hasn't been helpful on this one...
Can you boot with panic_on_oops=1, reproduce it, and capture that Oops? The trace in your photo is a secondary Oops (tainted D), which means that something else went wrong before that and now the system is tripping over it. Secondary Oopses don't really help the debugging process because the system was already in a broken, undefined, state. -Jeff -- Jeff Mahoney SUSE Labs
Description: OpenPGP digital signature