[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.100 / U:0.976 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site