[lkml]   [1998]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Cyrix 6x86MX and Centaur C6 CPUs in 2.1.102
Hi James,

James Mastros wrote:
> On these, the basic issue is information overload vs. information underload
> (not getting all of the information that you want). Myself, I'd take
> overload over underload any day.

Yes, for a long time I thought the same. But now I prefer to get just
the information I want/need, no more, no less. Perhaps I am getting old
(and wise)? :)
> > and I don't even care if I get wrong CPU stepping information on non-Intel
> > CPUs.
> Now this is a matter of _wrong_ information -- write a patch, test it, and
> make it ellagant (or at least not ugly). Then send it to Linus and
> linux-kernel.

Too much ego-related resistance for just a small change. I prefer to do
it just on my systems, and make my patches available to the public.
> Worked around it, or fixed it? Work-arounds are unlikly to make it into the
> kernel, for idealistic reasons. Somtimes, we kernel-hackers (I use the first
> person even though I hardly qualify as a kernel-hacker -- it makes me feel
> better) care more about the quality of the code then it's ablity to
> acatually _work_.

Ah! I prefer something that works, actually. Having to reboot a machine
every day is enough of a nuisance to make me implement a workaround.

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.

BTW "quality of the code" is something very subjective. For example, I
prefer heavily documented code, specially assembly language parts; but
this is a matter of taste. Works/crashes is more objective.

> Indeed, if you have a problem with a workaround but without a solution,
> then it may be generaly best to point people in the right direction, rather
> then simply posting a workaround. People are more likely to work on fixing
> it that way. Sad, but true.

I have done that over and over.
> > 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.

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.

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.

Note that other architectures support a feature similar to the TSC,
which can be used to work out the MHz rating of the processor.
> > 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.
> 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.

> Then again,
> if it deviates from the Intel chips on an undefined matter, or goes above
> and beyond the call of duty, then the chip is better then the Intel
> "equivlent" in that respect, and we should take advantage of those features
> as best as we can.

I support that :)

André Balsa

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.160 / U:1.248 seconds]
©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site