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.
The real problem is that you hit a panic during xfstests.
kernel BUG at fs/ext4/extents.c:1919!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/block/loop0/dev
Modules linked in: ext4 jbd2 nfs fscache(T) nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc cpufreq_ondemand powernow_k8 ipv6 dm_mirror dm_region_hash dm_log bnx2 sg microcode serio_raw k10temp i2c_piix4 ext3 jbd mbcache dm_round_robin scsi_dh_rdac sd_mod crc_t10dif mptsas mptscsih mptbase scsi_transport_sas qla2xxx scsi_transport_fc scsi_tgt radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core dm_multipath dm_mod [last unloaded: scsi_wait_scan]
Pid: 11886, comm: fiemap-tester Tainted: G ---------------- T (2.6.32-131.6.1.el6.i686 #1) BladeCenter LS22 -[79013SG]-
EIP: 0060:[<fe4f190b>] EFLAGS: 00210212 CPU: 0
EIP is at ext4_ext_walk_space+0x29b/0x2f0 [ext4]
EAX: 00000000 EBX: 00000119 ECX: 0000008a EDX: 00000085
ESI: edfb96c0 EDI: 00000001 EBP: ea5201bc ESP: dc147e88
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process fiemap-tester (pid: 11886, ti=dc146000 task=ee19d570 task.ti=dc146000)
Stack:
ea5201bc dc147f68 00001000 dc147ed8 00000004 000000e8 00000000 e731bd64
<0> 00000201 e731bd54 00000004 e731bcdc 00048cca 00000000 00000000 00000118
<0> 000000e8 00000001 e731bd64 dc147f68 fffffee8 00000119 fe4f1aca fe4efac0
Call Trace:
[<fe4f1aca>] ? ext4_fiemap+0x16a/0x1e0 [ext4]
[<fe4efac0>] ? ext4_ext_fiemap_cb+0x0/0x210 [ext4]
[<c05a4f72>] ? file_has_perm+0xd2/0xe0
[<c05380b5>] ? do_vfs_ioctl+0x505/0x5c0
[<c05381e6>] ? sys_ioctl+0x76/0x90
[<c04ad970>] ? __audit_syscall_exit+0x220/0x250
[<c0409bdf>] ? sysenter_do_call+0x12/0x28
Code: e9 eb fe ff ff 8b 4c 24 1c bd fb ff ff ff c7 44 24 08 54 be 50 fe c7 04 24 26 4d 50 fe 89 4c 24 04 e8 0a 71 ff ff e9 c5 fe ff ff <0f> 0b eb fe 0f 0b eb fe 0f 0b 8d 74 26 00 8d bc 27 00 00 00 00
EIP: [<fe4f190b>] ext4_ext_walk_space+0x29b/0x2f0 [ext4] SS:ESP 0068:dc147e88
The second problem is that your kdump is misconfigured.
Saving to the local filesystem /dev/sdc2
e2fsck 1.41.12 (17-May-2010)
fsck.ext3: No such device or address while trying to open /dev/sdc2
Possibly non-existent or swap device?
mount: mounting /dev/sdc2 on /mnt failed: No such device or address
Attempting to enter user-space to capture vmcore
So, it then tried to enter user-space to capture vmcore which your system was running out of free memory from reserved 128MB at that time, but unfortunately oom won't work in kdump kernel.
The bug is in:
ext4_ext_walk_space()
{
...
while (block < last && block != EXT_MAX_BLOCK) {
...
BUG_ON(end <= start);
Given that this function is ONLY used for fiemap, BUG_ON is quite a terrible result - we should at least just fail the fiemap call with a message I suppose rather than taking down the box...
Duping because the bug summary is identical to 692063.
Please open a new bug explicitly for the memory-related issues you mentioned; I'm not quite sure what the actual issue is there.
Thanks,
-Eric
*** This bug has been marked as a duplicate of bug 692063 ***