Messages in this thread | | | Date | Fri, 22 May 1998 10:14:21 -0100 | From | André Derrick Balsa <> | Subject | Re: 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 :)
Cheers, ------------------------ André Balsa andrebalsa@altern.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |