> On 27 Mar, Thomas Wouters spewed forth:
> :: This is getting peculiar :) I have a very similar AMD,
> :: processor : 0
> :: vendor_id : AuthenticAMD
> :: cpu family : 5
> :: model : 8
> :: model name : AMD-K6(tm) 3D processor
> :: stepping : 12
> :: cpu MHz : 400.924185
> :: fdiv_bug : no
> Is it a real 400, or did you OC? I've just not OC'd mine yet, and
> don't really know if I ever will.
It's a real one. You can supposedly overclock the AMD more reliable than,
say, Pentiums or Pentium2s, but in my case, the MB defines the limit -- a
multiplier of 4.5 is too steep for me, and either the MB or some of the PCI
cards wont swallow higher bus speeds. (Or the memory, of course. Or even the
processor. One never knows with overclocking :)
A friend of mine claims to have his 300mhz AMD K6 (1, not 2) running on
411mhz or some such speed, and stable so. I am not sure howmuch higher the
actual performance is though, but then, he mostly uses it to add some cycles
to his RC5 stats :)
> :: You wont ever see mtrr in the cpuflags for a non-intel processor :) It works
> :: now, though. I might run some benchmarks if i find some time, this weekend.
> :: Regardless, Matthew, you should have /proc/mtrr on 2.2.4-ac1. I can send
> :: along my .config to see if anything significant is different ?
> No, that's Ok. I'm not sure who's patch to get, though, Alan's or
> Richard's. Decisions, decisions! Are there implications in going one
> way or the other? How about when 2.2.5 is released; how well will that
> patch work? I've never really done in-between patches before.
Well, as far as I understand, Richard's patch is only for Cyrix cpus, or it
includes Alan's mtrr patches for the AMD. Alan's 'ac' kernel patches include
a lot, lot more, mostly semi-stable drivers and interface changes that need
testing. Alan also fixes the paper-bag mistakes Linus sometimes makes in
releases (and makes one of his own, occasionally, but he releases the next
version sooner than Linus :)
A simple rule of thumb: If you dont need anything special, and you want a
stable, simple kernel and easy upgrading to newer kernel versions, use
Linus's official tree without any patches. This means you dont care about
inefficient drivers or nonexistant support, or you prefer reliable but
medium support over beta/untested but possible better support :)
(Then again, most 'inefficiencies' are relative to the kernel, which means
you'll hardly notice the difference except in stress situations. Mostly it's
the thought of wasted power that counts :-)
The moment you start adding patches, upgrading gets painful. Using
patch-collections like Alans' makes upgrading a lot less painful, since he
usually has his patch-collection updated for the next kernel release inside
a day, but you also might get a lot more changes than you bargained for.
Personally, I prefer living-on-the-edge with Alans' patches, as they carry a
number of changes and driver updates i care about, and because I think
everyone can take their share in the testing Linus wants before he adds
something to the official tree. We also use -ac patches for our servers,
mostly because they need updated drivers, the NFS changes and the
large-fd-table patch.
Regards,
Thomas (bored and trying to break his wpm record)
-- Thomas Wouters <thomas@xs4all.net>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/