[lkml]   [2002]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Re: time() glitch on 2.4.18: solved
    On Tue, 5 Nov 2002, Willy Tarreau wrote:

    > On Tue, Nov 05, 2002 at 01:57:16PM -0500, Richard B. Johnson wrote:
    > > No! You will break many machines. You cannot use out_p() when
    > > writing the latch it __must__ be out(). the "_p" puts a write
    > > to another port between the two writes. That will screw up
    > > the internal state-machine of most PITs including AMD-SC520.
    > You make an interesting point. Have you checked if an inb_p() on this hardware
    > could unlock the latch when reading the first byte ? It may also be one cause
    > of time jumps if the counter is just about to wrap when it's being read, and
    > gets unlocked by an out to port 0x80 (the "_p").
    > > count = inb_p(0x40); /* read the latched count */
    > > count |= inb(0x40) << 8;
    > Or perhaps it will be time to change port 0x80 to something else, that no
    > chipset will use. I've seen 0xED in a bios somewhere, but I don't remember
    > where.
    > Cheers,
    > Willy

    It may well be that the inb_p() also causes the same problem. You
    don't want any port read/write between those required consecutive
    reads or writes. You just don't want to use the _p option there --ever.

    The _p option is not a panacea that one uses to make sure that the
    port read/writes go okay. It's also not a "bus settle time" as IBM
    said in their BIOS. It is to give the internal state-machine of
    some devices enough time to set up. For instance, the CMOS clock
    runs with low-power CMOS. Its internal state-machine is low-power.
    It does not run as fast as an external bus can run. Therefore, when
    you set the next address to be read or written, with an out to the
    port at 0x70, you need to wait for the internal low-power CMOS state
    machine to actually latch the internal address. Then you can read
    or write from 0x71.

    There are only a few devices that require the _p. They are not the
    PIT, any UARTS, or the DMA controller. Sometimes you need to play
    nurse-maid to the FDC, but modern ones in super-IO chips are fine.
    The only hardware a modern PC needs to use "slow-down_io" on is
    the RTC CMOS device. Since we need to support older boards, you
    don't want to remove the _p options indiscriminately, but you do
    not want them ever between two consecutive writes to the same device-

    Dick Johnson
    Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
    Bush : The Fourth Reich of America

    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 13:30    [W:0.021 / U:2.432 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site