1 |
JimD posted <20060329135203.1de782ba@××××××.localdomain>, excerpted below, |
2 |
on Wed, 29 Mar 2006 13:52:03 -0500: |
3 |
|
4 |
> On Wed, 29 Mar 2006 09:14:55 -0700 |
5 |
> Duncan <1i5t5.duncan@×××.net> wrote: |
6 |
> |
7 |
>> Meanwhile, with the iommu=soft switch, I can run 2.6.16 kernels with |
8 |
>> full memory, just as I could .15 kernels. |
9 |
> |
10 |
> Do you know of any other issues with memory and or amd64 and the 2.6.16 |
11 |
> series? I have run into a weird issue. |
12 |
> |
13 |
> I have an AMD64 3200+ that runs at 2 GHz and runs *very* cool at about |
14 |
> 34c. My motherboard makes it pretty easy to overclock so I have |
15 |
> overclocked the 3200+ to 2.2 GHz and it has been running very stable |
16 |
> and still only around 39c, though a long compile job did get it to 41c. |
17 |
> |
18 |
> When I was runing overclocked in 2.6.15 cat /proc/cpuinfo would show: |
19 |
> |
20 |
> jim@keelie$ cat /proc/cpuinfo |
21 |
> processor : 0 |
22 |
> vendor_id : AuthenticAMD |
23 |
> cpu family : 15 |
24 |
> model : 47 |
25 |
> model name : AMD Athlon(tm) 64 Processor 3200+ |
26 |
> stepping : 2 |
27 |
> cpu MHz : 2200.000 |
28 |
> cache size : 512 KB |
29 |
> fdiv_bug : no |
30 |
> hlt_bug : no |
31 |
> f00f_bug : no |
32 |
> coma_bug : no |
33 |
> fpu : yes |
34 |
> fpu_exception : yes |
35 |
> cpuid level : 1 |
36 |
> wp : yes |
37 |
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr |
38 |
> pge mca cmov pat pse36 clflush mmx fxsr sse sse2 |
39 |
> syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni |
40 |
> lahf_lm ts fid vid ttp tm stc |
41 |
> bogomips : 4409.17 |
42 |
> |
43 |
> |
44 |
> Now with 2.6.16 it shows: |
45 |
> jim@keelie$ cat /proc/cpuinfo |
46 |
> processor : 0 |
47 |
> vendor_id : AuthenticAMD |
48 |
> cpu family : 15 |
49 |
> model : 47 |
50 |
> model name : AMD Athlon(tm) 64 Processor 3200+ |
51 |
> stepping : 2 |
52 |
> cpu MHz : 2000.000 |
53 |
> ^^^^^^^^^^ |
54 |
> <snip> |
55 |
> bogomips : 4409.17 |
56 |
> |
57 |
> |
58 |
> The bogomips are showing the same though the kernel is not reporting |
59 |
> the correct MHz. |
60 |
> |
61 |
> Does anyone have a clue what could be causing this? |
62 |
|
63 |
I'd say look at the changelogs. If whatever it is isn't extremely obvious |
64 |
(grep cpu speed or similar), they get rather huge to go thru, so do the |
65 |
usual binary elimination thing. If you know .15 did one thing and .16 |
66 |
does another, go download the second rc (the majority of the changes will |
67 |
be before that) and try it. Then try either rc1 or rc4 (say), depending |
68 |
on the results, until you either get a specific rc or get a changelog |
69 |
that's moderately sized enough to do a better search on. |
70 |
|
71 |
You can if you wish break it down beyond rcs, into days between rcs, with |
72 |
the gitX snapshots. Thus, before rc1, the snapshots would be 2.6.15-git1, |
73 |
git2, etc, for each day. |
74 |
|
75 |
... |
76 |
|
77 |
What I'm suspecting happened is that cpu info is /supposed/ to report what |
78 |
the CPU says when queried -- that is, what it thinks it is regardless of |
79 |
the clock rate it's actually running at. If it's reporting the clock rate |
80 |
it's actually running at rather than what the CPU actually says, it's |
81 |
playing into the hands of the counterfeiters that will try to sell you a 2 |
82 |
GHz as a 2.2 GHz. |
83 |
|
84 |
Somebody probably figured out that it wasn't reporting the right figure, |
85 |
and changed it. The BIOS should say what it's running at boot, and with |
86 |
the speedstep, coolNquiet, or whatever, I'm guessing the running speed |
87 |
info is avaiilable from there. /proc/cpuinfo, OTOH, should report /rated/ |
88 |
CPU info, as burnt into the chip and available with CPUID, /not/ actual |
89 |
clocked speed, which is available elsewhere. |
90 |
|
91 |
If that's what it was and it wasn't just a config change on your end |
92 |
(turning on CPUID in the kernel config, for instance, so it can actually |
93 |
read it), it should be in the changelog as /something/ related to that. |
94 |
|
95 |
As for general amd64 issues, remember, the full releases are several |
96 |
months apart, and Andy Kleen, the kernel AMD64 guy, always has a bit of a |
97 |
backlog by the time of release and opening up of the tree again to bigger |
98 |
changes (which are supposed to happen in a two-week period after kernel |
99 |
release, before rc1, after which they get stricter about letting in big |
100 |
changes). You'll see several AMD64 entries, normally by Andy Kleen, in |
101 |
every kernel release. They do try to test them, but if nobody runs the |
102 |
rcs and gets back to them about their corner case, sometimes regressions |
103 |
do slip in. What I'm running is mine, not for some mission critical |
104 |
application at some corporation, and I enjoy testing, so while I don't hit |
105 |
every rc, I do try to get at least rc1 or 2, and then one later in the |
106 |
cycle, say 5-ish. The .16 cycle was however the first time I actually |
107 |
filed a bug, as it appeared in rc1 and hadn't disappeared by rc3 or so, |
108 |
which meant they might not be catching it, and indeed, they weren't, so it |
109 |
was a good thing I filed it. |
110 |
|
111 |
-- |
112 |
Duncan - List replies preferred. No HTML msgs. |
113 |
"Every nonfree program has a lord, a master -- |
114 |
and if you use the program, he is your master." Richard Stallman in |
115 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
116 |
|
117 |
|
118 |
-- |
119 |
gentoo-amd64@g.o mailing list |