From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan
> Sent: Thursday, March 01, 2007 6:30 PM
> To: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [PATCH] libata: Cable detection fixes
&
PROTECTED] On Behalf Of Alan
Sent: Thursday, March 01, 2007 6:30 PM
To: linux-ide@vger.kernel.org; linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [PATCH] libata: Cable detection fixes
2.6.21-rc has horrible problems with libata and PATA cable
Alan Cox wrote:
However, given that we are in -rc cycle, and the wide impact of this
change, this patch wants splitting. The ->cable_detect stuff should be
in a separate patch from the IDENTIFY DEVICE ordering stuff. This
ensures sanity when git-bisecting changes, and allows fast-tracking of
Alan wrote:
2.6.21-rc has horrible problems with libata and PATA cable types (and
thus speeds). This occurs because Tejun fixed a pile of other bugs and
we now do cable detect enforcement for drive side detection properly.
Unfortunately we don't do the process around cable detection right.
> Hm, I got recently hands on a hardware where 2.6.21-rc1 based
> kernels from Fedora rawhide simply do not boot as there is no
> way to get to disks. I would not mind some change in behavior
> although so far I can boot at least some earlier kernels.
Doesn't look related at all. Looks like the
> However, given that we are in -rc cycle, and the wide impact of this
> change, this patch wants splitting. The ->cable_detect stuff should be
> in a separate patch from the IDENTIFY DEVICE ordering stuff. This
> ensures sanity when git-bisecting changes, and allows fast-tracking of
> the
However, given that we are in -rc cycle, and the wide impact of this
change, this patch wants splitting. The -cable_detect stuff should be
in a separate patch from the IDENTIFY DEVICE ordering stuff. This
ensures sanity when git-bisecting changes, and allows fast-tracking of
the
Hm, I got recently hands on a hardware where 2.6.21-rc1 based
kernels from Fedora rawhide simply do not boot as there is no
way to get to disks. I would not mind some change in behavior
although so far I can boot at least some earlier kernels.
Doesn't look related at all. Looks like the box
Alan wrote:
2.6.21-rc has horrible problems with libata and PATA cable types (and
thus speeds). This occurs because Tejun fixed a pile of other bugs and
we now do cable detect enforcement for drive side detection properly.
Unfortunately we don't do the process around cable detection right.
Alan Cox wrote:
However, given that we are in -rc cycle, and the wide impact of this
change, this patch wants splitting. The -cable_detect stuff should be
in a separate patch from the IDENTIFY DEVICE ordering stuff. This
ensures sanity when git-bisecting changes, and allows fast-tracking of
On Thu, Mar 01, 2007 at 08:33:17PM -0500, Jeff Garzik wrote:
>
> That little change, buried in the middle of Alan's patch, changes the
> probing order for a /lot/ of devices, possibly millions, when you
> consider that it changes behavior of ata_piix (Intel SATA) as well as
> all the
Linus Torvalds wrote:
On Thu, 1 Mar 2007, Alan wrote:
The patch switches the identify order so that we can do the drive side
detection correctly.
Secondly we add a ->cable_detect() method called after the identify
sequence which allows a host to do host side detection at this point
should
Alan wrote:
2.6.21-rc has horrible problems with libata and PATA cable types (and
thus speeds). This occurs because Tejun fixed a pile of other bugs and
we now do cable detect enforcement for drive side detection properly.
Unfortunately we don't do the process around cable detection right.
On Thu, 1 Mar 2007, Alan wrote:
>
> The patch switches the identify order so that we can do the drive side
> detection correctly.
>
> Secondly we add a ->cable_detect() method called after the identify
> sequence which allows a host to do host side detection at this point
> should it wish, or
2.6.21-rc has horrible problems with libata and PATA cable types (and
thus speeds). This occurs because Tejun fixed a pile of other bugs and
we now do cable detect enforcement for drive side detection properly.
Unfortunately we don't do the process around cable detection right. Tejun
identified
2.6.21-rc has horrible problems with libata and PATA cable types (and
thus speeds). This occurs because Tejun fixed a pile of other bugs and
we now do cable detect enforcement for drive side detection properly.
Unfortunately we don't do the process around cable detection right. Tejun
identified
On Thu, 1 Mar 2007, Alan wrote:
The patch switches the identify order so that we can do the drive side
detection correctly.
Secondly we add a -cable_detect() method called after the identify
sequence which allows a host to do host side detection at this point
should it wish, or to
Alan wrote:
2.6.21-rc has horrible problems with libata and PATA cable types (and
thus speeds). This occurs because Tejun fixed a pile of other bugs and
we now do cable detect enforcement for drive side detection properly.
Unfortunately we don't do the process around cable detection right.
Linus Torvalds wrote:
On Thu, 1 Mar 2007, Alan wrote:
The patch switches the identify order so that we can do the drive side
detection correctly.
Secondly we add a -cable_detect() method called after the identify
sequence which allows a host to do host side detection at this point
should it
On Thu, Mar 01, 2007 at 08:33:17PM -0500, Jeff Garzik wrote:
That little change, buried in the middle of Alan's patch, changes the
probing order for a /lot/ of devices, possibly millions, when you
consider that it changes behavior of ata_piix (Intel SATA) as well as
all the
20 matches
Mail list logo
