On 18/12/2014 05:28, NeilBrown wrote: > I suspect md/raid5 is sending down a discard request in some way that the > scsi/sata layer or driver doesn't like, but without the full oops, I really > cannot guess what it might be. We've tried 4 times to reproduce the panic we got originally, but unforunately with no luck. Below are the outputs from all four crashes as captured by netconsole, in case they are any help. Crash #1 [63207.177400] BUG: unable to handle kernel paging request at 0000001e00008000 Crash #2 [ 531.210340] BUG: unable to handle kernel paging request at 0000000100000000 [ 531.210514] IP:[ 531.210340] BUG: unable to handle kernel [<ffffffff8128788e>] __blk_segment_map_sg+0x5e/0x1b0 paging request[ 531.210632] PGD 20187f067 PUD 0 at 0000000100000000 [ 531.210514] IP: [<ffffffff8128788e>] __blk_segment_map_sg+0x5e/0x1b0 [ 531.210632] PGD 20187f067 PUD 0 [ 531.210783] Oops: 0000 [#1] SMP [ 531.210932] Modules linked in: eql netconsole configfs raid456[ 531.210783] Oops: 0000 [#1] SMP [ 531.210932] Modules linked in: eql netconsole configfs raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq xt_multiport async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq xt_multiport xt_tcpudp iptable_filter ip_tables x_tables aesni_intel aes_x86_64 glue_helper lrw xt_tcpudp iptable_filter ip_tables x_tables aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd ppdev gf128mul ablk_helper cryptd ppdev Crash #3 [ 268.115094] general protection fault: 0000 [#1] SMP [ 268.115263] Modules linked in:[ 268.115094] general protection fault: 0000 [#1] SMP [ 268.115263] Modules linked in: Crash #4 [ 276.325157] general protection fault: 0000 [#1] SMP -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
