On Wed, 3 Jan 2007, Tejun Heo wrote:
> bbee wrote:
>>> Yeap, I have major issues with SDB FISes which contains spurious
>>> completions but most other spurious interrupts shouldn't be dangerous
>>> and I haven't seen spurious completions for quite some time, so I was
>>> thinking either removing the message or printing it only on SDB FIS
>>> containing spurious completions.
>>>
>>> But, Andrew Lyon *is* reporting spurious completions. Now I just wanna
>>> update those printks such that more info is reported only on spurious
>>> SDB FISes.
>>
>> That would certainly help verify that I'm having the exact same problem,
>> since Andrew didn't say anything about his drive going offline.
>
> Okay.
Sorry, I thought you meant you would need to update it *further*. I applied
the patch you gave to Andrew with this result so far:
$ dmesg | grep -A1 "spurious interrupt"
ata1: spurious interrupt (irq_stat 0x8 active_tag 0xfafbfcfd sactive 0x0)
ata1: issue=0x0 SAct=0x0 SDB_FIS=004040a1:00000008
--
ata1: spurious interrupt (irq_stat 0x8 active_tag 0xfafbfcfd sactive 0x0)
ata1: issue=0x0 SAct=0x0 SDB_FIS=004040a1:00000001
No luck yet triggering the exception.
On Wed, 3 Jan 2007, Andrew Lyon wrote:
> Alan said he was going to add the drive to a blacklist he was
> maintaining for NCQ, perhaps that has been done in kernel 2.6.19, I
> dont know as I am still running 2.6.18.
>
> Perhaps the WD Raptor drive that I have does have lousy NCQ and that
> explains both the poor performance and the spurious interrupts.
Blacklisting NCQ on the drive(s) for all controllers might be ill advised,
since it could be a JMicron-specific issue (or ahci-specific, since the
person in the thread I referenced had a different ahci controller..).
Either that, or both our drive models have "lousy NCQ"..
Thanks,
bbee