On 11/29/2018 12:33 PM, petecb wrote:
I followed these instructions and found that "ucode=scan" was already present.
But was it actually present in the grub.cfg you are using?
I also noticed that it had "iommu=no-igfx"
That is an intel thing
so I changed this to "iommu=on" and rebooted. Unfortunately this did not appear to have an effect and when I ran the "qubes-hcl-report" it still indicated IOMMU was > not active :-(
Can you provide me dmesg and # lspci -vvv from your system either in qubes or xen (does not matter what version)
Have you successfully got a 6386 on this board running with Qubes and all the microcode updates?
Yeah I have with various 63xx CPU's.
To clarify, have you been successful with Qubes 4?
Yes I have and I know other people who have done it as well.
The rest of my systems are running this so I need to figure out a way to get version 4 running securely on this system.
Do you have any other suggestions? If this is a Xen issue do you expect it to be a while before it is fixed and merged in to Qubes?
Note you can always use new versions of xen with qubes by installing yourself but I doubt that would do anything.
If a 62xx CPU definitely works and doesn't have these problems, it may be better for me to procure one of those so I can be up and running quicker.
IMO Keep what you have and find out what is wrong the 63xx CPU's are much faster than 62xx.
I have attached a copy of my serial output booting the system with 2 sticks of 16Gb ECC RAM (32Gb total) in case this is of any help.
Put your RAM back in that would not effect anything :]
I noticed it tended to take longer to boot with more RAM, so I took some out whilst I was troubleshooting :-)
Yeah more RAM takes longer to train.
Do you know if this system is likely to be more stable with a single CPU and 128Gb RAM in all its slots or whether it would be better to have 2 CPUs and split the 128Gb RAM between them (ie. all Orange slots populated)
Nah it doesn't matter you just can't have more than 192GB total without potentially running in to issues.
Anyway don't worry I won't stop replying till all is well :D
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, November 29, 2018 9:35 PM, Taiidan@gmx.com Taiidan@gmx.com wrote:
On 11/29/2018 12:33 PM, petecb wrote:
I followed these instructions and found that "ucode=scan" was already present.
But was it actually present in the grub.cfg you are using?
I think so. I left it in when I changed "iommu=on", applied the settings as you instructed with "grub2-mkconfig" and then rebooted.
I also noticed that it had "iommu=no-igfx"
That is an intel thing
so I changed this to "iommu=on" and rebooted. Unfortunately this did not appear to have an effect and when I ran the "qubes-hcl-report" it still indicated IOMMU was > not active :-(
Can you provide me dmesg and # lspci -vvv from your system either in qubes or xen (does not matter what version)
Please find these attached.
Have you successfully got a 6386 on this board running with Qubes and all the microcode updates?
Yeah I have with various 63xx CPU's.
To clarify, have you been successful with Qubes 4?
Yes I have and I know other people who have done it as well.
The rest of my systems are running this so I need to figure out a way to get version 4 running securely on this system. Do you have any other suggestions? If this is a Xen issue do you expect it to be a while before it is fixed and merged in to Qubes?
Note you can always use new versions of xen with qubes by installing yourself but I doubt that would do anything.
If a 62xx CPU definitely works and doesn't have these problems, it may be better for me to procure one of those so I can be up and running quicker.
IMO Keep what you have and find out what is wrong the 63xx CPU's are much faster than 62xx.
I have attached a copy of my serial output booting the system with 2 sticks of 16Gb ECC RAM (32Gb total) in case this is of any help.
Put your RAM back in that would not effect anything :]
I noticed it tended to take longer to boot with more RAM, so I took some out whilst I was troubleshooting :-)
Yeah more RAM takes longer to train.
Do you know if this system is likely to be more stable with a single CPU and 128Gb RAM in all its slots or whether it would be better to have 2 CPUs and split the 128Gb RAM between them (ie. all Orange slots populated)
Nah it doesn't matter you just can't have more than 192GB total without potentially running in to issues.
Anyway don't worry I won't stop replying till all is well :D
Thanks again for all your help. Please let me know if you need any more info.
coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot