Proxmox 7.0 on HP Gen8 DMAR error

E

Errorsssss

New Member
Sep 5, 2021
1
0
1
31
Hello.

Soo it seems like the WebGUI does not work anymore. It worked for briefly 30 seconds while the system were rebooting but become unresponsive after a few seconds soo i could not login. I got this DMAR error. Anyone know what it is? Kernel version im running is 5.11.22-4-pve. I tried to boot into kernel version 5.44 and i did not get any DMAR error but the webgui still did not work.

Server im running is HP DL380 Gen8

Code: 
root@pve: # [ 312.007936] DMAR: DRHD: handling fault status reg 102
[  312.008002] DMAR: [INTR-REMAP] Request device: [01:00.0] fault index 22 [fault reason 38] Blocked an interrupt request to source-id verification failure


EDIT: I also forgot to mention that when i got the DMAR error in the iLO console it become unresponsive.
 
Last edited:
did you enable/use pci passthrough? how does your network setup look like? what does 'ss -tlpn' say?
 
Wanted to follow up, was this ever fixed? Right now, with the new kernel:

Code: 
BOOT_IMAGE=/boot/vmlinuz-5.15.35-1-pve root=/dev/mapper/pve-root ro quiet fsck.mode=force

HW is an HP Proliant DL360 Gen8, ILO terminal shows this error (I believe the same as above?):

1652713116540.png

I have forced check on HDD, as maybe that was this issue, no luck. Appreciate any help
 
I am following this issue as well. I am running the latest ver. of Proxmox with kernel 5.13.xx with HW (HP Proliant DL360 gen 8) doing the same thing. ILO crashed.. and the system in general became unstable.

I did try the above option. THIS didn't fix the issue.

What I have do for the mean time is revert back to kernel 5.4.143, This kernel with this HW is stable and has been stable for some time. BUT I would like to move to the newer kernel WHEN possible.

Q: Has anyone found a workable fix yet?
 
Seeing this problem on 5.15.60-2-pve too on an HP DL360p Gen8, with the same iLO console issue.
 
Installed 7.3 prox and so far all work, just super slow io with that old gear. For simple nas, on spinner all ok.
 
I have the same issue on 8.0.3 - HW is HP ProLiant DL360p Gen 8 2 x E5-2650 160GB RAM, DId not have this on my prevoius server (DL360 Gen7)

Will try kernel parameter.....
 
Last edited:
I have 2 ideas to try out.

- First, make sure that you're on the latest ilo Version (if you have a key, don't forget to backup it)
https://pingtool.org/latest-hp-ilo-firmwares/amp/

- second, i don't know (and don't have anymore an hp account), to download the latest Servicepack Iso from HP, which contains bios Updates, but as alternative you can try out this:
https://tteck.github.io/Proxmox/ -> Proxmox VE Tools --> Proxmox Processor Microcode Updates.

Hopefully that helps, otherwise Gen8's are pretty old nowadays, even as NAS Storage:-(

Cheers
 
I managed to get rid of the error by disabling VT-d - Have noticed any degredation on my VMs and my iLO remote terminal deos not lock up any more.

Any Ideas if I am losing anything by disabling VT-d?
 
miyoung999 said:
I managed to get rid of the error by disabling VT-d - Have noticed any degredation on my VMs and my iLO remote terminal deos not lock up any more.

Any Ideas if I am losing anything by disabling VT-d?
Click to expand...
Iommu, means you can't passthrough pci(e) devices anymore.
 
if you really want to put prox7 on this specific box, you can do search about it and kernel or mod.. and they will show that you need a custom patch to be applied. pass the igpu work, but it's soo slow. Just not do any update after as it will break and get you back to the dmar error.
 
For anyone still investigating the iLO console input failure with "Request device [01:00.0]" and source-id verification failure (reason 38 / 0x26), we reproduced it on a MicroServer Gen8 and tested a narrowly scoped kernel workaround with VT-d and interrupt remapping still enabled:

https://gist.github.com/arikon/652b2432a15a71e77ad8578cb0fb83e7

The write-up is in Russian; the attached patch is C, and the key result is this: Linux configured the iLO USB function's MSI interrupt-remapping entry to require source ID 0x0104 (01:00.4), while the fault log reported requester 0x0100 (01:00.0). The USB IRQ counter stayed at zero. USB completions arrived through a fallback timer, producing delayed input and software key repeats; reconnect could also leave the controller unable to wake.

An opt-in MSI-only quirk changes the expected source for this exact hardware from 0x0104 to 0x0100, retaining the exact 16-bit source check (SVT=1, SQ=0) and leaving DMA aliases unchanged. With the same test kernel image OFF/ON, the ON test delivered all 80 rapid test keystrokes across four rounds and worked after three console reconnects, with no repeat events or observed 0x26 faults.

This is an experimental result on one MicroServer Gen8 with iLO 4 2.82, not an upstream fix or a confirmed fix for DL360/DL380 systems. The patch deliberately has strict hardware/topology guards, is disabled by default, and requires a separate kernel build. We returned to the stock kernel after testing; mouse input and long-term stability were not established. Shared requester identity also does not create independent isolation between iLO functions.

It addresses the keyboard/USB interrupt failure; it does not establish that unrelated web UI or network failures in this thread have the same cause. For another model, the requester and IRTE need to be checked before considering an equivalent quirk rather than simply removing the guards.
 
You must log in or register to reply here.
Top Bottom
Back