[lkml]   [2006]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: libata/sata_nv latency on NVIDIA CK804 [was Re: AMD64 X2 lost ticks on PM timer]

    * Ingo Molnar <> wrote:

    > in this particular case there's only very simple (and non-IO)
    > instructions in that codepath (no loops either), except for
    > ata_bmdma_status() which does IO ops: so i agree with you that the
    > most likely candidate for the delay is the readb() or the inb() in
    > ata_bdma_status().
    > I'm wondering which one of the two. inb()s are known to be horrible on
    > some systems - but i've never seen them take 16 milliseconds. If it's
    > the inb(), then that could also involve SMM mode and IO
    > emulation/bug-workaround BIOS hackery - which could indeed cause such
    > delays. [but i havent seen such a thing either.]
    > the other option is that this is a random delay [e.g. DMA starvation]
    > hitting ata_bmdma_status() only by accident. (That looks a bit
    > unlikely though, given how related this codepath seems to the whole
    > problem area.)

    i'd exclude this option based on the second latency trace: that too
    shows a delay in ata_bmdma_status().

    so my guess would be that this device doesnt do MMIO, and the PIO inb()
    causes some bad BIOS-based SMM handler/emulator to trigger, which takes
    16.6 msecs. If indeed the device is not in MMIO mode, is there a way to
    force it into MMIO mode, to test this theory?

    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: 2006-03-15 23:09    [W:0.023 / U:34.088 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site