linux-kernel - Re: Linux v2.6.22-rc3

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:	Fri, 1 Jun 2007 10:59:51 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Garzik <jgarzik@...ox.com>
cc:	Tejun Heo <htejun@...il.com>, Gregor Jasny <gjasny@...glemail.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-ide@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Linux v2.6.22-rc3

On Fri, 1 Jun 2007, Jeff Garzik wrote:
> 
> With these old PATA devices, device reset is "six of one, half-dozen of the
> other."  Using SRST is the only way to kick some ATAPI devices into working:
> http://suif.stanford.edu/~csapuntz/blackmagic.html#reset

Well, wouldn't it be a good thing to
 1) if BUSY/DRQ is set even before you try the problem, obviously skip the 
    two polite cases, and go to #4
 2) try to just do an IDENTIFY 
 3) if that doesn't work, do a HOST RESET and then try again
 4) if that doesn't work, do the full SRST

(or some variation of the above).

That at least has the potential to get you six working devices, and half a 
dozen other working devices, for a total of 12. With no unnecessary resets 
or long timeouts!

(Btw, the 150ms wait after reset is really nasty. A few of those, and 
we're wasting seconds during bootup. Why the hell does it do that, when 
the old driver - and the spec - said 2ms?)

> I'm mainly interested in hearing feedback from Fedora 7 damage, before making
> a major decision about the probing code.  If this is a single dain bramaged
> device, we should avoid punishing the majority.  But if this is a trend, it
> warrants careful reconsideration.

I thought the default in Fedora was to use the PATA driver first? If so, 
you're going to miss a lot of cases that "just work", because they use the 
old driver.

At least that was what my situation was on the P4 that I recently 
complained about the "set transfer mode" problem: it used to use the old 
PATA drivers that didn't have the issue, so I never even _knew_ the new 
libata-based code had problems.

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