Kernel BUG at c02cc29c - Linux xbian 3.18.8+

[ErickPH]

I just want to report this bug that I have after very intense download sessions with my Rpi B+ model, 2TB usb3 Hdd and wireless mouse and keyboard. It always happen when my 15Mbit internet connection is downloading at 1.5Mbit/s and I am doing nothing but waiting for the download to finish.

details: XBian 20150304-2 - Bleeding Edge, xbian@xbian ~ $ uname -a Linux xbian 3.18.8+ #1 PREEMPT Thu Mar 5 03:43:34 CET 2015 armv6l GNU/Linux xbian@xbian ~ $

I apologize for capturing with my camera. But I dont know how to dump this or any debug log from xbian to a txt file for later retrieval.

[f1vefour]

Try the kernel I linked in my last post of Issue #698 please.

[ErickPH]

@f1vefour Will try your kernel right now. BTW after reading the other referenced post, here are some additional details

root@xbian /boot # cat cmdline.txt
telnet zswap.enabled=1 zswap.compressor=lz4 sdhci-bcm2708.sync_after_dma=0 dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootflags=subvol=root/@,thread_pool=2,autodefrag,compress=lz4,commit=120 rootfstype=btrfs rootwait smsc95xx.turbo_mode=N logo.nologo quiet noswap loglevel=0 mod_scsi.scan=sync partswap startevent=mountall splash nohdparm --startup-event mountall
root@xbian /boot #

root@xbian /boot # cat config.txt
#initramfs initramfs.gz  0x1000000
gpu_mem_1024=256
gpu_mem_512=144
gpu_mem_256=100
initial_turbo=3
hdmi_ignore_cec_init=1
disable_overscan=1
disable_splash=1
arm_freq=950
core_freq=450
sdram_freq=500
over_voltage=2
root@xbian /boot #

[f1vefour]

Thanks for the additional information, don't change to LZO or anything. I want to see if the kernel resolves the issue without changing anything else.

[ErickPH]

@f1vefour system booted with new kernel. root@xbian ~ # uname -a Linux xbian 3.19.3+ #4 PREEMPT Sat Mar 28 17:46:53 UTC 2015 armv6l GNU/Linux root@xbian ~ #

BTW I timed the pre and post kernel change and now It takes 1:09 minutes to boot. For me the system is booted when my USB3 HDD is mounted and I can access it via console. Before kernel change it took 1:23minutes.

Since it seems this bug may be IO (btrfs) related I have a question: My HDD was formated btrfs the first time I used Xbian back in RC2. Can it be something related to the btrfs tools used to format the hdd back then? If I remember correctly RC2 was LZO and not LZO4... I just kept using the HDD without any reformating. I dont have a place to dump 1.9TB of movies hehehe (perhaps this is pure nonsense...im not an expert on this subject)

[f1vefour]

It should be forward compatible if your drive was LZO since this is the standard included compression algorithm in BTRFS, meaning a mixture of LZO/LZ4 should work without issues. At least I believe it to be this way, @mk01 is our resident BTRFS expert.

[ErickPH]

So far....no crashes....but will need more hours to verify. will post back in about20 hours. Also, wanted to monitor with IOTOP but found but it requires I/O accounting enabled in the kernel. Will io accounting be enabled in future kernels now that we have RPI2?

[ErickPH]

I have scrubbed my disk, performed @hackedbellini (https://github.com/xbianonpi/xbian/issues/698) stress test while copying 1TB of data. And did some file transfer while watching a movie.

As of now, no crashes. Some more hours to test before begining movie party.

[f1vefour]

As far as IO accounting you will need to find out what needs to be enabled in the kernel configuration and create a enhancement git request including what needs enabled and I will likely add it.

[ErickPH]

@f1vefour So far, no Kernel Panics and I have made sure I keep my CPU highly stressed as well as the IO subsys. I consider this ticket solved with the new kernel xbian-package-kernel_3.19.3+_armhf.deb.

will see what i need to enable accounting and report back.

Thanks @f1vefour for your fast and correct help.

Will close.

[mk01]

@ErickPH

compression (type) is per block (so each block holds info about used compression). during mount (with corresponding compress=XXX) btrfs writes "feature flag" used - what will be needed during future mounts.

so actual compress= per each mount has no user / system / platform impact (considering all used kernels do support the same scope of feature flags).

the other implications: mount -o compress=off - writes no required feature flags mount -o compress=lz4 - writes LZ4 flag needed and requires it on EACH future mount - regardless of how many (even 0) block were saved and compressed during that mount (so lz4 was practically used).

(((although XBian uses compress=lz4 as default, image is prepared with lzo. that also means, that user can after flashing image (and BEFORE first boot) change the mount options (to off or lzo) and will make that way it's installation mountable on any kernel (above 3.8 I have the feeling)))

but once the image boots, lz4 is written as needed. then only kernel patched for btrfs/lz4 will mount it.