Hide Forgot
Description of problem: Panic in btrfs-endio-wri when checksum verify failed. Issue discussed directly with code owner. <josef> hrm bad checksums <josef> shouldnt have paniced tho <neb> before this happened. my machine which was doing an yum update from 5.5 to 5.6 on a disk that was on an external usb drive formatted with btrfs froze forcing me to hard power my system <neb> no crash log from that <neb> sorry <neb> so the FS could have been very inconsistent <josef> yeah thats probably why it crashed <josef> so can you do the following <josef> gdb <your btrfs.ko> <josef> list *(read_extent_buffer+22) <josef> oh heh i know what went wrong <josef> i'll fix it <neb> (gdb) list *(read_extent_buffer+22) <neb> 0x42396 is in read_extent_buffer (fs/btrfs/extent_io.c:3485). <neb> 3480 char *kaddr; <neb> 3481 char *dst = (char *)dstv; <neb> 3482 size_t start_offset = eb->start & ((u64)PAGE_CACHE_SIZE - 1); <neb> 3483 unsigned long i = (start_offset + start) >> PAGE_CACHE_SHIFT; <neb> 3484 <neb> 3485 WARN_ON(start > eb->len); <neb> 3486 WARN_ON(start + len > eb->start + eb->len); <neb> 3487 <neb> 3488 offset = (start_offset + start) & ((unsigned long)PAGE_CACHE_SIZE - 1); <neb> 3489 <josef> thats what i thought <josef> cool, i'll fix that up <neb> thansk <josef> np <josef> actually one more thing <josef> can you do <josef> list *(btrfs_del_csums+0x1bf) <josef> just so i know its where i think it is (gdb) list *(btrfs_del_csums+0x1bf) 0x19f8f is in btrfs_del_csums (fs/btrfs/ctree.h:1678). 1673 static inline void btrfs_disk_key_to_cpu(struct btrfs_key *cpu, 1674 struct btrfs_disk_key *disk) 1675 { 1676 cpu->offset = le64_to_cpu(disk->offset); 1677 cpu->type = disk->type; 1678 cpu->objectid = le64_to_cpu(disk->objectid); 1679 } 1680 1681 static inline void btrfs_cpu_key_to_disk(struct btrfs_disk_key *disk, 1682 struct btrfs_key *cpu) Version-Release number of selected component (if applicable): kernel 2.6.32-71.14.1.el6.x86_64 Actual results: Expected results: Additional info: Crash log http://pastebin.com/ZRQnK1Gp
*** This bug has been marked as a duplicate of bug 698324 ***