linux-ck: btrfs scrub causes kernel panic

erikf · 2015-02-14 16:29:42

Hi everyone!

I have run into some serious problems with the combination of btrfs and linux-ck. Running a scrub like this

# btrfs scrub start -B /

nearly immediately causes a kernel panic if a linux-ck kernel is running. This happens to me on two different machines; both with a btrfs root fs. Both machines perform the scrub just fine using the arch kernel. So I think this must have something to do with the ck-patchset.

This also happens with several different repo-ck packages. I have tested so far from repo-ck:

linux-ck
linux-ck-piledriver
linux-ck-core2

The same happens if I compile the ck-kernel with the linux-ck package from the AUR.

Has someone any idea what causes the kernel panic? I would like to continue using the ck-kernel but I am afraid it might silently eat my data...

The only other lead I have is, that I am pretty sure this did not happen when I first started using btrfs.

Best regards,
Erik

PS:
uname -a:
Linux pilatus 3.18.7-1-ck #1 SMP PREEMPT Wed Feb 11 15:27:10 EST 2015 x86_64 GNU/Linux

kernel output (kernel built with linux-ck from the AUR in a clean chroot):

[  166.205351] kernel BUG at block/bfq-sched.c:634!
[  166.208070] invalid opcode: 0000 [#1] PREEMPT SMP 
[  166.210822] Modules linked in: netconsole arc4 md4 md5 hmac nls_utf8 cifs dns_resolver fuse cfg80211 nct6775 hwmon_vid nls_iso8859_1 nls_cp437 vfat fat ecb kvm_amd kvm sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi ath3k btusb snd_hda_intel mousedev bluetooth joydev nfs snd_hda_controller aesni_intel aes_x86_64 alx lrw gf128mul glue_helper ablk_helper cryptd psmouse mdio snd_hda_codec shpchp rfkill snd_hwdep pcspkr k10temp crc16 lockd hwmon serio_raw snd_pcm grace snd_timer i2c_piix4 snd soundcore tpm_tis i2c_core tpm sunrpc fscache acpi_cpufreq video fglrx(O) processor evdev mac_hid amd_iommu_v2 button btrfs xor raid6_pq sd_mod ata_generic pata_acpi hid_generic usbhid hid atkbd libps2 crc32c_intel ahci pata_atiixp libahci xhci_pci ohci_pci ohci_hcd ehci_pci ehci_hcd libata xhci_hcd usbcore scsi_mod usb_common i8042 serio
[  166.236171] CPU: 0 PID: 96 Comm: kworker/u8:5 Tainted: G           O   3.18.7-1-ck #1
[  166.239497] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./FM2A88X-ITX+, BIOS P1.40 11/19/2013
[  166.242942] Workqueue: btrfs-readahead btrfs_readahead_helper [btrfs]
[  166.246504] task: ffff880222875e80 ti: ffff8802225e4000 task.ti: ffff8802225e4000
[  166.249947] RIP: 0010:[<ffffffff8128baa7>]  [<ffffffff8128baa7>] __bfq_entity_update_weight_prio+0x2b7/0x2c0
[  166.253485] RSP: 0018:ffff8802225e7828  EFLAGS: 00010046
[  166.257011] RAX: 0000000000000020 RBX: ffff8800941b8cf0 RCX: 0000000000000020
[  166.260567] RDX: 0000000000000000 RSI: ffff88022ec0d2d8 RDI: ffff88022ec0d2d8
[  166.264125] RBP: ffff8802225e7898 R08: 0000000000000096 R09: 00000000000003be
[  166.267703] R10: ffff88021cc32000 R11: 00000000000003be R12: ffff8800941b8c80
[  166.271288] R13: ffff8800ab5ef2f8 R14: ffff8800ab5ef2f8 R15: 0000000000000000
[  166.274888] FS:  00007f651d86a800(0000) GS:ffff88022ec00000(0000) knlGS:0000000000000000
[  166.278537] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  166.282195] CR2: 0000000000684010 CR3: 0000000213e89000 CR4: 00000000000407f0
[  166.285889] Stack:
[  166.289538]  ffff8801d1b70900 ffff88009a88ac80 ffff8802238b7800 ffff8802238b79e0
[  166.293289]  0000000000000001 0000000000000286 ffff8802225e78d8 ffff88007fd7b328
[  166.297058]  ffff88007fcd8000 ffff8800941b8cf0 ffff8800941b8c80 ffff8800ab5ef288
[  166.300804] Call Trace:
[  166.304475]  [<ffffffff8128bb5d>] __bfq_activate_entity+0xad/0x4b0
[  166.308135]  [<ffffffff8128c171>] bfq_activate_entity+0x31/0x50
[  166.311725]  [<ffffffff8128ede8>] bfq_insert_request+0x3c8/0xfd0
[  166.315243]  [<ffffffff812589cc>] __elv_add_request+0x1dc/0x320
[  166.318690]  [<ffffffff81260063>] blk_queue_bio+0x373/0x390
[  166.322069]  [<ffffffff8125dd20>] generic_make_request+0xe0/0x130
[  166.325387]  [<ffffffff8125dde8>] submit_bio+0x78/0x180
[  166.328651]  [<ffffffffa0386cf3>] submit_stripe_bio+0x63/0x90 [btrfs]
[  166.331859]  [<ffffffffa038b866>] btrfs_map_bio+0x2e6/0x530 [btrfs]
[  166.335002]  [<ffffffffa035669b>] btree_submit_bio_hook+0xfb/0x100 [btrfs]
[  166.338090]  [<ffffffffa037a697>] submit_one_bio+0x67/0xa0 [btrfs]
[  166.341109]  [<ffffffffa0382536>] read_extent_buffer_pages+0x196/0x360 [btrfs]
[  166.344058]  [<ffffffff8113aae7>] ? unlock_page+0x27/0x30
[  166.346954]  [<ffffffffa03546f0>] ? free_root_pointers+0x60/0x60 [btrfs]
[  166.349806]  [<ffffffffa0356761>] reada_tree_block_flagged+0x61/0xc0 [btrfs]
[  166.352682]  [<ffffffffa03bf29c>] reada_start_machine_worker+0x33c/0x3b0 [btrfs]
[  166.355566]  [<ffffffffa038fed3>] normal_work_helper+0x73/0x350 [btrfs]
[  166.358449]  [<ffffffffa0390532>] btrfs_readahead_helper+0x12/0x20 [btrfs]
[  166.361320]  [<ffffffff81089a35>] process_one_work+0x145/0x3f0
[  166.364189]  [<ffffffff81089fbb>] worker_thread+0x4b/0x460
[  166.367051]  [<ffffffff81089f70>] ? init_pwq.part.30+0x10/0x10
[  166.369853]  [<ffffffff8108eba8>] kthread+0xd8/0xf0
[  166.372574]  [<ffffffff8108ead0>] ? kthread_create_on_node+0x1c0/0x1c0
[  166.375248]  [<ffffffff8153347c>] ret_from_fork+0x7c/0xb0
[  166.377847]  [<ffffffff8108ead0>] ? kthread_create_on_node+0x1c0/0x1c0
[  166.380392] Code: c2 66 89 53 5c 66 89 53 5a e9 13 fe ff ff 66 0f 1f 44 00 00 0f 0b 0f 0b 0f 0b 0f b7 f0 48 c7 c7 70 95 72 81 31 c0 e8 38 12 2a 00 <0f> 0b 0f 1f 80 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 41 
[  166.386014] RIP  [<ffffffff8128baa7>] __bfq_entity_update_weight_prio+0x2b7/0x2c0
[  166.388528]  RSP <ffff8802225e7828>
[  166.390989] ---[ end trace 1c3d6a3b488b1e3e ]---
[  166.393418] note: kworker/u8:5[96] exited with preempt_count 1

graysky · 2015-02-14 16:47:12

erikf wrote:

[  166.205351] kernel BUG at block/bfq-sched.c:634!
...

This line makes me think you have discovered a bug with the bfq scheduler, not the BFS. To test this hypothesis, do not enable the bfq io scheduling and (use cfq which is the ARCH default) and try the scrub again. If you can complete it without a panic, report the bug upstream: http://algo.ing.unimo.it/people/paolo/d … ources.php

erikf · 2015-02-14 17:28:03

Looks like the bfq scheduler might not be the culprit. I have switched to the cfq scheduler by changing the kernel command line to "elevator=cfq" (to make sure it is not touched at all) and I still get a kernel panic when running btrfs scrub. The kernel error messages are quite different this time around.

Kernel output follows (again the one built using linux-ck from the AUR):

[  180.040615] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[  180.043248] IP: [<ffffffff812867ad>] cfq_remove_request+0x2d/0x170
[  180.045821] PGD 205be0067 PUD 1cf400067 PMD 0 
[  180.048359] Oops: 0002 [#1] PREEMPT SMP 
[  180.050981] Modules linked in: netconsole arc4 md4 md5 hmac nls_utf8 cifs dns_resolver fuse cfg80211 nct6775 hwmon_vid nls_iso8859_1 nls_cp437 vfat fat ecb kvm_amd kvm snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul snd_hda_codec_generic ghash_clmulni_intel joydev alx ath3k snd_hda_codec_hdmi mdio mousedev btusb snd_hda_intel aesni_intel snd_hda_controller aes_x86_64 lrw bluetooth gf128mul glue_helper psmouse ablk_helper shpchp pcspkr cryptd k10temp snd_hda_codec hwmon serio_raw i2c_piix4 snd_hwdep rfkill snd_pcm crc16 i2c_core snd_timer snd soundcore tpm_tis tpm video acpi_cpufreq processor sch_fq_codel evdev mac_hid nfs lockd grace sunrpc fscache fglrx(O) amd_iommu_v2 button btrfs xor raid6_pq sd_mod ata_generic pata_acpi hid_generic usbhid hid atkbd libps2 crc32c_intel ahci pata_atiixp libahci xhci_pci ohci_pci ohci_hcd ehci_pci xhci_hcd libata ehci_hcd usbcore scsi_mod usb_common i8042 serio
[  180.073914] CPU: 3 PID: 0 Comm: BFS/3 Tainted: G           O   3.18.7-1-ck #1
[  180.076912] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./FM2A88X-ITX+, BIOS P1.40 11/19/2013
[  180.079990] task: ffff8802242f6660 ti: ffff880224390000 task.ti: ffff880224390000
[  180.082964] RIP: 0010:[<ffffffff812867ad>]  [<ffffffff812867ad>] cfq_remove_request+0x2d/0x170
[  180.085891] RSP: 0018:ffff88022ed83a38  EFLAGS: 00010007
[  180.088763] RAX: ffff880072b248a0 RBX: ffff880072b24a10 RCX: 0000000000000000
[  180.091650] RDX: 0000000000000000 RSI: ffff8802224c9df0 RDI: ffff880072b24a10
[  180.094544] RBP: ffff88022ed83a58 R08: 00000000002a2ce8 R09: 0000000000000000
[  180.097383] R10: ffff88022ed9002f R11: ffffea00079e002f R12: ffff880072b24a10
[  180.100116] R13: ffff8800ab1af3a0 R14: ffff880222628000 R15: ffff880072b248a0
[  180.102823] FS:  00007ffa3a64f700(0000) GS:ffff88022ed80000(0000) knlGS:0000000000000000
[  180.105503] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  180.108131] CR2: 0000000000000008 CR3: 00000001e83cb000 CR4: 00000000000407e0
[  180.110746] Stack:
[  180.113322]  ffff880072b24a10 ffff8800ab1af3a0 ffff880072b24a10 ffff8802224c9c00
[  180.115951]  ffff88022ed83b18 ffffffff81286ae0 ffff88022ed83a78 000000000000002f
[  180.118540]  0000000000000001 ffff8802228d002f ffff88022ed83ae8 ffffffff81097938
[  180.121105] Call Trace:
[  180.123574]  <IRQ> 
[  180.123600]  [<ffffffff81286ae0>] cfq_dispatch_insert+0xc0/0x2d0
[  180.128535]  [<ffffffff81097938>] ? try_preempt.isra.74+0x168/0x1b0
[  180.130934]  [<ffffffff8109c7a5>] ? sched_clock_cpu+0xb5/0xe0
[  180.133245]  [<ffffffff8108a3e5>] ? wq_worker_waking_up+0x15/0x70
[  180.135555]  [<ffffffff81286f58>] cfq_dispatch_requests+0x268/0xcc0
[  180.137793]  [<ffffffff81098477>] ? wake_up_process+0x27/0x50
[  180.140006]  [<ffffffff81086bf4>] ? wake_up_worker+0x24/0x30
[  180.142130]  [<ffffffff8108872e>] ? insert_work+0x6e/0xb0
[  180.144245]  [<ffffffff81088896>] ? __queue_work+0x126/0x360
[  180.146311]  [<ffffffff8125f6ef>] blk_peek_request+0x4f/0x2c0
[  180.148347]  [<ffffffffa0088ad8>] scsi_request_fn+0x48/0x5e0 [scsi_mod]
[  180.150297]  [<ffffffff8125ba97>] __blk_run_queue+0x37/0x50
[  180.152252]  [<ffffffff8125bdc6>] blk_run_queue+0x26/0x40
[  180.154158]  [<ffffffffa0086d08>] scsi_run_queue+0x258/0x2f0 [scsi_mod]
[  180.156165]  [<ffffffffa007f8c7>] ? scsi_host_free_command.isra.13+0x47/0x50 [scsi_mod]
[  180.158089]  [<ffffffffa00890b0>] scsi_next_command+0x20/0x40 [scsi_mod]
[  180.160046]  [<ffffffffa0089215>] scsi_end_request+0x145/0x1e0 [scsi_mod]
[  180.161997]  [<ffffffffa00893ca>] scsi_io_completion+0xba/0x620 [scsi_mod]
[  180.163855]  [<ffffffff81088b90>] ? execute_in_process_context+0x70/0x70
[  180.165764]  [<ffffffffa008037e>] scsi_finish_command+0xbe/0x100 [scsi_mod]
[  180.167657]  [<ffffffffa0088a5a>] scsi_softirq_done+0x11a/0x150 [scsi_mod]
[  180.169496]  [<ffffffff81265a0b>] blk_done_softirq+0x8b/0xb0
[  180.171268]  [<ffffffff8107550a>] __do_softirq+0xea/0x2d0
[  180.173038]  [<ffffffff8107585e>] irq_exit+0x8e/0xb0
[  180.174663]  [<ffffffff81535ffa>] do_IRQ+0x5a/0xf0
[  180.176285]  [<ffffffff81533fed>] common_interrupt+0x6d/0x6d
[  180.177891]  <EOI> 
[  180.177912]  [<ffffffff8101e849>] ? sched_clock+0x9/0x10
[  180.180934]  [<ffffffff813e2432>] ? cpuidle_enter_state+0x62/0x1a0
[  180.182409]  [<ffffffff813e2421>] ? cpuidle_enter_state+0x51/0x1a0
[  180.183875]  [<ffffffff813e2657>] cpuidle_enter+0x17/0x20
[  180.185293]  [<ffffffff8109d6b1>] cpu_startup_entry+0x391/0x420
[  180.186770]  [<ffffffff81049fe4>] start_secondary+0x1b4/0x1f0
[  180.188262] Code: 66 66 90 55 48 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 08 4c 8b af a8 00 00 00 49 39 7d 58 0f 84 12 01 00 00 48 8b 13 48 8b 43 08 <48> 89 42 08 48 89 10 8b 43 40 4c 8b a3 a8 00 00 00 48 89 1b 48 
[  180.191723] RIP  [<ffffffff812867ad>] cfq_remove_request+0x2d/0x170
[  180.193129]  RSP <ffff88022ed83a38>
[  180.194449] CR2: 0000000000000008
[  180.195764] ---[ end trace 00db7b84dd0795bd ]---
[  180.197070] Kernel panic - not syncing: Fatal exception in interrupt
[  180.198379] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
[  180.199582] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

erikf · 2015-02-14 17:50:04

I have tried another kernel. This time I tested linux-lts-ck (3.14.33). With this kernel btrfs scrub finishes just fine.

Seems like something broke between 3.14 and 3.18. Are there PKGBUILDs for 3.15 to 3.17 available somewhere? If so, I could check which versions cause the kernel panic with btrfs scrub.

ooo · 2015-02-14 21:03:56

there was a bug on bfs460/3.18-ck1 that caused lockups when running btrfs scrub, or other IO intensive tasks.
con kolivas posted a patch on his blog that fixed the issue for me & others, but looks like it didn't make it into graysky's linux-ck packages.

here's the patch: http://ck.kolivas.org/patches/bfs/3.0/3 … edio.patch
relevant comments from ck's blog here.

graysky · 2015-02-14 21:58:37

I was unaware of the patch. Can the OP try it and let me know if it fixes the issue? If so, I can include it and rebuild 3.18.7 with it.

EDIT: I see now from the comments on the blog that the patch is effective. I just bumped to 3.18.7-2 and am rebuilding repo packages. Should be a few hours before they are posted and indexed.

Last edited by graysky (2015-02-15 01:29:07)

graysky · 2015-02-15 01:29:14

Packages online now.

erikf · 2015-02-15 09:05:31

I have tested the new packages with mixed results:

ck-kernel + cfq-scheduler: btrfs scrub finishes.

ck-kernel + bfq-scheduler: btrfs scrub still causes a kernel panic on my AMD A10 6700T if "elevator=bfq" is set on the kernel command line (see kernel output below).

While I did the testing, I made some observations:

btrfs scrub works with ck-kernel and bfq on my T60 (core2duo).
scrubbing even works on the A10 A6700T if I switch to bfq after boot for sda and sdb (the two devices on which the root fs is)

It looks like the patch improves the situation, but on machines with fast IO the ck-kernel still runs into problems.

kernel output (kernel from linux-ck-piledriver-3.18.7-2):

[  103.366372] Modules linked in:[  103.366247] kernel BUG at block/bfq-sched.c:634!
 netconsole nct6775 hwmon_vid ecb nls_iso8859_1 nls_cp437 vfat fat kvm_amd ath3k kvm btusb snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul bluetooth ghash_clmulni_intel snd_hda_codec_generic rfkill snd_hda_codec_hdmi crc16 snd_hda_intel snd_hda_controller aesni_intel aes_x86_64 alx lrw gf128mul glue_helper ablk_helper cryptd mdio joydev snd_hda_codec psmouse snd_hwdep k10temp shpchp hwmon snd_pcm serio_raw pcspkr snd_timer sch_fq_codel i2c_piix4 i2c_core tpm_tis tpm snd soundcore nfs lockd grace sunrpc fscache video acpi_cpufreq processor fglrx(O) evdev mac_hid amd_iommu_v2 button hid_generic btrfs usbhid hid xor raid6_pq sd_mod ata_generic pata_acpi atkbd libps2 crc32c_intel pata_atiixp[  103.368284] RAX: 0000000000000020 RBX: ffff8800ab778070 RCX: 0000000000000020
[  103.370539] RDX: 0000000000000000 RSI: ffff88022ed0d2d8 RDI: ffff88022ed0d2d8
[  103.371515] RBP: ffff8802224a3898 R08: 0000000000000096 R09: 0000000000000398
[  103.372508] R10: ffff880222c70000 R11: 0000000000000398 R12: ffff8800ab778000
[  103.373558] R13: ffff88022283daf8 R14: ffff88022283daf8 R15: ffff88007fec3b00
[  103.374620] FS:  00007fe63e6cf700(0000) GS:ffff88022ed00000(0000) knlGS:0000000000000000
[  103.375681] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  103.376746] CR2: 0000000000684010 CR3: 000000021b019000 CR4: 00000000000407e0
[  103.377825] Stack:
[  103.378905]  ffff88021d61b200 ffff880222a99380 ffff8802229aa000 ffff8802229aa1e0
[  103.379952]  0000000000000001 0000000000000286 ffff8802224a38d8 ffff8800ab69faa8
[  103.381016]  ffff880222430000 ffff8800ab778070 ffff8800ab778000 ffff88022283da88
[  103.382135] Call Trace:
[  103.383222]  [<ffffffff8128bb5d>] __bfq_activate_entity+0xad/0x4b0
[  103.384379]  [<ffffffff8128c171>] bfq_activate_entity+0x31/0x50
[  103.385496]  [<ffffffff8128ede8>] bfq_insert_request+0x3c8/0xfd0
[  103.386598]  [<ffffffff812589cc>] __elv_add_request+0x1dc/0x320
[  103.387716]  [<ffffffff81260063>] blk_queue_bio+0x373/0x390
[  103.388801]  [<ffffffff8125dd20>] generic_make_request+0xe0/0x130
[  103.389996]  [<ffffffff8125dde8>] submit_bio+0x78/0x180
[  103.391204]  [<ffffffffa02eecf3>] submit_stripe_bio+0x63/0x90 [btrfs]
[  103.392404]  [<ffffffffa02f3866>] btrfs_map_bio+0x2e6/0x530 [btrfs]
[  103.393608]  [<ffffffffa02be69b>] btree_submit_bio_hook+0xfb/0x100 [btrfs]
[  103.394785]  [<ffffffffa02e2697>] submit_one_bio+0x67/0xa0 [btrfs]
[  103.395935]  [<ffffffffa02ea536>] read_extent_buffer_pages+0x196/0x360 [btrfs]
[  103.397102]  [<ffffffff8113aae7>] ? unlock_page+0x27/0x30
[  103.398325]  [<ffffffffa02bc6f0>] ? free_root_pointers+0x60/0x60 [btrfs]
[  103.399538]  [<ffffffffa02be761>] reada_tree_block_flagged+0x61/0xc0 [btrfs]
[  103.400781]  [<ffffffffa032729c>] reada_start_machine_worker+0x33c/0x3b0 [btrfs]
[  103.401990]  [<ffffffffa02f7ed3>] normal_work_helper+0x73/0x350 [btrfs]
[  103.403163]  [<ffffffffa02f8532>] btrfs_readahead_helper+0x12/0x20 [btrfs]
[  103.404348]  [<ffffffff81089a35>] process_one_work+0x145/0x3f0
[  103.405584]  [<ffffffff81089fbb>] worker_thread+0x4b/0x460
[  103.406739]  [<ffffffff81089f70>] ? init_pwq.part.30+0x10/0x10
[  103.407878]  [<ffffffff8108eba8>] kthread+0xd8/0xf0
[  103.408973]  [<ffffffff8108ead0>] ? kthread_create_on_node+0x1c0/0x1c0
[  103.410054]  [<ffffffff8153347c>] ret_from_fork+0x7c/0xb0
[  103.411107]  [<ffffffff8108ead0>] ? kthread_create_on_node+0x1c0/0x1c0
[  103.412152] Code: c2 66 89 53 5c 66 89 53 5a e9 13 fe ff ff 66 0f 1f 44 00 00 0f 0b 0f 0b 0f 0b 0f b7 f0 48 c7 c7 60 95 72 81 31 c0 e8 38 12 2a 00 <0f> 0b 0f 1f 80 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 41 
[  103.414455] RIP  [<ffffffff8128baa7>] __bfq_entity_update_weight_prio+0x2b7/0x2c0
[  103.415484]  RSP <ffff8802224a3828>
[  103.416490] ---[ end trace 5e3849f5fa8e91a2 ]---
[  103.417476] note: kworker/u8:2[87] exited with preempt_count 1

graysky · 2015-02-15 11:16:01

You should report this to CK on his blog (link provided earlier in thread).

ooo · 2015-02-15 11:46:06

It's still possible that you have discovered some rarely occuring bug in bfq scheduler also, hence the

erikf wrote:

[  103.366247] kernel BUG at block/bfq-sched.c:634!

you could test compiling a kernel with bfq, and none of the ck-patches. If the issue still persists on your AMD system, it would be good idea to report it upstream to bfq developers.

or it could be that ck missed something with his plugged IO fixes..

erikf · 2015-02-15 19:01:32

I have given it another try and took out the all patches except for the bfq patches. The issue remains and the output after the kernel panic looks the same.

I have used this PKGBUILD: http://pastebin.com/s1sUE9rG

Thanks to everyone for your input. I will take this to CK on this blog next.

ooo · 2015-02-15 22:58:25

erikf wrote:

I will take this to CK on this blog next.

CK isn't responsible for bfq patches.
Report it to bfq developers instead: http://algo.ing.unimo.it/people/paolo/disk_sched/

erikf · 2015-02-22 20:54:44

I just wanted to let you know that the bfq devs have come up with a patch which solves th issue.

Arch Linux

#1 2015-02-14 16:29:42

linux-ck: btrfs scrub causes kernel panic

#2 2015-02-14 16:47:12

Re: linux-ck: btrfs scrub causes kernel panic

#3 2015-02-14 17:28:03

Re: linux-ck: btrfs scrub causes kernel panic

#4 2015-02-14 17:50:04

Re: linux-ck: btrfs scrub causes kernel panic

#5 2015-02-14 21:03:56

Re: linux-ck: btrfs scrub causes kernel panic

#6 2015-02-14 21:58:37

Re: linux-ck: btrfs scrub causes kernel panic

#7 2015-02-15 01:29:14

Re: linux-ck: btrfs scrub causes kernel panic

#8 2015-02-15 09:05:31

Re: linux-ck: btrfs scrub causes kernel panic

#9 2015-02-15 11:16:01

Re: linux-ck: btrfs scrub causes kernel panic

#10 2015-02-15 11:46:06

Re: linux-ck: btrfs scrub causes kernel panic

#11 2015-02-15 19:01:32

Re: linux-ck: btrfs scrub causes kernel panic

#12 2015-02-15 22:58:25

Re: linux-ck: btrfs scrub causes kernel panic

#13 2015-02-22 20:54:44

Re: linux-ck: btrfs scrub causes kernel panic

Board footer