* Bill Rugolsky Jr. <brugolsky@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
<...>-2913 0d.h. 8us : raise_softirq_irqoff (blk_complete_request)
<...>-2913 0d.h. 8us : __ata_qc_complete (ata_qc_complete)
<...>-2913 0d.h. 9us : ata_host_intr (nv_interrupt)
<...>-2913 0d.h. 9us!: ata_bmdma_status (ata_host_intr)
<...>-2913 0d.h. 16641us : nv_check_hotplug_ck804 (nv_interrupt)
<...>-2913 0d.h. 16642us : _spin_unlock_irqrestore (nv_interrupt)
<...>-2913 0d.h. 16642us : smp_apic_timer_interrupt (apic_timer_interrupt)
<...>-2913 0d.h. 16642us : exit_idle (smp_apic_timer_interrupt)
ouch. The codepath in question (ata_host_intr()) doesnt seem to have any loop that could take 16.6 msecs (!). This very much looks like some hardware-triggered delay - some really screwed up DMA prioritization perhaps, starving the host CPU for 16.6 msecs? But what DMA takes 16.6 msecs? That's enough time to transfer dozens of megabytes of data on a midrange system.