This patch fixes a potential system hang. Don't know why this patch isn't included if 'CONFIG_K8_REV_F_SUPPORT == 1'.
Signed-off-by: Josef Kellermann mailto://seppk@arcor.deseppk@arcor.de mailto://seppk@arcor.de
Erratum 89 is already handled on line 390:
if (!is_cpu_pre_b3()) {
/* Erratum 89 ... */ msr = rdmsr(NB_CFG_MSR); msr.lo |= 1 << 3;
If this is also needed when CONFIG_K8_REV_F_SUPPORT == 1, then we should move the existing one out of the #if CONFIG_K8_REV_F_SUPPORT == 0 so it gets executed in both cases, as opposed to duplicating it.
Alex
On 02/02/2011 07:39 PM, Josef Kellermann wrote:
This patch fixes a potential system hang. Don't know why this patch isn't included if 'CONFIG_K8_REV_F_SUPPORT == 1'.
Signed-off-by: Josef Kellermann mailto://seppk@arcor.deseppk@arcor.de mailto://seppk@arcor.de
Am 02.02.2011 20:11, schrieb Alex G.:
Erratum 89 is already handled on line 390:
if (!is_cpu_pre_b3()) {
/* Erratum 89 ... */ msr = rdmsr(NB_CFG_MSR); msr.lo |= 1<< 3;
If this is also needed when CONFIG_K8_REV_F_SUPPORT == 1, then we should move the existing one out of the #if CONFIG_K8_REV_F_SUPPORT == 0 so it gets executed in both cases, as opposed to duplicating it.
Alex
On 02/02/2011 07:39 PM, Josef Kellermann wrote:
This patch fixes a potential system hang. Don't know why this patch isn't included if 'CONFIG_K8_REV_F_SUPPORT == 1'.
Signed-off-by: Josef Kellermannmailto://seppk@arcor.deseppk@arcor.de mailto://seppk@arcor.de
Ok, now it gets executed in both cases.
Signed-off-by: Josef Kellermann seppk@arcor.de mailto://seppk@arcor.de
That looks way better. :)
Acked-by: Alexandru Gagniuc mr.nuke.me@gmail.com
On 02/02/2011 10:17 PM, Josef Kellermann wrote:
Am 02.02.2011 20:11, schrieb Alex G.:
Erratum 89 is already handled on line 390:
if (!is_cpu_pre_b3()) {
/* Erratum 89 ... */ msr = rdmsr(NB_CFG_MSR); msr.lo |= 1 << 3;
If this is also needed when CONFIG_K8_REV_F_SUPPORT == 1, then we should move the existing one out of the #if CONFIG_K8_REV_F_SUPPORT == 0 so it gets executed in both cases, as opposed to duplicating it.
Alex
On 02/02/2011 07:39 PM, Josef Kellermann wrote:
This patch fixes a potential system hang. Don't know why this patch isn't included if 'CONFIG_K8_REV_F_SUPPORT == 1'.
Signed-off-by: Josef Kellermann mailto://seppk@arcor.deseppk@arcor.de mailto://seppk@arcor.de
Ok, now it gets executed in both cases.
Signed-off-by: Josef Kellermann seppk@arcor.de mailto://seppk@arcor.de
Can someone with commit access please commit this patch, or NACK it?
Alex
On 02/02/2011 11:55 PM, Alex G. wrote:
That looks way better. :)
Acked-by: Alexandru Gagniuc mr.nuke.me@gmail.com
On 02/02/2011 10:17 PM, Josef Kellermann wrote:
Am 02.02.2011 20:11, schrieb Alex G.:
Erratum 89 is already handled on line 390:
if (!is_cpu_pre_b3()) {
/* Erratum 89 ... */ msr = rdmsr(NB_CFG_MSR); msr.lo |= 1 << 3;
If this is also needed when CONFIG_K8_REV_F_SUPPORT == 1, then we should move the existing one out of the #if CONFIG_K8_REV_F_SUPPORT == 0 so it gets executed in both cases, as opposed to duplicating it.
Alex
On 02/02/2011 07:39 PM, Josef Kellermann wrote:
This patch fixes a potential system hang. Don't know why this patch isn't included if 'CONFIG_K8_REV_F_SUPPORT == 1'.
Signed-off-by: Josef Kellermann mailto://seppk@arcor.deseppk@arcor.de mailto://seppk@arcor.de
Ok, now it gets executed in both cases.
Signed-off-by: Josef Kellermann seppk@arcor.de mailto://seppk@arcor.de
While we are at it. I'm attaching some very old patch (r2978 ;) which contains some errata fixes too, if you have some spare time please try to check if it is correct.
Signed-off-by: Rudolf Marek r.marek@assembler.cz
Thanks, Rudolf
src/northbridge/amd/amdk8/coherent_ht_car.c was renamed to someting else since then (I wasn't around then), and the patch can no longer be applied.
Can you please check this?
Alex
On 02/02/2011 11:20 PM, Rudolf Marek wrote:
While we are at it. I'm attaching some very old patch (r2978 ;) which contains some errata fixes too, if you have some spare time please try to check if it is correct.
Signed-off-by: Rudolf Marek r.marek@assembler.cz
Thanks, Rudolf
Am 02.02.2011 22:20, schrieb Rudolf Marek:
While we are at it. I'm attaching some very old patch (r2978 ;) which contains some errata fixes too, if you have some spare time please try to check if it is correct.
Signed-off-by: Rudolf Marek r.marek@assembler.cz
Thanks, Rudolf
Hi, are you sure ?
-#if K8_REV_F_SUPPORT == 1 - /* Erratum 131... */ + /* Erratum 131 is fixed together with erratum 169 */ msr = rdmsr(NB_CFG_MSR); - msr.lo |= 1<< 20; + msr.lo |= 1<< 32;<======================= wrmsr(NB_CFG_MSR, msr);
Josef
On 02/03/2011 10:17 AM, Josef Kellermann wrote:
e are at it. I'm attaching some very old patch (r2978 ;) which contains some errata fixes too, if you have some spare time please try to check if it is correct.
Signed-off-by: Rudolf Marek r.marek@assembler.cz
Thanks, Rudolf
Hi, are you sure ?
You're right:
AMD Publication #33610, page34
"[Regarding erratum #131] Systems implementing the workaround for erratum #169 should not apply this workaround."
So it seems AMD recommends either or, but not both.
Page 59: "[Regarding erratum #169] The workaround for this erratum supersedes the workaround for erratum #131. When implementing this workaround, the workaround for erratum #131 should not be applied."
So we better implement only 169, and explain in the comments why 131 is left out.
Alex
Am 03.02.2011 10:14, schrieb Alex G.:
On 02/03/2011 10:17 AM, Josef Kellermann wrote:
e are at it. I'm attaching some very old patch (r2978 ;) which contains some errata fixes too, if you have some spare time please try to check if it is correct.
Signed-off-by: Rudolf Marekr.marek@assembler.cz
Thanks, Rudolf
Hi, are you sure ?
You're right:
AMD Publication #33610, page34
"[Regarding erratum #131] Systems implementing the workaround for erratum #169 should not apply this workaround."
So it seems AMD recommends either or, but not both.
Page 59: "[Regarding erratum #169] The workaround for this erratum supersedes the workaround for erratum #131. When implementing this workaround, the workaround for erratum #131 should not be applied."
So we better implement only 169, and explain in the comments why 131 is left out.
Alex
Hi, sorry for the misunderstanding. Setting bit 32 in msr should be -> 'msr.hi |= (1<< 0)', no?
Josef
Hi, sorry for the misunderstanding. Setting bit 32 in msr should be -> 'msr.hi |= (1<< 0)', no?
LOL! Nice catch.
This is what happens when you're still up at 6AM, obsessive drawing lines on a Google Earth printscreen in order to finish a project due in a few hours. :P
It's funny to see those logic mistakes made with so much ease. As for #169, we should set 'msr.hi |= (1<< 0)' :P, "set F0x68[22:21](DsNpReqLmt0) to 01b," and drop #131 altogether.
I'm assuming the second part means 0:18.0, register 0x6b-0x68[22:21], or Rx6a[6-5].
reg = pci_read_config8(0:18.0, 0x6a); reg |= 0x20; pci_write_config8(0:18.0, 0x6a, reg);
Alex