Re: libata/sata_nv latency on NVIDIA CK804 [was Re: AMD64 X2 lost ticks on PM timer]

[Ingo Molnar <mingo@elte.hu>]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Wed, 2006-03-15 at 16:36 -0500, Bill Rugolsky Jr. wrote:
> >    <...>-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) 
> 
> There's your problem - it looks like ata_bmdma_status() stalled the 
> machine for almost 17ms.

i agree. Here's a bit more detailed analysis: the tracer timestamps 
function entry points. So what we know is that from the call to 
ata_bdma_status(), up to the call to nv_check_hotplug_ck804(), 16.6 
msecs passed. The codepath includes:

 - the whole of the ata_bdma_status() function

 - a small portion of ata_host_intr() [from the point where it returns 
   from the ops->bdma_status() call up to the return]

 - and a small portion of nv_interrupt(), from the ata_host_intr() 
   return to the ->check_hotplug() call.

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.)

	Ingo