I seem to recal that these patches were embroziled in with a whole bunch of
Cyrix specific code -- have you submitted just the cpuid relateds, without
the new feature code? (Can you send me that patch? I'd be interested in
cutting it down, beutifing it, and sending it out for some re-testing before
shipping it off to Linus.)
[...]
> In this precise case, I have also provided an explanation for the oops
> (summarizing: do_fast_gettimeoffset() makes assumptions that it
> shouldn't make about the TSC), and C. Scott Ananian is looking into the
> precise mechanism that leads to a divide by zero error.
Or rather, we assume that if there is a TSC then it is monoticly increasing
over time, without repeating in 2^n years (where n is some large number that
I don't remember). We can't always trust that this is true. We could
sanity-check the TSC value. (Is it greater then the last recorded TSC? If
not, take the old TSC+1 as the new TSC). Or, we could just ignore the TSC
in those cases where the cpuid data seems to indicate a possibly broken TSC.
> > > Now, the problem is that you guys think that most people understand
> > > what's going on. Well, the truth is they don't.
> > >
> > > When the average Linux user sees a Bogomips line in /proc/cpuinfo, he
> > > doesn't understand what this thing means. If it said MHz, OK.
> > The thing is that it isn't MHz, it's BogoMIPS. They aren't the same thing.
> > Again, I thing the Goodness of having that information easly avaible for
> > those who request it offsets the Badness of confusing people who look in
> > the deep dark depths (cating the files in /proc qualifies) without being
> > prepared to find stuff they don't understand. OTOH, the Badness of
> > thrusting this knowledge upon an unwitting public is more debatable (and
> > thus more debated.)
>
> I know that Linus called this internal kernel parameter "BogoMIPS" as a
> touch of humor. Unfortunately, non-English speaking Linux users usually
> don't understand the word "bogus". And even English speaking people
> sometimes think this is a measure of performance. Something humorous is
> mistaken for something serious, real, and confusing.
BogoMIPS ratings are a mesure of preformance: specificly, how fast the chip
can do an empty loop. It is serious, real, and confusing. (As well as a
mesure of Million Instructions Per Second -- just really bogus
instructions.) In any case, if people are looking in /proc, they should be
prepared to find stuff that they don't understand. If this suddently
changes with no explanation, they shouldn't freak -- if they wish to know
what it is, asking would be a good idea, rather then writing to linux-kernel
saying "MY BOGOMIPS CHANGED! WHAT SHOULD I DO? IS MY PROCESSOR DYEING?"
(OK, perhaps I'm exagrating a little bit.)
> If we have to calculate a TSC rate/jiffy during boot, and since this
> essentially reflects MHz rating, I would prefer, for the sake of
> clarity, to have that information replace Bogomips in /proc/cpuinfo,
> _when_ the CPU supports a TSC.
TSCs/jiffies isn't neccessarly equal to the Hz rate that the processor is
running at. Nobody gauranees that 1 TSC == 1 clock tick, not even the Intel
spec.
In any case, what is wrong with having both the TSCs/jiffies value AND the
bogomips?
I do not belive in gearing to the lowest common denominator. Ever. If
people want to look in /proc, more power to them, but if they don't
understand what they see there, the way to fix the problem is not to have
less information avaible, but to have the information better documented.
Can you say BogoMIPS-howto? Can you say linux/Documentation/bogomips.txt
(sombody, PLEASE write one! I'm going to start on one shortly.)
> 386 and 486 users will have to do with a Bogomips rating, since as noted
> by Pavel, calculating a MHz rating for these processors represents too
> much code for too little information gain.
This is better done in userspace, or by a custom-written kernel-module
(which should figure the information and printk it within it's module_init()
function.)
> > > Same goes for all the bug related lines, some of which are so old that
> > > they only apply to 386 CPUs (and people who are still using 386s don't
> > > parse /proc/cpuinfo, believe me).
> > I don't think the knowledge of a Linux user can be mesured by the power of
> > their systems. It wouldn't surprise me if Uberhackers commonly run 386es
> > -- they are cheap, so you can have a lot of them, for routers and
> > reduntant machines and such.
>
> I never wrote that. I wrote that people who use 386s don't usually run
> programs that parse the F00F line in /proc/cpuinfo, for example. No
> assumption was made on the knowledge of these Linux users.
Ahh... OTOH, it is perfectly correct to say that 386es don't have the f00f
bug, and makes the code slightly simpler if we do.
> > OTOH, Intel is the body that defines the ia32 standards. That's why the
> > name is "Intel Architecture 32", not "Intel et al Architecture 32". If a
> > processor's behivor deviates from that which the Intel specs specify, it is
> > buggy, whether it is Intel or Cyrix or AMD or TI or Transmeta.
>
> If a CPU is supposed to behave in a given, logical way, and it instead
> behaves in another, unpredictable, erratic way, then I call this a bug.
> When a CPU behaviour deviates from the "GenuineIntel" way, I call this a
> difference. It makes it easier to understand if we don't label it a bug
> *before* we even take a look at what's happening.
Not at all. *All bugs have a pattern to them*. Nothing in the computer
world is truly random. (OK, you could argue about quantum effects.)
If a chip wants to be called Intel compatable, then it needs to behave in
the "GenuineIntel" way when the "GenuineIntel" way has been defined by spec
and not just by implementation. The TSC is defined by spec to be
monatonicly increasing. The Cyrix TSC dosn't do that. Ergo, the Cyrix TSC
is buggy. It may be a bug that we can work around. I don't think it is.
You call it a bug when somthing behaves in "...another, unpredictable
way...", I call it a bug when somthing behaves in a way contridictary to the
spec that it claims to implement.
-=- James Mastros
-- True mastery is knowing enough to bullshit the rest. -=- MePS -- I'm having some connectivity problems. This will probably sit in a buffer for a while. Also, mail to theorb@iname.com or *@jennifer-unix.dyn.ml.org may bounce. Sucks to be me.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu