svn commit: r270249 - head/sys/cam/ata

Warner Losh imp at bsdimp.com
Fri Aug 22 05:34:55 UTC 2014


On Aug 21, 2014, at 10:31 PM, Neel Natu <neelnatu at gmail.com> wrote:

> Hi Warner,
> 
> On Wed, Aug 20, 2014 at 3:58 PM, Warner Losh <imp at freebsd.org> wrote:
>> Author: imp
>> Date: Wed Aug 20 22:58:12 2014
>> New Revision: 270249
>> URL: http://svnweb.freebsd.org/changeset/base/270249
>> 
>> Log:
>>  Turns out that IDENTIFY DEVICE and IDENTIFY PACKET DEVICE return data
>>  that's only mostly similar. Specifically word 78 bits are defined for
>>  IDENTIFY DEVICE as
>>        5 Supports Hardware Feature Control
>>  while a IDENTIFY PACKET DEVICE defines them as
>>        5 Asynchronous notification supported
>>  Therefore, only pay attention to bit 5 when we're talking to ATAPI
>>  devices (we don't use the hardware feature control at this time).
>>  Ignore it for ATA devices. Remove kludge that papered over this issue
>>  for Samsung SATA SSDs, since Micron drives also have the bit set and
>>  the error was caused by this bad interpretation of the spec (which is
>>  quite easy to do, since bits aren't normally overlapping like this).
>> 
>> Modified:
>>  head/sys/cam/ata/ata_xpt.c
>> 
>> Modified: head/sys/cam/ata/ata_xpt.c
>> ==============================================================================
>> --- head/sys/cam/ata/ata_xpt.c  Wed Aug 20 22:39:26 2014        (r270248)
>> +++ head/sys/cam/ata/ata_xpt.c  Wed Aug 20 22:58:12 2014        (r270249)
>> @@ -458,12 +458,18 @@ negotiate:
>>                    0, 0x02);
>>                break;
>>        case PROBE_SETAN:
>> -               /* Remember what transport thinks about AEN. */
>> -               if (softc->caps & CTS_SATA_CAPS_H_AN)
>> +               /*
>> +                * Only ATAPI defines this bit to mean AEN, but remember
>> +                * what transport thinks about AEN.
>> +                */
>> +               if ((softc->caps & CTS_SATA_CAPS_H_AN) &&
>> +                   periph->path->device->protocol == PROTO_ATAPI)
>>                        path->device->inq_flags |= SID_AEN;
>>                else
>>                        path->device->inq_flags &= ~SID_AEN;
>>                xpt_async(AC_GETDEV_CHANGED, path, NULL);
>> +               if (periph->path->device->protocol != PROTO_ATAPI)
>> +                       break;
>>                cam_fill_ataio(ataio,
>>                    1,
>>                    probedone,
>> @@ -750,14 +756,6 @@ out:
>>                        goto noerror;
>> 
>>                /*
>> -                * Some Samsung SSDs report supported Asynchronous Notification,
>> -                * but return ABORT on attempt to enable it.
>> -                */
>> -               } else if (softc->action == PROBE_SETAN &&
>> -                   status == CAM_ATA_STATUS_ERROR) {
>> -                       goto noerror;
>> -
>> -               /*
>>                 * SES and SAF-TE SEPs have different IDENTIFY commands,
>>                 * but SATA specification doesn't tell how to identify them.
>>                 * Until better way found, just try another if first fail.
>> 
> 
> This change causes a panic for me on boot. Here is the boot log:
> 
> ahci0: <Intel Patsburg AHCI SATA controller> port
> 0xf050-0xf057,0xf040-0xf043,0xf030-0xf037,0xf020-0xf023,0xf000-0xf01f
> mem 0xfbb21000-0xfbb217ff irq 18 at device 31.2 on pci0
> ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported
> ahcich0: <AHCI channel> at channel 0 on ahci0
> ahcich1: <AHCI channel> at channel 1 on ahci0
> ahcich2: <AHCI channel> at channel 2 on ahci0
> ahcich3: <AHCI channel> at channel 3 on ahci0
> ahcich4: <AHCI channel> at channel 4 on ahci0
> ahcich5: <AHCI channel> at channel 5 on ahci0
> ahciem0: <AHCI enclosure management bridge> on ahci0
> ...
> xpt_action_default: CCB type 0xdeadc0de not supported
> ...
> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
> run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
> run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config
> run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config
> run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
> panic: run_interrupt_driven_config_hooks: waited too long
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff81d92920
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffffff81d929d0
> vpanic() at vpanic+0x189/frame 0xffffffff81d92a50
> kassert_panic() at kassert_panic+0x139/frame 0xffffffff81d92ac0
> boot_run_interrupt_driven_config_hooks() at
> boot_run_interrupt_driven_config_hooks+0x111/frame 0xffffffff81d92b50
> mi_startup()fffff81d92b70
> btext() at btext+0x2c
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at      kdb_enter+0x3e: movq    $0,kdb_why
> db>
> 
> The peripheral in question is a SATA attached CDROM:
> 
> % camcontrol devlist
> <INTEL SSDSC2CW240A3 400i>         at scbus0 target 0 lun 0 (pass0,ada0)
> <ATAPI iHAS524   C LL23>           at scbus2 target 0 lun 0 (cd0,pass1)
> <WDC WD1000CHTZ-04JCPV0 04.06A00>  at scbus3 target 0 lun 0 (pass2,ada1)
> <Corsair Neutron GTX SSD M306>     at scbus4 target 0 lun 0 (pass3,ada2)
> <AHCI SGPIO Enclosure 1.00 0001>   at scbus6 target 0 lun 0 (ses0,pass4)
> 
> pass1 at ahcich2 bus 0 scbus2 target 0 lun 0
> pass1: <ATAPI iHAS524   C LL23> Removable CD-ROM SCSI-0 device
> pass1: Serial Number 3524472 2N8225501140
> pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
> 
> The following patch fixes the panic.
> 
> Index: sys/cam/ata/ata_xpt.c
> ===================================================================
> --- sys/cam/ata/ata_xpt.c       (revision 270249)
> +++ sys/cam/ata/ata_xpt.c       (working copy)
> @@ -468,7 +468,8 @@
>                else
>                        path->device->inq_flags &= ~SID_AEN;
>                xpt_async(AC_GETDEV_CHANGED, path, NULL);
> -               if (periph->path->device->protocol != PROTO_ATAPI)
> +               if (periph->path->device->protocol != PROTO_ATAPI &&
> +                   periph->path->device->protocol != PROTO_SCSI)
>                        break;
>                cam_fill_ataio(ataio,
>                    1,

I think the more proper test is == PROTO_ATA elsewhere, since that’s what
distinguishes the ATA_IDENTIFY from the ATAPI_IDENTIFY.

> However, there seem to be a couple of issues with the original patch:
> 
> 1. The 'periph->path->device->protocol' is not initialized to
> PROTO_ATAPI anywhere in the tree so the not-equal-to test is  a no-op.

We test here to determine which identify command to send:

		if (periph->path->device->protocol == PROTO_ATA)
                        ata_28bit_cmd(ataio, ATA_ATA_IDENTIFY, 0, 0, 0);
                else
                        ata_28bit_cmd(ataio, ATA_ATAPI_IDENTIFY, 0, 0, 0);

and that is working to send the right command.

> 2. It seems not right to break out of switch in 'probestart()' without
> providing a way for 'probedone()' to be called. I believe that this
> stops the state machine from making forward progress and results in
> 'xpt_config()' not completing.

That’s a problem, you’re right. Let me rework.

> If you need more information to debug this some more or test a proper
> fix then I am happy to help.

Please try the one included here. I think it will address things. I’ve tried it on one system, and am trying it on others in parallel to sending this.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ata-xpt-patch
Type: application/octet-stream
Size: 1437 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140821/5f4ef757/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140821/5f4ef757/attachment.sig>


More information about the svn-src-head mailing list