linux-kernel - Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe issue?

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: <4B41216F.4070906@kernel.org>
Date:	Mon, 04 Jan 2010 07:59:59 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Johannes Stezenbach <js@...21.net>
CC:	Hans Werner <HWerner4@....de>, linux-kernel@...r.kernel.org,
	trenn@...e.de, mmalygin@....de, hancockrwd@...il.com,
	greg@...ah.com
Subject: Re: Samsung N130 ATA exception after 5min uptime -- Phoenix FailSafe
 issue?

Hello,

On 01/04/2010 07:11 AM, Johannes Stezenbach wrote:
> On Wed, Dec 30, 2009 at 01:04:28PM +0100, Hans Werner wrote:
>>
>> testing in the Arch Linux Forums has shown that if one applies
>> a patch which you posted to the linux-ide ML on 2008-11-21
>> then the problem is no longer seen. Instead the kernel log shows
>> that a spurious IRQ was cleared.
>>
>> [PATCH #upstraem-fixes] ata_piix: detect and clear spurious IRQs
>> http://marc.info/?l=linux-ide&m=122724081603679&w=2
>> http://bbs.archlinux.org/viewtopic.php?id=86454
>>
>> What's the current status of this patch? Is it safe to use?
>> What does it tell us about the Samsung N130/140?
> 
> FWIW, I just tested a current git kernel (v2.6.33-rc2-268-g45d28b0)
> with Tejun's patch applied on my N130.  The ATA exception and hang is
> indeed gone, just "ata1: clearing spurious IRQ" is logged.
> 
> I've see Tejun's comment in
> http://bugzilla.kernel.org/show_bug.cgi?id=14314
> and I would like to add that the ATA irq is not shared.
> 
>  14:      43885          0   IO-APIC-edge      ata_piix
>  15:          0          0   IO-APIC-edge      ata_piix

Can you please post that on bug#14314?  If the IRQ line indeed wasn't
shared, it might mean that the controller raised the IRQ line before
getting its internal state in order and the IRQ checking sequence
cleared the external IRQ status while leaving the internal pending bit
intact, which I've never heard of on piix and don't think is possible.
Hmmmm... given that the problem was dependent on BIOS on the other
model (is it the N130?), maybe the BIOS is doing something funny.  :-(
Anyways, please post full output of "cat /proc/interrupts" at the bz.

Thanks.

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