[gentoo-amd64] Re: Re: 2.6.16 and >=4G mem

[Duncan]

JimD posted <20060329135203.1de782ba@××××××.localdomain>, excerpted below,
 on Wed, 29 Mar 2006 13:52:03 -0500:

> On Wed, 29 Mar 2006 09:14:55 -0700
> Duncan <1i5t5.duncan@×××.net> wrote:
>
>> Meanwhile, with the iommu=soft switch, I can run 2.6.16 kernels with
>> full memory, just as I could .15 kernels.
>
> Do you know of any other issues with memory and or amd64 and the 2.6.16
> series?  I have run into a weird issue.
>
> I have an AMD64 3200+ that runs at 2 GHz and runs *very* cool at about
> 34c.  My motherboard makes it pretty easy to overclock so I have
> overclocked the 3200+ to 2.2 GHz and it has been running very stable
> and still only around 39c, though a long compile job did get it to 41c.
>
> When I was runing overclocked in 2.6.15 cat /proc/cpuinfo would show:
>
> jim@keelie$ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 15
> model           : 47
> model name      : AMD Athlon(tm) 64 Processor 3200+
> stepping        : 2
> cpu MHz         : 2200.000
> cache size      : 512 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 1
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
>                   pge mca cmov pat pse36 clflush mmx fxsr sse sse2
>                   syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni
>                   lahf_lm ts fid vid ttp tm stc
> bogomips        : 4409.17
>
>
> Now with 2.6.16 it shows:
> jim@keelie$ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 15
> model           : 47
> model name      : AMD Athlon(tm) 64 Processor 3200+
> stepping        : 2
> cpu MHz         : 2000.000
>                  ^^^^^^^^^^
> <snip>
> bogomips        : 4409.17
>
>
> The bogomips are showing the same though the kernel is not reporting
> the correct MHz.
>
> Does anyone have a clue what could be causing this?

I'd say look at the changelogs.  If whatever it is isn't extremely obvious
(grep cpu speed or similar), they get rather huge to go thru, so do the
usual binary elimination thing.  If you know .15 did one thing and .16
does another, go download the second rc (the majority of the changes will
be before that) and try it.  Then try either rc1 or rc4 (say), depending
on the results, until you either get a specific rc or get a changelog
that's moderately sized enough to do a better search on.

You can if you wish break it down beyond rcs, into days between rcs, with
the gitX snapshots.  Thus, before rc1, the snapshots would be 2.6.15-git1,
git2, etc, for each day.

...

What I'm suspecting happened is that cpu info is /supposed/ to report what
the CPU says when queried -- that is, what it thinks it is regardless of
the clock rate it's actually running at.  If it's reporting the clock rate
it's actually running at rather than what the CPU actually says, it's
playing into the hands of the counterfeiters that will try to sell you a 2
GHz as a 2.2 GHz.

Somebody probably figured out that it wasn't reporting the right figure,
and  changed it.  The BIOS should say what it's running at boot, and with
the speedstep, coolNquiet, or whatever, I'm guessing the running speed
info is avaiilable from there.  /proc/cpuinfo, OTOH, should report /rated/
CPU info, as burnt into the chip and available with CPUID, /not/ actual
clocked speed, which is available elsewhere.

If that's what it was and it wasn't just a config change on your end
(turning on CPUID in the kernel config, for instance, so it can actually
read it), it should be in the changelog as /something/ related to that.

As for general amd64 issues, remember, the full releases are several
months apart, and Andy Kleen, the kernel AMD64 guy, always has a bit of a
backlog by the time of release and opening up of the tree again to bigger
changes (which are supposed to happen in a  two-week period after kernel
release, before rc1, after which they get stricter about letting in big
changes).  You'll see several AMD64 entries, normally by Andy Kleen, in
every kernel release.  They do try to test them, but if nobody runs the
rcs and gets back to them about their corner case, sometimes regressions
do slip in.  What I'm running is mine, not for some mission critical
application at some corporation, and I enjoy testing, so while I don't hit
every rc, I do try to get at least rc1 or 2, and then one later in the
cycle, say 5-ish.  The .16 cycle was however the first time I actually
filed a bug, as it appeared in rc1 and hadn't disappeared by rc3 or so,
which meant they might not be catching it, and indeed, they weren't, so it
was a good thing I filed it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list