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: <47949AA4.9090601@gmail.com>
Date:	Mon, 21 Jan 2008 22:14:12 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Georgi Chulkov <g.chulkov@...obs-university.de>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	Mark Lord <liml@....ca>
Subject: Re: ATA device reset, shoud I be concerned?

Alan Cox wrote:
>> transmission failure as timeouts.  Of course, if we're ticking the timer
>> while the command is not in flight, that's a bug.  If there are cases
>> where 30 secs isn't enough, can you please point me to those reports?
> 
> I have been, in bugzilla - the raid failure example where old IDE
> eventually reports a media error while libata keeps timing out,
> resetting, repeating.

Maybe the difference is not in timeout but what the driver does after
timeout happens.  After timeout, libata ignores almost everything (it
considers DMA error reported on BMDMA status) and resets the device
while IDE thinks that IRQ might be lost and complete the command if the
TF status register says so.

It could be that the particular device doesn't raise IRQ on certain
error conditions but updates TF registers.  After timeout, IDE completes
the command with the indicated error while libata ignores the status and
resets the device.

libata never touches TF register after timeout because some controllers
lock up hard if TF register is read after certain error conditions
(event the status register).

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