linux-kernel - Re: libata git tree, mbox queue status and contents

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: <46B5DFE0.4060008@ru.mvista.com>
Date:	Sun, 05 Aug 2007 18:34:08 +0400
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Jeff Garzik <jeff@...zik.org>,
	IDE/ATA development list <linux-ide@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: libata git tree, mbox queue status and contents

Alan Cox wrote:

>>* Alan: IORDY handling -- upstream whenever Alan is happy

> I'm happy with it from testing. Just a little worried about it going
> upstream mid -rc as it could have a weird side effect somewhere. I've
> verified an original pre ATA IDE drive with it too now 8)

>>* Alan: ACPI checks for 80wire cable -- upstream whenever Alan is happy

> Happy

>>* Albert: irq_on/off.  Really need to give this some thought.  Not sure 
>>I like where this model is going.  Polling and twiddling irq on/off 
>>should be kept to a minimum, because it's sorta an admission that the 
>>host state machine has broken down, and we need to bandaid.  Its a 
>>bandaid not a root-cause solution.

> I think of it more as an admission that the IDE design is lacking in a
> few areas. No suprise as its an emulation of a 15 year old interface that
> was normally used polled.

    Hehe, note that even host polling has always been racy the way ATA spec. 
described it: there was noting said about the period whithin which the device 
should assert INTRQ after clearing BSY (and the interrupt-pending state wasn't 
clearly specified also), so there's a possibility for the fast host to *not* 
clear interrupt pending by reading the status reg. with BSY=0 but before the 
devie enters interrupt-pending state, and thus possibly stalling the further 
transfer.

MBR, Sergei
-
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/