![]() | |||||||||||||
Messages in this thread |
* Ingo Molnar <mingo@elte.hu> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-03-15 23:09 [from the cache] ©2003-2008 | |||||||||||||