[git patch] 2.6.x libata fix

[git patch] 2.6.x libata fix

[Jeff Garzik]

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

Please pull from 'upstream' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

to obtain the fix described in the attached diffstat/changelog/patch.


[-- Attachment #2: libata-dev.txt --]
[-- Type: text/plain, Size: 2359 bytes --]

 drivers/scsi/ata_piix.c |   19 +++++++++++++------
 1 files changed, 13 insertions(+), 6 deletions(-)


commit 7b6dbd6872ca1d0c03dc0e0a7108d79c8dafa793
Author: Greg Felix <gregfelixlkml@gmail.com>
Date:   Thu Jul 28 15:54:15 2005 -0400

    libata: Check PCI sub-class code before disabling AHCI
    
    This patch adds functionality to check the PCI sub-class code of an
    AHCI capable device before disabling AHCI.  It fixes a bug where an
    ICH7 sata controller is being setup by the BIOS as sub-class 1 (ide)
    and the AHCI control registers weren't being initialized, thus causing
    an IO error in piix_disable_ahci().
    
    Signed-off-by: Gregory Felix <greg.felix@gmail.com>


diff --git a/drivers/scsi/ata_piix.c b/drivers/scsi/ata_piix.c
--- a/drivers/scsi/ata_piix.c
+++ b/drivers/scsi/ata_piix.c
@@ -38,6 +38,7 @@ enum {
 	PIIX_IOCFG		= 0x54, /* IDE I/O configuration register */
 	ICH5_PMR		= 0x90, /* port mapping register */
 	ICH5_PCS		= 0x92,	/* port control and status */
+	PIIX_SCC		= 0x0A, /* sub-class code register */
 
 	PIIX_FLAG_AHCI		= (1 << 28), /* AHCI possible */
 	PIIX_FLAG_CHECKINTR	= (1 << 29), /* make sure PCI INTx enabled */
@@ -62,6 +63,8 @@ enum {
 	ich6_sata_rm		= 4,
 	ich7_sata		= 5,
 	esb2_sata		= 6,
+
+	PIIX_AHCI_DEVICE	= 6,
 };
 
 static int piix_init_one (struct pci_dev *pdev,
@@ -574,11 +577,11 @@ static int piix_disable_ahci(struct pci_
 	addr = pci_resource_start(pdev, AHCI_PCI_BAR);
 	if (!addr || !pci_resource_len(pdev, AHCI_PCI_BAR))
 		return 0;
-	
+
 	mmio = ioremap(addr, 64);
 	if (!mmio)
 		return -ENOMEM;
-	
+
 	tmp = readl(mmio + AHCI_GLOBAL_CTL);
 	if (tmp & AHCI_ENABLE) {
 		tmp &= ~AHCI_ENABLE;
@@ -588,7 +591,7 @@ static int piix_disable_ahci(struct pci_
 		if (tmp & AHCI_ENABLE)
 			rc = -EIO;
 	}
-	
+
 	iounmap(mmio);
 	return rc;
 }
@@ -626,9 +629,13 @@ static int piix_init_one (struct pci_dev
 	port_info[1] = NULL;
 
 	if (port_info[0]->host_flags & PIIX_FLAG_AHCI) {
-		int rc = piix_disable_ahci(pdev);
-		if (rc)
-			return rc;
+               u8 tmp;
+               pci_read_config_byte(pdev, PIIX_SCC, &tmp);
+               if (tmp == PIIX_AHCI_DEVICE) {
+                       int rc = piix_disable_ahci(pdev);
+                       if (rc)
+                           return rc;
+               }
 	}
 
 	if (port_info[0]->host_flags & PIIX_FLAG_COMBINED) {

[git patch] 2.6.x libata fix

[Jeff Garzik]

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

to receive the following updates:

 drivers/scsi/sata_nv.c |   30 ++++++++++++++++++++++++------
 1 files changed, 24 insertions(+), 6 deletions(-)

Andrew Chew:
      sata_nv, spurious interrupts at system startup with MAXTOR 6H500F0 drive

diff --git a/drivers/scsi/sata_nv.c b/drivers/scsi/sata_nv.c
index c0cf52c..bbbb55e 100644
--- a/drivers/scsi/sata_nv.c
+++ b/drivers/scsi/sata_nv.c
@@ -29,6 +29,12 @@
  *  NV-specific details such as register offsets, SATA phy location,
  *  hotplug info, etc.
  *
+ *  0.10
+ *     - Fixed spurious interrupts issue seen with the Maxtor 6H500F0 500GB
+ *       drive.  Also made the check_hotplug() callbacks return whether there
+ *       was a hotplug interrupt or not.  This was not the source of the
+ *       spurious interrupts, but is the right thing to do anyway.
+ *
  *  0.09
  *     - Fixed bug introduced by 0.08's MCP51 and MCP55 support.
  *
@@ -124,10 +130,10 @@ static void nv_scr_write (struct ata_por
 static void nv_host_stop (struct ata_host_set *host_set);
 static void nv_enable_hotplug(struct ata_probe_ent *probe_ent);
 static void nv_disable_hotplug(struct ata_host_set *host_set);
-static void nv_check_hotplug(struct ata_host_set *host_set);
+static int nv_check_hotplug(struct ata_host_set *host_set);
 static void nv_enable_hotplug_ck804(struct ata_probe_ent *probe_ent);
 static void nv_disable_hotplug_ck804(struct ata_host_set *host_set);
-static void nv_check_hotplug_ck804(struct ata_host_set *host_set);
+static int nv_check_hotplug_ck804(struct ata_host_set *host_set);
 
 enum nv_host_type
 {
@@ -176,7 +182,7 @@ struct nv_host_desc
 	enum nv_host_type	host_type;
 	void			(*enable_hotplug)(struct ata_probe_ent *probe_ent);
 	void			(*disable_hotplug)(struct ata_host_set *host_set);
-	void			(*check_hotplug)(struct ata_host_set *host_set);
+	int			(*check_hotplug)(struct ata_host_set *host_set);
 
 };
 static struct nv_host_desc nv_device_tbl[] = {
@@ -309,12 +315,16 @@ static irqreturn_t nv_interrupt (int irq
 			qc = ata_qc_from_tag(ap, ap->active_tag);
 			if (qc && (!(qc->tf.ctl & ATA_NIEN)))
 				handled += ata_host_intr(ap, qc);
+			else
+				// No request pending?  Clear interrupt status
+				// anyway, in case there's one pending.
+				ap->ops->check_status(ap);
 		}
 
 	}
 
 	if (host->host_desc->check_hotplug)
-		host->host_desc->check_hotplug(host_set);
+		handled += host->host_desc->check_hotplug(host_set);
 
 	spin_unlock_irqrestore(&host_set->lock, flags);
 
@@ -497,7 +507,7 @@ static void nv_disable_hotplug(struct at
 	outb(intr_mask, host_set->ports[0]->ioaddr.scr_addr + NV_INT_ENABLE);
 }
 
-static void nv_check_hotplug(struct ata_host_set *host_set)
+static int nv_check_hotplug(struct ata_host_set *host_set)
 {
 	u8 intr_status;
 
@@ -522,7 +532,11 @@ static void nv_check_hotplug(struct ata_
 		if (intr_status & NV_INT_STATUS_SDEV_REMOVED)
 			printk(KERN_WARNING "nv_sata: "
 				"Secondary device removed\n");
+
+		return 1;
 	}
+
+	return 0;
 }
 
 static void nv_enable_hotplug_ck804(struct ata_probe_ent *probe_ent)
@@ -560,7 +574,7 @@ static void nv_disable_hotplug_ck804(str
 	pci_write_config_byte(pdev, NV_MCP_SATA_CFG_20, regval);
 }
 
-static void nv_check_hotplug_ck804(struct ata_host_set *host_set)
+static int nv_check_hotplug_ck804(struct ata_host_set *host_set)
 {
 	u8 intr_status;
 
@@ -585,7 +599,11 @@ static void nv_check_hotplug_ck804(struc
 		if (intr_status & NV_INT_STATUS_SDEV_REMOVED)
 			printk(KERN_WARNING "nv_sata: "
 				"Secondary device removed\n");
+
+		return 1;
 	}
+
+	return 0;
 }
 
 static int __init nv_init(void)

Re: [git patch] 2.6.x libata fix

[Matt Darcy]

Jeff Garzik wrote:

>Please pull from 'upstream-linus' branch of
>master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>
>to receive the following updates:
>
> drivers/scsi/sata_nv.c |   30 ++++++++++++++++++++++++------
> 1 files changed, 24 insertions(+), 6 deletions(-)
>
>Andrew Chew:
>      sata_nv, spurious interrupts at system startup with MAXTOR 6H500F0 drive
>
>diff --git a/drivers/scsi/sata_nv.c b/drivers/scsi/sata_nv.c
>index c0cf52c..bbbb55e 100644
>--- a/drivers/scsi/sata_nv.c
>+++ b/drivers/scsi/sata_nv.c
>
> <snip reset of patch>
>  
>
Hi Jeff, et all

I pulled this down last night from 
git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
as I don't have an account on master.kernel.org, I assume these are the 
same physical tree.

This built fine and seemed aware of all the SATA disks on my controller 
(as did previous git branches).

Again using my raid5 (7 disks 1.4tb) example, I am unable to build an 
array without the machine hanging.

I am able to access the individual disks for a short period of time 
before the box hangs totally which I assume is why the raid array will 
not build as the access for the disks hangs, not the actual building of 
the array.

I havn't got any output yet on the errors (if there are any) as I left 
the array building overnight (300+ minutes) and when I woke up this 
morning the box had hung, but power saver had come on the screen so I 
couldn't see the messages.

I'll do another test this afternoon and try to get some output for you, 
but I just thought I'd let you know this was coming.

Aslo FYI: I'm using maxtor SATA disks, so your patch was of particular 
interesting to me.

Many thanks,

Matt

Re: [git patch] 2.6.x libata fix

[Matt Darcy]

Matt Darcy wrote:

> Jeff Garzik wrote:
>
>> Please pull from 'upstream-linus' branch of
>> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>>
>> to receive the following updates:
>>
>> drivers/scsi/sata_nv.c |   30 ++++++++++++++++++++++++------
>> 1 files changed, 24 insertions(+), 6 deletions(-)
>>
>> Andrew Chew:
>>      sata_nv, spurious interrupts at system startup with MAXTOR 
>> 6H500F0 drive
>>
>> diff --git a/drivers/scsi/sata_nv.c b/drivers/scsi/sata_nv.c
>> index c0cf52c..bbbb55e 100644
>> --- a/drivers/scsi/sata_nv.c
>> +++ b/drivers/scsi/sata_nv.c
>>
>> <snip reset of patch>
>>  
>>
> Hi Jeff, et all
>
> I pulled this down last night from 
> git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> as I don't have an account on master.kernel.org, I assume these are 
> the same physical tree.
>
> This built fine and seemed aware of all the SATA disks on my 
> controller (as did previous git branches).
>
> Again using my raid5 (7 disks 1.4tb) example, I am unable to build an 
> array without the machine hanging.
>
> I am able to access the individual disks for a short period of time 
> before the box hangs totally which I assume is why the raid array will 
> not build as the access for the disks hangs, not the actual building 
> of the array.
>
> I havn't got any output yet on the errors (if there are any) as I left 
> the array building overnight (300+ minutes) and when I woke up this 
> morning the box had hung, but power saver had come on the screen so I 
> couldn't see the messages.
>
> I'll do another test this afternoon and try to get some output for 
> you, but I just thought I'd let you know this was coming.
>
> Aslo FYI: I'm using maxtor SATA disks, so your patch was of particular 
> interesting to me.
>
> Many thanks,
>
> Matt


I can now provide further updates for this, although this are not really 
super useful.

I've copied the linux-raid list in as well, as after a little more 
testing on my part I'd appriciate some input from the raid guys also.

First of all, please ignore the comments above, there was a problem with 
grub and it actually "failed back" and booted into the older git 
release, so my initial test was actually done running the wrong kenel 
which I didn't notice. Appologies to all for this.

Last nights tests where done using the correct kernel (I fixed the grub 
typo) 2.6.15-g5367f2d6

The details I have are as follows.

I can run the machine accessing the 7 maxtor SATA disks as individual 
disks for around 12 hours now, without any hangs or errors or any real 
problems. I've not hit them very hard, but initial performance seems 
fine and more than usable.

The actual problems occurr when including these disks in a raid group.

root@berger:~# fdisk -l /dev/sdc

Disk /dev/sdc: 251.0 GB, 251000193024 bytes
255 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1       30515   245111706   fd  Linux raid 
autodetect

root@berger:~# fdisk -l /dev/sde

Disk /dev/sde: 251.0 GB, 251000193024 bytes
255 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sde1               1       30515   245111706   fd  Linux raid 
autodetect


As you can see from my two random disks examples, they are partitioned 
and makred as raid auto detect.

I issue the mdadm command to build the raid 5 array

 mdadm -C /dev/md6 -l5 -n6 -x1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 
/dev/sdg1 /dev/sdh1 /dev/sdi1

and the array starts to build.......

md6 : active raid5 sdh1[7] sdi1[6](S) sdg1[4] sdf1[3] sde1[2] sdd1[1] 
sdc1[0]
      1225558080 blocks level 5, 64k chunk, algorithm 2 [6/5] [UUUUU_]
      [>....................]  recovery =  0.1% (374272/245111616) 
finish=337.8min speed=12073K/sec


however at around %25 - %40 completion the box will simpley just hang - 
I'm getting no on screen messages and the sylog is not reporting anything.

SysRQ is unusable.

I'm open to options on how to resolve this and move the driver forward 
(assuming it is the drivers interfaction with the raid sub system)
or
how to get some meaningful debug out to report back to the appropriate 
development groups.

thanks.

Matt.

Re: [git patch] 2.6.x libata fix

[PFC]

	Hello,

	I've had a lot of problems with nv_sata (nforce3) and Maxtor harddrives.  
Basically it always boils down to :

Dec 24 23:04:34 apollo13 ata3: command 0x35 timeout, stat 0xd0 host_stat  
0x21
Dec 24 23:04:34 apollo13 ata3: translated ATA stat/err 0x35/00 to SCSI  
SK/ASC/ASCQ 0x4/00/00
Dec 24 23:04:34 apollo13 ata3: status=0x35 { DeviceFault SeekComplete  
CorrectedError Error }
Dec 24 23:04:34 apollo13 sd 2:0:0:0: SCSI error: return code = 0x8000002
Dec 24 23:04:34 apollo13 sdc: Current: sense key=0x4
Dec 24 23:04:34 apollo13 ASC=0x0 ASCQ=0x0
Dec 24 23:04:34 apollo13 end_request: I/O error, dev sdc, sector 490223295
Dec 24 23:04:34 apollo13 raid5: Disk failure on sdc1, disabling device.  
Operation continuing on 3 devices

	Plugging the Maxtor drives on the not-nv SATA sockets solved it (thanks  
god I have 2 maxtor and 2 seagate drives)...

	If you want more info, just ask.

Re: [git patch] 2.6.x libata fix

[Matt Darcy]

PFC wrote:

>
>     Hello,
>
>     I've had a lot of problems with nv_sata (nforce3) and Maxtor 
> harddrives.  Basically it always boils down to :
>
> Dec 24 23:04:34 apollo13 ata3: command 0x35 timeout, stat 0xd0 
> host_stat  0x21
> Dec 24 23:04:34 apollo13 ata3: translated ATA stat/err 0x35/00 to 
> SCSI  SK/ASC/ASCQ 0x4/00/00
> Dec 24 23:04:34 apollo13 ata3: status=0x35 { DeviceFault SeekComplete  
> CorrectedError Error }
> Dec 24 23:04:34 apollo13 sd 2:0:0:0: SCSI error: return code = 0x8000002
> Dec 24 23:04:34 apollo13 sdc: Current: sense key=0x4
> Dec 24 23:04:34 apollo13 ASC=0x0 ASCQ=0x0
> Dec 24 23:04:34 apollo13 end_request: I/O error, dev sdc, sector 
> 490223295
> Dec 24 23:04:34 apollo13 raid5: Disk failure on sdc1, disabling 
> device.  Operation continuing on 3 devices
>
>     Plugging the Maxtor drives on the not-nv SATA sockets solved it 
> (thanks  god I have 2 maxtor and 2 seagate drives)...
>
>

Thanks for the message,

I'm not using nv_sata, I'm using sata_mv,

just to clarify.

Could we please try to keep this thread on topic.

Regards,

Matt

Re: [git patch] 2.6.x libata fix

[Matt Darcy]

>
>
> I can now provide further updates for this, although this are not 
> really super useful.
>
> I've copied the linux-raid list in as well, as after a little more 
> testing on my part I'd appriciate some input from the raid guys also.
>
> First of all, please ignore the comments above, there was a problem 
> with grub and it actually "failed back" and booted into the older git 
> release, so my initial test was actually done running the wrong kenel 
> which I didn't notice. Appologies to all for this.
>
> Last nights tests where done using the correct kernel (I fixed the 
> grub typo) 2.6.15-g5367f2d6
>
> The details I have are as follows.
>
> I can run the machine accessing the 7 maxtor SATA disks as individual 
> disks for around 12 hours now, without any hangs or errors or any real 
> problems. I've not hit them very hard, but initial performance seems 
> fine and more than usable.
>
> The actual problems occurr when including these disks in a raid group.
>
> root@berger:~# fdisk -l /dev/sdc
>
> Disk /dev/sdc: 251.0 GB, 251000193024 bytes
> 255 heads, 63 sectors/track, 30515 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sdc1               1       30515   245111706   fd  Linux raid 
> autodetect
>
> root@berger:~# fdisk -l /dev/sde
>
> Disk /dev/sde: 251.0 GB, 251000193024 bytes
> 255 heads, 63 sectors/track, 30515 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sde1               1       30515   245111706   fd  Linux raid 
> autodetect
>
>
> As you can see from my two random disks examples, they are partitioned 
> and makred as raid auto detect.
>
> I issue the mdadm command to build the raid 5 array
>
> mdadm -C /dev/md6 -l5 -n6 -x1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 
> /dev/sdg1 /dev/sdh1 /dev/sdi1
>
> and the array starts to build.......
>
> md6 : active raid5 sdh1[7] sdi1[6](S) sdg1[4] sdf1[3] sde1[2] sdd1[1] 
> sdc1[0]
>      1225558080 blocks level 5, 64k chunk, algorithm 2 [6/5] [UUUUU_]
>      [>....................]  recovery =  0.1% (374272/245111616) 
> finish=337.8min speed=12073K/sec
>
>
> however at around %25 - %40 completion the box will simpley just hang 
> - I'm getting no on screen messages and the sylog is not reporting 
> anything.
>
> SysRQ is unusable.
>
> I'm open to options on how to resolve this and move the driver forward 
> (assuming it is the drivers interfaction with the raid sub system)
> or
> how to get some meaningful debug out to report back to the appropriate 
> development groups.
>
> thanks.
>
> Matt.
>
>
>
Further further information

The speed that the raid array is being built att appears to drop as the 
array is created

[=====>...............]  recovery = 29.2% (71633360/245111616) 
finish=235.1min speed=12296K/sec
[=====>...............]  recovery = 29.3% (71874512/245111616) 
finish=235.2min speed=12269K/sec
[=====>...............]  recovery = 29.4% (72115872/245111616) 
finish=236.0min speed=12209K/sec
[=====>...............]  recovery = 29.7% (72839648/245111616) 
finish=237.4min speed=12091K/sec
[=====>...............]  recovery = 29.8% (73078560/245111616) 
finish=238.6min speed=12010K/sec
[=====>...............]  recovery = 29.8% (73139424/245111616) 
finish=350.5min speed=8176K/sec
[=====>...............]  recovery = 29.8% (73139424/245111616) 
finish=499.6min speed=5735K/sec
[=====>...............]  recovery = 29.8% (73139776/245111616) 
finish=691.0min speed=4147K/sec

Now the box is hung

I didn't notice this until about %20 through the creation of the array 
then I started paying attention to this. These snap shots are taken 
every 30 seconds

So the problem appears to sap bandwidth on the card to the point there 
the box hangs.

This may have some relevance, or it may not, but worth mentioning at least.

Matt










[=====>...............]  recovery = 29.8% (73139424/245111616) 
finish=350.5min speed=8176K/sec

[git patch] 2.6.x libata fix

[Jeff Garzik]

Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

to receive the following updates:

 drivers/scsi/libata-scsi.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

Tejun Heo:
      libata: fix ata_scsi_pass_thru error handling

diff --git a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c
index 3b4ca55..379e870 100644
--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -2239,7 +2239,7 @@ ata_scsi_pass_thru(struct ata_queued_cmd
 	struct scsi_cmnd *cmd = qc->scsicmd;
 
 	if ((tf->protocol = ata_scsi_map_proto(scsicmd[1])) == ATA_PROT_UNKNOWN)
-		return 1;
+		goto invalid_fld;
 
 	/*
 	 * 12 and 16 byte CDBs use different offsets to
@@ -2301,7 +2301,7 @@ ata_scsi_pass_thru(struct ata_queued_cmd
 	 */
 	if ((tf->command == ATA_CMD_SET_FEATURES)
 	 && (tf->feature == SETFEATURES_XFER))
-		return 1;
+		goto invalid_fld;
 
 	/*
 	 * Set flags so that all registers will be written,
@@ -2322,6 +2322,11 @@ ata_scsi_pass_thru(struct ata_queued_cmd
 	qc->nsect = cmd->bufflen / ATA_SECT_SIZE;
 
 	return 0;
+
+ invalid_fld:
+	ata_scsi_set_sense(qc->scsicmd, ILLEGAL_REQUEST, 0x24, 0x00);
+	/* "Invalid field in cdb" */
+	return 1;
 }
 
 /**

[git patch] 2.6.x libata fix

[Jeff Garzik]

Please pull from the 'upstream' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

to obtain the following fix:


 drivers/scsi/sata_promise.c |   50 +++++++++++++++++++++++++++++++++++++-------
 1 files changed, 43 insertions(+), 7 deletions(-)


commit 2cba582a49f1535c1a12a687cfb3dab713c22cc4
Author: Jeff Garzik <jgarzik@pobox.com>
Date:   Mon Aug 29 05:12:30 2005 -0400

    [libata sata_promise] Do not attempt to use SATA phy on PATA controllers


diff --git a/drivers/scsi/sata_promise.c b/drivers/scsi/sata_promise.c
--- a/drivers/scsi/sata_promise.c
+++ b/drivers/scsi/sata_promise.c
@@ -84,7 +84,8 @@ static irqreturn_t pdc_interrupt (int ir
 static void pdc_eng_timeout(struct ata_port *ap);
 static int pdc_port_start(struct ata_port *ap);
 static void pdc_port_stop(struct ata_port *ap);
-static void pdc_phy_reset(struct ata_port *ap);
+static void pdc_pata_phy_reset(struct ata_port *ap);
+static void pdc_sata_phy_reset(struct ata_port *ap);
 static void pdc_qc_prep(struct ata_queued_cmd *qc);
 static void pdc_tf_load_mmio(struct ata_port *ap, struct ata_taskfile *tf);
 static void pdc_exec_command_mmio(struct ata_port *ap, struct ata_taskfile *tf);
@@ -111,19 +112,22 @@ static Scsi_Host_Template pdc_ata_sht = 
 	.ordered_flush		= 1,
 };
 
-static struct ata_port_operations pdc_ata_ops = {
+static struct ata_port_operations pdc_sata_ops = {
 	.port_disable		= ata_port_disable,
 	.tf_load		= pdc_tf_load_mmio,
 	.tf_read		= ata_tf_read,
 	.check_status		= ata_check_status,
 	.exec_command		= pdc_exec_command_mmio,
 	.dev_select		= ata_std_dev_select,
-	.phy_reset		= pdc_phy_reset,
+
+	.phy_reset		= pdc_sata_phy_reset,
+
 	.qc_prep		= pdc_qc_prep,
 	.qc_issue		= pdc_qc_issue_prot,
 	.eng_timeout		= pdc_eng_timeout,
 	.irq_handler		= pdc_interrupt,
 	.irq_clear		= pdc_irq_clear,
+
 	.scr_read		= pdc_sata_scr_read,
 	.scr_write		= pdc_sata_scr_write,
 	.port_start		= pdc_port_start,
@@ -131,6 +135,27 @@ static struct ata_port_operations pdc_at
 	.host_stop		= ata_host_stop,
 };
 
+static struct ata_port_operations pdc_pata_ops = {
+	.port_disable		= ata_port_disable,
+	.tf_load		= pdc_tf_load_mmio,
+	.tf_read		= ata_tf_read,
+	.check_status		= ata_check_status,
+	.exec_command		= pdc_exec_command_mmio,
+	.dev_select		= ata_std_dev_select,
+
+	.phy_reset		= pdc_pata_phy_reset,
+
+	.qc_prep		= pdc_qc_prep,
+	.qc_issue		= pdc_qc_issue_prot,
+	.eng_timeout		= pdc_eng_timeout,
+	.irq_handler		= pdc_interrupt,
+	.irq_clear		= pdc_irq_clear,
+
+	.port_start		= pdc_port_start,
+	.port_stop		= pdc_port_stop,
+	.host_stop		= ata_host_stop,
+};
+
 static struct ata_port_info pdc_port_info[] = {
 	/* board_2037x */
 	{
@@ -140,7 +165,7 @@ static struct ata_port_info pdc_port_inf
 		.pio_mask	= 0x1f, /* pio0-4 */
 		.mwdma_mask	= 0x07, /* mwdma0-2 */
 		.udma_mask	= 0x7f, /* udma0-6 ; FIXME */
-		.port_ops	= &pdc_ata_ops,
+		.port_ops	= &pdc_sata_ops,
 	},
 
 	/* board_20319 */
@@ -151,7 +176,7 @@ static struct ata_port_info pdc_port_inf
 		.pio_mask	= 0x1f, /* pio0-4 */
 		.mwdma_mask	= 0x07, /* mwdma0-2 */
 		.udma_mask	= 0x7f, /* udma0-6 ; FIXME */
-		.port_ops	= &pdc_ata_ops,
+		.port_ops	= &pdc_sata_ops,
 	},
 
 	/* board_20619 */
@@ -162,7 +187,7 @@ static struct ata_port_info pdc_port_inf
 		.pio_mask	= 0x1f, /* pio0-4 */
 		.mwdma_mask	= 0x07, /* mwdma0-2 */
 		.udma_mask	= 0x7f, /* udma0-6 ; FIXME */
-		.port_ops	= &pdc_ata_ops,
+		.port_ops	= &pdc_pata_ops,
 	},
 };
 
@@ -277,12 +302,23 @@ static void pdc_reset_port(struct ata_po
 	readl(mmio);	/* flush */
 }
 
-static void pdc_phy_reset(struct ata_port *ap)
+static void pdc_sata_phy_reset(struct ata_port *ap)
 {
 	pdc_reset_port(ap);
 	sata_phy_reset(ap);
 }
 
+static void pdc_pata_phy_reset(struct ata_port *ap)
+{
+	/* FIXME: add cable detect.  Don't assume 40-pin cable */
+	ap->cbl = ATA_CBL_PATA40;
+	ap->udma_mask &= ATA_UDMA_MASK_40C;
+
+	pdc_reset_port(ap);
+	ata_port_probe(ap);
+	ata_bus_reset(ap);
+}
+
 static u32 pdc_sata_scr_read (struct ata_port *ap, unsigned int sc_reg)
 {
 	if (sc_reg > SCR_CONTROL)

[git patch] 2.6.x libata fix

[Jeff Garzik]

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

Please pull from the 'upstream' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

to obtain the fix (and cleanup) described in the attachment.


[-- Attachment #2: libata-dev.txt --]
[-- Type: text/plain, Size: 1268 bytes --]

 drivers/scsi/libata-scsi.c |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)


Philip Pokorny:
  libata fix read capacity handling for more than 2TB


diff --git a/drivers/scsi/libata-scsi.c b/drivers/scsi/libata-scsi.c
--- a/drivers/scsi/libata-scsi.c
+++ b/drivers/scsi/libata-scsi.c
@@ -1176,8 +1176,12 @@ unsigned int ata_scsiop_read_cap(struct 
 		n_sectors = ata_id_u32(args->id, 60);
 	n_sectors--;		/* ATA TotalUserSectors - 1 */
 
-	tmp = n_sectors;	/* note: truncates, if lba48 */
 	if (args->cmd->cmnd[0] == READ_CAPACITY) {
+		if( n_sectors >= 0xffffffffULL )
+			tmp = 0xffffffff ;  /* Return max count on overflow */
+		else
+			tmp = n_sectors ;
+
 		/* sector count, 32-bit */
 		rbuf[0] = tmp >> (8 * 3);
 		rbuf[1] = tmp >> (8 * 2);
@@ -1191,10 +1195,12 @@ unsigned int ata_scsiop_read_cap(struct 
 
 	} else {
 		/* sector count, 64-bit */
-		rbuf[2] = n_sectors >> (8 * 7);
-		rbuf[3] = n_sectors >> (8 * 6);
-		rbuf[4] = n_sectors >> (8 * 5);
-		rbuf[5] = n_sectors >> (8 * 4);
+		tmp = n_sectors >> (8 * 4);
+		rbuf[2] = tmp >> (8 * 3);
+		rbuf[3] = tmp >> (8 * 2);
+		rbuf[4] = tmp >> (8 * 1);
+		rbuf[5] = tmp;
+		tmp = n_sectors;
 		rbuf[6] = tmp >> (8 * 3);
 		rbuf[7] = tmp >> (8 * 2);
 		rbuf[8] = tmp >> (8 * 1);

[git patch] 2.6.x libata fix

[Jeff Garzik]

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


Please pull branch 'misc-fixes' of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

to obtain the fix described in the attachment.



[-- Attachment #2: libata-2.6.txt --]
[-- Type: text/plain, Size: 3129 bytes --]



 drivers/scsi/libata-core.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)


commit 32529e0128923e42126b5d14e444c18295a452ba
tree d50736f63bd9692076d68c3f8748f1b6bf540a80
parent bef9c558841604116704e10b3d9ff3dbf4939423
author Albert Lee <albertcc@tw.ibm.com> Thu, 26 May 2005 11:49:42 -0400
committer Jeff Garzik <jgarzik@pobox.com> Thu, 26 May 2005 11:49:42 -0400

[PATCH] libata: Fix zero sg_dma_len() on 64-bit platform

When testing ATAPI PIO data transfer on the ppc64 platform,  __atapi_pio_bytes() got zero when
sg_dma_len() is used. I checked the <asm-ppc64/scatterlish.h>, the struct scatterlist is defined as:

struct scatterlist {
	struct page *page;
	unsigned int offset;
	unsigned int length;

	/* For TCE support */
	u32 dma_address;
	u32 dma_length;
};

#define sg_dma_address(sg)	((sg)->dma_address)
#define sg_dma_len(sg)		((sg)->dma_length)

So, if the scatterlist is not DMA mapped, sg_dma_len() will return zero on ppc64.
The same problem should occur on the x86-64 platform.
On the i386 platform, sg_dma_len() returns sg->length, that's why the problem does not occur on an i386.

Changes:
- Use sg->length if the scatterlist is not DMA mapped (yet).

Signed-off-by: Albert Lee <albertcc@tw.ibm.com>

--------------------------


diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -2071,7 +2071,7 @@ void ata_sg_init_one(struct ata_queued_c
 	sg = qc->sg;
 	sg->page = virt_to_page(buf);
 	sg->offset = (unsigned long) buf & ~PAGE_MASK;
-	sg_dma_len(sg) = buflen;
+	sg->length = buflen;
 }
 
 void ata_sg_init(struct ata_queued_cmd *qc, struct scatterlist *sg,
@@ -2101,11 +2101,12 @@ static int ata_sg_setup_one(struct ata_q
 	dma_addr_t dma_address;
 
 	dma_address = dma_map_single(ap->host_set->dev, qc->buf_virt,
-				     sg_dma_len(sg), dir);
+				     sg->length, dir);
 	if (dma_mapping_error(dma_address))
 		return -1;
 
 	sg_dma_address(sg) = dma_address;
+	sg_dma_len(sg) = sg->length;
 
 	DPRINTK("mapped buffer of %d bytes for %s\n", sg_dma_len(sg),
 		qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
@@ -2310,7 +2311,7 @@ static void ata_pio_sector(struct ata_qu
 	qc->cursect++;
 	qc->cursg_ofs++;
 
-	if ((qc->cursg_ofs * ATA_SECT_SIZE) == sg_dma_len(&sg[qc->cursg])) {
+	if ((qc->cursg_ofs * ATA_SECT_SIZE) == (&sg[qc->cursg])->length) {
 		qc->cursg++;
 		qc->cursg_ofs = 0;
 	}
@@ -2347,7 +2348,7 @@ next_page:
 	page = nth_page(page, (offset >> PAGE_SHIFT));
 	offset %= PAGE_SIZE;
 
-	count = min(sg_dma_len(sg) - qc->cursg_ofs, bytes);
+	count = min(sg->length - qc->cursg_ofs, bytes);
 
 	/* don't cross page boundaries */
 	count = min(count, (unsigned int)PAGE_SIZE - offset);
@@ -2358,7 +2359,7 @@ next_page:
 	qc->curbytes += count;
 	qc->cursg_ofs += count;
 
-	if (qc->cursg_ofs == sg_dma_len(sg)) {
+	if (qc->cursg_ofs == sg->length) {
 		qc->cursg++;
 		qc->cursg_ofs = 0;
 	}
@@ -2371,7 +2372,7 @@ next_page:
 	kunmap(page);
 
 	if (bytes) {
-		if (qc->cursg_ofs < sg_dma_len(sg))
+		if (qc->cursg_ofs < sg->length)
 			goto next_page;
 		goto next_sg;
 	}