[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Latest microcode data from Intel.
    On Fri, 10 Sep 2004, Tigran Aivazian wrote:

    > On Fri, 10 Sep 2004, Bill Davidsen wrote:
    > > Tigran Aivazian wrote:
    > > > Hello,
    > > >
    > > > I have received and tested the latest microcode data file from Intel, The
    > > > file is dated 2nd September 2004. You can download it both as standalone
    > > > (bzip2-ed) text file and bundled with microcode_ctl utility from the
    > > > Download section of the website:
    > > >
    > > >
    > > >
    > > > Please let me know if you find any problems with this data file or with
    > > > the Linux microcode driver. Thank you.
    > >
    > > Why are you using /dev/cpu/microcode instead of /dev/cpu/N/microcode for
    > > each CPU? Today they are all the same device, but for the future I would
    > > think this was an obvious CYA.
    > I have two questions:
    > 1. What does "CYA" mean?

    Cover Your Ass - or more politely, plan for likely future changes if there
    isn't a high cost doing so.
    > 2. How do you know which device nodes exist on my workstation?

    I don't need to... the stat() call will tell me. If a /dev/cpu/0/microcode
    exists it is more likely to be the correct loader for CPU0 than some
    generic loader. Obviously if the user provides a name use it.
    > Actually, I am using /dev/cpu/0/microcode as the device node (entry point
    > into the microcode driver) because that is what is in the distribution I
    > am running (old Red Hat).

    That's exactly why I mentioned using the per-cpu device if present. While
    having CPUs with different loaders is not a feature today, I wouldn't bet
    that will always be true. We know that AMD expects to ship dual core CPUs
    in an Opteron form factor. If I have a dual opteron system and replace one
    CPU with dual core, will I need a different loader? I have no idea, but
    since it's easy to use the per-CPU microcode I would.

    > The microcode_ctl utility had a hardcoded default "/dev/cpu/microcode" and
    > there is no real reason to change it because different distributions
    > prefer a different value, so how to decide who is "right"?

    The obvious seems to be to see if the per-CPU device is present, and use
    it if possible. I can't believe that it would be (by design) less correct
    than the generic device.
    > Also, there is no obvious reason why the future has to be in any way
    > different from the present (or the past :)

    Your distro and mine already have per-CPU microcode, that's the present.
    Lots of people just compile and run, that's the present. It's easy to
    check for /dev/cpu/N/micorcode first, then /dev/cpu/microcode, I think
    that's the future. I just like having code try a little harder to do the
    right thing, Linux should be easy.

    bill davidsen <>
    CTO, TMR Associates, Inc
    Doing interesting things with little computers since 1979.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:06    [W:0.026 / U:88.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site