Linux kernel 2.6.10 sata_nv.c stops working on my hardware

Linux kernel 2.6.10 sata_nv.c stops working on my hardware

[Grzegorz Adam Hankiewicz]

Hello.

On monday, 19 Jun, I sent an email to Andrew Chew at nvidia.com
regarding an issue I have with the sata_nv.c driver.  Basically,
it doesn't work for me from 2.6.10 up. I haven't received any kind
of reply yet. In case he's not available any more, I'm posting this
here in the hope somebody can suggest me how to solve the problem.

What follows is my original email sent to Andrew, with small
changes. Also, as requested on the FAQ, attachments are available
at http://gradha.sdf-eu.org/sata/ instead of being attached to
this mail.

I have subscribed to this mailing list. If you can do so, please
avoid sending me a copy, answer just to the mailing list. TIA.

----

I've recently had to upgrade my computer and bought an AMD Sempron
64bit 3100+ SK754, with motherboard K8 Asrock Upgrade K8NF3. Along
with this, two Maxtor 300GB hard drives, model 6V300F0.

I booted with the latest Knoppix 5.0 to set up the partitions
and found that while I could fdisk /dev/sd?, even changing a few
parameters would make fdisk hang indefinitely. On the other hand,
I got a Debian Sarge net installation disk which booted perfectly
with a 2.6 kernel.  After installing a basic system with it, I
started to tear the system to pieces to find out what was making
the hard disks fails.

After a while I found out that it was the SATA NV driver. The Sarge I
installed contains a 2.6.8 kernel + Debian patches.  I downloaded all
kernels from 2.6.8 up to 2.6.17 and created a synthetic configuration
which was loaded through "make menuconfig" in all of them (attached).
This configuration just makes SCSI and Nvidia Sata as built in code,
to make sure the machine can boot from /dev/sda1.

I started testing the kernels down from 2.6.8 (to weed out any
additional effects of Debian patches) and soon discovered that
while I could boot and work with the 2.6.9 kernel, 2.6.10 would
fail and hang forever during boot up, trying to mount/read the
main ext3 partition of my hard disk. So basically, 2.6.9 works,
2.6.10 doesn't, both with the same configuration loaded.

The problem: as mentioned above, the Knoppix would be able to see the
hard disks, but unable to mount them, or format with fdisk. Albeit
this would happen randomly. Sometimes I would be able to mount
/dev/sda1, but hang forever on /dev/sdb1. Sometimes the other
way round. However, everything would work OK if I mounted them
read-only. So the problem seems to be related to drive write mode.

Now, starting with my custom kernels the boot sequence stops when
it wants to mount the main filesystem.  The ext3 fs is detected
and mounted, but just after a line in the form of "ext3 clean
blah blah blah", it hangs, and after half a minute or so I get a
round of these errors (possibly hand transcriptions error follow,
and only different significant ones were copied:

 ata1: command 0x35 timeout, stat 0xd0 host stat 0x21
 ata1: translated ATA stat/err 0xd0/00 to SCSI SK/ACC/ASCQ 0xB/47/00
 ata1: status=0xd0 { busy }
 
or repeated several times
 
 ATA: abnormal status 0xD0 on port 0xF87

To my dismay I have discovered that the motherboard I got basically
sucks in terms of SATA support, or at least so do angry people on
forums claim, blaming nvidia for bad drivers and whatnot under
Windows. I have also found that the hard disks I have *may* have
a buggy firmware:

  https://maxtor.custhelp.com/cgi-bin/maxtor.cfg/php/enduser/std_adp.php?p_faqid=2685&p_created=1136595488&p_sid=sFOM9iai&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MSZwX3Byb2RzPTAmcF9jYXRzPTAmcF9wdj0mcF9jdj0mcF9zZWFyY2hfdHlwZT1hbnN3ZXJzLnNlYXJjaF9ubCZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PStuZm9yY2UzICtzYXRh&p_li=&p_topview=1

Both hard disks I have are marked as:

  6V300F0 - VA111630 - V60EA5F6
  6V300F0 - VA111630 - V60EYSY6

According to the web page mentioned before, these serials mean I'm
not affected by this report. That doesn't necessarily mean they are
ok, but I do hope so, and at least they work with kernels <2.6.9
flawlessly (I've been using them for a week on a raid0 setup while
I wait for a correct fix).

So, from the web information I've gathered, there are four possible
likely problems:

  1) Bad cables, recommended to buy new ones on some forums.
  2) Bad motherboard, upgrade firmware.
  3) Bad hard disks, replace or upgrade firmware.
  4) Bad OS drivers.

I think the usage of the Debian 2.6.8-2-386 kernel for two weeks
discards the first three, leaving the fourth to deal with.

I want to know if you agree with this reasoning, and if as writer
of the sata_nv.c file you could help me diagnose the problem and
modify the last kernel version to make it work on my system. Please
suggest me change stuff to discard other kernel interferences,
or send my patches to try to address the problem.

My intention is to format the raid0 setup with reiser4. Even though
there are patches for 2.6.9, I would like to try their latest
version for 2.6.16, since they have fixed some bugs in the meantime.

I hope to hear from you soon. Apart from the configuration file
I loaded in the custom kernels, I'm also sending the just-booted
output of dmesg with both the Debian stock kernel 2.6.8-2 and
2.6.9 I compiled myself. You will notice many differences, which is
expected, since I didn't bother to load Debian's settings. But both
logs show a successful boot. I wish I could send you the output of
a superior kernel version failing, but as said, I cannot because
it hangs indefenitely during ext3 mounting.

RE: Linux kernel 2.6.10 sata_nv.c stops working on my hardware

[Allen Martin]

Have you tried the 2.6.9 sata_nv.c on 2.6.10?  All you should have to do
to get
it working is change the host_set->pdev references to use to_pci_dev().

The only functional change in sata_nv that should make any difference is
the 
following:  

 static struct ata_port_info nv_port_info = {
        .sht            = &nv_sht,
        .host_flags     = ATA_FLAG_SATA |
-                         ATA_FLAG_SATA_RESET |
+                         /* ATA_FLAG_SATA_RESET | */
                          ATA_FLAG_SRST |
                          ATA_FLAG_NO_LEGACY,
        .pio_mask       = NV_PIO_MASK,


You can try changing that back to see if it makes a difference.  I would
also
investigate changes in libata too.

-Allen

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
> Grzegorz Adam Hankiewicz
> Sent: Monday, June 26, 2006 12:23 PM
> To: Linux kernel mailing list
> Subject: Linux kernel 2.6.10 sata_nv.c stops working on my hardware
> 
> Hello.
> 
> On monday, 19 Jun, I sent an email to Andrew Chew at nvidia.com
> regarding an issue I have with the sata_nv.c driver.  Basically,
> it doesn't work for me from 2.6.10 up. I haven't received any kind
> of reply yet. In case he's not available any more, I'm posting this
> here in the hope somebody can suggest me how to solve the problem.
> 
> What follows is my original email sent to Andrew, with small
> changes. Also, as requested on the FAQ, attachments are available
> at http://gradha.sdf-eu.org/sata/ instead of being attached to
> this mail.
> 
> I have subscribed to this mailing list. If you can do so, please
> avoid sending me a copy, answer just to the mailing list. TIA.
> 
> ----
> 
> I've recently had to upgrade my computer and bought an AMD Sempron
> 64bit 3100+ SK754, with motherboard K8 Asrock Upgrade K8NF3. Along
> with this, two Maxtor 300GB hard drives, model 6V300F0.
> 
> I booted with the latest Knoppix 5.0 to set up the partitions
> and found that while I could fdisk /dev/sd?, even changing a few
> parameters would make fdisk hang indefinitely. On the other hand,
> I got a Debian Sarge net installation disk which booted perfectly
> with a 2.6 kernel.  After installing a basic system with it, I
> started to tear the system to pieces to find out what was making
> the hard disks fails.
> 
> After a while I found out that it was the SATA NV driver. The Sarge I
> installed contains a 2.6.8 kernel + Debian patches.  I downloaded all
> kernels from 2.6.8 up to 2.6.17 and created a synthetic configuration
> which was loaded through "make menuconfig" in all of them (attached).
> This configuration just makes SCSI and Nvidia Sata as built in code,
> to make sure the machine can boot from /dev/sda1.
> 
> I started testing the kernels down from 2.6.8 (to weed out any
> additional effects of Debian patches) and soon discovered that
> while I could boot and work with the 2.6.9 kernel, 2.6.10 would
> fail and hang forever during boot up, trying to mount/read the
> main ext3 partition of my hard disk. So basically, 2.6.9 works,
> 2.6.10 doesn't, both with the same configuration loaded.
> 
> The problem: as mentioned above, the Knoppix would be able to see the
> hard disks, but unable to mount them, or format with fdisk. Albeit
> this would happen randomly. Sometimes I would be able to mount
> /dev/sda1, but hang forever on /dev/sdb1. Sometimes the other
> way round. However, everything would work OK if I mounted them
> read-only. So the problem seems to be related to drive write mode.
> 
> Now, starting with my custom kernels the boot sequence stops when
> it wants to mount the main filesystem.  The ext3 fs is detected
> and mounted, but just after a line in the form of "ext3 clean
> blah blah blah", it hangs, and after half a minute or so I get a
> round of these errors (possibly hand transcriptions error follow,
> and only different significant ones were copied:
> 
>  ata1: command 0x35 timeout, stat 0xd0 host stat 0x21
>  ata1: translated ATA stat/err 0xd0/00 to SCSI SK/ACC/ASCQ 0xB/47/00
>  ata1: status=0xd0 { busy }
>  
> or repeated several times
>  
>  ATA: abnormal status 0xD0 on port 0xF87
> 
> To my dismay I have discovered that the motherboard I got basically
> sucks in terms of SATA support, or at least so do angry people on
> forums claim, blaming nvidia for bad drivers and whatnot under
> Windows. I have also found that the hard disks I have *may* have
> a buggy firmware:
> 
>   
> https://maxtor.custhelp.com/cgi-bin/maxtor.cfg/php/enduser/std
> _adp.php?p_faqid=2685&p_created=1136595488&p_sid=sFOM9iai&p_lv
a=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MSZwX3By
b2RzPTAmcF9jYXRzPTAmcF9wdj0mcF9jdj0mcF9zZWFyY2hfdHlwZT1hbnN3ZXJzLnNlYXJj
aF9ubCZwX3>
BhZ2U9MSZwX3NlYXJjaF90ZXh0PStuZm9yY2UzICtzYXRh&p_li=&p_topview=1
> 
> Both hard disks I have are marked as:
> 
>   6V300F0 - VA111630 - V60EA5F6
>   6V300F0 - VA111630 - V60EYSY6
> 
> According to the web page mentioned before, these serials mean I'm
> not affected by this report. That doesn't necessarily mean they are
> ok, but I do hope so, and at least they work with kernels <2.6.9
> flawlessly (I've been using them for a week on a raid0 setup while
> I wait for a correct fix).
> 
> So, from the web information I've gathered, there are four possible
> likely problems:
> 
>   1) Bad cables, recommended to buy new ones on some forums.
>   2) Bad motherboard, upgrade firmware.
>   3) Bad hard disks, replace or upgrade firmware.
>   4) Bad OS drivers.
> 
> I think the usage of the Debian 2.6.8-2-386 kernel for two weeks
> discards the first three, leaving the fourth to deal with.
> 
> I want to know if you agree with this reasoning, and if as writer
> of the sata_nv.c file you could help me diagnose the problem and
> modify the last kernel version to make it work on my system. Please
> suggest me change stuff to discard other kernel interferences,
> or send my patches to try to address the problem.
> 
> My intention is to format the raid0 setup with reiser4. Even though
> there are patches for 2.6.9, I would like to try their latest
> version for 2.6.16, since they have fixed some bugs in the meantime.
> 
> I hope to hear from you soon. Apart from the configuration file
> I loaded in the custom kernels, I'm also sending the just-booted
> output of dmesg with both the Debian stock kernel 2.6.8-2 and
> 2.6.9 I compiled myself. You will notice many differences, which is
> expected, since I didn't bother to load Debian's settings. But both
> logs show a successful boot. I wish I could send you the output of
> a superior kernel version failing, but as said, I cannot because
> it hangs indefenitely during ext3 mounting.
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

Re: Linux kernel 2.6.10 sata_nv.c stops working on my hardware

[Grzegorz Adam Hankiewicz]

On 2006-06-26, Allen Martin <AMartin@nvidia.com> wrote:
> Have you tried the 2.6.9 sata_nv.c on 2.6.10?  All you should have
> to do to get it working is change the host_set->pdev references
> to use to_pci_dev().
> 
> The only functional change in sata_nv that should make any
> difference is the following:
> 
>  static struct ata_port_info nv_port_info = {
>         .sht            = &nv_sht,
>         .host_flags     = ATA_FLAG_SATA |
> -                         ATA_FLAG_SATA_RESET |
> +                         /* ATA_FLAG_SATA_RESET | */
>                           ATA_FLAG_SRST |
>                           ATA_FLAG_NO_LEGACY,
>         .pio_mask       = NV_PIO_MASK,
> 
> 
> You can try changing that back to see if it makes a difference.
> I would also investigate changes in libata too.

Actually the change you proposed works on my system. A 2.6.10 with
the ATA_FLAG_SATA_RESET works.  I did the same to a 2.6.16 kernel
but there it didn't work. I guess something else was introduced
between 2.6.10 and 2.6.16.  I'll start recompiling again everything
from 2.6.10 up to 2.6.16 with that flag turned on to see where it
stops working again.

Re: Linux kernel 2.6.10 sata_nv.c stops working on my hardware

[Grzegorz Adam Hankiewicz]

On 2006-06-27, Grzegorz Adam Hankiewicz <gradha@titanium.sabren.com> wrote:
> On 2006-06-26, Allen Martin <AMartin@nvidia.com> wrote:
> >  static struct ata_port_info nv_port_info = {
> >         .sht            = &nv_sht,
> >         .host_flags     = ATA_FLAG_SATA |
> > -                         ATA_FLAG_SATA_RESET |
> > +                         /* ATA_FLAG_SATA_RESET | */
> >                           ATA_FLAG_SRST |
> >                           ATA_FLAG_NO_LEGACY,
> >         .pio_mask       = NV_PIO_MASK,
> 
> Actually the change you proposed works on my system. A 2.6.10
> with the ATA_FLAG_SATA_RESET works.  I did the same to a 2.6.16
> kernel but there it didn't work. I guess something else was
> introduced between 2.6.10 and 2.6.16.  I'll start recompiling
> again everything from 2.6.10 up to 2.6.16 with that flag turned
> on to see where it stops working again.

I recompiled all kernels from 2.6.11 to 2.6.16 with the
ATA_FLAG_SATA_RESET and was able to boot up to 2.6.12.  2.6.13 would
hang mounting ext3. This is bad news though, a sata_nv.c diff between
2.6.12 and 2.6.13 shows no changes. Which I guess it means there's
nothing wrong with sata_nv.c.

I would understand now that the ATA_FLAG_SATA_RESET introduced in
2.6.10 just highlighted another bug somewhere else which affects
my machine, and I would need to look at other changes between 2.6.9
and 2.6.10. What should I do now?

Another thing I have discovered is that if I boot with a Knoppix
5 (kernel 2.6.17 I believe) and mount the sata drives read only,
there is no problem with them. I can read their whole contents,
really fast, without hiccups. It's at the point of using fdisk on
them or trying to mount them as writeable that the commands hang.

Re: Linux kernel 2.6.10 sata_nv.c stops working on my hardware

[Grzegorz Adam Hankiewicz]

On 2006-06-26, Allen Martin <AMartin@nvidia.com> wrote:
> Have you tried the 2.6.9 sata_nv.c on 2.6.10?  All you should have
> to do to get it working is change the host_set->pdev references
> to use to_pci_dev().
> [...]
> You can try changing that back to see if it makes a difference.
> I would also investigate changes in libata too.

I checked the differences between libata-*c and the following
changes seemed relevant to me. Though I have no idea if they do
anything at all for my setup, and I don't know really what to change.

--- linux-2.6.9/drivers/scsi/libata-core.c      2004-10-18 23:53:06.000000000 +0200
+++ linux-2.6.10/drivers/scsi/libata-core.c     2004-12-24 22:33:48.000000000 +0100
@@ -1945,8 +1950,6 @@ void ata_sg_init_one(struct ata_queued_c
        sg->page = virt_to_page(buf);
        sg->offset = (unsigned long) buf & ~PAGE_MASK;
        sg_dma_len(sg) = buflen;
-
-       WARN_ON(buflen > PAGE_SIZE);
 }
 
 void ata_sg_init(struct ata_queued_cmd *qc, struct scatterlist *sg,
@@ -2167,14 +2170,20 @@ static void ata_pio_sector(struct ata_qu
        struct scatterlist *sg = qc->sg;
        struct ata_port *ap = qc->ap;
        struct page *page;
+       unsigned int offset;
        unsigned char *buf;
 
        if (qc->cursect == (qc->nsect - 1))
                ap->pio_task_state = PIO_ST_LAST;
 
        page = sg[qc->cursg].page;
-       buf = kmap(page) +
-             sg[qc->cursg].offset + (qc->cursg_ofs * ATA_SECT_SIZE);
+       offset = sg[qc->cursg].offset + qc->cursg_ofs * ATA_SECT_SIZE;
+
+       /* get the current page and offset */
+       page = nth_page(page, (offset >> PAGE_SHIFT));
+       offset %= PAGE_SIZE;
+
+       buf = kmap(page) + offset;
 
        qc->cursect++;
        qc->cursg_ofs++;
@@ -2265,19 +2318,30 @@ static void ata_pio_block(struct ata_por
                }
        }
 
-       /* handle BSY=0, DRQ=0 as error */
-       if ((status & ATA_DRQ) == 0) {
-               ap->pio_task_state = PIO_ST_ERR;
-               return;
-       }
-
        qc = ata_qc_from_tag(ap, ap->active_tag);
        assert(qc != NULL);
 
-       if (is_atapi_taskfile(&qc->tf))
-               atapi_pio_sector(qc);
-       else
+       if (is_atapi_taskfile(&qc->tf)) {
+               /* no more data to transfer or unsupported ATAPI command */
+               if ((status & ATA_DRQ) == 0) {
+                       ap->pio_task_state = PIO_ST_IDLE;
+
+                       ata_irq_on(ap);
+
+                       ata_qc_complete(qc, status);
+                       return;
+               }
+
+               atapi_pio_bytes(qc);
+       } else {
+               /* handle BSY=0, DRQ=0 as error */
+               if ((status & ATA_DRQ) == 0) {
+                       ap->pio_task_state = PIO_ST_ERR;
+                       return;
+               }
+
                ata_pio_sector(qc);
+       }
 }
 
 static void ata_pio_error(struct ata_port *ap)
@@ -2356,10 +2473,29 @@ static void ata_pio_task(void *_data)
 static void ata_qc_timeout(struct ata_queued_cmd *qc)
 {
        struct ata_port *ap = qc->ap;
+       struct ata_device *dev = qc->dev;
        u8 host_stat = 0, drv_stat;
 
        DPRINTK("ENTER\n");
 
+       /* FIXME: doesn't this conflict with timeout handling? */
+       if (qc->dev->class == ATA_DEV_ATAPI && qc->scsicmd) {
+               struct scsi_cmnd *cmd = qc->scsicmd;
+
+               if (!scsi_eh_eflags_chk(cmd, SCSI_EH_CANCEL_CMD)) {
+
+                       /* finish completing original command */
+                       __ata_qc_complete(qc);
+
+                       atapi_request_sense(ap, dev, cmd);
+
+                       cmd->result = (CHECK_CONDITION << 1) | (DID_OK << 16);
+                       scsi_finish_command(cmd);
+
+                       goto out;
+               }
+       }
+
        /* hack alert!  We cannot use the supplied completion
         * function from inside the ->eh_strategy_handler() thread.
         * libata is the only user of ->eh_strategy_handler() in
--- linux-2.6.9/drivers/scsi/libata-scsi.c      2004-10-18 23:53:51.000000000 +0200
+++ linux-2.6.10/drivers/scsi/libata-scsi.c     2004-12-24 22:34:32.000000000 +0100
@@ -100,7 +97,7 @@ int ata_scsi_ioctl(struct scsi_device *s
                return 0;
 
        default:
-               rc = -EOPNOTSUPP;
+               rc = -ENOTTY;
                break;
        }
@@ -901,8 +898,8 @@ unsigned int ata_scsiop_inq_80(struct at
        };
        memcpy(rbuf, hdr, sizeof(hdr));
 
-       if (buflen > (ATA_SERNO_LEN + 4))
-               ata_dev_id_string(args->dev, (unsigned char *) &rbuf[4],
+       if (buflen > (ATA_SERNO_LEN + 4 - 1))
+               ata_dev_id_string(args->id, (unsigned char *) &rbuf[4],
                                  ATA_ID_SERNO_OFS, ATA_SERNO_LEN);
 
        return 0;
@@ -930,7 +927,7 @@ unsigned int ata_scsiop_inq_83(struct at
        rbuf[3] = 4 + strlen(inq_83_str);       /* page len */
 
        /* our one and only identification descriptor (vendor-specific) */
-       if (buflen > (strlen(inq_83_str) + 4 + 4)) {
+       if (buflen > (strlen(inq_83_str) + 4 + 4 - 1)) {
                rbuf[4 + 0] = 2;        /* code set: ASCII */
                rbuf[4 + 3] = strlen(inq_83_str);
                memcpy(rbuf + 4 + 4, inq_83_str, strlen(inq_83_str));

Re: Linux kernel 2.6.10 sata_nv.c stops working on my hardware

[Grzegorz Adam Hankiewicz]

On 2006-07-02, Allen Martin <AMartin@nvidia.com> wrote:
> Can you try 2.6.13 with 2.6.12 libata and the sata_nv with
> ATA_FLAG_SATA_RESET?  Probably the thing that changed in 2.6.13
> that made your system unhappy was in libata.

Shouldn't I see the changes between 2.6.9 and 2.6.10 which is
when the ATA_FLAG_SATA_RESET flag was removed, and thus the kernel
stopped working on the system?

> What was the model number of your SATA drive?  SATA_RESET shouldn't
> really be necessary if the drive is well behaving.

Maxtor 300GB sata I, 6V300F0 - VA111630 - V60EA5F6 and 6V300F0 -
VA111630 - V60EYSY6. Is this the info you wanted?