Latest working kernel version: unknown Earliest failing kernel version: unknown Distribution: kernel.org Hardware Environment: AMD Family 10h or Family 11h processor Software Environment: none Problem Description: x86 structure memory incorrectly checked in amd.c Steps to reproduce: Review the source In the source for 2.6.25-rc7, arch/x86/kernel/cpu/amd.c lines 254 and 255 incorrectly use 0x10 and 0x11 for c->x86 instead of 0x1F and 0x2F respectively. See setup_64.c at lines 921 and 922: if (c->x86 == 0x0f) c->x86 += (tfms >>20) & 0xff; Kernel 2.6.24.4 is similarly broken, with an additional x86 check for 0x10 at line 287 when it should be checking for 0x1F.
Reassigning to the x86 guys.. Can you email us a patch?
Created attachment 15485 [details] Fixes for AMD Family 10h and 11h, I think I posted two copies of amd.c, for kernel versions 2.6.24.4 and 2.6.25-rc7 http://home.att.net/~chip.programmer/linux-2.6.24.4/amd.c http://home.att.net/~chip.programmer/linux-2.6.25-rc7/amd.c The changes have not been tested, yet, but I made them based on setup_64.c. I might be able to check the code on Monday, I have both processor families available in my lab.
if (c->x86 == 0x0f) c->x86 += (tfms >> 20) & 0xff; implements the spec of the data sheet: "Family is an 8-bit value and is defined as: Family[7:0] = ({0000b,BaseFamily[3:0]} + ExtendedFamily[7:0]). E.g. If BaseFamily[3:0]=Fh and ExtendedFamily[7:0]=01h, then Family[7:0]=10h. This document applies only to family 0Fh processors." The extended family bits are at bit 20-27. Shift right 20 brings it down to the right place. So the code is correct and needs to check for 0x10 / 0x11 and not for 0x1f/0x2f Thanks, tglx
What you are saying is that the code in amd.c is not in reference to the Hound or Griffin series of processors, what AMD calls Rev 10h and Rev 11h respectively? If this is true, that the source applies only to RevF/G series of processors, then this _should_ be clearly documented in the source because the values used conflict with the names used by AMD. The values in the source code, without documentation, leads to confusion over their intent when compared to how AMD documents their processors. This bug is, therefore, reopened so that the source code could be CLEARLY documented as to intent versus AMD naming conventions.
(In reply to comment #4) > What you are saying is that the code in amd.c is not in reference to the > Hound > or Griffin series of processors, what AMD calls Rev 10h and Rev 11h > respectively? Sigh, 0x01 + 0x0f = 0x10 and not 0x1f 0x02 + 0x0f = 0x10 and not 0x2f That's what the code does and that's what the AMD documentation says. > If this is true, that the source applies only to RevF/G series > of processors, then this _should_ be clearly documented in the source because > the values used conflict with the names used by AMD. The values in the > source > code, without documentation, leads to confusion over their intent when > compared > to how AMD documents their processors. Care to read the relevant AMD data sheets and documentation how to identify the CPU family ? The code is correct and there is no conflict at all. > This bug is, therefore, reopened so that the source code could be CLEARLY > documented as to intent versus AMD naming conventions. Again. This is not a bug. The code is correct and it does not conflict with any of the naming conventions. If you think this code needs comments/documentation then please read Documentation/SubmittingPatches in the kernel source directory and submit a patch with a useful rationale on LKML.
My apologies to all, I suffered a brain fart. When I went riding Saturday, I realized what I did, that I was thinking my AMD processors were giving an ID value 01000F22 instead of 00100F22.