On Fri, December 15, 2017 10:00 am, Ivan Ivanov wrote:
> awokd, could you please answer some questions:
>
> 1) From where you got that 0x06001119 microcode patch?
> Is it a trusted source of a microcode? (hope its directly from AMD)
>
>
> 2) Is there any way to determine that 0x06001119 is really t
awokd, could you please answer some questions:
1) From where you got that 0x06001119 microcode patch?
Is it a trusted source of a microcode? (hope its directly from AMD)
2) Is there any way to determine that 0x06001119 is really the latest microcode?
Or there could be more recent versions availab
Congratulations for following through on the investigation :D
I am not sure how to do a commit, but I hope you are able to find out as
you will have helped a lot of people.
I am pleased with myself for noticing that the lack of microcode updates
was the issue - as the CPU is similar to a pile
On Mon, December 11, 2017 12:56 am, awokd wrote:
> I got it [after many days of research and trial]! I had to update
> src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnEquivalenceTable.c
> from:
>
> STATIC CONST UINT16 ROMDATA CpuF15TnMicrocodeEquivalenceTable[] =
> {
> 0x6101, 0x6101
On Fri, December 1, 2017 12:10 pm, awokd wrote:
> On Thu, November 30, 2017 05:38, Zoran Stojsavljevic wrote:
>>> Last resort is to flash back the OEM image but I'm hoping to avoid that.
>>
>> I would suggest to do this step now. As interim step, Then you can verify
> Thanks, will report back
> on
On Fri, December 1, 2017 15:33, Ivan Ivanov wrote:
> I have thought that if Qubes sees HVM available it is always using it.
> (so if Qubes reports to you that HVM is enabled, that means its using
> HVM and without any problems). Am I wrong here?
That's true of 4.0 but not 3.2. Look for virt_mode
On Thu, November 30, 2017 05:38, Zoran Stojsavljevic wrote:
>> Last resort is to flash back the OEM image but I'm hoping to avoid that.
>
> I would suggest to do this step now. As interim step, Then you can verify
> everything you are trying to do
> with Coreboot. The first and obvious step is to c
> Last resort is to flash back the OEM image but I'm hoping to avoid that.
I would suggest to do this step now. As interim step, Then you can verify
everything you are trying to do
with Coreboot. The first and obvious step is to check for MCU using dmesg,
if any exists. If yes, the next
step, prob
On Wed, November 29, 2017 16:35, Ivan Ivanov wrote:
> Hi awokd,
Hi and thanks for your reply!
> are you sure that your HVM is correctly installed / has a
> correct config ?
> Because: you may have heard about Qubes OS - excellent OS which is based
> on Xen,
> has the same and even stronger securit
Hi awokd, are you sure that your HVM is correctly installed / has a
correct config ?
Because: you may have heard about Qubes OS - excellent OS which is based on Xen,
has the same and even stronger security than Xen in some cases, and it
is working perfectly
at Lenovo G505S laptop with coreboot inst
Have been struggling for the past couple months to get Xen hardware
virtualization working on this Corebooted laptop. Paravirtualized VMs
work, but whenever I start a fully virtualized VM (HVM) it hard freezes
the entire system- no keyboard or mouse response. No related output is
showing in any log
11 matches
Mail list logo
