<br><br><div class="gmail_quote">On Tue, Jun 16, 2009 at 12:48 PM, Ward Vandewege <span dir="ltr"><<a href="mailto:ward@gnu.org">ward@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Tue, Jun 16, 2009 at 11:16:16AM -0600, Marc Jones wrote:<br>
> On Tue, Jun 16, 2009 at 4:07 AM, Maximilian<br>
> Thuermer<<a href="mailto:Maximilian.Thuermer@stud.uni-karlsruhe.de">Maximilian.Thuermer@stud.uni-karlsruhe.de</a>> wrote:<br>
><br>
> ><br>
> > its hard to tell by the logs. I am not familiar with the board topology.<br>
> > However, if I read<br>
> > the output correctly, the code seems to perform alright on the first but not<br>
> > on the second<br>
> > CPU. I went through our code patches and discovered that there may be an<br>
> > additional fix<br>
> > you might need to incorporate in order to get it working.<br>
> > The AMD_checkLinkType procedure only checks for gangend/unganged, HT1 vs.<br>
> > HT3<br>
> > and so forth, but omitts a check as to whether the link was initialized<br>
> > correctly (i.e.present device,<br>
> > no CRC errors on the link, the like).<br>
> > We added a procedure checking bit no. 4 and 5 of the link control register<br>
> > whether the link was<br>
> > initialized correctly and didnt suffer a link failure. The procedure is<br>
> > called just before the HtSetPhyRegister<br>
> > function is executed. I attached the procedure to make it clear - not a diff<br>
> > file because this should normally<br>
> > be contained somewhere in the checkLinkType function (up until now, it was<br>
> > just a quick hack sort of).<br>
> > Check if this reports your link1 on cpu1 unconnnected. It should solve your<br>
> > problem then. Good luck,<br>
><br>
><br>
> Maximilian,<br>
><br>
> You found another bug. This one in checkLinkType. It checks the<br>
> connect, init complete, and type but continues on regardless if the<br>
> link is initialized. The caller expects the return value to be 0 is<br>
> there was any problems with the link. Yeah, that is bad...<br>
><br>
> I don't think that you need the CRC errror checking at this point (but<br>
> it wouldn't hurt). I think that should be handled in the HT init code<br>
> and only the init<br>
><br>
> Here is an updated patch (untested as usual).<br>
<br>
</div></div>Here's a boot log:<br>
<br>
  <a href="http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-am.cap" target="_blank">http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-am.cap</a><br>
<br>
This patch now exhibits the same behaviour as Maximilian's two patches: no<br>
more hang at initialization of CPU1, but a soft reset a little futher down. I<br>
guess we're not quite there yet, but this is definitely a step in the right<br>
direction.<br>
<div class="im"><br>
> Signed-off-by: Marc Jones <<a href="mailto:marcj303@yahoo.com">marcj303@yahoo.com</a>><br>
<br>
</div>Acked-by: Ward Vandewege <<a href="mailto:ward@gnu.org">ward@gnu.org</a>><br>
<br>
Thanks,<br>
Ward.<br>
</blockquote></div><br>Did you test with defaults.h errata patch as well? Can you ack it too?<br><br>r4358<br><br>Marc<br><br>-- <br><a href="http://marcjonesconsulting.com">http://marcjonesconsulting.com</a><br>