* Ingo Molnar <[email protected]> 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?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
