linux-kernel - Re: ata1: spurious interrupt (irq_stat 0x8 active

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 3 Jan 2007 17:50:38 +0100 (CET)
From:	bbee <bumble.bee@...all.nl>
To:	Tejun Heo <htejun@...il.com>, Andrew Lyon <andrew.lyon@...il.com>
cc:	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995
 sactive 0x0) r0xj0

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/