I have uploaded 2 changes on top of Aaron's change. Can you please
give these three changes a try:
https://review.coreboot.org/c/coreboot/+/41363
https://review.coreboot.org/c/coreboot/+/41418
https://review.coreboot.org/c/coreboot/+/41419
Thank you!
- Furquan
On Thu, May 14, 2020 at 4:16 PM
On Thu, May 14, 2020 at 3:46 PM Aaron Durbin wrote:
>
>
> On Thu, May 14, 2020 at 2:46 PM Mike Banon wrote:
>
>> Unfortunately it seems a lot of boards are affected by this. A88XM-E
>> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at
>> booting - and, when they do, no boot
On Thu, May 14, 2020 at 4:44 PM Keith Hui wrote:
> Hi Aaron,
>
> You may want to check the QEMU-q35 target as well:
>
> Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4
> Emulation targets:
> "QEMU x86 q35/ich9" using payload TianoCore : FAIL :
> https://lava.9esec.io/r/3427
> "QEMU x86
Hi Aaron,
You may want to check the QEMU-q35 target as well:
Automatic boot test returned (PASS/FAIL/TOTAL): 2/2/4
Emulation targets:
"QEMU x86 q35/ich9" using payload TianoCore : FAIL :
https://lava.9esec.io/r/3427
"QEMU x86 q35/ich9" using payload SeaBIOS : FAIL : https://lava.9esec.io/r/3426
On Thu, May 14, 2020 at 2:46 PM Mike Banon wrote:
> Unfortunately it seems a lot of boards are affected by this. A88XM-E
> and Lenovo G505S (AMD fam15h) also got broken: they rarely succeed at
> booting - and, when they do, no boot devices are available (virtual
> floppies too, for some reason)
One more issue I just remembered is that FreeBSD was unstable with
cpu_cc6_state enabled. It just crashed when putting more load on the system (no
panic whatsoever, just a reboot). Disabling it made things stable.
Maybe try disabling it?
___
coreboot
Nice to see a possible fix. Thank you very much, going to test it tomorrow.
On Thu, May 14, 2020 at 11:29 PM Aaron Durbin via coreboot
wrote:
>
>
>
> On Thu, May 14, 2020 at 2:25 PM Keith Hui wrote:
>>
>> Hi Aaron,
>>
>> I think I have success after applying 41363 as well. Please see
>>
Hi there, KGPE-D16 friends.
1) Please look at my not-merged-yet "AMD_XMP" changes on
review.coreboot.org: they could help you to either use a XMP 1 or XMP
2 memory profile (should exist on ALL your sticks), or - preferably -
to set up your custom memory profile that will override the SPD
values.
On Thu, May 14, 2020 at 2:25 PM Keith Hui wrote:
> Hi Aaron,
>
> I think I have success after applying 41363 as well. Please see
> attached and tell us if this is what you set out to do.
>
That looks correct, and what I was expecting. Thanks for the help gathering
logs.
> Thanks
> Keith
>
>
Hi Aaron,
I think I have success after applying 41363 as well. Please see
attached and tell us if this is what you set out to do.
Thanks
Keith
On Thu, May 14, 2020 at 4:01 PM Aaron Durbin wrote:
>
> Hi Keith,
>
> Did the newresalloc.log file contain this patch?
>
It did not. Let me grab that and take another log.
On Thu, May 14, 2020 at 4:01 PM Aaron Durbin wrote:
>
> Hi Keith,
>
> Did the newresalloc.log file contain this patch?
> https://review.coreboot.org/c/coreboot/+/41363
>
> I ask because I see the fixed resources on the domain that are dram:
>
Hi Keith,
Did the newresalloc.log file contain this patch?
https://review.coreboot.org/c/coreboot/+/41363
I ask because I see the fixed resources on the domain that are dram:
DOMAIN: resource base 0 size a align 0 gran 0 limit 0 flags
e0004200 index a
DOMAIN: resource base
Hi Aaron,
Here are two more logs at SPEW. Old log is a separate branch where I
reverted all the problem commits; new log has everything.
Thanks
Keith
coreboot-4.12-56-g31ab7de51a Wed May 13 20:23:32 UTC 2020 romstage starting (log level: 8)...
Romstage stack size limited to 0x1000!
SMBus
ragna...@tenebr.is wrote:
> 4. For 32GB configuration (2 x 16GB sticks), installing to the
> closest orange slot of each CPU would not boot, it booted when I
> installed the sticks to the second closest orange slot of each CPU.
If you install memory modules as far *away* from CPU/chipset as
Hi guys,
31ab7de51a is CB:41368, cherry picked into my local repo.
Turns out I have to back out all four of Furquan's patches
(CB:39486~39489) for my board to boot normally again.
Thoughts?
I'll now get a log with everything in at SPEW.
On Thu, May 14, 2020 at 1:05 PM Aaron Durbin wrote:
>
I have two KGPE-D16's running coreboot 4.11. One runs as my server and uses
FreeBSD, the other is my desktop and dual boots FreeBSD and Linux. Both work
great. Both have 64 GB RAM (4x Kingston KVR16R11D4/16). You need to remember
that the manual part for positioning RAM sticks in the ASUS
Dear Furquan, dear Aaron,
Am 14.05.20 um 12:02 schrieb Paul Menzel:
Commit 3b02006afe (device: Enable resource allocator to use multiple
ranges) [1] also breaks the qemu-i440fx, that SeaBIOS does not show any
graphics. Please find the logs attached.
Sorry, I missed that Furquan already
Dear Furquan, dear Aaron,
Commit 3b02006afe (device: Enable resource allocator to use multiple
ranges) [1] also breaks the qemu-i440fx, that SeaBIOS does not show any
graphics. Please find the logs attached.
Kind regards,
Paul
[1]: https://review.coreboot.org/c/coreboot/+/39486
$
Dear coreboot users,
Several users reported regressions with commit 3b02006afe (device:
Enable resource allocator to use multiple ranges) [1] on their devices.
$ git describe 3b02006afe8a85477dafa1bd149f1f0dba02afc7
4.12-9-g3b02006afe
It is my understanding that the change exposes
19 matches
Mail list logo
