DMAR: ERROR: DMA PTE for vPFN 0x7bf32 already set
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
I'm running Ubuntu 22.04 with kernel 5.15.0.27.30 on an HPE ProLiant DL20 Gen9 server. The server has an HPE Smart HBA H240 SATA controller.
Since Ubuntu 22.04, the kernel runs into trouble after a few hours of uptime. The problem starts with a few instances of a message such as this:
Apr 26 12:03:37 <hostname> kernel: DMAR: ERROR: DMA PTE for vPFN 0x7bf32 already set (to 7bf32003 not 24c563801)
Apr 26 12:03:37 <hostname> kernel: ------------[ cut here ]------------
Apr 26 12:03:37 <hostname> kernel: WARNING: CPU: 1 PID: 10171 at drivers/
Apr 26 12:03:37 <hostname> kernel: Modules linked in: tls rpcsec_gss_krb5 binfmt_misc ip6t_REJECT nf_reject_ipv6 xt_hl ip6_tables ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG nf_log_syslog nft_limit xt_limi>
Apr 26 12:03:37 <hostname> kernel: drm_kms_helper aesni_intel syscopyarea sysfillrect sysimgblt fb_sys_fops xhci_pci cec crypto_simd i2c_i801 rc_core cryptd drm xhci_pci_renesas ahci i2c_smbus tg3 hpsa>
Apr 26 12:03:37 <hostname> kernel: CPU: 1 PID: 10171 Comm: kworker/u4:0 Not tainted 5.15.0-27-generic #28-Ubuntu
Apr 26 12:03:37 <hostname> kernel: Hardware name: HP ProLiant DL20 Gen9/ProLiant DL20 Gen9, BIOS U22 04/01/2021
Apr 26 12:03:37 <hostname> kernel: Workqueue: writeback wb_workfn (flush-253:2)
Apr 26 12:03:37 <hostname> kernel: RIP: 0010:__
Apr 26 12:03:37 <hostname> kernel: Code: 27 9d 4c 89 4d b8 4c 89 45 c0 e8 03 c5 fa ff 8b 05 e7 e6 40 01 4c 8b 45 c0 4c 8b 4d b8 85 c0 74 09 83 e8 01 89 05 d2 e6 40 01 <0f> 0b e9 7e b2 b1 ff 89 ca 48 83 >
Apr 26 12:03:37 <hostname> kernel: RSP: 0018:ffffc07782
Apr 26 12:03:37 <hostname> kernel: RAX: 0000000000000004 RBX: ffff9f0042062990 RCX: 0000000000000000
Apr 26 12:03:37 <hostname> kernel: RDX: 0000000000000000 RSI: ffff9f02b3d20980 RDI: ffff9f02b3d20980
Apr 26 12:03:37 <hostname> kernel: RBP: ffffc077826b2ff0 R08: 000000024c563801 R09: 000000000024c563
Apr 26 12:03:37 <hostname> kernel: R10: 00000000ffffffff R11: ffffffffc01550e0 R12: 000000000000000f
Apr 26 12:03:37 <hostname> kernel: R13: 000000000007bf32 R14: ffff9f00412f5800 R15: ffff9f0042062938
Apr 26 12:03:37 <hostname> kernel: FS: 000000000000000
Apr 26 12:03:37 <hostname> kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 26 12:03:37 <hostname> kernel: CR2: 00001530f676a01c CR3: 000000029c210001 CR4: 00000000002706e0
Apr 26 12:03:37 <hostname> kernel: Call Trace:
Apr 26 12:03:37 <hostname> kernel: <TASK>
Apr 26 12:03:37 <hostname> kernel: intel_iommu_
Apr 26 12:03:37 <hostname> kernel: ? __alloc_
Apr 26 12:03:37 <hostname> kernel: __iommu_
Apr 26 12:03:37 <hostname> kernel: __iommu_
Apr 26 12:03:37 <hostname> kernel: iommu_map_
Apr 26 12:03:37 <hostname> kernel: iommu_dma_
Apr 26 12:03:37 <hostname> kernel: __dma_map_
Apr 26 12:03:37 <hostname> kernel: dma_map_
Apr 26 12:03:37 <hostname> kernel: scsi_dma_
Apr 26 12:03:37 <hostname> kernel: hpsa_scsi_
Apr 26 12:03:37 <hostname> kernel: ? __blk_rq_
Apr 26 12:03:37 <hostname> kernel: hpsa_scsi_
Apr 26 12:03:37 <hostname> kernel: hpsa_ioaccel_
Apr 26 12:03:37 <hostname> kernel: hpsa_scsi_
Apr 26 12:03:37 <hostname> kernel: ? recalibrate_
Apr 26 12:03:37 <hostname> kernel: scsi_dispatch_
Apr 26 12:03:37 <hostname> kernel: scsi_queue_
Apr 26 12:03:37 <hostname> kernel: blk_mq_
Apr 26 12:03:37 <hostname> kernel: ? __sbitmap_
Apr 26 12:03:37 <hostname> kernel: __blk_mq_
Apr 26 12:03:37 <hostname> kernel: __blk_mq_
Apr 26 12:03:37 <hostname> kernel: blk_mq_
Apr 26 12:03:37 <hostname> kernel: __blk_mq_
Apr 26 12:03:37 <hostname> kernel: __blk_mq_
Apr 26 12:03:37 <hostname> kernel: blk_mq_
Apr 26 12:03:37 <hostname> kernel: blk_mq_
Apr 26 12:03:37 <hostname> kernel: blk_mq_
Apr 26 12:03:37 <hostname> kernel: blk_flush_
Apr 26 12:03:37 <hostname> kernel: blk_mq_
Apr 26 12:03:37 <hostname> kernel: __submit_
Apr 26 12:03:37 <hostname> kernel: ? mempool_
Apr 26 12:03:37 <hostname> kernel: __submit_
Apr 26 12:03:37 <hostname> kernel: submit_
Apr 26 12:03:37 <hostname> kernel: ? radix_tree_
Apr 26 12:03:37 <hostname> kernel: ? bio_associate_
Apr 26 12:03:37 <hostname> kernel: submit_
Apr 26 12:03:37 <hostname> kernel: ? wbc_account_
Apr 26 12:03:37 <hostname> kernel: submit_
Apr 26 12:03:37 <hostname> kernel: __block_
Apr 26 12:03:37 <hostname> kernel: ? block_invalidat
Apr 26 12:03:37 <hostname> kernel: ? blkdev_
Apr 26 12:03:37 <hostname> kernel: block_write_
Apr 26 12:03:37 <hostname> kernel: blkdev_
Apr 26 12:03:37 <hostname> kernel: __writepage+
Apr 26 12:03:37 <hostname> kernel: write_cache_
Apr 26 12:03:37 <hostname> kernel: ? __set_page_
Apr 26 12:03:37 <hostname> kernel: generic_
Apr 26 12:03:37 <hostname> kernel: ? __blk_mq_
Apr 26 12:03:37 <hostname> kernel: blkdev_
Apr 26 12:03:37 <hostname> kernel: do_writepages+
Apr 26 12:03:37 <hostname> kernel: ? __percpu_
Apr 26 12:03:37 <hostname> kernel: ? __blk_mq_
Apr 26 12:03:37 <hostname> kernel: ? mem_cgroup_
Apr 26 12:03:37 <hostname> kernel: ? cpumask_
Apr 26 12:03:37 <hostname> kernel: __writeback_
Apr 26 12:03:37 <hostname> kernel: writeback_
Apr 26 12:03:37 <hostname> kernel: __writeback_
Apr 26 12:03:37 <hostname> kernel: wb_writeback+
Apr 26 12:03:37 <hostname> kernel: wb_do_writeback
Apr 26 12:03:37 <hostname> kernel: wb_workfn+
Apr 26 12:03:37 <hostname> kernel: ? psi_task_
Apr 26 12:03:37 <hostname> kernel: ? finish_
Apr 26 12:03:37 <hostname> kernel: process_
Apr 26 12:03:37 <hostname> kernel: worker_
Apr 26 12:03:37 <hostname> kernel: ? process_
Apr 26 12:03:37 <hostname> kernel: kthread+0x12a/0x150
Apr 26 12:03:37 <hostname> kernel: ? set_kthread_
Apr 26 12:03:37 <hostname> kernel: ret_from_
Apr 26 12:03:37 <hostname> kernel: </TASK>
Apr 26 12:03:37 <hostname> kernel: ---[ end trace 6eaabfe8ad4492e0 ]---
Afterwards, messages like
Apr 26 12:55:29 <hostname> kernel: dmar_fault: 152 callbacks suppressed
Apr 26 12:55:29 <hostname> kernel: DMAR: DRHD: handling fault status reg 2
Apr 26 12:55:29 <hostname> kernel: DMAR: [DMA Write NO_PASID] Request device [06:00.0] fault addr 0x7bf4a000 [fault reason 0x05] PTE Write access is not set
or
Apr 26 12:56:50 <hostname> kernel: dmar_fault: 152 callbacks suppressed
Apr 26 12:56:50 <hostname> kernel: DMAR: DRHD: handling fault status reg 2
Apr 26 12:56:50 <hostname> kernel: DMAR: [DMA Read NO_PASID] Request device [06:00.0] fault addr 0x7bf32000 [fault reason 0x06] PTE Read access is not set
are logged continuously. The logged device ID 06:00.0 is the HPE SATA controller.
The errors go away after a reboot until the problem occurs again after a few hours. In most cases, the server even reports a hardware fault and the storage fan spins up to 100 %.
The problem did _not_ occur in Ubuntu 20.04, the last 20.04 kernel I ran on this server was 5.13.0.
Setting the intel_iommu=off kernel boot parameter seems to work around the problem.
information type: | Public → Public Security |
information type: | Public Security → Public |
Status changed to 'Confirmed' because the bug affects multiple users.