lkml.org 
[lkml]   [1998]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Cyrix 6x86MX and Centaur C6 CPUs in 2.1.102
    Hi there.

    >> /proc/cpuinfo is supposed to report CPU information, not kernel
    >> bug-detection capabilities, IMNSHO. A normal Linux user with a
    >> non-Intel x86 would prefer to see a "clean" cpuinfo, without all
    >> the Intel-only bugs. Kernel bug-detection capabilities could be
    >> listed on another screen.

    > /proc/cpuinfo is not intended for reading _only_ by human users
    > (who can see all detected CPU bugs during system boot anyway), but
    > also for parsing by programs which need to know whether they can
    > rely on the CPU not having the specific bug. It seems obvious to me
    > that missing bug info should mean `bug not known to this kernel'
    > rather than `bug not present', so that the apps can get all info
    > they need at once without having to remember which kernels know the
    > bug in question or having to parse yet another file.

    Am I misunderstanding what's going on then?

    As I understand it, all the bugs listed in /proc/cpuinfo HAVE A
    WORKAROUND INSTALLED, so that ANY program trying to activate that bug
    MUST fail to do so. As a result, the ONLY meaning that ANY program can
    take from a particular processor bug NOT being listed in /proc/cpuinfo
    is "Ah, this machine doesn't have a workaround for bug X, so I can use
    it to crash this machine" which is the sort of reasoning that VIRUS
    programs tend to use and isn't applicable for anything else...

    >> BTW TSC calibration in the setup code would allow showing MHz
    >> rating in /proc/cpuinfo, so people would stop wondering why they
    >> get bogomips such and such everytime a new x86 processor comes
    >> out.

    > This would be interesting, but remember that CPU clock speed need
    > not be equal TSC frequency.

    Is that relevant?

    As I see it, there must be a FIXED relationship between CPU clock
    speed and TSC frequency, simply due to the fact that anything else
    would mean that some sort of random number generator was present.
    Remembering the sort of lengths Linux goes to to generate random
    numbers, I would find that VERY hard to believe...

    Best wishes from Riley.


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:42    [W:4.442 / U:0.400 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site