Re: patch sata_nv-disable-hardreset-for-generic.patch added to 2.6.26-stable tree

Re: patch sata_nv-disable-hardreset-for-generic.patch added to 2.6.26-stable tree

[Stefan Lippers-Hollmann]

[-- Attachment #1.1: Type: text/plain, Size: 11635 bytes --]

Hi

On Donnerstag, 2. Oktober 2008, gregkh@suse.de wrote:
> 
> This is a note to let you know that we have just queued up the patch titled
> 
>     Subject: sata_nv: disable hardreset for generic
> 
> to the 2.6.26-stable tree.  Its filename is
> 
>     sata_nv-disable-hardreset-for-generic.patch
> 
> A git repo of this tree can be found at 
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> 
> From 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 Mon Sep 17 00:00:00 2001
> From: Tejun Heo <tj@kernel.org>
> Date: Fri, 29 Aug 2008 16:13:12 +0200
> Subject: sata_nv: disable hardreset for generic
> 
> From: Tejun Heo <tj@kernel.org>
> 
> commit 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 upstream
> 
> of them being unifying probing, hotplug and EH reset paths uniform.
> Previously, broken hardreset could go unnoticed as it wasn't used
> during probing but when something goes wrong or after hotplug the
> problem will surface and bite hard.
> 
> OSDL bug 11195 reports that sata_nv generic flavor falls into this
> category.  Hardreset itself succeeds but PHY stays offline after
> hardreset.  I tried longer debounce timing but the result was the
> same.
> 
>   http://bugzilla.kernel.org/show_bug.cgi?id=11195
> 
> So, it seems we'll have to drop hardreset from the generic flavor.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Peer Chen <pchen@nvidia.com>
> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

On 2.6.26.5 + the pending stable queue applied, this patch results in lots 
of noise in my syslog (full gzipped dmesg with and without this patch 
attached):

ata4: EH complete
ata5: EH pending after 5 tries, giving up
ata5: EH complete
ata6: EH pending after 5 tries, giving up
ata6: EH complete
ata5: EH pending after 5 tries, giving up
ata5: EH complete
ata6: EH pending after 5 tries, giving up
ata6: EH complete

reverting just this patch fixes the issue again.

This triggers reproducably for me on different nforce3 and nforce4 systems 
running a 64 bit kernel:

nforce3:
00:00.0 Host bridge [0600]: nVidia Corporation nForce3 250Gb Host Bridge [10de:00e1] (rev a1)
00:01.0 ISA bridge [0601]: nVidia Corporation nForce3 250Gb LPC Bridge [10de:00e0] (rev a2)
00:01.1 SMBus [0c05]: nVidia Corporation nForce 250Gb PCI System Management [10de:00e4] (rev a1)
00:02.0 USB Controller [0c03]: nVidia Corporation CK8S USB Controller [10de:00e7] (rev a1)
00:02.1 USB Controller [0c03]: nVidia Corporation CK8S USB Controller [10de:00e7] (rev a1)
00:02.2 USB Controller [0c03]: nVidia Corporation nForce3 EHCI USB 2.0 Controller [10de:00e8] (rev a2)
00:05.0 Bridge [0680]: nVidia Corporation CK8S Ethernet Controller [10de:00df] (rev a2)
00:06.0 Multimedia audio controller [0401]: nVidia Corporation nForce3 250Gb AC'97 Audio Controller [10de:00ea] (rev a1)
00:08.0 IDE interface [0101]: nVidia Corporation CK8S Parallel ATA Controller (v2.5) [10de:00e5] (rev a2)
00:09.0 IDE interface [0101]: nVidia Corporation nForce3 Serial ATA Controller 2 [10de:00ee] (rev a2)
00:0a.0 IDE interface [0101]: nVidia Corporation nForce3 Serial ATA Controller [10de:00e3] (rev a2)
00:0b.0 PCI bridge [0604]: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge [10de:00e2] (rev a2)
00:0e.0 PCI bridge [0604]: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge [10de:00ed] (rev a2)
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV280 [Radeon 9200 PRO] [1002:5960] (rev 01)
01:00.1 Display controller [0380]: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) [1002:5940] (rev 01)
02:0a.0 Multimedia controller [0480]: Philips Semiconductors TriMedia TM-1300 [1131:5402] (rev 82)
02:0c.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller [1106:3044] (rev 46)
02:0d.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet [10ec:8169] (rev 10)

nforce4:
00:00.0 Memory controller [0580]: nVidia Corporation CK804 Memory Controller [10de:005e] (rev a3)
00:01.0 ISA bridge [0601]: nVidia Corporation CK804 ISA Bridge [10de:0050] (rev a3)
00:01.1 SMBus [0c05]: nVidia Corporation CK804 SMBus [10de:0052] (rev a2)
00:02.0 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005a] (rev a2)
00:02.1 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005b] (rev a3)
00:04.0 Multimedia audio controller [0401]: nVidia Corporation CK804 AC'97 Audio Controller [10de:0059] (rev a2)
00:06.0 IDE interface [0101]: nVidia Corporation CK804 IDE [10de:0053] (rev f2)
00:07.0 IDE interface [0101]: nVidia Corporation CK804 Serial ATA Controller [10de:0054] (rev f3)
00:08.0 IDE interface [0101]: nVidia Corporation CK804 Serial ATA Controller [10de:0055] (rev f3)
00:09.0 PCI bridge [0604]: nVidia Corporation CK804 PCI Bridge [10de:005c] (rev a2)
00:0a.0 Bridge [0680]: nVidia Corporation CK804 Ethernet Controller [10de:0057] (rev a3)
00:0b.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3)
00:0c.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3)
00:0d.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3)
00:0e.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3)
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
01:06.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller [10ec:8185] (rev 20)
01:07.0 Ethernet controller [0200]: Intel Corporation 82541GI Gigabit Ethernet Controller [8086:1076]
01:0c.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller [1106:3044] (rev 80)
05:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60]
05:00.1 Display controller [0380]: ATI Technologies Inc RV370 [Radeon X300SE] [1002:5b70]

and 

nforce4
00:00.0 Memory controller [0580]: nVidia Corporation CK804 Memory Controller [10de:005e] (rev a3)
00:01.0 ISA bridge [0601]: nVidia Corporation CK804 ISA Bridge [10de:0050] (rev a3)
00:01.1 SMBus [0c05]: nVidia Corporation CK804 SMBus [10de:0052] (rev a2)
00:02.0 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005a] (rev a2)
00:02.1 USB Controller [0c03]: nVidia Corporation CK804 USB Controller [10de:005b] (rev a3)
00:04.0 Multimedia audio controller [0401]: nVidia Corporation CK804 AC'97 Audio Controller [10de:0059] (rev a2)
00:06.0 IDE interface [0101]: nVidia Corporation CK804 IDE [10de:0053] (rev f2)
00:07.0 IDE interface [0101]: nVidia Corporation CK804 Serial ATA Controller [10de:0054] (rev f3)
00:08.0 IDE interface [0101]: nVidia Corporation CK804 Serial ATA Controller [10de:0055] (rev f3)
00:09.0 PCI bridge [0604]: nVidia Corporation CK804 PCI Bridge [10de:005c] (rev a2)
00:0a.0 Bridge [0680]: nVidia Corporation CK804 Ethernet Controller [10de:0057] (rev a3)
00:0b.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3)
00:0c.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3)
00:0d.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3)
00:0e.0 PCI bridge [0604]: nVidia Corporation CK804 PCIE Bridge [10de:005d] (rev a3)
00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100]
00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101]
00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102]
00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
01:07.0 Multimedia video controller [0400]: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05)
01:07.1 Multimedia controller [0480]: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8801] (rev 05)
01:07.2 Multimedia controller [0480]: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05)
01:07.4 Multimedia controller [0480]: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] [14f1:8804] (rev 05)
01:08.0 Network controller [0280]: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card [13d0:2103] (rev 02)
01:0a.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller [104c:8025] (rev 01)
02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller [11ab:4362] (rev 19)
05:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60]
05:00.1 Display controller [0380]: ATI Technologies Inc RV370 [Radeon X300SE] [1002:5b70]

Regards
	Stefan Lippers-Hollmann

> ---
>  drivers/ata/sata_nv.c |   19 +------------------
>  1 file changed, 1 insertion(+), 18 deletions(-)
> 
> --- a/drivers/ata/sata_nv.c
> +++ b/drivers/ata/sata_nv.c
> @@ -309,8 +309,6 @@ static void nv_nf2_freeze(struct ata_por
>  static void nv_nf2_thaw(struct ata_port *ap);
>  static void nv_ck804_freeze(struct ata_port *ap);
>  static void nv_ck804_thaw(struct ata_port *ap);
> -static int nv_hardreset(struct ata_link *link, unsigned int *class,
> -			unsigned long deadline);
>  static int nv_adma_slave_config(struct scsi_device *sdev);
>  static int nv_adma_check_atapi_dma(struct ata_queued_cmd *qc);
>  static void nv_adma_qc_prep(struct ata_queued_cmd *qc);
> @@ -407,7 +405,7 @@ static struct scsi_host_template nv_swnc
>  
>  static struct ata_port_operations nv_generic_ops = {
>  	.inherits		= &ata_bmdma_port_ops,
> -	.hardreset		= nv_hardreset,
> +	.hardreset		= ATA_OP_NULL,
>  	.scr_read		= nv_scr_read,
>  	.scr_write		= nv_scr_write,
>  };
> @@ -1588,21 +1586,6 @@ static void nv_mcp55_thaw(struct ata_por
>  	ata_sff_thaw(ap);
>  }
>  
> -static int nv_hardreset(struct ata_link *link, unsigned int *class,
> -			unsigned long deadline)
> -{
> -	int rc;
> -
> -	/* SATA hardreset fails to retrieve proper device signature on
> -	 * some controllers.  Request follow up SRST.  For more info,
> -	 * see http://bugzilla.kernel.org/show_bug.cgi?id=3352
> -	 */
> -	rc = sata_sff_hardreset(link, class, deadline);
> -	if (rc)
> -		return rc;
> -	return -EAGAIN;
> -}
> -
>  static void nv_adma_error_handler(struct ata_port *ap)
>  {
>  	struct nv_adma_port_priv *pp = ap->private_data;
> 
> 
> Patches currently in stable-queue which might be from tj@kernel.org are
> 
> queue-2.6.26/sata_nv-disable-hardreset-for-generic.patch

[-- Attachment #1.2: with-2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6.log.gz --]
[-- Type: application/x-gzip, Size: 8771 bytes --]

[-- Attachment #1.3: without-2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6.log.gz --]
[-- Type: application/x-gzip, Size: 8616 bytes --]

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: patch sata_nv-disable-hardreset-for-generic.patch added to 2.6.26-stable tree

[Greg KH]

On Sat, Oct 04, 2008 at 06:27:03PM +0200, Stefan Lippers-Hollmann wrote:
> Hi
> 
> On Donnerstag, 2. Oktober 2008, gregkh@suse.de wrote:
> > 
> > This is a note to let you know that we have just queued up the patch titled
> > 
> >     Subject: sata_nv: disable hardreset for generic
> > 
> > to the 2.6.26-stable tree.  Its filename is
> > 
> >     sata_nv-disable-hardreset-for-generic.patch
> > 
> > A git repo of this tree can be found at 
> >     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> > 
> > 
> > From 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 Mon Sep 17 00:00:00 2001
> > From: Tejun Heo <tj@kernel.org>
> > Date: Fri, 29 Aug 2008 16:13:12 +0200
> > Subject: sata_nv: disable hardreset for generic
> > 
> > From: Tejun Heo <tj@kernel.org>
> > 
> > commit 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 upstream
> > 
> > of them being unifying probing, hotplug and EH reset paths uniform.
> > Previously, broken hardreset could go unnoticed as it wasn't used
> > during probing but when something goes wrong or after hotplug the
> > problem will surface and bite hard.
> > 
> > OSDL bug 11195 reports that sata_nv generic flavor falls into this
> > category.  Hardreset itself succeeds but PHY stays offline after
> > hardreset.  I tried longer debounce timing but the result was the
> > same.
> > 
> >   http://bugzilla.kernel.org/show_bug.cgi?id=11195
> > 
> > So, it seems we'll have to drop hardreset from the generic flavor.
> > 
> > Signed-off-by: Tejun Heo <tj@kernel.org>
> > Cc: Peer Chen <pchen@nvidia.com>
> > Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> On 2.6.26.5 + the pending stable queue applied, this patch results in lots 
> of noise in my syslog (full gzipped dmesg with and without this patch 
> attached):

This patch has been removed from the stable queue, so it shouldn't be an
issue anymore, right?

thanks,

greg k-h

Re: patch sata_nv-disable-hardreset-for-generic.patch added to 2.6.26-stable tree

[Tejun Heo]

Greg KH wrote:
>>> From 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 Mon Sep 17 00:00:00 2001
>>> From: Tejun Heo <tj@kernel.org>
>>> Date: Fri, 29 Aug 2008 16:13:12 +0200
>>> Subject: sata_nv: disable hardreset for generic
>>>
>>> From: Tejun Heo <tj@kernel.org>
>>>
>>> commit 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 upstream
>>>
>>> of them being unifying probing, hotplug and EH reset paths uniform.
>>> Previously, broken hardreset could go unnoticed as it wasn't used
>>> during probing but when something goes wrong or after hotplug the
>>> problem will surface and bite hard.
>>>
>>> OSDL bug 11195 reports that sata_nv generic flavor falls into this
>>> category.  Hardreset itself succeeds but PHY stays offline after
>>> hardreset.  I tried longer debounce timing but the result was the
>>> same.
>>>
>>>   http://bugzilla.kernel.org/show_bug.cgi?id=11195
>>>
>>> So, it seems we'll have to drop hardreset from the generic flavor.
>>>
>>> Signed-off-by: Tejun Heo <tj@kernel.org>
>>> Cc: Peer Chen <pchen@nvidia.com>
>>> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
>>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>> On 2.6.26.5 + the pending stable queue applied, this patch results in lots 
>> of noise in my syslog (full gzipped dmesg with and without this patch 
>> attached):
> 
> This patch has been removed from the stable queue, so it shouldn't be an
> issue anymore, right?

It's currently a mess.  Please take a look at the following message for
the whole story.

  http://article.gmane.org/gmane.linux.ide/34942

It's interesting how they fixed hardreset of the chipset step-by-step. :-(

Thanks.

-- 
tejun

Re: patch sata_nv-disable-hardreset-for-generic.patch added to 2.6.26-stable tree

[Greg KH]

On Sun, Oct 05, 2008 at 12:20:18PM +0900, Tejun Heo wrote:
> Greg KH wrote:
> >>> From 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 Mon Sep 17 00:00:00 2001
> >>> From: Tejun Heo <tj@kernel.org>
> >>> Date: Fri, 29 Aug 2008 16:13:12 +0200
> >>> Subject: sata_nv: disable hardreset for generic
> >>>
> >>> From: Tejun Heo <tj@kernel.org>
> >>>
> >>> commit 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 upstream
> >>>
> >>> of them being unifying probing, hotplug and EH reset paths uniform.
> >>> Previously, broken hardreset could go unnoticed as it wasn't used
> >>> during probing but when something goes wrong or after hotplug the
> >>> problem will surface and bite hard.
> >>>
> >>> OSDL bug 11195 reports that sata_nv generic flavor falls into this
> >>> category.  Hardreset itself succeeds but PHY stays offline after
> >>> hardreset.  I tried longer debounce timing but the result was the
> >>> same.
> >>>
> >>>   http://bugzilla.kernel.org/show_bug.cgi?id=11195
> >>>
> >>> So, it seems we'll have to drop hardreset from the generic flavor.
> >>>
> >>> Signed-off-by: Tejun Heo <tj@kernel.org>
> >>> Cc: Peer Chen <pchen@nvidia.com>
> >>> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> >>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> >> On 2.6.26.5 + the pending stable queue applied, this patch results in lots 
> >> of noise in my syslog (full gzipped dmesg with and without this patch 
> >> attached):
> > 
> > This patch has been removed from the stable queue, so it shouldn't be an
> > issue anymore, right?
> 
> It's currently a mess.  Please take a look at the following message for
> the whole story.
> 
>   http://article.gmane.org/gmane.linux.ide/34942
> 
> It's interesting how they fixed hardreset of the chipset step-by-step. :-(

Ick, you are right, what a mess.

Do you want that patch in 2.6.26-stable now?  Or just don't worry about
it?

thanks,

greg k-h

Re: patch sata_nv-disable-hardreset-for-generic.patch added to 2.6.26-stable tree

[Tejun Heo]

Greg KH wrote:
>> It's currently a mess.  Please take a look at the following message for
>> the whole story.
>>
>>   http://article.gmane.org/gmane.linux.ide/34942
>>
>> It's interesting how they fixed hardreset of the chipset step-by-step. :-(
> 
> Ick, you are right, what a mess.
> 
> Do you want that patch in 2.6.26-stable now?  Or just don't worry about
> it?

2.6.26-stable should be fixed but given the series of breakages I
wanna be a bit cautious before proceeding.  Just give me a few more
days so that I can confirm the posted patch fixes the problem for both
generic and nf2/3 flavors.  I'll forward the final patch against
-stable to you then.

Thanks.

-- 
tejun

Re: patch sata_nv-disable-hardreset-for-generic.patch added to 2.6.26-stable tree

[Greg KH]

On Sun, Oct 05, 2008 at 01:43:52PM +0900, Tejun Heo wrote:
> Greg KH wrote:
> >> It's currently a mess.  Please take a look at the following message for
> >> the whole story.
> >>
> >>   http://article.gmane.org/gmane.linux.ide/34942
> >>
> >> It's interesting how they fixed hardreset of the chipset step-by-step. :-(
> > 
> > Ick, you are right, what a mess.
> > 
> > Do you want that patch in 2.6.26-stable now?  Or just don't worry about
> > it?
> 
> 2.6.26-stable should be fixed but given the series of breakages I
> wanna be a bit cautious before proceeding.  Just give me a few more
> days so that I can confirm the posted patch fixes the problem for both
> generic and nf2/3 flavors.  I'll forward the final patch against
> -stable to you then.

Sounds good to me.

thanks,

greg k-h

Re: patch sata_nv-disable-hardreset-for-generic.patch added to 2.6.26-stable tree

[Stefan Lippers-Hollmann]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

Hi

On Sonntag, 5. Oktober 2008, Greg KH wrote:
> On Sat, Oct 04, 2008 at 06:27:03PM +0200, Stefan Lippers-Hollmann wrote:
> > Hi
> > 
> > On Donnerstag, 2. Oktober 2008, gregkh@suse.de wrote:
> > > 
> > > This is a note to let you know that we have just queued up the patch titled
> > > 
> > >     Subject: sata_nv: disable hardreset for generic
> > > 
> > > to the 2.6.26-stable tree.  Its filename is
> > > 
> > >     sata_nv-disable-hardreset-for-generic.patch
> > > 
> > > A git repo of this tree can be found at 
> > >     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> > > 
> > > 
> > > From 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 Mon Sep 17 00:00:00 2001
> > > From: Tejun Heo <tj@kernel.org>
> > > Date: Fri, 29 Aug 2008 16:13:12 +0200
> > > Subject: sata_nv: disable hardreset for generic
> > > 
> > > From: Tejun Heo <tj@kernel.org>
> > > 
> > > commit 2fd673ecf0378ddeeeb87b3605e50212e0c0ddc6 upstream
> > > 
> > > of them being unifying probing, hotplug and EH reset paths uniform.
> > > Previously, broken hardreset could go unnoticed as it wasn't used
> > > during probing but when something goes wrong or after hotplug the
> > > problem will surface and bite hard.
> > > 
> > > OSDL bug 11195 reports that sata_nv generic flavor falls into this
> > > category.  Hardreset itself succeeds but PHY stays offline after
> > > hardreset.  I tried longer debounce timing but the result was the
> > > same.
> > > 
> > >   http://bugzilla.kernel.org/show_bug.cgi?id=11195
> > > 
> > > So, it seems we'll have to drop hardreset from the generic flavor.
> > > 
> > > Signed-off-by: Tejun Heo <tj@kernel.org>
> > > Cc: Peer Chen <pchen@nvidia.com>
> > > Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > 
> > On 2.6.26.5 + the pending stable queue applied, this patch results in lots 
> > of noise in my syslog (full gzipped dmesg with and without this patch 
> > attached):
> 
> This patch has been removed from the stable queue, so it shouldn't be an
> issue anymore, right?

Yes, you're right. I missed it being removed from queue-2.6.26 a few hours 
before I actually sent the mail, sorry for the noise.

Thanks
	Stefan Lippers-Hollmann

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]