aic94xx: fix smartctl utility problem
PATCH 1/1 aic94xx: fix smartctl utility problem
Fixed the problem that "smartctl -a /dev/some_sata_disk -d ata" does not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
The aic94xx also mark out the DRQ bit from status register which is
treated as AC_ERR_HSM (host state machine violation) error by top layer if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device. So the DRQ bit may not reflect the last state of device when the command finished and it is no meaning for the caller.
diff -urN a/drivers/scsi/aic94xx/aic94xx_task.cb/drivers/scsi/aic94xx/aic94xx_task.c
drivers/scsi/aic94xx/aic94xx_task.c +35 -0
@@ -25,6 +25,7 @@*/ #include <linux/spinlock.h> +#include <linux/ata.h> #include "aic94xx.h" #include "aic94xx_sas.h" #include "aic94xx_hwi.h"
@@ -220,6 +221,7 @@memcpy (&resp->ending_fis[0 ], r+16 ,24 ); ts->buf_valid_size =sizeof (*resp); } + resp->ending_fis[2 ] &= ~ATA_DRQ ; }asd_invalidate_edb (escb, edb_id);
@@ -257,6 +259,11 @@ ts->stat =SAS_PROTO_RESPONSE ;asd_get_response_tasklet (ascb, dl);break ; +case TC_CSMI : + ts->resp =SAS_TASK_COMPLETE ; + ts->stat =SAM_GOOD ; +asd_get_response_tasklet (ascb, dl); +break ;case TF_OPEN_REJECT : ts->resp =SAS_TASK_UNDELIVERED ; ts->stat =SAS_OPEN_REJECT ;
@@ -374,7 +381,32 @@ }/* ---------- ATA ---------- */ +int is_ata_rw_cmd (u8 ata_cmd) +{ +switch (ata_cmd) { +case ATA_CMD_READ : +case ATA_CMD_READ_EXT : +case ATA_CMD_WRITE : +case ATA_CMD_WRITE_EXT : +case ATA_CMD_WRITE_FUA_EXT : +case ATA_CMD_FPDMA_READ : +case ATA_CMD_FPDMA_WRITE : +case ATA_CMD_PIO_READ : +case ATA_CMD_PIO_READ_EXT : +case ATA_CMD_PIO_WRITE : +case ATA_CMD_PIO_WRITE_EXT : +case ATA_CMD_READ_MULTI : +case ATA_CMD_READ_MULTI_EXT : +case ATA_CMD_WRITE_MULTI : +case ATA_CMD_WRITE_MULTI_EXT : +case ATA_CMD_WRITE_MULTI_FUA_EXT : +case ATA_CMD_VERIFY : +case ATA_CMD_VERIFY_EXT : +return 1 ; + } +return 0 ; +}static int asd_build_ata_ascb (struct asd_ascb *ascb,struct sas_task *task,gfp_t gfp_flags) {
@@ -427,6 +459,9 @@ flags |=STP_AFFIL_POLICY ; scb->ata_task.flags = flags; } +if (!is_ata_rw_cmd (scb->ata_task.fis.command)) + scb->ata_task.ata_flags |=CSMI_TASK ; + ascb->tasklet_complete = asd_task_tasklet_complete;if (likely (!task->ata_task.device_control_reg_update))
Quoted 13 lines · Gilbert Wu
Fixed the problem that "smartctl -a
/dev/some_sata_disk-d ata" does not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
The aic94xx also mark out the DRQ bit from status register which is
treated asAC_ERR_HSM(host state machine violation) error by top layer if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device. So the DRQ bit may not reflect the last state of device when the command finished and it is no meaning for the caller.
Quoted 1 line
Signed-off-by Gilbert Wu <[email protected]>
ACK
Quoted 13 lines · Gilbert Wu
Fixed the problem that "smartctl -a
/dev/some_sata_disk-d ata" does not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
The aic94xx also mark out the DRQ bit from status register which is
treated asAC_ERR_HSM(host state machine violation) error by top layer if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device. So the DRQ bit may not reflect the last state of device when the command finished and it is no meaning for the caller.
Quoted 1 line
Signed-off-by Gilbert Wu <[email protected]>
I'm afraid this can't go in. It has a bad effect on my expander remote ATAPI device:
aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loaded
modprobe used greatest stack depth: 5312 bytes left
ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 17 (level, low) -> IRQ 17
aic94xx: found Adaptec AIC-9410W SAS/SATA Host Adapter, device 0000:03:03.0
scsi2 : aic94xx
OCM is not initialized by BIOS,reinitialize it and ignore it, current IntrptStatusis 0x0
aic94xx: couldn't find BIOS_CHIM dir ent
aic94xx: couldn't read ocm(-2)
aic94xx: manuf sect SAS_ADDR 50000d100001cae0
aic94xx: manuf sect PCBA SN
aic94xx: ms: num_phy_desc: 8
aic94xx: ms: phy0: ENABLED
aic94xx: ms: phy1: ENABLED
aic94xx: ms: phy2: ENABLED
aic94xx: ms: phy3: ENABLED
aic94xx: ms: phy4: ENABLED
aic94xx: ms: phy5: ENABLED
aic94xx: ms: phy6: ENABLED
aic94xx: ms: phy7: ENABLED
aic94xx: ms: max_phys:0x8, num_phys:0x8
aic94xx: ms: enabled_phys:0xff
aic94xx: ctrla: phy0: sas_addr: 50000d100001cae0, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0
aic94xx: ctrla: phy1: sas_addr: 50000d100001cae0, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0
aic94xx: ctrla: phy2: sas_addr: 50000d100001cae0, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0
aic94xx: ctrla: phy3: sas_addr: 50000d100001cae0, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0
aic94xx: ctrla: phy4: sas_addr: 50000d100001cae0, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0
aic94xx: ctrla: phy5: sas_addr: 50000d100001cae0, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0
aic94xx: ctrla: phy6: sas_addr: 50000d100001cae0, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0
aic94xx: ctrla: phy7: sas_addr: 50000d100001cae0, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0
aic94xx: max_scbs:512, max_ddbs:128
aic94xx: setting phy0 addr to 50000d100001cae0
aic94xx: setting phy1 addr to 50000d100001cae0
aic94xx: setting phy2 addr to 50000d100001cae0
aic94xx: setting phy3 addr to 50000d100001cae0
aic94xx: setting phy4 addr to 50000d100001cae0
aic94xx: setting phy5 addr to 50000d100001cae0
aic94xx: setting phy6 addr to 50000d100001cae0
aic94xx: setting phy7 addr to 50000d100001cae0
aic94xx: num_edbs:21
aic94xx: num_escbs:3
aic94xx: Found sequencer Firmware version 1.1 (V30)
aic94xx: downloading CSEQ...
aic94xx: dma-ing 8192 bytes
aic94xx: verified 8192 bytes, passed
aic94xx: downloading LSEQs...
aic94xx: dma-ing 14336 bytes
aic94xx: LSEQ0 verified 14336 bytes, passed
aic94xx: LSEQ1 verified 14336 bytes, passed
aic94xx: LSEQ2 verified 14336 bytes, passed
aic94xx: LSEQ3 verified 14336 bytes, passed
aic94xx: LSEQ4 verified 14336 bytes, passed
aic94xx: LSEQ5 verified 14336 bytes, passed
aic94xx: LSEQ6 verified 14336 bytes, passed
aic94xx: LSEQ7 verified 14336 bytes, passed
aic94xx: max_scbs:446
aic94xx: first_scb_site_no:0x20
aic94xx: last_scb_site_no:0x1fe
aic94xx: First SCB dma_handle: 0x37682000
aic94xx: device 0000:03:03.0: SAS addr 50000d100001cae0, PCBA SN , 8 phys, 8 enabled phys, flash present, BIOS not present0
aic94xx: posting 3 escbs
aic94xx: escbs posted
aic94xx: posting 8 control phy scbs
aic94xx: control_phy_tasklet_complete: phy5, lrate:0x8, proto:0xe
aic94xx: control_phy_tasklet_complete: phy2, lrate:0x9, proto:0xe
aic94xx: control_phy_tasklet_complete: phy3, lrate:0x9, proto:0xe
aic94xx: escb_tasklet_complete: phy2: BYTES_DMAED
aic94xx: SAS proto IDENTIFY:
aic94xx: 00: 20 00 00 02
aic94xx: 04: 00 00 00 00
aic94xx: 08: 00 00 00 00
aic94xx: 0c: 50 06 05 b0
aic94xx: 10: 00 00 14 50
aic94xx: 14: 01 00 00 00
aic94xx: 18: 00 00 00 00
aic94xx: asd_form_port: updating phy_mask 0x4 for phy2
aic94xx: escb_tasklet_complete: phy3: BYTES_DMAED
aic94xx: SAS proto IDENTIFY:
aic94xx: 00: 20 00 00 02
aic94xx: 04: 00 00 00 00
aic94xx: 08: 00 00 00 00
aic94xx: 0c: 50 06 05 b0
aic94xx: 10: 00 00 14 50
aic94xx: 14: 00 00 00 00
aic94xx: 18: 00 00 00 00
aic94xx: asd_form_port: updating phy_mask 0xc for phy3
aic94xx: control_phy_tasklet_complete: phy0: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy1: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy4: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy6: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy7: no device present: oob_status:0x0
sas: phy2 added to port0, phy_mask:0x4
sas: phy3 matched wide port0
sas: phy3 added to port0, phy_mask:0xc
sas: DOING DISCOVERY on port 0, pid:2047
sas: ex 500605b000001450 phy00:S attached: 50000d100001cae0
sas: ex 500605b000001450 phy01:S attached: 50000d100001cae0
sas: ex 500605b000001450 phy02:S attached: 0000000000000000
sas: ex 500605b000001450 phy03:S attached: 0000000000000000
sas: ex 500605b000001450 phy04:T attached: 0000000000000000
sas: ex 500605b000001450 phy05:T attached: 500605b000001455
sas: ex 500605b000001450 phy06:T attached: 0000000000000000
sas: ex 500605b000001450 phy07:T attached: 0000000000000000
sas: ex 500605b000001450 phy08:T attached: 500605b000001110
sas: ex 500605b000001450 phy09:T attached: 500605b000001110
sas: ex 500605b000001450 phy10:T attached: 0000000000000000
sas: ex 500605b000001450 phy11:T attached: 0000000000000000
sas: sas_ata_phy_reset: Found ATAPI device.
ata1.00: ATAPI: PLEXTOR DVDR PX-755A, 1.03, max UDMA/66
ata1.00: configured for UDMA/66
scsi 2:0:0:0: CD-ROM PLEXTOR DVDR PX-755A 1.03 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 2:0:0:0: Attached scsi generic sg1 type 5
sas: ex 500605b000001110 phy00:S attached: 500605b000001450
sas: ex 500605b000001110 phy01:S attached: 500605b000001450
sas: ex 500605b000001110 phy02:S attached: 0000000000000000
sas: ex 500605b000001110 phy03:S attached: 0000000000000000
sas: ex 500605b000001110 phy04:T attached: 0000000000000000
sas: ex 500605b000001110 phy05:T attached: 0000000000000000
sas: ex 500605b000001110 phy06:T attached: 0000000000000000
sas: ex 500605b000001110 phy07:T attached: 0000000000000000
sas: ex 500605b000001110 phy08:T attached: 5000c50000202511
sas: ex 500605b000001110 phy09:T attached: 0000000000000000
sas: ex 500605b000001110 phy10:T attached: 0000000000000000
sas: ex 500605b000001110 phy11:T attached: 0000000000000000
scsi 2:0:1:0: Direct-Access IBM-ESXS ST973401SS B519 PQ: 0 ANSI: 5
sd 2:0:1:0: [sdb] 143374000 512-byte hardware sectors (73407 MB)
sd 2:0:1:0: [sdb] Write Protect is off
sd 2:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 2:0:1:0: [sdb] 143374000 512-byte hardware sectors (73407 MB)
sd 2:0:1:0: [sdb] Write Protect is off
sd 2:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
sdb: sdb1
sd 2:0:1:0: [sdb] Attached SCSI disk
sd 2:0:1:0: Attached scsi generic sg2 type 0
sas: DONE DISCOVERY on port 0, pid:2047, result:0
sas: command 0xde7c4648, task 0xf77cf6e0, timed out: EH_NOT_HANDLED
sas: Enter sas_scsi_recover_host
sas: trying to find task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: task 0xf77cf6e0 is not at LU: I_T recover
sas: I_T nexus reset for dev 500605b000001455
sas: clearing nexus for port:0
aic94xx: asd_clear_nexus_port: PRE
aic94xx: asd_clear_nexus_port: POST
aic94xx: asd_clear_nexus_port: clear nexus posted, waiting...
aic94xx: asd_clear_nexus_tasklet_complete: here
aic94xx: asd_clear_nexus_tasklet_complete: opcode: 0x0
sas: clear nexus port:0 succeeded
sas: --- Exit sas_scsi_recover_host
sas: command 0xde7c4648, task 0xf77cf6e0, timed out: EH_NOT_HANDLED
sas: Enter sas_scsi_recover_host
sas: trying to find task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: task 0xf77cf6e0 aborted, res: 0x4
sas: sas_scsi_find_task: querying task 0xf77cf6e0
sas: task 0xf77cf6e0 is not at LU: I_T recover
sas: I_T nexus reset for dev 500605b000001455
sas: clearing nexus for port:0
aic94xx: asd_clear_nexus_port: PRE
aic94xx: asd_clear_nexus_port: POST
aic94xx: asd_clear_nexus_port: clear nexus posted, waiting...
aic94xx: asd_clear_nexus_tasklet_complete: here
aic94xx: asd_clear_nexus_tasklet_complete: opcode: 0x0
sas: clear nexus port:0 succeeded
sas: --- Exit sas_scsi_recover_host
sas: command 0xde7c4648, task 0xf77cf6e0, timed out: EH_NOT_HANDLED
sas: Enter sas_scsi_recover_host
sas: trying to find task 0xf77cf6e0
sas: sas_scsi_find_task: aborting task 0xf77cf6e0
aic94xx: task 0xf77cf6e0 done with opcode 0x1e resp 0x0 stat 0x8d but aborted by upper layer!
aic94xx: tmf tasklet complete
aic94xx: tmf came back
aic94xx: asd_abort_task: task 0xf77cf6e0 done
aic94xx: task 0xf77cf6e0 aborted, res: 0x0
sas: sas_scsi_find_task: task 0xf77cf6e0 is done
sas: sas_eh_handle_sas_errors: task 0xf77cf6e0 is done
sas: sas_ata_task_done: SAS error 8d
sas: --- Exit sas_scsi_recover_host
And then the system hangs
James
Quoted 14 lines · James Bottomley
Quoted 13 lines · Gilbert Wu
Fixed the problem that "smartctl -a
/dev/some_sata_disk-d ata" does not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
The aic94xx also mark out the DRQ bit from status register which is
treated asAC_ERR_HSM(host state machine violation) error by top layer if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device. So the DRQ bit may not reflect the last state of device when the command finished and it is no meaning for the caller.
Quoted 4 lines
Quoted 1 line
Signed-off-by Gilbert Wu <[email protected]>I'm afraid this can't go in. It has a bad effect on my expander remote ATAPI device:
OK, found the root cause: your CSMI_TASK flag is getting set on all packet commands. I can think of two fixes: either smartctl should never be used on ATAPI devices (reasonable, since smart is a disc protocol), so we predicate the check by a test for the device being ATA:
if (dev->sata_dev.command_set == ATA_COMMAND_SET && !is_ata_rw_cmd(scb->ata_task.fis.command))
Or simply add ATA_CMD_PACKET to your is_ata_rw_cmd() switch.
Either works on my system ... which do you prefer.
James
Quoted 24 lines · James Bottomley
Quoted 14 lines · James Bottomley
Quoted 13 lines · Gilbert Wu
Fixed the problem that "smartctl -a
/dev/some_sata_disk-d ata" does not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
The aic94xx also mark out the DRQ bit from status register which is
treated asAC_ERR_HSM(host state machine violation) error by top layer if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device. So the DRQ bit may not reflect the last state of device when the command finished and it is no meaning for the caller.Quoted 3 lines
Quoted 1 line
Signed-off-by Gilbert Wu <[email protected]>I'm afraid this can't go in. It has a bad effect on my expander remote ATAPI device:
OK, found the root cause: your
CSMI_TASKflag is getting set on all packet commands. I can think of two fixes: either smartctl should never be used on ATAPI devices (reasonable, since smart is a disc protocol), so we predicate the check by a test for the device being ATA:
Quoted 4 lines
if (dev->sata_dev.command_set == ATA_COMMAND_SET && !is_ata_rw_cmd(scb->ata_task.fis.command))Or simply add
ATA_CMD_PACKETto youris_ata_rw_cmd()switch.
Agreed. I missed that in my review.
Jeff
Quoted 15 lines · James Bottomley
Quoted 14 lines · James Bottomley
Quoted 13 lines · Gilbert Wu
Fixed the problem that "smartctl -a
/dev/some_sata_disk-d ata" does not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
The aic94xx also mark out the DRQ bit from status register which is
treated asAC_ERR_HSM(host state machine violation) error by top layer if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device. So the DRQ bit may not reflect the last state of device when the command finished and it is no meaning for the caller.
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Gilbert Wu <[email protected]>I'm afraid this can't go in. It has a bad effect on my expander remote ATAPI device:
OK, found the root cause: your
CSMI_TASKflag is getting set on all packet commands. I can think of two fixes: either smartctl should never be used on ATAPI devices (reasonable, since smart is a disc protocol),
Feature code 101h in MMC seems to sink your argument for cd/dvd drives.
Also tape drives may support SMART and if they do, smartmontools can access the associated data. And tape drives may be on an ATAPI transport.
Doug Gilbert
Quoted 8 lines
so we predicate the check by a test for the device being ATA:
if (dev->sata_dev.command_set == ATA_COMMAND_SET && !is_ata_rw_cmd(scb->ata_task.fis.command))Or simply add
ATA_CMD_PACKETto youris_ata_rw_cmd()switch.Either works on my system ... which do you prefer.
Quoted 20 lines · Douglas Gilbert
Quoted 19 lines · James Bottomley
Quoted 17 lines · James Bottomley
Quoted 13 lines · Gilbert Wu
Fixed the problem that "smartctl -a
/dev/some_sata_disk-d ata" does not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
The aic94xx also mark out the DRQ bit from status register which is
treated asAC_ERR_HSM(host state machine violation) error by top layer if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device. So the DRQ bit may not reflect the last state of device when the command finished and it is no meaning for the caller.Quoted 1 line
Signed-off-by Gilbert Wu <[email protected]>I'm afraid this can't go in. It has a bad effect on my expander remote ATAPI device:
Quoted 6 lines
Quoted 3 lines
OK, found the root cause: your
CSMI_TASKflag is getting set on all packet commands. I can think of two fixes: either smartctl should never be used on ATAPI devices (reasonable, since smart is a disc protocol),Feature code 101h in MMC seems to sink your argument for cd/dvd drives.
I was more thinking that smartctl is a pure ATA type thing (The problem which the flag is set for is to allow smartctl to muck with ATA commands)... the MMC devices supporting smart features report this via the informational exceptions mode page to conform to the MMC command set. So, when smartctl does SCSI transports, they'll go via a packet command anyway.
Quoted 3 lines
Also tape drives may support SMART and if they do, smartmontools can access the associated data. And tape drives may be on an ATAPI transport.
That's probably via the same mechanism, isn't it?
James
Hi All,
I tested the SATA DVD Plextor model 716SA and 755SA with direct
attached. Both failed in my tested system and it end up with System Panic even without my patch. The CSMI_TASK should not make any difference between ATA and ATAPI device. I am digging into it for root cause.
Thanks!
Gilbert
-----Original Message-----
From: James Bottomley [mailto:[email protected]]
Sent: Sunday, September 16, 2007 4:21 PM
To: [email protected]
Cc: Wu, Gilbert; [email protected]
Subject: Re: [PATCH] aic94xx: fix smartctl utility problem
Quoted 4 lines · Douglas Gilbert
Quoted 3 lines · James Bottomley
Quoted 2 lines · James Bottomley
Quoted 1 line · Gilbert Wu
Fixed the problem that "smartctl -a
/dev/some_sata_disk-d ata"
does
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
The aic94xx need to return ATA output register for all ATA
commands
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
except ATA Read/Write commands.
The aic94xx also mark out the DRQ bit from status register which
is
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
treated as
AC_ERR_HSM(host state machine violation) error by top
layer
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data
transfer
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
and return ATA output register which is sent by the device. So
the DRQ
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
bit may not reflect the last state of device when the command
finished
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
and it is no meaning for the caller.
Signed-off-by Gilbert Wu <[email protected]>I'm afraid this can't go in. It has a bad effect on my expander
remote
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
ATAPI device:
OK, found the root cause: your
CSMI_TASKflag is getting set on all packet commands. I can think of two fixes: either smartctl should
never
Quoted 1 line
Quoted 1 line
be used on ATAPI devices (reasonable, since smart is a disc
protocol),
Quoted 3 lines
Feature code 101h in MMC seems to sink your argument for cd/dvd drives.
I was more thinking that smartctl is a pure ATA type thing (The problem which the flag is set for is to allow smartctl to muck with ATA commands)... the MMC devices supporting smart features report this via the informational exceptions mode page to conform to the MMC command set. So, when smartctl does SCSI transports, they'll go via a packet command anyway.
Quoted 3 lines
Also tape drives may support SMART and if they do, smartmontools can access the associated data. And tape drives may be on an ATAPI transport.
That's probably via the same mechanism, isn't it?
James
Quoted 3 lines · Gilbert
I tested the SATA DVD Plextor model 716SA and 755SA with direct
attached. Both failed in my tested system and it end up with System Panic even without my patch.
Actually, because of the difficulty of wiring it up, I've not tried directly attached SATAPI devices, only expander remote ones (which do work). I did manage to cheat and force one into a drive bay using a mini inifiniband connector, and it seems to work just fine as well. This is the boot log with it directly connected to phy6:
aic94xx: posting 8 control phy scbs
aic94xx: control_phy_tasklet_complete: phy6, lrate:0x8, proto:0xe
aic94xx: control_phy_tasklet_complete: phy0: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy1: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy2: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy3: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy4: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy5: no device present: oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy7: no device present: oob_status:0x0
aic94xx: escb_tasklet_complete: phy6: BYTES_DMAED
aic94xx: STP proto device-to-host FIS:
aic94xx: 00: 34 00 10 01
aic94xx: 04: 01 14 eb 00
aic94xx: 08: 00 00 00 00
aic94xx: 0c: 01 00 00 00
aic94xx: 10: 00 00 00 00
aic94xx: asd_form_port: updating phy_mask 0x40 for phy6
sas: phy6 added to port0, phy_mask:0x40
sas: DOING DISCOVERY on port 0, pid:3197
sas: sas_ata_phy_reset: Found ATAPI device.
ata1.00: ATAPI: PLEXTOR DVDR PX-755A, 1.03, max UDMA/66
ata1.00: configured for UDMA/66
scsi 3:0:0:0: CD-ROM PLEXTOR DVDR PX-755A 1.03 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
sr 3:0:0:0: Attached scsi generic sg1 type 5
sas: DONE DISCOVERY on port 0, pid:3197, result:0
Quoted 3 lines
The
CSMI_TASKshould not make any
difference between ATA and ATAPI device. I am digging into it for root cause.
It does if it's set on a command that's not generated by the smartctl utility ... which is what happens for the ATA PACKET COMMAND case.
James
Hi James,
The ATA PACKET COMMAND should return with good status and ATA output
register if the CSMI_TASK is set. But you debug message shown the ATA PACKET COMMAND got command timeout. Not sure the firmware fails to deliver ATA PACKET command or output ATA register. Only the SAS trace can help solving the puzzle.
Below is my debug message and shows the Plextor PX755A response error to ATA PACKET command. The SAS trace also show the same thing. I will try the other machine to see any difference.
sas: phy6 added to port0, phy_mask:0x40
sas: DOING DISCOVERY on port 0, pid:3876
ata command=a1
ata_task_return code=0
sas: sas_ata_phy_reset: Found ATAPI device.
ata command=a1
ata_task_return code=0
ata1.00: ATAPI: PLEXTOR DVDR PX-755A, 1.02, max UDMA/66
ata1.00: applying bridge limits
ata command=ef
ata_task_return code=0
ata command=a1
ata_task_return code=0
ata1.00: configured for UDMA/66
ata command=a0
ata_task_return code=0
ata command=a0
ata_task_return code=0 ====> ****** cmd success then the no ATA
output register return.
scsi 2:0:0:0: CD-ROM PLEXTOR DVDR PX-755A 1.02 PQ: 0
ANSI: 5
scsi 2:0:0:0: Attached scsi generic sg2 type 5
ata command=a0
ata_task_return code=c ======> ***** cmd failed then return ATA output
register
return reg= 34 40 51 54 0 0 0 a0 0
ata command=a0
ata_task_return code=1
sas: sas_ata_phy_reset: Found ATAPI device.
ata command=a0
ata_task_return code=c
return reg= 34 40 51 24 0 0 20 a0 0
ata command=a0
ata_task_return code=1
ata command=a0
ata_task_return code=c
return reg= 34 40 51 24 0 0 20 a0 0
ata command=a0
ata_task_return code=1
ata command=a0
ata_task_return code=c
return reg= 34 40 51 24 0 0 20 a0 0
ata command=a0
ata_task_return code=1
ata command=a0
ata_task_return code=c
return reg= 34 40 51 24 0 0 20 a0 0
ata command=a0
ata_task_return code=1
ata command=a0
------------[ cut here ]------------ kernel BUG at drivers/ata/libata-core.c:1380! invalid opcode: 0000 [#1] SMP Modules linked in: sr_mod cdrom aic94xx libsas scsi_transport_sas ipv6
snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device af_packet button battery ac loop dm_mod snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer e100 snd soundcore mii snd_page_alloc parport_pc lp parport reiserfs edd fan thermal processor sg sd_mod aic79xx scsi_transport_spi piix ide_disk ide_core
CPU: 0 EIP: 0060:[<c0248aa6>] Not tainted VLI EFLAGS: 00010086 (2.6.23-rc5-smp #3)
EIP is at ata_exec_internal_sg+0x7e/0x384
eax: ffffffff ebx: 00000002 ecx: 00000000 edx: 00000292
esi: 00000000 edi: c605fcc4 ebp: c54a4000 esp: c605fc4c
ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
Process scsi_wq_2 (pid: 3876, ti=c605e000 task=ce29b770 task.ti=c605e000)
Stack: ce29b770 ce29b8d0 c1207e00 00000000 c605fd30 c54a4184 a1000282
c012c06c
c605fca0 ffffffff 00000000 00000292 c012c0cc 00000282 c605fca0
00000000
00000001 c605fc90 c605fc90 000001a8 00000000 c605fcc4 c605fd30
c0248e51
Call Trace:
[<c012c06c>] lock_timer_base+0x19/0x35
[<c012c0cc>] try_to_del_timer_sync+0x44/0x4a
[<c0248e51>] ata_exec_internal+0xa5/0xad
[<c01d31bd>] __delay+0x6/0x7
[<c0248f52>] ata_dev_read_id+0xf9/0x3fb
[<c01d2ddb>] vsnprintf+0x43f/0x47b
[<c012526a>] printk+0x1b/0x1f
[<c024aa5e>] ata_bus_probe+0xeb/0x237
[<c0241c21>] scsi_alloc_sdev+0x12d/0x16e
[<c023bd46>] scsi_device_lookup_by_target+0x60/0x68
[<c0241e81>] scsi_probe_and_add_lun+0xf5/0x94b
[<c01c5d01>] __freed_request+0x23/0x74
[<c01c5d6f>] freed_request+0x1d/0x37
[<c01c6003>] blk_put_request+0x22/0x36
[<c0240d96>] scsi_execute+0xd5/0xde
[<c0240e1c>] scsi_execute_req+0x7d/0xd5
[<c02430e8>] __scsi_scan_target+0x5ac/0x5d7
[<d0ff5f75>] sas_non_host_smp_request+0x0/0x38 [scsi_transport_sas]
[<c01cd2e2>] cfq_init_queue+0x5b/0xe3
[<c01c38b6>] elevator_init_queue+0x5/0x6
[<c01c3ebd>] elevator_init+0xa2/0xd6
[<c0243665>] scsi_scan_target+0x8c/0xa6
[<d0ff5a88>] sas_rphy_add+0x112/0x11e [scsi_transport_sas]
[<d100069d>] sas_discover_domain+0x3d1/0x474 [libsas]
[<c0131e3c>] __queue_work+0x1c/0x28
[<d10002cc>] sas_discover_domain+0x0/0x474 [libsas]
[<c01319b5>] run_workqueue+0x77/0xf8
[<c0134a0c>] prepare_to_wait+0x12/0x49
[<c01321c8>] worker_thread+0x0/0xd8
[<c0132296>] worker_thread+0xce/0xd8
[<c01348f9>] autoremove_wake_function+0x0/0x35
[<c0134832>] kthread+0x38/0x5e
[<c01347fa>] kthread+0x0/0x5e
[<c0106017>] kernel_thread_helper+0x7/0x10
=======================
Code: 00 8b 54 24 2c e8 a0 be 08 00 e9 18 03 00 00 8b 45 04 83 78 5c 0119 c9 f7 d1 83 e1 1f 90 0f ab 8d ac 1f 00 00 19 c0 85 c0 74 04 <0f> 0b eb fe 83 f9 1f c7 44 24 1c 00 00 00 00 77 11 69 c1 ac 00
EIP: [<c0248aa6>] ata_exec_internal_sg+0x7e/0x384 SS:ESP 0068:c605fc4c
ata_task_return code=c
return reg= 34 40 51 24 0 0 20 a0 0
Thanks!
Gilbert
-----Original Message-----
From: James Bottomley [mailto:[email protected]]
Sent: Monday, September 17, 2007 3:59 PM
To: Wu, Gilbert
Cc: [email protected]; [email protected]
Subject: RE: [PATCH] aic94xx: fix smartctl utility problem
Quoted 3 lines · Gilbert
I tested the SATA DVD Plextor model 716SA and 755SA with direct
attached. Both failed in my tested system and it end up with System Panic even without my patch.
Actually, because of the difficulty of wiring it up, I've not tried directly attached SATAPI devices, only expander remote ones (which do work). I did manage to cheat and force one into a drive bay using a mini inifiniband connector, and it seems to work just fine as well. This is the boot log with it directly connected to phy6:
aic94xx: posting 8 control phy scbs
aic94xx: control_phy_tasklet_complete: phy6, lrate:0x8, proto:0xe
aic94xx: control_phy_tasklet_complete: phy0: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy1: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy2: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy3: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy4: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy5: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy7: no device present:
oob_status:0x0
aic94xx: escb_tasklet_complete: phy6: BYTES_DMAED
aic94xx: STP proto device-to-host FIS:
aic94xx: 00: 34 00 10 01
aic94xx: 04: 01 14 eb 00
aic94xx: 08: 00 00 00 00
aic94xx: 0c: 01 00 00 00
aic94xx: 10: 00 00 00 00
aic94xx: asd_form_port: updating phy_mask 0x40 for phy6
sas: phy6 added to port0, phy_mask:0x40
sas: DOING DISCOVERY on port 0, pid:3197
sas: sas_ata_phy_reset: Found ATAPI device.
ata1.00: ATAPI: PLEXTOR DVDR PX-755A, 1.03, max UDMA/66
ata1.00: configured for UDMA/66
scsi 3:0:0:0: CD-ROM PLEXTOR DVDR PX-755A 1.03 PQ: 0
ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray sr 3:0:0:0: Attached scsi generic sg1 type 5
sas: DONE DISCOVERY on port 0, pid:3197, result:0
Quoted 3 lines
The
CSMI_TASKshould not make any
difference between ATA and ATAPI device. I am digging into it for root cause.
It does if it's set on a command that's not generated by the smartctl utility ... which is what happens for the ATA PACKET COMMAND case.
James
Quoted 11 lines · Gilbert
ata_task_returncode=0 ====> ****** cmd success then the no ATA
output register return.
scsi 2:0:0:0: CD-ROM PLEXTOR DVDR PX-755A 1.02 PQ: 0
ANSI: 5
scsi 2:0:0:0: Attached scsi generic sg2 type 5
ata command=a0
ata_task_returncode=c ======> ***** cmd failed then return ATA output
register
return reg= 34 40 51 54 0 0 0 a0 0
ata command=a0
ata_task_returncode=1
That just says a packet command returned an illegal request ... I think the CD layer expects this, but without seeing the SCSI command it's hard to tell.
Quoted 6 lines
sas:
sas_ata_phy_reset: Found ATAPI device.
ata command=a0
ata_task_returncode=c
return reg= 34 40 51 24 0 0 20 a0 0
ata command=a0
ata_task_returncode=1
This again is a packet command returning not ready (probably no media present).
Quoted 7 lines
ata command=a0
ata_task_returncode=c
return reg= 34 40 51 24 0 0 20 a0 0
ata command=a0
ata_task_returncode=1
ata command=a0
ata_task_returncode=c
Quoted 8 lines
return reg= 34 40 51 24 0 0 20 a0 0
ata command=a0
ata_task_returncode=1
ata command=a0
ata_task_returncode=c
return reg= 34 40 51 24 0 0 20 a0 0
ata command=a0
ata_task_returncode=1
These again look like normal CD probes returning not ready.
Quoted 4 lines
ata command=a0
------------[ cut here ]------------ kernel BUG at drivers/ata/libata-core.c:1380!invalid opcode: 0000 [#1]
OK, this is the fascinating one ... I think it's a bug in libata itself. It seems to mean that the tag its trying to use (which is fixed by convention) is already outstanding. Since the current probe sequence is single threaded, I can't really see how this has happened.
James
Hi James,
I can reproduce the problem on my machine. Most likely, the Sequencer
(Firmware) has bug on handling ATA output register for ATAPI device. I am still working on this issue with Sequencer engineer.
Thanks!
Gilbert
-----Original Message-----
From: James Bottomley [mailto:[email protected]]
Sent: Monday, September 17, 2007 3:59 PM
To: Wu, Gilbert
Cc: [email protected]; [email protected]
Subject: RE: [PATCH] aic94xx: fix smartctl utility problem
Quoted 3 lines · Gilbert
I tested the SATA DVD Plextor model 716SA and 755SA with direct
attached. Both failed in my tested system and it end up with System Panic even without my patch.
Actually, because of the difficulty of wiring it up, I've not tried directly attached SATAPI devices, only expander remote ones (which do work). I did manage to cheat and force one into a drive bay using a mini inifiniband connector, and it seems to work just fine as well. This is the boot log with it directly connected to phy6:
aic94xx: posting 8 control phy scbs
aic94xx: control_phy_tasklet_complete: phy6, lrate:0x8, proto:0xe
aic94xx: control_phy_tasklet_complete: phy0: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy1: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy2: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy3: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy4: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy5: no device present:
oob_status:0x0
aic94xx: control_phy_tasklet_complete: phy7: no device present:
oob_status:0x0
aic94xx: escb_tasklet_complete: phy6: BYTES_DMAED
aic94xx: STP proto device-to-host FIS:
aic94xx: 00: 34 00 10 01
aic94xx: 04: 01 14 eb 00
aic94xx: 08: 00 00 00 00
aic94xx: 0c: 01 00 00 00
aic94xx: 10: 00 00 00 00
aic94xx: asd_form_port: updating phy_mask 0x40 for phy6
sas: phy6 added to port0, phy_mask:0x40
sas: DOING DISCOVERY on port 0, pid:3197
sas: sas_ata_phy_reset: Found ATAPI device.
ata1.00: ATAPI: PLEXTOR DVDR PX-755A, 1.03, max UDMA/66
ata1.00: configured for UDMA/66
scsi 3:0:0:0: CD-ROM PLEXTOR DVDR PX-755A 1.03 PQ: 0
ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray sr 3:0:0:0: Attached scsi generic sg1 type 5
sas: DONE DISCOVERY on port 0, pid:3197, result:0
Quoted 3 lines
The
CSMI_TASKshould not make any
difference between ATA and ATAPI device. I am digging into it for root cause.
It does if it's set on a command that's not generated by the smartctl utility ... which is what happens for the ATA PACKET COMMAND case.
James
Quoted 3 lines · Gilbert
I can reproduce the problem on my machine. Most likely, the Sequencer
(Firmware) has bug on handling ATA output register for ATAPI device. I am still working on this issue with Sequencer engineer.
But, since you already vet the commands we can simply work around this by not asking for the ATA output register on packet commands (i.e. just add ATA_CMD_PACKET to the is_ata_rw_command() switch statement.
James
Hi James,
We want to find the root cause and make sure this problem will happen
on STA device certain commands. If it does not affect SATA device then we can adopt the workaround.
Thanks!
Gilbert
-----Original Message-----
From: James Bottomley [mailto:[email protected]]
Sent: Friday, September 21, 2007 1:40 PM
To: Wu, Gilbert
Cc: [email protected]; [email protected]
Subject: RE: [PATCH] aic94xx: fix smartctl utility problem
Quoted 1 line · Gilbert
I can reproduce the problem on my machine. Most likely, the
Sequencer
Quoted 2 lines
(Firmware) has bug on handling ATA output register for ATAPI device. I am still working on this issue with Sequencer engineer.
But, since you already vet the commands we can simply work around this by not asking for the ATA output register on packet commands (i.e. just add ATA_CMD_PACKET to the is_ata_rw_command() switch statement.
James
Quoted 26 lines · James Bottomley
Quoted 16 lines · Douglas Gilbert
Quoted 15 lines · James Bottomley
Quoted 14 lines · James Bottomley
Quoted 13 lines · Gilbert Wu
Fixed the problem that "smartctl -a
/dev/some_sata_disk-d ata" does not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
The aic94xx also mark out the DRQ bit from status register which is
treated asAC_ERR_HSM(host state machine violation) error by top layer if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device. So the DRQ bit may not reflect the last state of device when the command finished and it is no meaning for the caller.Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Gilbert Wu <[email protected]>I'm afraid this can't go in. It has a bad effect on my expander remote ATAPI device:
OK, found the root cause: your
CSMI_TASKflag is getting set on all packet commands. I can think of two fixes: either smartctl should never be used on ATAPI devices (reasonable, since smart is a disc protocol),Feature code 101h in MMC seems to sink your argument for cd/dvd drives.
Quoted 6 lines
I was more thinking that smartctl is a pure ATA type thing (The problem which the flag is set for is to allow smartctl to muck with ATA commands)... the MMC devices supporting smart features report this via the informational exceptions mode page to conform to the MMC command set. So, when smartctl does SCSI transports, they'll go via a packet command anyway.
I'm not sure what you mean by "smartctl is a pure ATA type thing". smartctl is hybrid ATA and SCSI "type of thing" (as is smartd). And I'm the maintainer of the SCSI part.
Life used to be simple in linux: a device name like "/dev/hd*" would be sent ATA commands to fetch SMART information while a device name like "dev/sd*" (or "/dev/*st*") would be sent SCSI commands to fetch SMART information.
Trying to guess the preferred command set of a device based on its device name (or initiator transport) is lame and getting lamer. If SAT was fully implemented, smartctl wouldn't have to worry when it detected an ATA device, as SAT defines the correct translations for the SCSI commands associated with SMART (e.g. self test results log page).
In the real world, SAT "compliance" usually means that the SCSI ATA PASS-THROUGH(16) command is supported. So the approach of smartctl is to start using SCSI commands (i.e. an INQUIRY) and if SAT is detected, switch to ATA commands tunnelled through the SCSI ATA PASS-THROUGH(16).
Note that the SCSI ATA PASS-THROUGH(16) command support may be needed to detect and change the logical unit's transport level characteristics but that is not really a concern of smartmontools.
As for the MMC reference, I was countering your "smart is a disc protocol" observation. smartmontools doesn't need to send ATA commands (if it supported SMART for cd/dvd drives) to cd/dvd drives.
Some other apps (e.g. hdparm) may want to send an ATA SET FEATURES command tunnelled via an SCSI ATA PASS-THROUGH(16) command to a cd/dvd drive connected, for example, to a SAS expander.
Quoted 5 lines
Quoted 3 lines
Also tape drives may support SMART and if they do, smartmontools can access the associated data. And tape drives may be on an ATAPI transport.
That's probably via the same mechanism, isn't it?
Yes, apart from the fact (until recent kernels) that such an ATAPI tape device would appear with a device name like "/dev/hdc". That further confuses the "guess which command set the device would like to use" game.
Doug Gilbert
Quoted 3 lines · --- Gilbert Wu
Fixed the problem that "smartctl -a
/dev/some_sata_disk-d ata" does not work on SATA device. ( The smartctl v5.38 does need "-d ata" option.)
I'm testing my own SATL with "-d sat".
Quoted 2 lines
The aic94xx need to return ATA output register for all ATA commands
except ATA Read/Write commands.
This isn't necessarily true. As an interconnect driver, you shouldn't care. A properly implemented SATL will tell you if/when the ending fis is needed on a per command basis, and then you can set CSMI_TASK.
It is quite possible that SATL may issue the same command wanting the ending fis at one time and not wanting the ending fis at another time.
Quoted 7 lines
The aic94xx also mark out the DRQ bit from status register which is
treated asAC_ERR_HSM(host state machine violation) error by top layer if it set to one.
The firmware of aic94xx chip handle all ATA handshaking, data transfer
and return ATA output register which is sent by the device. So the DRQ bit may not reflect the last state of device when the command finished and it is no meaning for the caller.
Yes, of course, this isn't a bug in aic94xx, but in "libata" which of course is *not* SATL.
Luben
Quoted 85 lines
Signed-off-by Gilbert Wu <[email protected]>diff -urN
a/drivers/scsi/aic94xx/aic94xx_task.cb/drivers/scsi/aic94xx/aic94xx_task.cdrivers/scsi/aic94xx/aic94xx_task.c +35
-1@@ -25,6 +25,7 @@*/ #include <linux/spinlock.h> +#include <linux/ata.h> #include "aic94xx.h" #include "aic94xx_sas.h" #include "aic94xx_hwi.h" @@ -220,6 +221,7 @@memcpy (&resp->ending_fis[0 ], r+16 ,24 ); ts->buf_valid_size =sizeof (*resp); } + resp->ending_fis[2 ] &= ~ATA_DRQ ; }asd_invalidate_edb (escb, edb_id);@@ -257,6 +259,11 @@ ts->stat =SAS_PROTO_RESPONSE ;asd_get_response_tasklet (ascb, dl);break ; +case TC_CSMI : + ts->resp =SAS_TASK_COMPLETE ; + ts->stat =SAM_GOOD ; +asd_get_response_tasklet (ascb, dl); +break ;case TF_OPEN_REJECT : ts->resp =SAS_TASK_UNDELIVERED ; ts->stat =SAS_OPEN_REJECT ;@@ -374,7 +381,32 @@ }/* ---------- ATA ---------- */ +int is_ata_rw_cmd (u8 ata_cmd) +{ +switch (ata_cmd) { +case ATA_CMD_READ : +case ATA_CMD_READ_EXT : +case ATA_CMD_WRITE : +case ATA_CMD_WRITE_EXT : +case ATA_CMD_WRITE_FUA_EXT : +case ATA_CMD_FPDMA_READ : +case ATA_CMD_FPDMA_WRITE : +case ATA_CMD_PIO_READ : +case ATA_CMD_PIO_READ_EXT : +case ATA_CMD_PIO_WRITE : +case ATA_CMD_PIO_WRITE_EXT : +case ATA_CMD_READ_MULTI : +case ATA_CMD_READ_MULTI_EXT : +case ATA_CMD_WRITE_MULTI : +case ATA_CMD_WRITE_MULTI_EXT : +case ATA_CMD_WRITE_MULTI_FUA_EXT : +case ATA_CMD_VERIFY : +case ATA_CMD_VERIFY_EXT : +return 1 ; + } +return 0 ; +}static int asd_build_ata_ascb (struct asd_ascb *ascb,struct sas_task *task,gfp_t gfp_flags) {@@ -427,6 +459,9 @@ flags |=STP_AFFIL_POLICY ; scb->ata_task.flags = flags; } +if (!is_ata_rw_cmd (scb->ata_task.fis.command)) + scb->ata_task.ata_flags |=CSMI_TASK ; + ascb->tasklet_complete = asd_task_tasklet_complete;if (likely (!task->ata_task.device_control_reg_update)) -To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html