DMAR:[fault reason 06] PTE Read access is not se


peter_sm

Recommended Posts

Hi,

 

I'm on version 6.1.6 and my syslog is full of these messages ,is this harmful ? or a kernel bug ?

Its' for my GPU that I pass trough to a VM

 

 

 

Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00485000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00486000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00488000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00488000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f0048a000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f0048b000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f0048d000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f0048e000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f0048f000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00490000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00492000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00493000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00494000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00495000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00497000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00498000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f00499000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 12 11:22:30 Tower kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f0049a000 
Dec 12 11:22:30 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 12 11:22:30 Tower kernel: dmar: DRHD: handling fault status reg 3

Link to comment
  • 2 weeks later...

@LT

This is for all pass trough I have, below show "error" on my USB controller passing trough to windows VM, would this be fixed in 6.2 ??

 

Dec 20 14:30:54 Tower kernel: vfio-pci 0000:00:1d.0: enabling device (0000 -> 0002)
Dec 20 14:30:54 Tower kernel: vfio_cap_init: 0000:00:1d.0 hiding cap 0xa
Dec 20 14:30:54 Tower kernel: vfio-pci 0000:02:00.1: enabling device (0400 -> 0402)
Dec 20 14:30:56 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 20 14:30:56 Tower kernel: dmar: DMAR:[DMA Read] Request device [00:1d.0] fault addr ee000 
Dec 20 14:30:56 Tower kernel: DMAR:[fault reason 06] PTE Read access is not set
Dec 20 14:30:56 Tower kernel: kvm: zapping shadow pages for mmio generation wraparound
Dec 20 14:37:29 Tower kernel: dmar: DRHD: handling fault status reg 3
Dec 20 14:37:29 Tower kernel: dmar: DMAR:[DMA Read] Request device [00:1d.0] fault addr ee000 

Link to comment
  • 2 months later...

I just wanted to note that I'm also getting these kind of errors over and over. I think it started sometime in 6beta10 plus minus could been there even before.

please let me know if you need the logs and if so the full or just once started? the "errors" appear on regular basis multipe times per minute.

 

the google-search give multiple similar issues possible linked to linux core, intel mainboards / network cards or VM settings in bios.

 

please let us know how to handle this issue (and please don't say ignore)

Link to comment

Yeah I have also always received these messages, it is for my Radeon HD6450 so I wonder if it doesn't like being passed through?

 

Mar 15 09:38:55 kernel: DMAR:[fault reason 06] PTE Read access is not set
Mar 15 09:38:55 kernel: dmar: DRHD: handling fault status reg 3
Mar 15 09:38:55 kernel: dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr f002fe000 

Link to comment
  • 2 weeks later...

I'm getting these messages every few hours, although mine are happening on my Sata Controller (SAS2LP-MV8) followed by at a errors, and its causing parity errors, have reseated every cable and my card to the board, and still getting errors.

 

Mar 24 07:21:16 Ness kernel: dmar: DRHD: handling fault status reg 3
Mar 24 07:21:16 Ness kernel: dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr ff67e000 
Mar 24 07:21:16 Ness kernel: DMAR:[fault reason 05] PTE Write access is not set
Mar 24 07:21:16 Ness kernel: dmar: DRHD: handling fault status reg 3
Mar 24 07:21:16 Ness kernel: dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr ff67e000 
Mar 24 07:21:16 Ness kernel: DMAR:[fault reason 05] PTE Write access is not set
Mar 24 07:21:16 Ness kernel: dmar: DRHD: handling fault status reg 3
Mar 24 07:21:16 Ness kernel: dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr ff67f000 
Mar 24 07:21:16 Ness kernel: DMAR:[fault reason 05] PTE Write access is not set
Mar 24 07:21:16 Ness kernel: dmar: DRHD: handling fault status reg 3
Mar 24 07:21:16 Ness kernel: dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr ff67f000 
Mar 24 07:21:16 Ness kernel: DMAR:[fault reason 05] PTE Write access is not set
Mar 24 07:21:16 Ness kernel: dmar: DRHD: handling fault status reg 3
Mar 24 07:21:16 Ness kernel: dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr ff67f000 
Mar 24 07:21:16 Ness kernel: DMAR:[fault reason 05] PTE Write access is not set
Mar 24 07:21:46 Ness kernel: sas: Enter sas_scsi_recover_host busy: 1 failed: 1
Mar 24 07:21:46 Ness kernel: sas: trying to find task 0xffff8802233da200
Mar 24 07:21:46 Ness kernel: sas: sas_scsi_find_task: aborting task 0xffff8802233da200
Mar 24 07:21:46 Ness kernel: sas: sas_scsi_find_task: task 0xffff8802233da200 is aborted
Mar 24 07:21:46 Ness kernel: sas: sas_eh_handle_sas_errors: task 0xffff8802233da200 is aborted
Mar 24 07:21:46 Ness kernel: sas: ata10: end_device-1:3: cmd error handler
Mar 24 07:21:46 Ness kernel: sas: ata7: end_device-1:0: dev error handler
Mar 24 07:21:46 Ness kernel: sas: ata8: end_device-1:1: dev error handler
Mar 24 07:21:46 Ness kernel: sas: ata9: end_device-1:2: dev error handler
Mar 24 07:21:46 Ness kernel: sas: ata10: end_device-1:3: dev error handler
Mar 24 07:21:46 Ness kernel: ata10.00: exception Emask 0x0 SAct 0x4 SErr 0x0 action 0x6 frozen
Mar 24 07:21:46 Ness kernel: ata10.00: failed command: READ FPDMA QUEUED
Mar 24 07:21:46 Ness kernel: ata10.00: cmd 60/00:00:10:bb:f6/04:00:fa:00:00/40 tag 2 ncq 524288 in
Mar 24 07:21:46 Ness kernel: res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Mar 24 07:21:46 Ness kernel: ata10.00: status: { DRDY }
Mar 24 07:21:46 Ness kernel: ata10: hard resetting link
Mar 24 07:21:46 Ness kernel: sas: ata11: end_device-1:4: dev error handler
Mar 24 07:21:46 Ness kernel: sas: ata12: end_device-1:5: dev error handler
Mar 24 07:21:46 Ness kernel: sas: ata13: end_device-1:6: dev error handler
Mar 24 07:21:46 Ness kernel: sas: sas_form_port: phy0 belongs to port3 already(1)!
Mar 24 07:21:48 Ness kernel: drivers/scsi/mvsas/mv_sas.c 1430:mvs_I_T_nexus_reset for device[0]:rc= 0
Mar 24 07:21:49 Ness kernel: ata10.00: configured for UDMA/133
Mar 24 07:21:49 Ness kernel: ata10.00: device reported invalid CHS sector 0
Mar 24 07:21:49 Ness kernel: ata10: EH complete
Mar 24 07:21:49 Ness kernel: sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1

Link to comment
  • 1 month later...

Just to add to this one, i am running beta 21 of 6.2 and still get this error. 1 usb controller works fine (passed to OVMF) but the other fails like this on boot of a vm so no usbs work (seabios)

 

Apr 24 12:29:34 Archangel kernel: DMAR: DRHD: handling fault status reg 2
Apr 24 12:29:34 Archangel kernel: DMAR: DMAR:[DMA Read] Request device [06:00.0] fault addr ee000 
Apr 24 12:29:34 Archangel kernel: DMAR:[fault reason 06] PTE Read access is not set

Link to comment
  • 1 month later...

Doing some research online, and I guess the best statement I can come up with is that when devices show these errors, they are currently incompatible with either VT-d or IOMMU.  Why 'currently'?  They may need an update to their firmware or their driver to better support passthrough or IOMMU.  Or, the system needs an update to the BIOS for better support of IOMMU, or the kernel needs an update to IOMMU or the passthrough support.  Apparently, buggy motherboard BIOS's and buggy drivers and firmware are common.

 

So I guess the best advice is to keep looking for updates to firmware, BIOS, and Linux kernel (the kernel core itself as well as the virtualization support, especially IOMMU, and the included drivers).

 

Some workarounds that are generally suggested, with possibly undesirable side-effects (choose only one!) -

- iommu=pt

- iommu=pt r8169.use_dac=1

- intel_iommu=pt

- intel_iommu=igfx_off

- iommu=off

- intel_iommu=off

- replace problem hardware

- disable virtualization support in BIOS

 

Disclaimer: I'm certainly not an expert in this area.

Link to comment
  • 4 months later...

Old thread, but it's one of the top search results so I figured I'd share my experiences.

 

Are you guys trying to passthrough multiple devices? In my testing (x58), I've found that just passing the gpu works well. However, passing the onboard sound (in its own iommu group) causes these "DMAR:[fault reason 06] PTE Read access is not set" messages for the gpu.

Link to comment
  • 11 months later...
  • 2 months later...
  • 1 year later...
  • 10 months later...
On 12/27/2018 at 2:32 AM, Jason Harris said:

I have this problem for an onboard Intel GPU.  I have no intention of passing it through. It is in its own IOMMU group.  Would there be any way to just not use this IOMMU group entirely?

 

As others have said, this is the top result when looking for this issue so any help would be appreciated.

Hi. I have exacly the same problem but when I put "intel_iommu=igfx_off" in syslinux.cfg file this error never shows up in log. But even if i don't use onboard Intel GPU when I pass my GeForce GT 1030 to any of my VMs unraid just hangs totally.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.