Hi all,
It seems r4233/4234 broke the tree for h8dme (k8). Here's how my boot hangs, note the corruption in the serial log:
---------------------------------- .... set DQS timing:RcvrEn:Pass2: 00 done Total DQS Training : tsc [00]=000000007acb45c5 Total DQS Training : tsc [01]=000000007c957514 Total DQS Training : tsc [02]=00000000f820fd23 Total DQS Training : tsc [03]=00000000fab0b966 Ram4 v_esp=000cefec testx = 5a5a5a5a Copying data from cache to RAM -- switching to use RAM as stack... Done testx = 5a5a5a5a Disabling cache as ram now Clearing initial memory region: Done src=fffdf000 sdsrtc==00100f0f0f0f80 eU7ncom pdrsets=s0i0n0gc 8i0m0a0ge tUon cRoAmMp.res sing image to RAM. image length = 00028560 Jumping to image. coreboot-2.0.0-r4234M_h8dme_Fallback Fri May 1 17:07:03 EDT 2009 booting... Enumerating buses... scan_static_bus for Root Device APIC_CLUSTER: 0 enabled PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 scanning... PCI: 00:18.3 siblings=1 CPU: APIC: 00 enabled malloc Enter, size 1100, free_memi_mpatgre 0l0e1n4g8t0h0 0= 0m0a0l0l2oac6 c001 4J8u0m0p0in gC PtUo: iAmPaIgCe:. 01 ----------------------------------
Full log available at http://ward.vandewege.net/coreboot/h8dme/r4234-corruption.log
Thanks, Ward.
It does look like an SMP machine in which both CPUs are trying to run as the BSP.
Possible?
ron
On Sat, May 02, 2009 at 01:42:34PM -0700, ron minnich wrote:
It does look like an SMP machine in which both CPUs are trying to run as the BSP.
Possible?
It's definitely an SMP machine, two dual-core CPUs.
Thanks, Ward.
On Sat, May 2, 2009 at 2:58 PM, Ward Vandewege ward@gnu.org wrote:
On Sat, May 02, 2009 at 01:42:34PM -0700, ron minnich wrote:
It does look like an SMP machine in which both CPUs are trying to run as the BSP.
Possible?
It's definitely an SMP machine, two dual-core CPUs.
So can you see what changed in the k8 north/cpu support since the last time it worked?
ron
On Sat, May 02, 2009 at 04:38:12PM -0700, ron minnich wrote:
On Sat, May 2, 2009 at 2:58 PM, Ward Vandewege ward@gnu.org wrote:
On Sat, May 02, 2009 at 01:42:34PM -0700, ron minnich wrote:
It does look like an SMP machine in which both CPUs are trying to run as the BSP.
Possible?
It's definitely an SMP machine, two dual-core CPUs.
So can you see what changed in the k8 north/cpu support since the last time it worked?
Sure. The last time it worked is r4232, I had to bisect to find the commit causing the problem. r4233/4234 are one changeset.
src/northbridge/amd is unchanged by this changeset.
The diff for src/cpu/amd is attached.
Thanks, Ward.
Am 03.05.2009 02:40, schrieb Ward Vandewege:
On Sat, May 02, 2009 at 04:38:12PM -0700, ron minnich wrote:
On Sat, May 2, 2009 at 2:58 PM, Ward Vandewegeward@gnu.org wrote:
On Sat, May 02, 2009 at 01:42:34PM -0700, ron minnich wrote:
It does look like an SMP machine in which both CPUs are trying to run as the BSP.
Possible?
It's definitely an SMP machine, two dual-core CPUs.
So can you see what changed in the k8 north/cpu support since the last time it worked?
Sure. The last time it worked is r4232, I had to bisect to find the commit causing the problem. r4233/4234 are one changeset.
src/northbridge/amd is unchanged by this changeset.
The diff for src/cpu/amd is attached.
The various copies of "copy_and_run" were merged into src/arch/i386/lib/copy_and_run.c. I tweaked the coreboot_apc generation a bit, by adding the serial driver and console output code. It worked on a fam10 board here, so I didn't think it to cause much trouble - seems like it does.
The interleaved messages are
(by the BSP) malloc Enter, size 1100, free_mem_ptr 00148000 malloc 00148000 CPU APIC: 01
(by the AP) image length = 00002a6c Jumping to image.
That's definitely a different image used for the AP than the one for the BSP (see image length some lines earlier)
Patrick
On Sun, May 3, 2009 at 1:42 AM, Patrick Georgi patrick@georgi-clan.de wrote:
Am 03.05.2009 02:40, schrieb Ward Vandewege:
On Sat, May 02, 2009 at 04:38:12PM -0700, ron minnich wrote:
On Sat, May 2, 2009 at 2:58 PM, Ward Vandewegeward@gnu.org wrote:
On Sat, May 02, 2009 at 01:42:34PM -0700, ron minnich wrote:
It does look like an SMP machine in which both CPUs are trying to run as the BSP.
Possible?
It's definitely an SMP machine, two dual-core CPUs.
So can you see what changed in the k8 north/cpu support since the last time it worked?
Sure. The last time it worked is r4232, I had to bisect to find the commit causing the problem. r4233/4234 are one changeset.
src/northbridge/amd is unchanged by this changeset.
The diff for src/cpu/amd is attached.
The various copies of "copy_and_run" were merged into src/arch/i386/lib/copy_and_run.c. I tweaked the coreboot_apc generation a bit, by adding the serial driver and console output code. It worked on a fam10 board here, so I didn't think it to cause much trouble - seems like it does.
The interleaved messages are
(by the BSP) malloc Enter, size 1100, free_mem_ptr 00148000 malloc 00148000 CPU APIC: 01
(by the AP) image length = 00002a6c Jumping to image.
That's definitely a different image used for the AP than the one for the BSP (see image length some lines earlier)
It didn't break my s2895 (dual dual-core K8)
I wonder what the difference is.
Thanks, Myles
Am 01.05.2009 23:15, schrieb Ward Vandewege:
It seems r4233/4234 broke the tree for h8dme (k8). Here's how my boot hangs, note the corruption in the serial log:
The "corruption" is fine - it's just both cores chatting at the same time.
I made a small mistake in the refactoring of copy_and_run that affected only the coreboot_apc codepath (which I can't test). While the copy_and_run_core function takes a "dst" argument, and compresses to that location, it jumped to a hardcoded entry point of _iseg - which works for all scenarios but coreboot_apc.
With the change, the dst value is used for all cases.
Please try attached patch which should fix it. It's tested to run in the non-APC codepath and is
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Hi Patrick,
On Tue, May 05, 2009 at 03:05:58PM +0200, Patrick Georgi wrote:
Am 01.05.2009 23:15, schrieb Ward Vandewege:
It seems r4233/4234 broke the tree for h8dme (k8). Here's how my boot hangs, note the corruption in the serial log:
The "corruption" is fine - it's just both cores chatting at the same time.
I made a small mistake in the refactoring of copy_and_run that affected only the coreboot_apc codepath (which I can't test). While the copy_and_run_core function takes a "dst" argument, and compresses to that location, it jumped to a hardcoded entry point of _iseg - which works for all scenarios but coreboot_apc.
With the change, the dst value is used for all cases.
Please try attached patch which should fix it. It's tested to run in the non-APC codepath and is
Thanks, tested on h8dme and this fixes the problem.
Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Acked-by: Ward Vandewege ward@gnu.org
Thanks, Ward.
-
Myles Watson -
Patrick Georgi -
ron minnich -
Ward Vandewege