kernel BUG at /build/linux-hwe-Fuabdm/linux-hwe-4.13.0/fs/jbd2/transaction.c:1868!

Bug #1753489 reported by dann frazier
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

[ 1678.415861] kernel BUG at /build/linux-hwe-Fuabdm/linux-hwe-4.13.0/fs/jbd2/transaction.c:1868!
[ 1678.425019] Internal error: Oops - BUG: 0 [#1] SMP
[ 1678.430358] Modules linked in: nls_iso8859_1 i2c_thunderx i2c_smbus cavium_rng_vf thunderx_edac thunderx_zip shpchp ipmi_ssif cavium_rng gpio_keys ipmi_devintf ipmi_msghandler uio_pdrv_genirq uio ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs algif_skcipher af_alg dm_crypt raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear nicvf nicpf ast i2c_algo_bit ttm drm_kms_helper syscopyarea aes_ce_blk sysfillrect sysimgblt aes_ce_cipher fb_sys_fops crc32_ce crct10dif_ce drm ghash_ce sha2_ce sha1_ce ahci libahci thunder_bgx thunder_xcv mdio_thunder thunderx_mmc mdio_cavium aes_neon_bs aes_neon_blk crypto_simd cryptd
[ 1678.503033] CPU: 3 PID: 776 Comm: jbd2/dm-1-8 Tainted: G W L 4.13.0-36-generic #40~16.04.1-Ubuntu
[ 1678.515386] Hardware name: Cavium ThunderX CRB/To be filled by O.E.M., BIOS 5.11 12/12/2012
[ 1678.525143] task: ffff801f8a75e900 task.stack: ffff801f633fc000
[ 1678.532489] PC is at __jbd2_journal_temp_unlink_buffer+0x104/0x160
[ 1678.540140] LR is at __jbd2_journal_file_buffer+0x8c/0x1f8
[ 1678.547111] pc : [<ffff0000083bc4bc>] lr : [<ffff0000083bd4f4>] pstate: 80400145
[ 1678.556071] sp : ffff801f633ffb70
[ 1678.560960] x29: ffff801f633ffb70 x28: ffff7e007ca625c0
[ 1678.567890] x27: 0000000000000000 x26: ffff801ecd5776e8
[ 1678.574845] x25: 0000000000000000 x24: 0000000001400040
[ 1678.581812] x23: 0000000000000001 x22: ffff801f3f4bb8f0
[ 1678.588799] x21: 0000000000000003 x20: ffff801f3f4bb8f0
[ 1678.595787] x19: ffff801f4a18ea50 x18: 0000000000000000
[ 1678.602807] x17: 0000000000000000 x16: 0000000000000000
[ 1678.609844] x15: 00000000ddd41681 x14: 000000003a7accb0
[ 1678.616895] x13: 000000004d1a8a2c x12: 0000000091b5ac46
[ 1678.623964] x11: ffff801f79729770 x10: ffff0000093c8c08
[ 1678.631058] x9 : 000000000000001d x8 : ffff801ecd577750
[ 1678.638182] x7 : 0000000000000000 x6 : 0000000000000001
[ 1678.645323] x5 : 0000000000000000 x4 : 0000000000400000
[ 1678.652468] x3 : 0000000000000016 x2 : ffff801f6d655a28
[ 1678.659633] x1 : 00000000ffffffff x0 : ffff801f6d655a00
[ 1678.666808] Process jbd2/dm-1-8 (pid: 776, stack limit = 0xffff801f633fc000)

Revision history for this message
dann frazier (dannf) wrote :
Changed in linux (Ubuntu):
status: New → Confirmed
Changed in linux (Ubuntu Artful):
status: New → Confirmed
Changed in linux (Ubuntu Bionic):
status: Confirmed → New
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1753489

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: artful
dann frazier (dannf)
summary: - arm64 - stress_ng triggers panic on crypted lvm
+ kernel BUG at /build/linux-hwe-Fuabdm/linux-
+ hwe-4.13.0/fs/jbd2/transaction.c:1868!
Revision history for this message
dann frazier (dannf) wrote :

I believe this occurred while running disk/disk_stress_ng_dm-1 from the certification test suite on the system in our lab called "seuss", which had been installed manually w/ d-i, using LVM w/ crypted home. (I dug that info out of LP: #1749040, from whence this bug was spawned).

Since this crash occurred in filesystem code - and we didn't see this crash in other configs - it's possible that an LVM crypt setup is relevant to the reproduction.

My suggestion for next steps would be to recreate this setup (same kernel, partitioning scheme, running the test from $HOME), and run the test several times (maybe overnight in a loop) to see if we can reproduce the same failure. Note that at least one other failure has been observed while running this test - what we're looking for is another panic in jbd code.

Revision history for this message
Manoj Iyer (manjo) wrote :
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments