[lkml]   [2007]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops
    I am going to do a test on another "unused" port.

    However, I realized as I was thinking about this. 0x80 is the
    "diagnostic device" port. It is not an "unused" port.

    Normally, Linux would support a device like the diagnostic device by
    providing a character device, called /dev/post-diagnosis (for the
    power-on test diagnostic). That device would reserve port 80 for its
    use, and the driver could be loaded if there was such a device.

    Now one possibility is that my laptop contains a diagnostic code device
    that stores all the out's to port 80 (documented only to the designers,
    and kept "secret"). That device may need "clearing" periodically,
    which is perhaps done by the SMM, which is turned off when I go into
    ACPI-on state. Or maybe it is designed to be cleared only when the
    system boots at the beginning of the BIOS. What happens when (as
    happens in hwclock's polling of the RTC) thousands of in/out*_p calls
    are made very fast? Well, perhaps it is not cleared quickly enough, and
    hangs the bus.

    The point here is that Linux is NOT using a defined-to-be "unused"
    port. It IS using the "diagnostic" port, and talking to a diagnostic
    device that *is* used, and may be present.

    Just doesn't seem clean to me.

    So I'd suggest 2 actions:

    1) figure out a better implementation of _p that is "safe" and doesn't
    use questionable heuristics. udelay seems reasonable because it doesn't
    drive contention on the busses on SMP machines, but perhaps someone has
    a better idea.

    2) Start a background task with the maintainers of drivers to clean up
    their code regarding these short delays for slow devices (note that it's
    never because the *bus* is slow, but because the *device* is slow.)
    Perhaps this could be helped by "deprecating" the _p calls and
    suggesting an alternative that requires the coder to be precise about
    what the delay is for, and how long it is supposed to be, perhaps on a
    per-machine basis.

     \ /
      Last update: 2007-12-08 21:51    [W:0.022 / U:27.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site