Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
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