I've a lot of panics with the rc1, rc2 and rc3 of kernel 2.6.38. I've a few btrfs partitions with uncompressed data and compressed data with lzo and zlib. Before of 2.6.38, I've used zlib compression for months without any problem. The bug occur with intensive IO activity and without that.
"lzo1x_decompress_safe" and "last sysfs file: /sys/devices/system/cpu/cpu3/cache" appears always.
Created attachment 46352 [details]
Output of /proc/version
Created attachment 46362 [details]
Output of ver_linux
Created attachment 46372 [details]
Output of /proc/cpuinfo
Created attachment 46382 [details]
Output of /proc/modules
Created attachment 46392 [details]
Output of /proc/ioports
Created attachment 46402 [details]
Output of /proc/iomem
Created attachment 46412 [details]
Output of lspci
Created attachment 46422 [details]
Output of /proc/scsi/scsi
The same problem with 2.6.38-rc4.
I've tried with many configurations in the kernel and the bug persist. Also I've tested with this kernel of Fedora ( http://koji.fedoraproject.org/koji/buildinfo?buildID=218287 ) and the same problem.
I really need this bug fixed, the computer is unusable with this. If you need any type of testing or more information, let me know.
I've tried the x86 and amd64 versions of the livecd of Ubuntu 11.04 alpha-2 ( http://cdimage.ubuntu.com/releases/natty/alpha-2/ ). Both have the kernel 2.6.38 rc1.
The amd64 version works without problems. The x86 version fail with the same Oops.
I've removed the regression label in this bug because I thought that the problem affect also to the zlib compression but the bug is only in the lzo code (new in 2.6.38).
For the people that has used the lzo compression and now can't access to their data:
- Run a amd64 system or amd64 livecd. Never with a x86 system.
- Mount the partition or subvolume with data inaccessible without the lzo compression activated.
- Mount other partition or subvolume without the lzo compression activated.
- Copy all data from the old partition or subvolume to the other partition or subvolume.
- Remove all data in the old partition or subvolume.
- Now copy the data again to the old subvolume or partition.
- Sync the filesystems or reboot.
Could you please post the oops? I'm unable reproduce this locally.
I'm sorry. I forgot the more important file :) .
Created attachment 47712 [details]
Thanks for the report! I'll look into it.
I managed to trigger the bug after running a test script for about 10 hours, and I think I know what's the cause.
I think that your patch fix the bug. I've tested the kernel 2.6.38-rc5+patch with intensive disk activity for more than 24 hours and all works perfect. Thank you so much for your work :) . You can close the bug.
The fix has been merged into v2.6.38-rc7:
Author: Li Zefan <firstname.lastname@example.org>
Date: Wed Feb 16 06:06:41 2011 +0000
Btrfs: Avoid accessing unmapped kernel address