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]
Message-ID: <459C7182.4020000@gmail.com>
Date:	Thu, 04 Jan 2007 12:16:18 +0900
From:	Tejun Heo <htejun@...il.com>
To:	bbee <bumble.bee@...all.nl>
CC:	Andrew Lyon <andrew.lyon@...il.com>, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org
Subject: Re: ata1: spurious interrupt (irq_stat 0x8 active_tag -84148995 sactive
 0x0) r0xj0

bbee wrote:
> 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

Ek... Your problem is similar too.

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

If it turns out to be drive's fault, I'm afraid there's no other
solution than blacklisting those drives on all controllers.  It's
protocol violation on drive's side, so I don't think there is an easy
way out here except for firmware upgrade.  I'm asking people about this,
so please be patient.

-- 
tejun
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ