lkml.org 
[lkml]   [2000]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch-2.3.46-p2] P6 microcode update support
    On Wed, 16 Feb 2000, Tigran Aivazian wrote:

    >> > I tested both SMP and UP kernels on my home SMP machine (CPU
    >> > signature=0x673, upgraded to revision=14 microcode)
    >>
    >> The code looks ok, but "mtrr.c"?
    >>
    >> That just doesn't make any sense. Why not a separate simple driver?
    >>
    >> Linus
    >
    >Oh ok. I wanted to do that but I thought you would say "why having a
    >separate simple driver if you can just put it in.. say mtrr.c?" :)
    >Besides, it is from mtrr.c I learned that Linux can do function call
    >IPIs like on other x86 UNIX flavours. Actually I wanted an ioctl on
    >/proc/cpuinfo but that meant upgrading it from the status of simple
    >"misc" proc file and mtrr already had ioctls.
    >
    >Ok, I will make a separate simple character driver with a single ioctl
    >(to not have to deal with issues of multiple read(2)), although being
    >able to just say "cat microcode > /dev/microcode" would be nice.
    >
    >Also, more importantly, Intel manual says "the update must run in the
    >early stages of POST and always before L2 cache controllers are
    >initialized". I ignored it and it still worked fine. However, on the bus
    >to work this morning I thought "perhaps I should use some MSRs to
    >disable cache and re-enable it?". I will think on this in the background
    >but first rewrite it as a char driver.
    >
    >Thanks for your feedback,
    >
    >I suppose I need to ask Peter to grant me minor=180 of the major=10
    >(misc character drivers)? And most difficult part - think of a short
    >name prefix abbreviation for "Intel P6 Microcode Update Device" - IMU?
    >/dev/imu

    Why make it Intel specific? "/dev/mcode"

    I dunno if other CPU's allow microcode updates, but there is
    nothing stopping other vendors from doing this, so why not make
    it generic from the start?

    Then again, if various vendors did in fact do so, it is highly
    likely that it would be very different from Intel's
    implementation, however possibly still likely to be done in a
    generic way no?

    --
    Mike A. Harris Linux advocate
    Computer Consultant GNU advocate
    Capslock Consulting Open Source advocate

    Join the FreeMWare project - the goal to produce a FREE program in
    which you can run Windows 95/98/NT, and other operating systems.

    http://www.freemware.org


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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