Re: mdadm's raid1 will not eliminate abnormal disk after 5 seconds under IO pressure
李春 于2019年1月30日周三 上午7:08写道： > > # Description of problem: > We loaded a disk from two network of storage node via iscsi, merged > into a disk through multipath, and made a raid1 with local disk by > mdadm. > However, when the storage machine of iscsi disk rebooted, raid1 disk > does not automatically eject the abnormal disk when there are some IO > pressure. > > # Version-Release number of selected component (if applicable): > vermagic: 2.6.32-573.el6.x86_64 SMP mod_unload modversions > srcversion: 39AAB97325332236F2FFCA9 > > # How reproducible: > always > > # Steps to Reproduce: > 1. export a disk from storage node > 2. load the disk on another node and merge it with multipath > 3. assemble a local disk and the multipath by madm to a raid1 disk > 4. reboot > > # Actual results: > * multipath disk not eject from raid1 disk under Fio pressure > * multipath disk eject immediately from raid1 disk when stop Fio pressure > > # Expected results: > * multipath disk eject immediately from raid1 disk under Fio pressure > > # Additional info: > We have done the following tests: > * In rhel6.7 with kernel of 2.6.32-573.el6.x86_64 test, mdadm's raid1 > will eliminate the abnormal disk after 5 seconds without IO pressure > * In rhel6.7 with kernel of 2.6.32-573.el6.x86_64 test, in the case of > IO pressure, mdadm's raid1 will not reject the abnormal disk, until > the IO pressure stops, the disk will be removed. > * In rhel7.4 with kernel of 3.10.0-693.el7.x86_64 test, mdadm's raid1 > will eliminate the abnormal disk after 5 seconds without IO pressure > * In rhel7.4 with kernel of 3.10.0-693.el7.x86_64 test, mdadm's raid1 > will eliminate abnormal disk after 5 seconds under IO pressure > > Thanks for your help. Sounds like, you want failfast feature in upstream, not sure if RH backport it into their kernel. Regards, Jack
Re: [PATCH 18/28] pm8001: switch to generic DMA API
Christoph Hellwig 于2018年10月11日周四 下午9:38写道： > > Switch from the legacy PCI DMA API to the generic DMA API. > > Signed-off-by: Christoph Hellwig Reviewed-by: Jack Wang Thanks, Jack
mpt3sas remove device erros
Hi, We have ssd failure sometimes, and mpt3sas remove the devices automatically, and readd again. For example [Tue Jul 31 13:46:58 2018] sd 11:0:4:0: device_block, handle(0x000d) [Tue Jul 31 13:47:00 2018] sd 11:0:4:0: device_unblock and setting to running, handle(0x000d) [Tue Jul 31 13:47:00 2018] [12846]: scst: Detached from scsi11, channel 0, id 4, lun 0, type 0 [Tue Jul 31 13:47:00 2018] sd 11:0:4:0: [sdo] Synchronizing SCSI cache [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1526 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1526 CDB: Write(10) 2a 00 4c 7a 00 70 00 00 20 00 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1434 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1283063920 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#222 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1434 CDB: Read(10) 28 00 58 5e ec e0 00 00 20 00 [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1482643456 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#222 CDB: Write(10) 2a 00 70 1f 0a 70 00 00 40 00 [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1482616032 [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1595 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#2194 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1881082480 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#2374 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#103 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#2193 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1595 CDB: Write(10) 2a 00 4c 7a 00 60 00 00 10 00 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#2194 CDB: Write(10) 2a 00 70 1f ca 20 00 00 20 00 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1523 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#2374 CDB: Read(10) 28 00 55 61 70 90 00 00 08 00 [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#103 CDB: Read(10) 28 00 64 4e f8 d8 00 00 08 00 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#2193 CDB: Write(10) 2a 00 4f 71 ca e0 00 00 30 00 [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1283063904 [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1881131552 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1433 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1432449168 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1433 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1432449168 [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1523 CDB: Write(10) 2a 00 70 20 1c 00 00 00 40 00 [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1932081488 [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1682897112 [Tue Jul 31 13:47:01 2018] blk_update_request: I/O error, dev sdo, sector 1482615952 [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) [Tue Jul 31 13:47:01 2018] sd 11:0:4:0: [sdo] tag#1433 CDB: Write(10) 2a 00 61 36 12 00 00 00 20 00 [Tue Jul 31 13:47:01 2018] mpt3sas_cm1: log_info(0x31110d00): originator(PL), cod
Re: [PATCH, RESEND] Avoid that SCSI device removal through sysfs triggers a deadlock
Bart Van Assche 于2018年7月25日周三 下午7:39写道：
>
> This patch avoids that self-removal triggers the following deadlock:
>
> ==
> WARNING: possible circular locking dependency detected
> 4.18.0-rc2-dbg+ #5 Not tainted
> --
> modprobe/6539 is trying to acquire lock:
> 8323c4cd (kn->count#202){}, at: kernfs_remove_by_name_ns+0x45/0x90
>
> but task is already holding lock:
> a6ec2c69 (&shost->scan_mutex){+.+.}, at: scsi_remove_host+0x21/0x150
> [scsi_mod]
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&shost->scan_mutex){+.+.}:
>__mutex_lock+0xfe/0xc70
>mutex_lock_nested+0x1b/0x20
>scsi_remove_device+0x26/0x40 [scsi_mod]
>sdev_store_delete+0x27/0x30 [scsi_mod]
>dev_attr_store+0x3e/0x50
>sysfs_kf_write+0x87/0xa0
>kernfs_fop_write+0x190/0x230
>__vfs_write+0xd2/0x3b0
>vfs_write+0x101/0x270
>ksys_write+0xab/0x120
>__x64_sys_write+0x43/0x50
>do_syscall_64+0x77/0x230
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> -> #0 (kn->count#202){}:
>lock_acquire+0xd2/0x260
>__kernfs_remove+0x424/0x4a0
>kernfs_remove_by_name_ns+0x45/0x90
>remove_files.isra.1+0x3a/0x90
>sysfs_remove_group+0x5c/0xc0
>sysfs_remove_groups+0x39/0x60
>device_remove_attrs+0x82/0xb0
>device_del+0x251/0x580
>__scsi_remove_device+0x19f/0x1d0 [scsi_mod]
>scsi_forget_host+0x37/0xb0 [scsi_mod]
>scsi_remove_host+0x9b/0x150 [scsi_mod]
>sdebug_driver_remove+0x4b/0x150 [scsi_debug]
>device_release_driver_internal+0x241/0x360
>device_release_driver+0x12/0x20
>bus_remove_device+0x1bc/0x290
>device_del+0x259/0x580
>device_unregister+0x1a/0x70
>sdebug_remove_adapter+0x8b/0xf0 [scsi_debug]
>scsi_debug_exit+0x76/0xe8 [scsi_debug]
>__x64_sys_delete_module+0x1c1/0x280
>do_syscall_64+0x77/0x230
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
>CPU0CPU1
>
> lock(&shost->scan_mutex);
>lock(kn->count#202);
>lock(&shost->scan_mutex);
> lock(kn->count#202);
>
> *** DEADLOCK ***
>
> 2 locks held by modprobe/6539:
> #0: efaf9298 (&dev->mutex){}, at:
> device_release_driver_internal+0x68/0x360
> #1: a6ec2c69 (&shost->scan_mutex){+.+.}, at:
> scsi_remove_host+0x21/0x150 [scsi_mod]
>
> stack backtrace:
> CPU: 10 PID: 6539 Comm: modprobe Not tainted 4.18.0-rc2-dbg+ #5
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> 1.0.0-prebuilt.qemu-project.org 04/01/2014
> Call Trace:
> dump_stack+0xa4/0xf5
> print_circular_bug.isra.34+0x213/0x221
> __lock_acquire+0x1a7e/0x1b50
> lock_acquire+0xd2/0x260
> __kernfs_remove+0x424/0x4a0
> kernfs_remove_by_name_ns+0x45/0x90
> remove_files.isra.1+0x3a/0x90
> sysfs_remove_group+0x5c/0xc0
> sysfs_remove_groups+0x39/0x60
> device_remove_attrs+0x82/0xb0
> device_del+0x251/0x580
> __scsi_remove_device+0x19f/0x1d0 [scsi_mod]
> scsi_forget_host+0x37/0xb0 [scsi_mod]
> scsi_remove_host+0x9b/0x150 [scsi_mod]
> sdebug_driver_remove+0x4b/0x150 [scsi_debug]
> device_release_driver_internal+0x241/0x360
> device_release_driver+0x12/0x20
> bus_remove_device+0x1bc/0x290
> device_del+0x259/0x580
> device_unregister+0x1a/0x70
> sdebug_remove_adapter+0x8b/0xf0 [scsi_debug]
> scsi_debug_exit+0x76/0xe8 [scsi_debug]
> __x64_sys_delete_module+0x1c1/0x280
> do_syscall_64+0x77/0x230
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> See also
> https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg54525.html.
>
> Suggested-by: Eric W. Biederman
> Fixes: ac0ece9174ac ("scsi: use device_remove_file_self() instead of
> device_schedule_callback()")
> Signed-off-by: Bart Van Assche
> Cc: Eric W. Biederman
> Cc: Tejun Heo
> Cc: Hannes Reinecke
> Cc: Johannes Thumshirn
> Cc: Ingo Molnar
> Cc: Oleg Nesterov
> Cc:
Looks good to me!
Reviewed-by: Jack Wang
Re: How to Locate drive directly attached to mpt3sas HBA
2018-03-19 18:44 GMT+01:00 James Bottomley : > On Mon, 2018-03-19 at 17:30 +0100, Jack Wang wrote: >> > >> > >> > > >> > > And I think either mpt2sas and/or mpt3sas HBAs (I don't have my >> > > hardware >> > > nearby) have a SMP target hidden away somewhere. Perhaps someone >> > > from >> > > LSI/Avago/Broadcom could supply more information about that. >> >> Indeed, mpt3sas has internal enclosure some how. >> snip from "sas3ircu 0 display" output: >> Device is a Hard disk >> Enclosure # : 1 >> Slot # : 4 >> SAS Address : 4433221-1-0400- >> State : Ready (RDY) >> >> And it's possible to locate it using "sas3ircu 0 locate 1:4 ON" to >> locate the drive. > > The fat firmware eats pretty much all trace of the enclosure. I think > it could be exposed as a device, but that would disrupt the mpt3sas > internal handling if our Linux enclosure service also binds to it. > > James > Agree, they're doing a lot in FW. Regards, Jack
Re: How to Locate drive directly attached to mpt3sas HBA
> >> And I think either mpt2sas and/or mpt3sas HBAs (I don't have my hardware >> nearby) have a SMP target hidden away somewhere. Perhaps someone from >> LSI/Avago/Broadcom could supply more information about that. Indeed, mpt3sas has internal enclosure some how. snip from "sas3ircu 0 display" output: Device is a Hard disk Enclosure # : 1 Slot # : 4 SAS Address : 4433221-1-0400- State : Ready (RDY) And it's possible to locate it using "sas3ircu 0 locate 1:4 ON" to locate the drive. Thanks, Jack
Re: How to Locate drive directly attached to mpt3sas HBA
2018-03-19 15:20 GMT+01:00 Douglas Gilbert : > On 2018-03-19 11:40 AM, Jack Wang wrote: >> >> Hi list, >> >> Any one knows how can I locate a HDD directly attached to mpt3sas, >> sas3ircu only supports LOCATE commd to locates driver installed in a >> disk enclosure, but not directly attached. >> >> I know microsemi/PMCs supports SGPIO interface to locate drive eg: >> Adp80xxapp sgpio 0 set 0 1 >> >> I searched in latest upstream mpt3sas code, didn't find such >> interface. Do I miss something? > > > Hi, > If its a SAS disk, it might have an onboard LED. > > In the sdparm package there is a script called "sas_disk_blink" > that will flash that LED. > > > And I think either mpt2sas and/or mpt3sas HBAs (I don't have my hardware > nearby) have a SMP target hidden away somewhere. Perhaps someone from > LSI/Avago/Broadcom could supply more information about that. > > Doug Gilbert > Thanks Doug for your information, we're interested mainly on SATA SSD from Intel. I hope Broadcom could shed some light. The HBA is Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02) Regards, Jack
How to Locate drive directly attached to mpt3sas HBA
Hi list, Any one knows how can I locate a HDD directly attached to mpt3sas, sas3ircu only supports LOCATE commd to locates driver installed in a disk enclosure, but not directly attached. I know microsemi/PMCs supports SGPIO interface to locate drive eg: Adp80xxapp sgpio 0 set 0 1 I searched in latest upstream mpt3sas code, didn't find such interface. Do I miss something? Thanks, Jack
Re: [PATCH v2] scsi: libsas: defer ata device eh commands to libata
2018-03-07 8:47 GMT+01:00 Jason Yan :
> When ata device doing EH, some commands still attached with tasks are not
> passed to libata when abort failed or recover failed, so libata did not
> handle these commands. After these commands done, sas task is freed, but
> ata qc is not freed. This will cause ata qc leak and trigger a warning
> like below:
>
> WARNING: CPU: 0 PID: 28512 at drivers/ata/libata-eh.c:4037
> ata_eh_finish+0xb4/0xcc
> CPU: 0 PID: 28512 Comm: kworker/u32:2 Tainted: G W OE 4.14.0#1
> ..
> Call trace:
> [] ata_eh_finish+0xb4/0xcc
> [] ata_do_eh+0xc4/0xd8
> [] ata_std_error_handler+0x44/0x8c
> [] ata_scsi_port_error_handler+0x480/0x694
> [] async_sas_ata_eh+0x4c/0x80
> [] async_run_entry_fn+0x4c/0x170
> [] process_one_work+0x144/0x390
> [] worker_thread+0x144/0x418
> [] kthread+0x10c/0x138
> [] ret_from_fork+0x10/0x18
>
> If ata qc leaked too many, ata tag allocation will fail and io blocked
> for ever.
>
> As suggested by Dan Williams, defer ata device commands to libata and
> merge sas_eh_finish_cmd() with sas_eh_defer_cmd(). libata will handle
> ata qcs correctly after this.
>
> Signed-off-by: Jason Yan
> CC: Xiaofei Tan
> CC: John Garry
> CC: Dan Williams
Hi Jason,
Would be good if you add the Fixes tag, so distribution could pick it up easily.
And wasn't the idea to delete sas_eh_finish_cmd instead of sas_eh_defer_cmd?
Thanks,
Jack
> ---
> drivers/scsi/libsas/sas_scsi_host.c | 30 ++
> 1 file changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/scsi/libsas/sas_scsi_host.c
> b/drivers/scsi/libsas/sas_scsi_host.c
> index 6de9681ace82..fd76436b289c 100644
> --- a/drivers/scsi/libsas/sas_scsi_host.c
> +++ b/drivers/scsi/libsas/sas_scsi_host.c
> @@ -223,6 +223,7 @@ int sas_queuecommand(struct Scsi_Host *host, struct
> scsi_cmnd *cmd)
> static void sas_eh_finish_cmd(struct scsi_cmnd *cmd)
> {
> struct sas_ha_struct *sas_ha = SHOST_TO_SAS_HA(cmd->device->host);
> + struct domain_device *dev = cmd_to_domain_dev(cmd);
> struct sas_task *task = TO_SAS_TASK(cmd);
>
> /* At this point, we only get called following an actual abort
> @@ -231,6 +232,11 @@ static void sas_eh_finish_cmd(struct scsi_cmnd *cmd)
> */
> sas_end_task(cmd, task);
>
> + if (dev_is_sata(dev)) {
> + list_move_tail(&cmd->eh_entry, &sas_ha->eh_ata_q);
> + return;
> + }
> +
> /* now finish the command and move it on to the error
> * handler done list, this also takes it off the
> * error handler pending list.
> @@ -238,22 +244,6 @@ static void sas_eh_finish_cmd(struct scsi_cmnd *cmd)
> scsi_eh_finish_cmd(cmd, &sas_ha->eh_done_q);
> }
>
> -static void sas_eh_defer_cmd(struct scsi_cmnd *cmd)
> -{
> - struct domain_device *dev = cmd_to_domain_dev(cmd);
> - struct sas_ha_struct *ha = dev->port->ha;
> - struct sas_task *task = TO_SAS_TASK(cmd);
> -
> - if (!dev_is_sata(dev)) {
> - sas_eh_finish_cmd(cmd);
> - return;
> - }
> -
> - /* report the timeout to libata */
> - sas_end_task(cmd, task);
> - list_move_tail(&cmd->eh_entry, &ha->eh_ata_q);
> -}
> -
> static void sas_scsi_clear_queue_lu(struct list_head *error_q, struct
> scsi_cmnd *my_cmd)
> {
> struct scsi_cmnd *cmd, *n;
> @@ -261,7 +251,7 @@ static void sas_scsi_clear_queue_lu(struct list_head
> *error_q, struct scsi_cmnd
> list_for_each_entry_safe(cmd, n, error_q, eh_entry) {
> if (cmd->device->sdev_target == my_cmd->device->sdev_target &&
> cmd->device->lun == my_cmd->device->lun)
> - sas_eh_defer_cmd(cmd);
> + sas_eh_finish_cmd(cmd);
> }
> }
>
> @@ -631,12 +621,12 @@ static void sas_eh_handle_sas_errors(struct Scsi_Host
> *shost, struct list_head *
> case TASK_IS_DONE:
> SAS_DPRINTK("%s: task 0x%p is done\n", __func__,
> task);
> - sas_eh_defer_cmd(cmd);
> + sas_eh_finish_cmd(cmd);
> continue;
> case TASK_IS_ABORTED:
> SAS_DPRINTK("%s: task 0x%p is aborted\n",
> __func__, task);
> - sas_eh_defer_cmd(cmd);
> + sas_eh_finish_cmd(cmd);
> continue;
> case TASK_IS_AT_LU:
> SAS_DPRINTK("task 0x%p is at LU: lu recover\n", task);
> @@ -647,7 +637,7 @@ static void sas_eh_handle_sas_errors(struct Scsi_Host
> *shost, struct list_head *
> "recovered\n",
> SAS_ADDR(task->dev),
> cmd->device->lun);
> - sas_eh_defer_cmd(cmd);
> +
Re: [PATCH] scsi: libsas: defer ata device eh commands to libata
2018-02-27 12:50 GMT+01:00 John Garry :
> On 27/02/2018 06:59, Jason Yan wrote:
>>
>> When ata device doing EH, some commands still attached with tasks are not
>> passed to libata when abort failed or recover failed, so libata did not
>> handle these commands. After these commands done, sas task is freed, but
>> ata qc is not freed. This will cause ata qc leak and trigger a warning
>> like below:
>
>
> It's seems like a bug that we're just killing the ATA command in libsas
> error handling and not deferring them to ATA EH also.
>
> And this WARN, below, in ata_eh_finish() is a longterm issue I see (but
> maybe because of other issue also).
>
> As mentioned to Jason privately, I wonder why Dan's patch excluded the
> change here:
> commit 3944f50995f947558c35fb16ae0288354756762c
> Author: Dan Williams
> Date: Tue Nov 29 12:08:50 2011 -0800
>
> [SCSI] libsas: let libata handle command timeouts
>
> libsas-eh if it successfully aborts an ata command will hide the timeout/
> condition (AC_ERR_TIMEOUT) from libata. The command likely completes
> with the all-zero task->task_status it started with. Instead, interpret
> a TMF_RESP_FUNC_COMPLETE as the end of the sas_task but keep the scmd
> around for libata-eh to handle.
>
> Tested-by: Andrzej Jakowski
> Signed-off-by: Dan Williams
> Signed-off-by: James Bottomley
>
>
>>
>> WARNING: CPU: 0 PID: 28512 at drivers/ata/libata-eh.c:4037
>> ata_eh_finish+0xb4/0xcc
>> CPU: 0 PID: 28512 Comm: kworker/u32:2 Tainted: G W OE 4.14.0#1
>> ..
>> Call trace:
>> [] ata_eh_finish+0xb4/0xcc
>> [] ata_do_eh+0xc4/0xd8
>> [] ata_std_error_handler+0x44/0x8c
>> [] ata_scsi_port_error_handler+0x480/0x694
>> [] async_sas_ata_eh+0x4c/0x80
>> [] async_run_entry_fn+0x4c/0x170
>> [] process_one_work+0x144/0x390
>> [] worker_thread+0x144/0x418
>> [] kthread+0x10c/0x138
>> [] ret_from_fork+0x10/0x18
Hi John, hi Jason,
We've seen this warning once on pm80xx with sata SSD in production (on
3.12 kernel), but failed to see the root cause.
In my case, it's a chain sequence, one SSD failed, lead to error
handle & IO stuck.
Do you have reproducer?
Your change looks good to me, but would be good to hear from Dan & James.
Thanks,
Jack
>>
>> If ata qc leaked too many, ata tag allocation will fail and io blocked
>> for ever.
>>
>> It is always safe to defer all commands to libata if it is sata device.
>> The ata_scsi_cmd_error_handler() will flag the timeout command as
>> ATA_QCFLAG_FAILED if it is not set already. The libata EH will handle
>> these
>> qcs correctly.
>>
>> Signed-off-by: Jason Yan
>> CC: Xiaofei Tan
>> CC: John Garry
>
>
> The change looks ok to me.
>
> But we need more review here from domain expert please.
>
>
>> ---
>> drivers/scsi/libsas/sas_scsi_host.c | 14 +++---
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/scsi/libsas/sas_scsi_host.c
>> b/drivers/scsi/libsas/sas_scsi_host.c
>> index 6de9681ace82..fd00e432112b 100644
>> --- a/drivers/scsi/libsas/sas_scsi_host.c
>> +++ b/drivers/scsi/libsas/sas_scsi_host.c
>> @@ -274,7 +274,7 @@ static void sas_scsi_clear_queue_I_T(struct list_head
>> *error_q,
>> struct domain_device *x = cmd_to_domain_dev(cmd);
>>
>> if (x == dev)
>> - sas_eh_finish_cmd(cmd);
>> + sas_eh_defer_cmd(cmd);
>> }
>> }
>>
>> @@ -288,7 +288,7 @@ static void sas_scsi_clear_queue_port(struct list_head
>> *error_q,
>> struct asd_sas_port *x = dev->port;
>>
>> if (x == port)
>> - sas_eh_finish_cmd(cmd);
>> + sas_eh_defer_cmd(cmd);
>> }
>> }
>>
>> @@ -662,7 +662,7 @@ static void sas_eh_handle_sas_errors(struct Scsi_Host
>> *shost, struct list_head *
>> struct domain_device *dev = task->dev;
>> SAS_DPRINTK("I_T %016llx recovered\n",
>>
>> SAS_ADDR(task->dev->sas_addr));
>> - sas_eh_finish_cmd(cmd);
>> + sas_eh_defer_cmd(cmd);
>> sas_scsi_clear_queue_I_T(work_q, dev);
>> goto Again;
>> }
>> @@ -676,7 +676,7 @@ static void sas_eh_handle_sas_errors(struct Scsi_Host
>> *shost, struct list_head *
>> if (res == TMF_RESP_FUNC_COMPLETE) {
>> SAS_DPRINTK("clear nexus port:%d "
>> "succeeded\n",
>> port->id);
>> - sas_eh_finish_cmd(cmd);
>> + sas_eh_defer_cmd(cmd);
>> sas_scsi_clear_queue_port(work_q,
>> port);
>> goto Again;
>> @@ -688,7 +688,7 @@ static void sas_eh_
[PATCH] sd: succeed check_event if device is not removable
From: Jack Wang
The check_events interface was added for check if device changes,
mainly for device is removable eg. CDROM
In sd_open, it checks if device is removable then check_disk_change.
when the device is not removable, we can simple succeeds the call
without send TUR.
Signed-off-by: Jack Wang
---
drivers/scsi/sd.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index ab75ebd..773ce81 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1576,6 +1576,10 @@ static unsigned int sd_check_events(struct gendisk
*disk, unsigned int clearing)
sdp = sdkp->device;
SCSI_LOG_HLQUEUE(3, sd_printk(KERN_INFO, sdkp, "sd_check_events\n"));
+ if (!sdp->removable) {
+ retval = 0;
+ goto out;
+ }
/*
* If the device is offline, don't send any commands - just pretend as
* if the command failed. If the device ever comes back online, we
--
2.7.4
Re: PMC(Adaptec) 7805H(7H series) HBA compatibility problem with many Seagate HDDs
+cc Viswas from micorsemi. maybe he can help. 2018-01-12 12:15 GMT+01:00 : > > Hello, we have a long standing issue for a couple of years with our SAS HBA. > > It happens no matter what distribution we use(Debian, CentOS, Ubuntu). > > When we bought this HBA we had already two 500GB Seagate SAS HDDs, > Constellation ES.2 ST3500620SS. Those were working fine as expected. > In order to back up SATA disks we bought a couple of 4TB Seagate SAS HDDs, > Constellation ES.3 ST4000NM0023. > Unfortunately they did not work with this HBA even though we updated both the > HBA and the HDDs firmware a couple of times back in 2015 :( > Our LSI SAS Gen2 HBA had no issues at all with the same disks... > > A couple of years ago my brother contacted PMC and Seagate but the issue > remains... Since the issue persisted they were moved to the LSI HBA. > > My brother thought it was a compatibility issue with Constellation ES.3 so he > bought 3 newer Seagate disks in December. Those are Enterprise Capacity > v5(ECv5) now called Exos 7E2. > Unfortunately none of them works on this HBA! Again our LSI SAS Gen2 HBA had > no issues at all with the newer disks... > > In order to have a decent disk for the PMC HBA, we bought a couple of 10K > 2,5" Toshiba HDDs which support T1O DIF but have it inactive. Luckily those > disks worked fine! > > The problem is that we have 5(2+3) Seagate 7200 class disks that cannot work > with this controller! > Any newer seagate SAS HDD we tried and had protection information (aka T1O > DIF) cannot be written on this HBA for some reason (even though DIF was never > activated). > Formatting the disk from the HBA did not solve the issue. So dd and mke2fs > are unusable. Both always hang even though the disk and the HBA are in good > condition. > The affected disk was tested on all SAS ports but it failed miserably. > Different cables were also used to ensure that no cabling issues arise. > > The ES.3 disks are unavailable for now as they have data. Any patch will be > only tested with our ECv5. > > Here is what we get at normal boot with dd (input /dev/zero, block 8k in this > case): > > [0.00] Linux version 4.9.0-5-amd64 (debian-ker...@lists.debian.org) > (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.65-3+deb9u2 > (2018-01-04) > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-5-amd64 > root=UUID=5e47893b-3c41-4eef-b6c8-c401681ec19f ro quiet > [0.644856] pci :06:00.0: [9005:8088] type 00 class 0x010700 > [0.644867] pci :06:00.0: reg 0x10: [mem 0xfe25-0xfe25 64bit] > [0.644875] pci :06:00.0: reg 0x18: [mem 0xfe24-0xfe24 64bit] > [0.644884] pci :06:00.0: reg 0x24: [mem 0xfe20-0xfe23] > [0.644890] pci :06:00.0: reg 0x30: [mem 0xfe10-0xfe1f pref] > [0.644933] pci :06:00.0: supports D1 > [0.644934] pci :06:00.0: PME# supported from D0 D1 D3hot > [1.290266] iommu: Adding device :06:00.0 to group 22 > [1.441672] pm80xx :06:00.0: pm80xx: driver version 0.1.38 > [2.302240] scsi host0: pm80xx > [2.802851] sas: phy-0:1 added to port-0:0, phy_mask:0x2 (5000c500) > [2.802858] sas: DOING DISCOVERY on port 0, pid:189 > [2.862822] sas: DONE DISCOVERY on port 0, pid:189, result:0 > [2.877467] scsi 0:0:0:0: Direct-Access SEAGATE ST2000NM0045 N003 > PQ: 0 ANSI: 6 > [3.792502] sd 0:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 > TB/1.82 TiB) > [3.795080] sd 0:0:0:0: [sdb] Write Protect is off > [3.795082] sd 0:0:0:0: [sdb] Mode Sense: db 00 10 08 > [3.796995] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, > supports DPO and FUA > [3.810543] sd 0:0:0:0: [sdb] Attached SCSI disk > [8.164122] sd 0:0:0:0: Attached scsi generic sg2 type 0 > [ 380.487177] sas: Enter sas_scsi_recover_host busy: 151 failed: 151 Looks all IO just can't finished, and was aborted. I suppose PMCS/microsemi have compatible list for their HBA, did you check that? Have you try the driver from their website, does it work? https://storage.microsemi.com/en-us/support/sas/sas/asa-7805h/ [snip] Regards, Jack
Re: [PATCH 0/2] sd: Fix a deadlock between event checking and device removal
2017-11-17 18:01 GMT+01:00 Bart Van Assche :
> On Fri, 2017-11-17 at 16:14 +0100, Jack Wang wrote:
>> I suspect could be missing run queue or lost IO, IMHO it's unlikely
>> below disk probing fix the bug.
>
> If the system is still in this state or if you can reproduce this issue,
> please collect and analyze the information under /sys/kernel/debug/block.
> That's the only way I know of to verify whether or not a lockup has been
> caused by a missing queue run. If the following command resolves the lockup
> then the root cause is definitely a missing queue run:
It's production server, I was too late to gather more information.
kernel is 4.4.36/4.4.50
Request mode for both multipath and scsi, no multiqueue involvement.
I found thread back to 2012, you also report this problem in 3.2..
https://lkml.org/lkml/2012/1/3/163
I might be a very old bug.
I will try harder to reproduce.
Thanks,
Jack
>
> for f in /sys/kernel/debug/block/*; do echo kick >$f/state; done
>
> When analyzing queue lockups it's important to also have information about
> requests that have been queued but that have not yet been started. I'm using
> the following patch locally (will split this patch and submit it properly when
> I have the time):
>
> diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
> index 29e8451931ff..3c9d64793865 100644
> --- a/block/blk-mq-debugfs.c
> +++ b/block/blk-mq-debugfs.c
> @@ -408,8 +408,7 @@ static void hctx_show_busy_rq(struct request *rq, void
> *data, bool reserved)
> {
> const struct show_busy_params *params = data;
>
> - if (blk_mq_map_queue(rq->q, rq->mq_ctx->cpu) == params->hctx &&
> - test_bit(REQ_ATOM_STARTED, &rq->atomic_flags))
> + if (blk_mq_map_queue(rq->q, rq->mq_ctx->cpu) == params->hctx)
> __blk_mq_debugfs_rq_show(params->m,
> list_entry_rq(&rq->queuelist));
> }
> diff --git a/drivers/scsi/scsi_debugfs.c b/drivers/scsi/scsi_debugfs.c
> index 01f08c03f2c1..41d1e3a01786 100644
> --- a/drivers/scsi/scsi_debugfs.c
> +++ b/drivers/scsi/scsi_debugfs.c
> @@ -7,10 +7,14 @@
> void scsi_show_rq(struct seq_file *m, struct request *rq)
> {
> struct scsi_cmnd *cmd = container_of(scsi_req(rq), typeof(*cmd), req);
> - int msecs = jiffies_to_msecs(jiffies - cmd->jiffies_at_alloc);
> - char buf[80];
> + int alloc_ms = jiffies_to_msecs(jiffies - cmd->jiffies_at_alloc);
> + int timeout_ms = jiffies_to_msecs(rq->timeout);
> + const u8 *const cdb = READ_ONCE(cmd->cmnd);
> + char buf[80] = "(?)";
>
> - __scsi_format_command(buf, sizeof(buf), cmd->cmnd, cmd->cmd_len);
> - seq_printf(m, ", .cmd=%s, .retries=%d, allocated %d.%03d s ago", buf,
> - cmd->retries, msecs / 1000, msecs % 1000);
> + if ((cmd->flags & SCMD_INITIALIZED) && cdb)
> + __scsi_format_command(buf, sizeof(buf), cdb, cmd->cmd_len);
> + seq_printf(m, ", .cmd=%s, .retries=%d, .timeout=%d.%03d, allocated
> %d.%03d s ago",
> + buf, cmd->retries, timeout_ms / 1000, timeout_ms % 1000,
> + alloc_ms / 1000, alloc_ms % 1000);
> }
Re: [PATCH 0/2] sd: Fix a deadlock between event checking and device removal
2017-11-14 18:33 GMT+01:00 Bart Van Assche : > On Tue, 2017-11-14 at 18:01 +0100, Jack Wang wrote: >> I suspect we run into same bug you were trying to fix in this patch >> set. we're running in v4.4.50 >> >> I was trying to reproduce it, but no lucky yet, do you still have your >> reproducer? > > Hello Jack, > > I can reproduce this about every fifth run of test one of the srp-test > software and with the SRP initiator and target drivers of what will become > kernel v4.15-rc1 and by switching the ib_srpt driver from non-SRQ to SRQ > mode while the initiator is logging in. I'm currently analyzing where in the > block layer a queue run is missing. The patch below for the sd driver does > not fix the root cause but seems to help. > > Bart. > Thanks Bart, You're always kind and helpful. I tried srp-test in my test machine, but still no luck. In my case, we had on storage failure, and lead scsi error handle and offlined both devices, so both paths down, raid1 failed one leg (the dm device). During incident recovery, when tried to delete the broken scsi device, there are processes in D state [Mon Nov 6 09:55:19 2017] sysrq: SysRq : Show Blocked State [Mon Nov 6 09:55:19 2017] taskPC stack pid father [Mon Nov 6 09:55:19 2017] kworker/40:2D 883004327a98 0 65322 2 0x [Mon Nov 6 09:55:19 2017] Workqueue: events_freezable_power_ disk_events_workfn [Mon Nov 6 09:55:19 2017] 883004327a98 881804973400 882fe6e4b400 883004327ad0 [Mon Nov 6 09:55:19 2017] 0282 883004328000 00011c546eb0 883004327ad0 [Mon Nov 6 09:55:19 2017] 883007c0cd80 0028 883004327ab0 81800540 [Mon Nov 6 09:55:19 2017] Call Trace: [Mon Nov 6 09:55:19 2017] [] schedule+0x30/0x80 [Mon Nov 6 09:55:19 2017] [] schedule_timeout+0x14a/0x290 [Mon Nov 6 09:55:19 2017] [] ? trace_raw_output_itimer_expire+0x80/0x80 [Mon Nov 6 09:55:19 2017] [] io_schedule_timeout+0xb6/0x130 [Mon Nov 6 09:55:19 2017] [] wait_for_completion_io_timeout+0x9b/0x110 [Mon Nov 6 09:55:19 2017] [] ? wake_up_q+0x70/0x70 [Mon Nov 6 09:55:19 2017] [] blk_execute_rq+0x92/0x110 [Mon Nov 6 09:55:19 2017] [] ? wait_woken+0x80/0x80 [Mon Nov 6 09:55:19 2017] [] ? blk_get_request+0x7d/0xe0 [Mon Nov 6 09:55:19 2017] [] scsi_execute+0x143/0x5f0 [scsi_mod] [Mon Nov 6 09:55:19 2017] [] scsi_execute_req_flags+0x94/0x100 [scsi_mod] [Mon Nov 6 09:55:19 2017] [] scsi_test_unit_ready+0x7b/0x2a0 [scsi_mod] [Mon Nov 6 09:55:19 2017] [] 0xa0644971 sd_check_events [Mon Nov 6 09:55:19 2017] [] disk_check_events+0x54/0x130 [Mon Nov 6 09:55:19 2017] [] disk_events_workfn+0x11/0x20 [Mon Nov 6 09:55:19 2017] [] process_one_work+0x148/0x410 [Mon Nov 6 09:55:19 2017] [] worker_thread+0x61/0x450 [Mon Nov 6 09:55:19 2017] [] ? rescuer_thread+0x2e0/0x2e0 [Mon Nov 6 09:55:19 2017] [] ? rescuer_thread+0x2e0/0x2e0 [Mon Nov 6 09:55:19 2017] [] kthread+0xd6/0xf0 [Mon Nov 6 09:55:19 2017] [] ? kthread_park+0x50/0x50 [Mon Nov 6 09:55:19 2017] [] ret_from_fork+0x3f/0x70 [Mon Nov 6 09:55:19 2017] [] ? kthread_park+0x50/0x50 [Mon Nov 6 09:55:19 2017] repair_md_dev D 8807a258fa28 0 18979 18978 0x [Mon Nov 6 09:55:19 2017] 8807a258fa28 88180497 8807f11eb400 882807d146e0 [Mon Nov 6 09:55:19 2017] 882807d146e0 8807a259 7fff 8807a258fb70 [Mon Nov 6 09:55:19 2017] 8807f11eb400 8807f11eb400 8807a258fa40 81800540 [Mon Nov 6 09:55:19 2017] Call Trace: [Mon Nov 6 09:55:19 2017] [] schedule+0x30/0x80 [Mon Nov 6 09:55:19 2017] [] schedule_timeout+0x220/0x290 [Mon Nov 6 09:55:19 2017] [] ? physflat_send_IPI_mask+0x9/0x10 [Mon Nov 6 09:55:19 2017] [] ? try_to_wake_up+0x4f/0x3c0 [Mon Nov 6 09:55:19 2017] [] wait_for_completion+0x9a/0xf0 [Mon Nov 6 09:55:19 2017] [] ? wake_up_q+0x70/0x70 [Mon Nov 6 09:55:19 2017] [] flush_work+0xe5/0x140 [Mon Nov 6 09:55:19 2017] [] ? destroy_worker+0x90/0x90 [Mon Nov 6 09:55:19 2017] [] __cancel_work_timer+0x97/0x1b0 [Mon Nov 6 09:55:19 2017] [] ? kernfs_put+0xf3/0x1a0 [Mon Nov 6 09:55:19 2017] [] cancel_delayed_work_sync+0xe/0x10 [Mon Nov 6 09:55:19 2017] [] disk_block_events+0x8d/0x90 [Mon Nov 6 09:55:19 2017] [] del_gendisk+0x35/0x230 [Mon Nov 6 09:55:19 2017] [] 0xa0643b79 [Mon Nov 6 09:55:19 2017] [] __device_release_driver+0x91/0x130 [Mon Nov 6 09:55:19 2017] [] device_release_driver+0x27/0x40 [Mon Nov 6 09:55:19 2017] [] bus_remove_device+0xfc/0x170 [Mon Nov 6 09:55:19 2017] [] device_del+0x123/0x240 [Mon Nov 6 09:55:19 2017] [] ? sysfs_remove_file_ns+0x10/0x20 [Mon Nov 6 09:55:19 2017] [] __scsi_remove_device+0xc9/0xd0 [scsi_mod] [Mon Nov 6 09:55:19 2017] [] scsi_remove_device+0x2a/0x80 [scsi_mod] [Mon Nov 6 09:55:19 2017] [] scsi_remove_device+0x6b/0x80 [scsi_mod] [Mon Nov 6 09:55:19 2
Re: [PATCH 0/2] sd: Fix a deadlock between event checking and device removal
2016-11-14 19:35 GMT+01:00 Bart Van Assche : > On 11/12/2016 09:47 PM, James Bottomley wrote: >> >> On Fri, 2016-11-11 at 16:38 -0800, Bart Van Assche wrote: >>> >>> Hello James and Martin, >>> >>> This short patch series fixes a deadlock that I ran into for the >>> first time several months ago but for which I had not yet had the >>> time to post a fix. As usual, feedback is appreciated. >> >> >> First question would be why do we need to push highly dm specific >> knowledge into block, like REQ_FAIL_IF_NO_PATH. Can't we just use >> REQ_FAILFAST_X for this? >> >> Also, I don't quite understand how you've configured multipath >> underneath SCSI. I thought dm-mp always went on top? > > > Hello James, > > dm-multipath was running on top of SCSI in my setup which means that at > least the patch description is wrong. Since it was some time ago that I ran > into this deadlock, I will check first whether I can still reproduce it. > > Bart. Hi Bart, I suspect we run into same bug you were trying to fix in this patch set. we're running in v4.4.50 I was trying to reproduce it, but no lucky yet, do you still have your reproducer? Thanks, Jack > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 05/11] libsas: Use dynamic alloced work to avoid sas event lost
ORTE_BYTES_DMAED, &phy->port_events_pending);
> -
> sas_form_port(phy);
> }
>
> @@ -273,8 +271,6 @@ void sas_porte_broadcast_rcvd(struct work_struct *work)
> unsigned long flags;
> u32 prim;
>
> - clear_bit(PORTE_BROADCAST_RCVD, &phy->port_events_pending);
> -
> spin_lock_irqsave(&phy->sas_prim_lock, flags);
> prim = phy->sas_prim;
> spin_unlock_irqrestore(&phy->sas_prim_lock, flags);
> @@ -288,8 +284,6 @@ void sas_porte_link_reset_err(struct work_struct *work)
> struct asd_sas_event *ev = to_asd_sas_event(work);
> struct asd_sas_phy *phy = ev->phy;
>
> - clear_bit(PORTE_LINK_RESET_ERR, &phy->port_events_pending);
> -
> sas_deform_port(phy, 1);
> }
>
> @@ -298,8 +292,6 @@ void sas_porte_timer_event(struct work_struct *work)
> struct asd_sas_event *ev = to_asd_sas_event(work);
> struct asd_sas_phy *phy = ev->phy;
>
> - clear_bit(PORTE_TIMER_EVENT, &phy->port_events_pending);
> -
> sas_deform_port(phy, 1);
> }
>
> @@ -308,8 +300,6 @@ void sas_porte_hard_reset(struct work_struct *work)
> struct asd_sas_event *ev = to_asd_sas_event(work);
> struct asd_sas_phy *phy = ev->phy;
>
> - clear_bit(PORTE_HARD_RESET, &phy->port_events_pending);
> -
> sas_deform_port(phy, 1);
> }
>
> @@ -353,3 +343,11 @@ void sas_unregister_ports(struct sas_ha_struct *sas_ha)
> sas_deform_port(sas_ha->sas_phy[i], 0);
>
> }
> +
> +const work_func_t sas_port_event_fns[PORT_NUM_EVENTS] = {
> + [PORTE_BYTES_DMAED] = sas_porte_bytes_dmaed,
> + [PORTE_BROADCAST_RCVD] = sas_porte_broadcast_rcvd,
> + [PORTE_LINK_RESET_ERR] = sas_porte_link_reset_err,
> + [PORTE_TIMER_EVENT] = sas_porte_timer_event,
> + [PORTE_HARD_RESET] = sas_porte_hard_reset,
> +};
> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
> index 99f32b5..c80321b 100644
> --- a/include/scsi/libsas.h
> +++ b/include/scsi/libsas.h
> @@ -292,6 +292,7 @@ struct asd_sas_port {
> struct asd_sas_event {
> struct sas_work work;
> struct asd_sas_phy *phy;
> + int event;
> };
>
> static inline struct asd_sas_event *to_asd_sas_event(struct work_struct
> *work)
> @@ -301,17 +302,20 @@ static inline struct asd_sas_event
> *to_asd_sas_event(struct work_struct *work)
> return ev;
> }
>
> +static inline void INIT_SAS_EVENT(struct asd_sas_event *ev, void
> (*fn)(struct work_struct *),
> + struct asd_sas_phy *phy, int event)
> +{
> + INIT_SAS_WORK(&ev->work, fn);
> + ev->phy = phy;
> + ev->event = event;
> +}
> +
> +
> /* The phy pretty much is controlled by the LLDD.
> * The class only reads those fields.
> */
> struct asd_sas_phy {
> /* private: */
> - struct asd_sas_event port_events[PORT_NUM_EVENTS];
> - struct asd_sas_event phy_events[PHY_NUM_EVENTS];
> -
> - unsigned long port_events_pending;
> - unsigned long phy_events_pending;
> -
> int error;
> int suspended;
>
> --
> 2.5.0
>
Looks good, thanks!
Reviewed-by: Jack Wang
Re: [PATCH v4 07/11] libsas: make the event threshold configurable
2017-09-06 11:15 GMT+02:00 Jason Yan :
> Add a sysfs attr that LLDD can configure it for every host. We made
> a example in hisi_sas. Other LLDDs using libsas can implement it if
> they want.
>
> Suggested-by: Hannes Reinecke
> Signed-off-by: Jason Yan
> CC: John Garry
> CC: Johannes Thumshirn
> CC: Ewan Milne
> CC: Christoph Hellwig
> CC: Tomas Henzl
> CC: Dan Williams
> ---
> drivers/scsi/hisi_sas/hisi_sas_main.c | 6 ++
> drivers/scsi/libsas/sas_init.c| 27 +++
> include/scsi/libsas.h | 1 +
> 3 files changed, 34 insertions(+)
>
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
> b/drivers/scsi/hisi_sas/hisi_sas_main.c
> index 5e47abb..9eceed1 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -1470,6 +1470,11 @@ EXPORT_SYMBOL_GPL(hisi_sas_rescan_topology);
> struct scsi_transport_template *hisi_sas_stt;
> EXPORT_SYMBOL_GPL(hisi_sas_stt);
>
> +struct device_attribute *host_attrs[] = {
> +&dev_attr_phy_event_threshold,
> +NULL,
> +};
> +
> static struct scsi_host_template _hisi_sas_sht = {
> .module = THIS_MODULE,
> .name = DRV_NAME,
> @@ -1489,6 +1494,7 @@ static struct scsi_host_template _hisi_sas_sht = {
> .eh_bus_reset_handler = sas_eh_bus_reset_handler,
> .target_destroy = sas_target_destroy,
> .ioctl = sas_ioctl,
> + .shost_attrs= host_attrs,
> };
> struct scsi_host_template *hisi_sas_sht = &_hisi_sas_sht;
> EXPORT_SYMBOL_GPL(hisi_sas_sht);
> diff --git a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas/sas_init.c
> index b1e03d5..e2d98a8 100644
> --- a/drivers/scsi/libsas/sas_init.c
> +++ b/drivers/scsi/libsas/sas_init.c
> @@ -537,6 +537,33 @@ static struct sas_function_template sft = {
> .smp_handler = sas_smp_handler,
> };
>
> +static inline ssize_t phy_event_threshold_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct Scsi_Host *shost = class_to_shost(dev);
> + struct sas_ha_struct *sha = SHOST_TO_SAS_HA(shost);
> +
> + return scnprintf(buf, PAGE_SIZE, "%u\n", sha->event_thres);
> +}
> +
> +static inline ssize_t phy_event_threshold_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct Scsi_Host *shost = class_to_shost(dev);
> + struct sas_ha_struct *sha = SHOST_TO_SAS_HA(shost);
> +
> + sha->event_thres = simple_strtol(buf, NULL, 10);
> +
> + return count;
> +}
> +
> +DEVICE_ATTR(phy_event_threshold,
> + S_IRUGO|S_IWUSR,
> + phy_event_threshold_show,
> + phy_event_threshold_store);
> +EXPORT_SYMBOL_GPL(dev_attr_phy_event_threshold);
> +
> struct scsi_transport_template *
> sas_domain_attach_transport(struct sas_domain_function_template *dft)
> {
> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
> index 2fa0b13..08c1c32 100644
> --- a/include/scsi/libsas.h
> +++ b/include/scsi/libsas.h
> @@ -679,6 +679,7 @@ extern int sas_bios_param(struct scsi_device *,
> sector_t capacity, int *hsc);
> extern struct scsi_transport_template *
> sas_domain_attach_transport(struct sas_domain_function_template *);
> +extern struct device_attribute dev_attr_phy_event_threshold;
>
> int sas_discover_root_expander(struct domain_device *);
>
> --
> 2.5.0
>
Looks good, thanks!
Reviewed-by: Jack Wang
Re: [PATCH 3/6] pm80xx : Different SAS addresses for phys.
2017-08-30 18:55 GMT+02:00 Viswas G :
> Hi Jack,
>
> This is a customer requirement. Since the SAS addresses of all the phys were
> same , when the attached SAS addresses are different, it was forming only one
> domain. If we assign different SAS addresses, this will cause duplicate
> domain unless we set the strict_wide_port to 1.
>
> Regards,
> Viswas G
Ok, understand now!
Acked-by: Jack Wang
Thanks!
>
>
>> -----Original Message-
>> From: Jack Wang [mailto:xjtu...@gmail.com]
>> Sent: Tuesday, August 29, 2017 4:55 PM
>> To: Viswas G
>> Cc: linux-scsi@vger.kernel.org; Vasanthalakshmi Tharmarajan
>>
>> Subject: Re: [PATCH 3/6] pm80xx : Different SAS addresses for phys.
>>
>> EXTERNAL EMAIL
>>
>>
>> 2015-01-30 7:06 GMT+01:00 Viswas G :
>> > Different SAS addresses are assigned for each set of phys.
>> >
>> > Signed-off-by: Viswas G
>> > ---
>> > drivers/scsi/pm8001/pm8001_init.c | 13 +
>> > drivers/scsi/pm8001/pm80xx_hwi.c | 3 +--
>> > 2 files changed, 10 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/scsi/pm8001/pm8001_init.c
>> b/drivers/scsi/pm8001/pm8001_init.c
>> > index 034b2f7d1135..d282f1562615 100644
>> > --- a/drivers/scsi/pm8001/pm8001_init.c
>> > +++ b/drivers/scsi/pm8001/pm8001_init.c
>> > @@ -132,7 +132,7 @@ static void pm8001_phy_init(struct
>> pm8001_hba_info *pm8001_ha, int phy_id)
>> > sas_phy->oob_mode = OOB_NOT_CONNECTED;
>> > sas_phy->linkrate = SAS_LINK_RATE_UNKNOWN;
>> > sas_phy->id = phy_id;
>> > - sas_phy->sas_addr = &pm8001_ha->sas_addr[0];
>> > + sas_phy->sas_addr = (u8 *)&phy->dev_sas_addr;
>> > sas_phy->frame_rcvd = &phy->frame_rcvd[0];
>> > sas_phy->ha = (struct sas_ha_struct *)pm8001_ha->shost->hostdata;
>> > sas_phy->lldd_phy = phy;
>> > @@ -593,10 +593,12 @@ static void pm8001_post_sas_ha_init(struct
>> Scsi_Host *shost,
>> > for (i = 0; i < chip_info->n_phy; i++) {
>> > sha->sas_phy[i] = &pm8001_ha->phy[i].sas_phy;
>> > sha->sas_port[i] = &pm8001_ha->port[i].sas_port;
>> > + sha->sas_phy[i]->sas_addr =
>> > + (u8 *)&pm8001_ha->phy[i].dev_sas_addr;
>> > }
>> > sha->sas_ha_name = DRV_NAME;
>> > sha->dev = pm8001_ha->dev;
>> > -
>> > + sha->strict_wide_ports = 1;
>> > sha->lldd_module = THIS_MODULE;
>> > sha->sas_addr = &pm8001_ha->sas_addr[0];
>> > sha->num_phys = chip_info->n_phy;
>> > @@ -613,6 +615,7 @@ static void pm8001_post_sas_ha_init(struct
>> Scsi_Host *shost,
>> > static void pm8001_init_sas_add(struct pm8001_hba_info *pm8001_ha)
>> > {
>> > u8 i, j;
>> > + u8 sas_add[8];
>> > #ifdef PM8001_READ_VPD
>> > /* For new SPC controllers WWN is stored in flash vpd
>> > * For SPC/SPCve controllers WWN is stored in EEPROM
>> > @@ -674,10 +677,12 @@ static void pm8001_init_sas_add(struct
>> pm8001_hba_info *pm8001_ha)
>> > pm8001_ha->sas_addr[j] =
>> > payload.func_specific[0x804 + i];
>> > }
>> > -
>> > + memcpy(sas_add, pm8001_ha->sas_addr, SAS_ADDR_SIZE);
>> > for (i = 0; i < pm8001_ha->chip->n_phy; i++) {
>> > + if (i && ((i % 4) == 0))
>> > + sas_add[7] = sas_add[7] + 4;
>> > memcpy(&pm8001_ha->phy[i].dev_sas_addr,
>> > - pm8001_ha->sas_addr, SAS_ADDR_SIZE);
>> > + sas_add, SAS_ADDR_SIZE);
>> > PM8001_INIT_DBG(pm8001_ha,
>> > pm8001_printk("phy %d sas_addr = %016llx\n", i,
>> > pm8001_ha->phy[i].dev_sas_addr));
>> > diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
>> b/drivers/scsi/pm8001/pm80xx_hwi.c
>> > index 8fb5ddf08cc4..a07b023c09bf 100644
>> > --- a/drivers/scsi/pm8001/pm80xx_hwi.c
>> > +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
>> > @@ -3041,7 +3041,6 @@ hw_event_phy_down(struct pm8001_hba_info
>> *pm8001_ha, void *piomb)
>> > port->port_state = portstate;
>> > phy->identify.device_type = 0;
>> > phy->phy_attached = 0;
>> > - memset(&phy->dev_sas_addr, 0, SAS_ADDR_SIZE);
>> > switch (portstate) {
>> > case PORT_VALID:
>> > break;
>> > @@ -4394,7 +4393,7 @@ pm80xx_chip_phy_start_req(struct
>> pm8001_hba_info *pm8001_ha, u8 phy_id)
>> > payload.sas_identify.dev_type = SAS_END_DEVICE;
>> > payload.sas_identify.initiator_bits = SAS_PROTOCOL_ALL;
>> > memcpy(payload.sas_identify.sas_addr,
>> > - pm8001_ha->sas_addr, SAS_ADDR_SIZE);
>> > + &pm8001_ha->phy[phy_id].dev_sas_addr, SAS_ADDR_SIZE);
>> > payload.sas_identify.phy_id = phy_id;
>> > ret = pm8001_mpi_build_cmd(pm8001_ha, circularQ, opcode,
>> &payload, 0);
>> > return ret;
>> > --
>> > 2.12.3
>> >
>> This removes the possibility to form a wide port, why do you want to do it?
Re: [PATCH 1/6] pm80xx : redefine sas_identify_frame structure
2017-08-30 17:41 GMT+02:00 Viswas G :
> Hi Jack,
>
> The firmware expectation is that there is no 4 byte CRC. This causes the IOMB
> to be generated incorrectly for PHY_START. Local structure for SAS Identify
> included in the driver so that it matches the Programmer's Manual and
> Firmware expectations.
>
> The sas_identify struct from the kernel includes the checksum word (32-bits)
> . So it is 32 bytes rather than 28 bytes. The changed size for the sas
> identify frame means that the "spasti" field for PHY_START is at a different
> offset than documented, word 11 rather than word 10. We're not changing the
> phy analog settings so this doesn't really matter, but the docs indicate that
> the sas frame's crc isn't included. So having a local definition will be
> better than taking the system definition.
>
> Regards,
> Viswas G
Hi Viswas,
The spasti field is only for pm80xx, not for pm8001, I think it's
better to move sas_identify_frame_local to pm80xx_hwi.h.
Regards,
Jack
>
>> -Original Message-
>> From: Jack Wang [mailto:xjtu...@gmail.com]
>> Sent: Tuesday, August 29, 2017 4:49 PM
>> To: Viswas G
>> Cc: linux-scsi@vger.kernel.org; Vasanthalakshmi Tharmarajan
>>
>> Subject: Re: [PATCH 1/6] pm80xx : redefine sas_identify_frame structure
>>
>> EXTERNAL EMAIL
>>
>>
>> 2015-01-30 7:06 GMT+01:00 Viswas G :
>> > sas_identify structure defined by pm80xx doesn't have CRC field.
>> > So added a new sas_identify structure without CRC.
>> >
>> > Signed-off-by: Raj Dinesh
>> > Signed-off-by: Viswas G
>> > ---
>> > drivers/scsi/pm8001/pm8001_hwi.h | 2 +-
>> > drivers/scsi/pm8001/pm8001_sas.h | 95
>>
>> > drivers/scsi/pm8001/pm80xx_hwi.h | 2 +-
>> > 3 files changed, 97 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/scsi/pm8001/pm8001_hwi.h
>> b/drivers/scsi/pm8001/pm8001_hwi.h
>> > index e4867e690c84..f4331afe9b0b 100644
>> > --- a/drivers/scsi/pm8001/pm8001_hwi.h
>> > +++ b/drivers/scsi/pm8001/pm8001_hwi.h
>> > @@ -157,7 +157,7 @@ struct mpi_msg_hdr{
>> > struct phy_start_req {
>> > __le32 tag;
>> > __le32 ase_sh_lm_slr_phyid;
>> > - struct sas_identify_frame sas_identify;
>> > + struct sas_identify_frame_local sas_identify;
>> > u32 reserved[5];
>> > } __attribute__((packed, aligned(4)));
>> >
>> > diff --git a/drivers/scsi/pm8001/pm8001_sas.h
>> b/drivers/scsi/pm8001/pm8001_sas.h
>> > index e81a8fa7ef1a..2e17505ed5b8 100644
>> > --- a/drivers/scsi/pm8001/pm8001_sas.h
>> > +++ b/drivers/scsi/pm8001/pm8001_sas.h
>> > @@ -118,6 +118,101 @@ extern const struct pm8001_dispatch
>> pm8001_80xx_dispatch;
>> > struct pm8001_hba_info;
>> > struct pm8001_ccb_info;
>> > struct pm8001_device;
>> > +#ifdef __LITTLE_ENDIAN_BITFIELD
>> > +struct sas_identify_frame_local {
>> > + /* Byte 0 */
>> > + u8 frame_type:4;
>> > + u8 dev_type:3;
>> > + u8 _un0:1;
>> > +
>> > + /* Byte 1 */
>> > + u8 _un1;
>> > +
>> > + /* Byte 2 */
>> > + union {
>> > + struct {
>> > + u8 _un20:1;
>> > + u8 smp_iport:1;
>> > + u8 stp_iport:1;
>> > + u8 ssp_iport:1;
>> > + u8 _un247:4;
>> > + };
>> > + u8 initiator_bits;
>> > + };
>> > +
>> > + /* Byte 3 */
>> > + union {
>> > + struct {
>> > + u8 _un30:1;
>> > + u8 smp_tport:1;
>> > + u8 stp_tport:1;
>> > + u8 ssp_tport:1;
>> > + u8 _un347:4;
>> > + };
>> > + u8 target_bits;
>> > + };
>> > +
>> > + /* Byte 4 - 11 */
>> > + u8 _un4_11[8];
>> > +
>> > + /* Byte 12 - 19 */
>> > + u8 sas_addr[SAS_ADDR_SIZE];
>> > +
>> > + /* Byte 20 */
>> > + u8 phy_id;
>> > +
>> > + u8 _un21_27[7];
>> > +
>> > +} __packed;
>> > +
>> > +#elif defined(__
Re: [PATCH 5/6] pm80xx : panic on ncq error cleaning up the read log
2015-01-30 7:06 GMT+01:00 Viswas G : > when there's an error in 'ncq mode' the host has to read the ncq > error log (10h) to clear the error state. however, the ccb that > is setup for doing this doesn't setup the ccb so that the > previous state is cleared. if the ccb was previously used for an IO > n_elems is set and pm8001_ccb_task_free() treats this as the signal > to go free a scatter-gather list (that's already been free-ed). > > Signed-off-by: Deepak Ukey > Signed-off-by: Viswas G > --- > drivers/scsi/pm8001/pm80xx_hwi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c > b/drivers/scsi/pm8001/pm80xx_hwi.c > index ae9252cf1706..e75b0aa497f0 100644 > --- a/drivers/scsi/pm8001/pm80xx_hwi.c > +++ b/drivers/scsi/pm8001/pm80xx_hwi.c > @@ -1489,6 +1489,7 @@ static void pm80xx_send_read_log(struct pm8001_hba_info > *pm8001_ha, > ccb->device = pm8001_ha_dev; > ccb->ccb_tag = ccb_tag; > ccb->task = task; > + ccb->n_elem = 0; > pm8001_ha_dev->id |= NCQ_READ_LOG_FLAG; > pm8001_ha_dev->id |= NCQ_2ND_RLE_FLAG; > > -- > 2.12.3 > Thanks. Looks good to me! Acked-by: Jack Wang
Re: [PATCH 4/6] pm80xx : Corrected SATA abort handling.
2015-01-30 7:06 GMT+01:00 Viswas G :
> Modified SATA abort handling with following steps:
> 1) Set device state as recovery.
> 2) Send phy reset.
> 3) Wait for reset completion.
> 4) After successful reset, abort all IO's to the device.
> 5) After aborting all IO's to device, set device state as operational.
>
> Signed-off-by: Deepak Ukey
> Signed-off-by: Viswas G
This one includes more than described above.
Would be good to split it better.
comments inline.
> ---
> drivers/scsi/pm8001/pm8001_hwi.c | 11 +++-
> drivers/scsi/pm8001/pm8001_sas.c | 125
> +++
> drivers/scsi/pm8001/pm8001_sas.h | 8 +++
> drivers/scsi/pm8001/pm80xx_hwi.c | 52 +---
> 4 files changed, 148 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index 10546faac58c..db88a8e7ee0e 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -3198,19 +3198,28 @@ pm8001_mpi_get_nvmd_resp(struct pm8001_hba_info
> *pm8001_ha, void *piomb)
>
> int pm8001_mpi_local_phy_ctl(struct pm8001_hba_info *pm8001_ha, void *piomb)
> {
> + u32 tag;
> struct local_phy_ctl_resp *pPayload =
> (struct local_phy_ctl_resp *)(piomb + 4);
> u32 status = le32_to_cpu(pPayload->status);
> u32 phy_id = le32_to_cpu(pPayload->phyop_phyid) & ID_BITS;
> u32 phy_op = le32_to_cpu(pPayload->phyop_phyid) & OP_BITS;
> + tag = le32_to_cpu(pPayload->tag);
> if (status != 0) {
> PM8001_MSG_DBG(pm8001_ha,
> pm8001_printk("%x phy execute %x phy op failed!\n",
> phy_id, phy_op));
> - } else
> + } else {
> PM8001_MSG_DBG(pm8001_ha,
> pm8001_printk("%x phy execute %x phy op success!\n",
> phy_id, phy_op));
> + pm8001_ha->phy[phy_id].reset_success = true;
> + }
> + if (pm8001_ha->phy[phy_id].enable_completion) {
> + complete(pm8001_ha->phy[phy_id].enable_completion);
> + pm8001_ha->phy[phy_id].enable_completion = NULL;
> + }
> + pm8001_tag_free(pm8001_ha, tag);
> return 0;
> }
>
> diff --git a/drivers/scsi/pm8001/pm8001_sas.c
> b/drivers/scsi/pm8001/pm8001_sas.c
> index ce584c31d36e..a409d3a6a3cb 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -1159,40 +1159,47 @@ int pm8001_query_task(struct sas_task *task)
> int pm8001_abort_task(struct sas_task *task)
> {
> unsigned long flags;
> - u32 tag = 0xdeadbeef;
> + u32 tag;
> u32 device_id;
> struct domain_device *dev ;
> - struct pm8001_hba_info *pm8001_ha = NULL;
> + struct pm8001_hba_info *pm8001_ha;
> struct pm8001_ccb_info *ccb;
> struct scsi_lun lun;
> struct pm8001_device *pm8001_dev;
> struct pm8001_tmf_task tmf_task;
> - int rc = TMF_RESP_FUNC_FAILED;
> + int rc = TMF_RESP_FUNC_FAILED, ret;
> + u32 phy_id;
> + struct sas_task_slow slow_task;
> +
> if (unlikely(!task || !task->lldd_task || !task->dev))
> - return rc;
> + return TMF_RESP_FUNC_FAILED;
> +
> + dev = task->dev;
> + pm8001_dev = dev->lldd_dev;
> + pm8001_ha = pm8001_find_ha_by_dev(dev);
> + device_id = pm8001_dev->device_id;
> + phy_id = pm8001_dev->attached_phy;
> + rc = pm8001_find_tag(task, &tag);
> + if (rc == 0) {
> + pm8001_printk("no tag for task:%p\n", task);
> + return TMF_RESP_FUNC_FAILED;
> + }
This part is cleanup.
> spin_lock_irqsave(&task->task_state_lock, flags);
> if (task->task_state_flags & SAS_TASK_STATE_DONE) {
> spin_unlock_irqrestore(&task->task_state_lock, flags);
> rc = TMF_RESP_FUNC_COMPLETE;
> - goto out;
> + }
> +
> + task->task_state_flags |= SAS_TASK_STATE_ABORTED;
> + if (task->slow_task == NULL) {
> + init_completion(&slow_task.completion);
> + task->slow_task = &slow_task;
> }
> spin_unlock_irqrestore(&task->task_state_lock, flags);
> +
> if (task->task_proto & SAS_PROTOCOL_SSP) {
> struct scsi_cmnd *cmnd = task->uldd_task;
> - dev = task->dev;
> - ccb = task->lldd_task;
> - pm8001_dev = dev->lldd_dev;
> - pm8001_ha = pm8001_find_ha_by_dev(dev);
> int_to_scsilun(cmnd->device->lun, &lun);
> - rc = pm8001_find_tag(task, &tag);
> - if (rc == 0) {
> - printk(KERN_INFO "No such tag in %s\n", __func__);
> - rc = TMF_RESP_FUNC_FAILED;
> - return rc;
> - }
> - device_id = pm8001_dev->device_id;
> -
Re: [PATCH 2/6] pm80xx: ILA and inactive firmware version through sysfs
on */ > + pm8001_ha->main_cfg_tbl.pm80xx_tbl.ila_version = > + pm8001_mr32(address, MAIN_MPI_ILA_RELEASE_TYPE); > + pm8001_ha->main_cfg_tbl.pm80xx_tbl.inc_fw_version = > + pm8001_mr32(address, MAIN_MPI_INACTIVE_FW_VERSION); > } > > /** > diff --git a/drivers/scsi/pm8001/pm80xx_hwi.h > b/drivers/scsi/pm8001/pm80xx_hwi.h > index 1ee2ec210065..d8e5d81e83f1 100644 > --- a/drivers/scsi/pm8001/pm80xx_hwi.h > +++ b/drivers/scsi/pm8001/pm80xx_hwi.h > @@ -1349,6 +1349,8 @@ typedef struct SASProtocolTimerConfig > SASProtocolTimerConfig_t; > #define MAIN_SAS_PHY_ATTR_TABLE_OFFSET 0x90 /* DWORD 0x24 */ > #define MAIN_PORT_RECOVERY_TIMER 0x94 /* DWORD 0x25 */ > #define MAIN_INT_REASSERTION_DELAY 0x98 /* DWORD 0x26 */ > +#define MAIN_MPI_ILA_RELEASE_TYPE 0xA4 /* DWORD 0x29 */ > +#define MAIN_MPI_INACTIVE_FW_VERSION 0XB0 /* DWORD 0x2C */ > > /* Gereral Status Table offset - byte offset */ > #define GST_GSTLEN_MPIS_OFFSET 0x00 > -- > 2.12.3 > Thanks, looks good to me. Acked-by: Jack Wang
Re: [PATCH 3/6] pm80xx : Different SAS addresses for phys.
2015-01-30 7:06 GMT+01:00 Viswas G :
> Different SAS addresses are assigned for each set of phys.
>
> Signed-off-by: Viswas G
> ---
> drivers/scsi/pm8001/pm8001_init.c | 13 +
> drivers/scsi/pm8001/pm80xx_hwi.c | 3 +--
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 034b2f7d1135..d282f1562615 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -132,7 +132,7 @@ static void pm8001_phy_init(struct pm8001_hba_info
> *pm8001_ha, int phy_id)
> sas_phy->oob_mode = OOB_NOT_CONNECTED;
> sas_phy->linkrate = SAS_LINK_RATE_UNKNOWN;
> sas_phy->id = phy_id;
> - sas_phy->sas_addr = &pm8001_ha->sas_addr[0];
> + sas_phy->sas_addr = (u8 *)&phy->dev_sas_addr;
> sas_phy->frame_rcvd = &phy->frame_rcvd[0];
> sas_phy->ha = (struct sas_ha_struct *)pm8001_ha->shost->hostdata;
> sas_phy->lldd_phy = phy;
> @@ -593,10 +593,12 @@ static void pm8001_post_sas_ha_init(struct Scsi_Host
> *shost,
> for (i = 0; i < chip_info->n_phy; i++) {
> sha->sas_phy[i] = &pm8001_ha->phy[i].sas_phy;
> sha->sas_port[i] = &pm8001_ha->port[i].sas_port;
> + sha->sas_phy[i]->sas_addr =
> + (u8 *)&pm8001_ha->phy[i].dev_sas_addr;
> }
> sha->sas_ha_name = DRV_NAME;
> sha->dev = pm8001_ha->dev;
> -
> + sha->strict_wide_ports = 1;
> sha->lldd_module = THIS_MODULE;
> sha->sas_addr = &pm8001_ha->sas_addr[0];
> sha->num_phys = chip_info->n_phy;
> @@ -613,6 +615,7 @@ static void pm8001_post_sas_ha_init(struct Scsi_Host
> *shost,
> static void pm8001_init_sas_add(struct pm8001_hba_info *pm8001_ha)
> {
> u8 i, j;
> + u8 sas_add[8];
> #ifdef PM8001_READ_VPD
> /* For new SPC controllers WWN is stored in flash vpd
> * For SPC/SPCve controllers WWN is stored in EEPROM
> @@ -674,10 +677,12 @@ static void pm8001_init_sas_add(struct pm8001_hba_info
> *pm8001_ha)
> pm8001_ha->sas_addr[j] =
> payload.func_specific[0x804 + i];
> }
> -
> + memcpy(sas_add, pm8001_ha->sas_addr, SAS_ADDR_SIZE);
> for (i = 0; i < pm8001_ha->chip->n_phy; i++) {
> + if (i && ((i % 4) == 0))
> + sas_add[7] = sas_add[7] + 4;
> memcpy(&pm8001_ha->phy[i].dev_sas_addr,
> - pm8001_ha->sas_addr, SAS_ADDR_SIZE);
> + sas_add, SAS_ADDR_SIZE);
> PM8001_INIT_DBG(pm8001_ha,
> pm8001_printk("phy %d sas_addr = %016llx\n", i,
> pm8001_ha->phy[i].dev_sas_addr));
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 8fb5ddf08cc4..a07b023c09bf 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -3041,7 +3041,6 @@ hw_event_phy_down(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> port->port_state = portstate;
> phy->identify.device_type = 0;
> phy->phy_attached = 0;
> - memset(&phy->dev_sas_addr, 0, SAS_ADDR_SIZE);
> switch (portstate) {
> case PORT_VALID:
> break;
> @@ -4394,7 +4393,7 @@ pm80xx_chip_phy_start_req(struct pm8001_hba_info
> *pm8001_ha, u8 phy_id)
> payload.sas_identify.dev_type = SAS_END_DEVICE;
> payload.sas_identify.initiator_bits = SAS_PROTOCOL_ALL;
> memcpy(payload.sas_identify.sas_addr,
> - pm8001_ha->sas_addr, SAS_ADDR_SIZE);
> + &pm8001_ha->phy[phy_id].dev_sas_addr, SAS_ADDR_SIZE);
> payload.sas_identify.phy_id = phy_id;
> ret = pm8001_mpi_build_cmd(pm8001_ha, circularQ, opcode, &payload, 0);
> return ret;
> --
> 2.12.3
>
This removes the possibility to form a wide port, why do you want to do it?
Re: [PATCH 1/6] pm80xx : redefine sas_identify_frame structure
2015-01-30 7:06 GMT+01:00 Viswas G :
> sas_identify structure defined by pm80xx doesn't have CRC field.
> So added a new sas_identify structure without CRC.
>
> Signed-off-by: Raj Dinesh
> Signed-off-by: Viswas G
> ---
> drivers/scsi/pm8001/pm8001_hwi.h | 2 +-
> drivers/scsi/pm8001/pm8001_sas.h | 95
>
> drivers/scsi/pm8001/pm80xx_hwi.h | 2 +-
> 3 files changed, 97 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.h
> b/drivers/scsi/pm8001/pm8001_hwi.h
> index e4867e690c84..f4331afe9b0b 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.h
> +++ b/drivers/scsi/pm8001/pm8001_hwi.h
> @@ -157,7 +157,7 @@ struct mpi_msg_hdr{
> struct phy_start_req {
> __le32 tag;
> __le32 ase_sh_lm_slr_phyid;
> - struct sas_identify_frame sas_identify;
> + struct sas_identify_frame_local sas_identify;
> u32 reserved[5];
> } __attribute__((packed, aligned(4)));
>
> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
> b/drivers/scsi/pm8001/pm8001_sas.h
> index e81a8fa7ef1a..2e17505ed5b8 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.h
> +++ b/drivers/scsi/pm8001/pm8001_sas.h
> @@ -118,6 +118,101 @@ extern const struct pm8001_dispatch
> pm8001_80xx_dispatch;
> struct pm8001_hba_info;
> struct pm8001_ccb_info;
> struct pm8001_device;
> +#ifdef __LITTLE_ENDIAN_BITFIELD
> +struct sas_identify_frame_local {
> + /* Byte 0 */
> + u8 frame_type:4;
> + u8 dev_type:3;
> + u8 _un0:1;
> +
> + /* Byte 1 */
> + u8 _un1;
> +
> + /* Byte 2 */
> + union {
> + struct {
> + u8 _un20:1;
> + u8 smp_iport:1;
> + u8 stp_iport:1;
> + u8 ssp_iport:1;
> + u8 _un247:4;
> + };
> + u8 initiator_bits;
> + };
> +
> + /* Byte 3 */
> + union {
> + struct {
> + u8 _un30:1;
> + u8 smp_tport:1;
> + u8 stp_tport:1;
> + u8 ssp_tport:1;
> + u8 _un347:4;
> + };
> + u8 target_bits;
> + };
> +
> + /* Byte 4 - 11 */
> + u8 _un4_11[8];
> +
> + /* Byte 12 - 19 */
> + u8 sas_addr[SAS_ADDR_SIZE];
> +
> + /* Byte 20 */
> + u8 phy_id;
> +
> + u8 _un21_27[7];
> +
> +} __packed;
> +
> +#elif defined(__BIG_ENDIAN_BITFIELD)
> +struct sas_identify_frame_local {
> + /* Byte 0 */
> + u8 _un0:1;
> + u8 dev_type:3;
> + u8 frame_type:4;
> +
> + /* Byte 1 */
> + u8 _un1;
> +
> + /* Byte 2 */
> + union {
> + struct {
> + u8 _un247:4;
> + u8 ssp_iport:1;
> + u8 stp_iport:1;
> + u8 smp_iport:1;
> + u8 _un20:1;
> + };
> + u8 initiator_bits;
> + };
> +
> + /* Byte 3 */
> + union {
> + struct {
> + u8 _un347:4;
> + u8 ssp_tport:1;
> + u8 stp_tport:1;
> + u8 smp_tport:1;
> + u8 _un30:1;
> + };
> + u8 target_bits;
> + };
> +
> + /* Byte 4 - 11 */
> + u8 _un4_11[8];
> +
> + /* Byte 12 - 19 */
> + u8 sas_addr[SAS_ADDR_SIZE];
> +
> + /* Byte 20 */
> + u8 phy_id;
> +
> + u8 _un21_27[7];
> +} __packed;
> +#else
> +#error "Bitfield order not defined!"
> +#endif
> /* define task management IU */
> struct pm8001_tmf_task {
> u8 tmf;
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.h
> b/drivers/scsi/pm8001/pm80xx_hwi.h
> index 7a443bad6163..1ee2ec210065 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.h
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.h
> @@ -248,7 +248,7 @@ struct mpi_msg_hdr {
> struct phy_start_req {
> __le32 tag;
> __le32 ase_sh_lm_slr_phyid;
> - struct sas_identify_frame sas_identify; /* 28 Bytes */
> + struct sas_identify_frame_local sas_identify; /* 28 Bytes */
> __le32 spasti;
> u32 reserved[21];
> } __attribute__((packed, aligned(4)));
> --
> 2.12.3
>
Did this cause any trouble? I guest not, as we does memset for
phy_start_req, why bother?
Jack
Re: [PATCH 6/6] pm80xx : corrected linkrate value.
2015-01-30 7:06 GMT+01:00 Viswas G : > Corrected the value defined for LINKRATE_60 (6 Gig). > > Signed-off-by: Raj Dinesh > Signed-off-by: Viswas G > --- > drivers/scsi/pm8001/pm80xx_hwi.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/pm8001/pm80xx_hwi.h > b/drivers/scsi/pm8001/pm80xx_hwi.h > index d8e5d81e83f1..71dee83aeef0 100644 > --- a/drivers/scsi/pm8001/pm80xx_hwi.h > +++ b/drivers/scsi/pm8001/pm80xx_hwi.h > @@ -167,7 +167,7 @@ > #define LINKMODE_AUTO (0x03 << 12) > #define LINKRATE_15(0x01 << 8) > #define LINKRATE_30(0x02 << 8) > -#define LINKRATE_60(0x06 << 8) > +#define LINKRATE_60(0x04 << 8) > #define LINKRATE_120 (0x08 << 8) > > /* phy_profile */ > -- > 2.12.3 > Thanks Viswas, how did this happen, checked pm8001_hwi.h, it's right. Anyway, looks good to me! Acked-by: Jack Wang
[PATCH] MAINTAINERS: remove pmchba list for PM8001
From: Jack Wang The email address is undeliverable for some time now, so just remove it. Signed-off-by: Jack Wang --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 12a528a..e3e61c5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9989,7 +9989,6 @@ F:drivers/scsi/pmcraid.* PMC SIERRA PM8001 DRIVER M: Jack Wang M: lindar_...@usish.com -L: pmc...@pmcs.com L: linux-scsi@vger.kernel.org S: Supported F: drivers/scsi/pm8001/ -- 2.7.4
Re: Getting "Wrong diagnostic page; asked for 7 got 0" error message on HBA's virtual SES device
2017-03-13 7:43 GMT+01:00 Sreekanth Reddy : > Hi, > > Our LSI(Broadcom) SAS3.5 HBA device's support virtual SES device. > > Whenever we load the mpt3sas driver then we are observing below error message, > > "Wrong diagnostic page; asked for 7 got 0" > > Our virtual SES device doesn't support Diagnostic page 7, it supports > only below diagnostic pages, > > • 00h List of Supported Diagnostic Pages > • 01h SES Configuration Diagnostic Page > • 02h SES Enclosure Control/Enclosure Status Diagnostic Page > • 0Ah SES Additional Element Status Diagnostic Page > > Page Code 07 is Element Descriptor Diagnostic Page > Per SES3 spec (see table 10) this page is optional and not supported > by our internal VSES. > > But 'ses' kernel module is issuing a RECEIVE_DIAGNOSTIC command for > diagnostic page 7 without checking whether target device supports this > page or not (i.e. without looking into 00h page) as shown below, > > result = ses_recv_diag(sdev, 7, hdr_buf, INIT_ALLOC_SIZE); > if (result) > goto simple_populate; > > As the virtual SES devices doesn't support this page 7, so it has > failed this RECEIVE_DIAGNOSTIC command with illegal request sense key > as shown below, > > ses 11:0:0:0: tag#0 Send: scmd 0x883fee898000 > ses 11:0:0:0: tag#0 CDB: Receive Diagnostic 1c 01 07 00 20 00 > ses 11:0:0:0: tag#0 CDB: Receive Diagnostic 1c 01 07 00 20 00 > mpt3sas_cm1:sas_address(0x510600b012345600), phy(16) > mpt3sas_cm1:enclosure_logical_id(0x500605b012345600),slot(16) > mpt3sas_cm1:enclosure level(0x), connector name( ) > mpt3sas_cm1:handle(0x0011), ioc_status(success)(0x), smid(1) > mpt3sas_cm1:request_len(32), underflow(0), resid(32) > mpt3sas_cm1:tag(0), transfer_count(0), sc->result(0x0002) > mpt3sas_cm1:scsi_status(check condition)(0x02), > scsi_state(autosense valid )(0x01) > mpt3sas_cm1:[sense_key,asc,ascq]: [0x05,0x26,0x00], count(18) > mpt3sas_cm1: log_info(0x31200205): originator(PL), code(0x20), > sub_code(0x0205) > ses 11:0:0:0: tag#0 Done: SUCCESS Result: hostbyte=DID_TARGET_FAILURE > driverbyte=DRIVER_OK > ses 11:0:0:0: tag#0 CDB: Receive Diagnostic 1c 01 07 00 20 00 > ses 11:0:0:0: tag#0 Sense Key : Illegal Request [current] > ses 11:0:0:0: tag#0 Add. Sense: Invalid field in parameter list > ses 11:0:0:0: tag#0 scsi host busy 1 failed 0 > ses 11:0:0:0: Notifying upper driver of completion (result 812) > ses 11:0:0:0: tag#0 0 sectors total, 32 bytes done. > ses 11:0:0:0: Wrong diagnostic page; asked for 7 got 0 > > As the command is failed with illegal request sense key, so the buffer > used In function 'ses_recv_diag' will be not updated and so it will > have all zero's. so the page_code will be zero and we observe below > wrong error message even though vSES device has failed the command > with illegal request error message and it has not returned any wrong > diagnostic page. > > sdev_printk(KERN_ERR, sdev, > "Wrong diagnostic page; asked for %d got %u\n", > page_code, recv_page_code); > > Thanks, > Sreekanth Hi Sreekanth, To me, we should fix ses module to check 00h List of Supported Diagnostic Pages first before ask for 07h. Add James in CC. Cheers, Jack Wang
Re: Help needed for a SCSI hang (SATA drives)
2017-03-07 1:54 GMT+01:00 V : > Hi, > > I am reaching out regarding a SCSI error handler issue, which we see > in our lab systems. > > Environment: Ubuntu 4.4.0-31-generic > > Issue: Write IOs are getting stuck in our system randomly. All drives > seen with the issue are all SATA drives. > Root cause: SCSI error handler is not woken up (or) it is up, but not > able to flush commands and hence the IOs get stuck. (as the requests > are not flushed out and host is not restarted) > > We have 6 instances seen till now. > > This is what we see. > 1) As part of testing our drives, we start lot of read/writes, along > with some user space utilities running to check the drive health. > 1) In our recent testing, we see lot of commands going through the > "abort scheduled" path. And we see that in between, for one of the > commands, the error handler is not woken up, and majority of > processes, which were writing, gets stalled. > 2) We are still trying to figure out what is causing this much number > of abort? Is it usual? Are there some other debugs, which I could > enable to get more information? We know these are user space commands > which are being aborted, but not sure which exact command it is for > now. > 3) I see the "abort scheduled" messages in almost all drives in all > systems, hence i dont believe it is a drive issue. > 4) I checked the host_failed and host_busy variables, both are set to > 1 in system 1. 2nd one is still alive, havent taken a crash dump yet. > 5) All drives seen with the issue are SATA drives. > 6) I have attached udevadm info of a drive which failed in system 2. > > Thanks in advance, > Viswesh > > > Logs > --- > System 1 > > [371546.605736] sd 9:0:0:0: scsi_block_when_processing_errors: rtn: 1 > [371546.606727] sd 9:0:0:0: scsi_block_when_processing_errors: rtn: 1 > [371546.607721] sd 9:0:0:0: scsi_block_when_processing_errors: rtn: 1 > [371546.618113] sd 9:0:0:0: [sg19] tag#20 abort scheduled > [371546.624039] sd 9:0:0:0: [sg19] tag#20 aborting command > [371546.624045] sd 9:0:0:0: [sg19] tag#20 cmd abort failed > [371546.624051] scsi host9: Waking error handler thread > [371546.624060] scsi host9: scsi_eh_9: waking up 0/1/1 > [371546.624081] sd 9:0:0:0: [sg19] tag#20 scsi_eh_9: flush finish cmd > [371546.624095] scsi host9: waking up host to restart > [371546.624098] scsi host9: scsi_eh_9: sleeping > > > [371546.635314] sd 8:0:0:0: [sg17] tag#13 abort scheduled > [371546.640031] sd 8:0:0:0: [sg17] tag#13 aborting command > [371546.640037] sd 8:0:0:0: [sg17] tag#13 cmd abort failed > [371546.640043] scsi host8: Waking error handler thread > [371546.640078] scsi host8: scsi_eh_8: waking up 0/1/1 > [371546.640098] sd 8:0:0:0: [sg17] tag#13 scsi_eh_8: flush finish cmd > [371546.640113] scsi host8: waking up host to restart > [371546.640117] scsi host8: scsi_eh_8: sleeping > > [371546.657269] sd 6:0:0:0: [sg12] tag#1 abort scheduled > [371546.664034] sd 6:0:0:0: [sg12] tag#1 aborting command > [371546.664040] sd 6:0:0:0: [sg12] tag#1 cmd abort failed > > Here we can see that, error handler is not woken up. And the entire > IO subsystem goes for a toss. > > [371777.594510] INFO: task md2_raid1:508 blocked for more than 120 seconds. > [371777.594571] Not tainted 4.4.0-31-generic #50~14.04.1-Ubuntu > [371777.594613] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [371777.594665] md2_raid1 D 883fed2afc780 508 2 0x > [371777.594673] 883fed2afc78 881fef0e8000 883fed21c4c0 > 883fed2b > [371777.594678] 883ff236e298 883ff236e000 883ff236e018 > 883ff236e018 > > By enabling more scsi logs(in a different system), including LL, we > get some more info ( I have enabled the full scsi levels for all > categories and it is still running) > > > System 2 > > [405197.171574] sd 5:0:0:0: [sg3] sg_write: count=3D88 > [405197.171577] sd 5:0:0:0: scsi_block_when_processing_errors: rtn: 1 > [405197.171581] sd 5:0:0:0: [sg3] sg_common_write: scsi > opcode=3D0x85, cmd_size=3D16 > [405197.171583] sd 5:0:0:0: [sg3] sg_start_req: dxfer_len=3D512 > [405197.171605] sd 5:0:0:0: [sg3] sg_link_reserve: size=3D512 > [405197.171623] sd 5:0:0:0: [sg3] sg_poll: res=3D0x104 > [405197.172648] sd 5:0:0:0: [sg3] sg_cmd_done: pack_id=3D0, res=3D0x0 > [405197.172701] sd 5:0:0:0: [sg3] sg_poll: res=3D0x145 > [405197.172710] sd 5:0:0:0: [sg3] sg_read: count=3D88 > [405197.172716] sd 5:0:0:0: [sg3] sg_finish_rem_req: res_used=3D1 > [405197.172721] sd 5:0:0:0: [sg3] sg_unlink_reserve: req->k_use_sg=3D1 > [405197.172756] sd 5:0:0:0: [sg3] sg_write: count=3D88 > [405197.172760] sd 5:0:0:0: scsi_block_when_processing_errors: rtn: 1 > [405197.172764] sd 5:0:0:0: [sg3] sg_common_write: scsi > opcode=3D0x85, cmd_size=3D16 > [405197.172767] sd 5:0:0:0: [sg3] sg_start_req: dxfer_len=3D512 > [405197.172774] sd 5:0:0:0: [sg3] sg_link_reserve: size=3D512 > [405197.172793] sd 5:0:0:0: [sg3] sg_poll: res=3D0x104 > [405197.173806] sd 5:0:0:0:
Re: [PATCH] pm8001: switch to pci_irq_alloc_vectors
On 01.02.2017 15:11, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/pm8001/pm8001_init.c | 35 ++-
> drivers/scsi/pm8001/pm8001_sas.h | 2 --
> 2 files changed, 14 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 9fc675f..417368c 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -888,7 +888,6 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
> *pm8001_ha)
> u32 i = 0, j = 0;
> u32 number_of_intr;
> int flag = 0;
> - u32 max_entry;
> int rc;
> static char intr_drvname[PM8001_MAX_MSIX_VEC][sizeof(DRV_NAME)+3];
>
> @@ -900,18 +899,14 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
> *pm8001_ha)
> flag &= ~IRQF_SHARED;
> }
>
> - max_entry = sizeof(pm8001_ha->msix_entries) /
> - sizeof(pm8001_ha->msix_entries[0]);
> - for (i = 0; i < max_entry ; i++)
> - pm8001_ha->msix_entries[i].entry = i;
> - rc = pci_enable_msix_exact(pm8001_ha->pdev, pm8001_ha->msix_entries,
> - number_of_intr);
> - pm8001_ha->number_of_intr = number_of_intr;
> - if (rc)
> + rc = pci_alloc_irq_vectors(pm8001_ha->pdev, number_of_intr,
> + number_of_intr, PCI_IRQ_MSIX);
> + if (rc < 0)
> return rc;
> + pm8001_ha->number_of_intr = number_of_intr;
>
> PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
> - "pci_enable_msix_exact request ret:%d no of intr %d\n",
> + "pci_alloc_irq_vectors request ret:%d no of intr %d\n",
> rc, pm8001_ha->number_of_intr));
>
> for (i = 0; i < number_of_intr; i++) {
> @@ -920,15 +915,15 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
> *pm8001_ha)
> pm8001_ha->irq_vector[i].irq_id = i;
> pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
>
> - rc = request_irq(pm8001_ha->msix_entries[i].vector,
> + rc = request_irq(pci_irq_vector(pm8001_ha->pdev, i),
> pm8001_interrupt_handler_msix, flag,
> intr_drvname[i], &(pm8001_ha->irq_vector[i]));
> if (rc) {
> for (j = 0; j < i; j++) {
> - free_irq(pm8001_ha->msix_entries[j].vector,
> + free_irq(pci_irq_vector(pm8001_ha->pdev, i),
> &(pm8001_ha->irq_vector[i]));
> }
> - pci_disable_msix(pm8001_ha->pdev);
> + pci_free_irq_vectors(pm8001_ha->pdev);
> break;
> }
> }
> @@ -1102,11 +1097,10 @@ static void pm8001_pci_remove(struct pci_dev *pdev)
>
> #ifdef PM8001_USE_MSIX
> for (i = 0; i < pm8001_ha->number_of_intr; i++)
> - synchronize_irq(pm8001_ha->msix_entries[i].vector);
> + synchronize_irq(pci_irq_vector(pdev, i));
> for (i = 0; i < pm8001_ha->number_of_intr; i++)
> - free_irq(pm8001_ha->msix_entries[i].vector,
> - &(pm8001_ha->irq_vector[i]));
> - pci_disable_msix(pdev);
> + free_irq(pci_irq_vector(pdev, i), &pm8001_ha->irq_vector[i]);
> + pci_free_irq_vectors(pdev);
> #else
> free_irq(pm8001_ha->irq, sha);
> #endif
> @@ -1152,11 +1146,10 @@ static int pm8001_pci_suspend(struct pci_dev *pdev,
> pm_message_t state)
> PM8001_CHIP_DISP->chip_soft_rst(pm8001_ha);
> #ifdef PM8001_USE_MSIX
> for (i = 0; i < pm8001_ha->number_of_intr; i++)
> - synchronize_irq(pm8001_ha->msix_entries[i].vector);
> + synchronize_irq(pci_irq_vector(pdev, i));
> for (i = 0; i < pm8001_ha->number_of_intr; i++)
> - free_irq(pm8001_ha->msix_entries[i].vector,
> - &(pm8001_ha->irq_vector[i]));
> - pci_disable_msix(pdev);
> + free_irq(pci_irq_vector(pdev, i), &pm8001_ha->irq_vector[i]);
> + pci_free_irq_vectors(pdev);
> #else
> free_irq(pm8001_ha->irq, sha);
> #endif
> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
> b/drivers/scsi/pm8001/pm8001_sas.h
> index 6628cc3..e81a8fa 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.h
> +++ b/drivers/scsi/pm8001/pm8001_sas.h
> @@ -521,8 +521,6 @@ struct pm8001_hba_info {
> struct pm8001_device*devices;
> struct pm8001_ccb_info *ccb_info;
> #ifdef PM8001_USE_MSIX
> - struct msix_entry msix_entries[PM8001_MAX_MSIX_VEC];
> - /*for msi-x interrupt*/
> int number_of_intr;/*will be used in remove()*/
> #endif
> #ifdef PM8001_USE_TASKLET
>
Looks good, thanks!
Acked-by: Jack Wang
Re: mvsas escalated kernel crash and ata mapping mvsas driver question
2017-01-26 12:53 GMT+01:00 Jelle de Jong :
> Beste Jack,
>
> I set the queue_depth to 1 and timeout to 300 for all SATA disk connected to
> the mvsas controller [ARC-1300ix-16].
>
> Does this mean that ata21 is mapped to /dev/sdq!
>
> root@sweeney:~# dmesg | grep ata21 | grep device
> [4.788568] sas: ata21: end_device-0:0:26: dev error handler
>
> root@sweeney:~# lsscsi -v | grep end_device-0:0:26
> dir: /sys/bus/scsi/devices/0:0:14:0
> [/sys/devices/pci:00/:00:1c.0/:08:00.0/host0/port-0:0/expander-0:0/port-0:0:26/end_device-0:0:26/target0:0:14/0:0:14:0]
>
> root@sweeney:~# lsscsi -v | grep 0:0:14:0
> [0:0:14:0] diskATA WDC WD1003FBYX-0 1V01 /dev/sdq
> dir: /sys/bus/scsi/devices/0:0:14:0
> [/sys/devices/pci:00/:00:1c.0/:08:00.0/host0/port-0:0/expander-0:0/port-0:0:26/end_device-0:0:26/target0:0:14/0:0:14:0]
>
> I added the following to my rc.local
>
> vim /etc/rc.local
>
> for disk in sd{c..r}; do
> echo deadline > /sys/block/$disk/queue/scheduler
> echo 0 > /sys/block/$disk/queue/iosched/front_merges
> echo 150 > /sys/block/$disk/queue/iosched/read_expire
> echo 1500 > /sys/block/$disk/queue/iosched/write_expire
> echo 1 > /sys/block/$disk/device/queue_depth;
> echo 300 > /sys/block/$disk/device/timeout;
> done
>
> I hope the performance impact of queue_depth = 1 is not to much
Yes, sdq maps to ata21.
Regards,
Jack
>
> Kind regards,
>
> Jelle de Jong
>
> On 26/01/17 11:17, Jack Wang wrote:
>>
>> 2017-01-26 10:51 GMT+01:00 Jelle de Jong :
>>>
>>> Hello everybody,
>>>
>>> I got a server that seemingly random gets kernel crashes, due to an
>>> escalation of events from most likely the mvsas based disk controller.
>>>
>>> The harddisk should be okay, I replaced a whole bunch to be sure, but the
>>> server does not get stable. I can not seem to figure out how to map for
>>> example ata21.00 to an disk so I can do a deep badblock check.
>>>
>>> I have to complete boot with kernel crash log saved with additional
>>> information.
>>>
>>> http://paste.debian.net/plainh/96325d89
>>>
>>> Can somebody take a look and maybe help?
>>>
>>>
>>> 08:00.0 SCSI storage controller: Areca Technology Corp. ARC-1300ix-16
>>> 16-Port PCI-Express to SAS Non-RAID Host Adapter (rev 02)
>>>
>>> Kind regards,
>>>
>>> Jelle de Jong
>>
>>
>> Your IO error seems related to NCQ, have you tried to disable NCQ?
>>
>> echo 1 > /sys/block/sdX/device/queue_depth
>>
>> Maybe try 4.10-rc5 is also a option?
>>
>> Regards,
>> Jack
>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mvsas escalated kernel crash and ata mapping mvsas driver question
2017-01-26 10:51 GMT+01:00 Jelle de Jong : > Hello everybody, > > I got a server that seemingly random gets kernel crashes, due to an > escalation of events from most likely the mvsas based disk controller. > > The harddisk should be okay, I replaced a whole bunch to be sure, but the > server does not get stable. I can not seem to figure out how to map for > example ata21.00 to an disk so I can do a deep badblock check. > > I have to complete boot with kernel crash log saved with additional > information. > > http://paste.debian.net/plainh/96325d89 > > Can somebody take a look and maybe help? > > > 08:00.0 SCSI storage controller: Areca Technology Corp. ARC-1300ix-16 > 16-Port PCI-Express to SAS Non-RAID Host Adapter (rev 02) > > Kind regards, > > Jelle de Jong Your IO error seems related to NCQ, have you tried to disable NCQ? echo 1 > /sys/block/sdX/device/queue_depth Maybe try 4.10-rc5 is also a option? Regards, Jack > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 121531] Adaptec 7805H SAS HBA (pm80xx): hangs when writing >80MB at once
Hi Viswas, Thanks for update. Good to know MicroSemi is still working on it! Could you update the Maintainer file about your guys working email address? Regards, Jack 2016-07-08 6:47 GMT+02:00 Viswas G : > Patch set for pm80xx is pending for the last 3 quarters. > We will submit those soon with all the buf fixes and performance > tuning changes. > > Regards, > Viswas G > > On Thu, Jul 7, 2016 at 10:04 PM, wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=121531 >> >> --- Comment #14 from Jack Wang --- >> The changes are huge, hard to do it, without help from MicroSemi/PMCs side. >> And I don't have hardware to test. >> >> I've asked developer from MicroSemi to upsteam their changes, but >> sadly no reply. >> >> 2016-07-07 17:36 GMT+02:00 : >>> https://bugzilla.kernel.org/show_bug.cgi?id=121531 >>> >>> --- Comment #13 from Martin von Wittich --- >>> Yup, the Debian installation worked and seems to work fine so far. I >>> manually >>> installed the pm80xx-1.4.0-11068-debian64.deb package in the target system >>> while I was still in the installer by chrooting to /target; then I added >>> "pm80xx" to /etc/initramfs/modules (without that update-initramfs wouldn't >>> add >>> the pm80xx module, I'm not really sure why). >>> >>> After booting the system, I've succcessfully written ~500 GB of /dev/zero >>> data >>> into a file on an MD raid consisting of both of the disks. No error >>> messages in >>> the dmesg either. >>> >>> Can you include those missing changes into the official kernel, or how can >>> we >>> resolve this bug? We'll ask to the customer if we can keep the server for an >>> additional two weeks for testing, so if you need me to test builds, let me >>> know. >>> >>> -- >>> You are receiving this mail because: >>> You are on the CC list for the bug. >> >> -- >> You are receiving this mail because: >> You are the assignee for the bug. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SCSI] pm80xx: Phy settings support for motherboard controller.
2016-04-13 13:24 GMT+02:00 Dan Carpenter :
> Hello Anand Kumar Santhanam,
>
> The patch 279094079a44: "[SCSI] pm80xx: Phy settings support for
> motherboard controller." from Sep 18, 2013, leads to the following
> static checker warning:
>
> drivers/scsi/pm8001/pm80xx_hwi.c:4554 mpi_set_phy_profile_req()
> error: uninitialized symbol 'tag'.
>
Thanks for reporting, attached patch should fix the warning.
From e30af801d9ee9979b2a7a2af815cb395c2255a09 Mon Sep 17 00:00:00 2001
From: Jack Wang
Date: Thu, 14 Apr 2016 14:38:57 +0200
Subject: [PATCH] pm80xx: avoid to use invalid tag
Fix static checker warning:
drivers/scsi/pm8001/pm80xx_hwi.c:4554 mpi_set_phy_profile_req()
error: uninitialized symbol 'tag'.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Jack Wang
---
drivers/scsi/pm8001/pm80xx_hwi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c b/drivers/scsi/pm8001/pm80xx_hwi.c
index eb4fee6..a3c1c08 100644
--- a/drivers/scsi/pm8001/pm80xx_hwi.c
+++ b/drivers/scsi/pm8001/pm80xx_hwi.c
@@ -4548,8 +4548,10 @@ void mpi_set_phy_profile_req(struct pm8001_hba_info *pm8001_ha,
memset(&payload, 0, sizeof(payload));
rc = pm8001_tag_alloc(pm8001_ha, &tag);
- if (rc)
+ if (rc) {
PM8001_FAIL_DBG(pm8001_ha, pm8001_printk("Invalid tag\n"));
+ return;
+ }
circularQ = &pm8001_ha->inbnd_q_tbl[0];
payload.tag = cpu_to_le32(tag);
payload.ppc_phyid = (((operation & 0xF) << 8) | (phyid & 0xFF));
@@ -4590,8 +4592,10 @@ void pm8001_set_phy_profile_single(struct pm8001_hba_info *pm8001_ha,
memset(&payload, 0, sizeof(payload));
rc = pm8001_tag_alloc(pm8001_ha, &tag);
- if (rc)
+ if (rc) {
PM8001_INIT_DBG(pm8001_ha, pm8001_printk("Invalid tag"));
+ return;
+ }
circularQ = &pm8001_ha->inbnd_q_tbl[0];
opc = OPC_INB_SET_PHY_PROFILE;
--
1.9.1
[PATCH 3/3] mvsas: remove SCSI host before detaching from SAS transport
commit cff549e4860f ("scsi: proper state checking and module refcount
handling in scsi_device_get")
the reference count of scsi device was changed, which could lead to
when rmmod with at least on drive attached, SCSI error handle will
run into infinite loop, and lockup the system.
Fix it by remove scsi host first, this way scsi core will not send
commands down after detaching SAS transport.
This is a follow up fix for Benjamin's fix for pm80xx.
See also:
http://www.spinics.net/lists/linux-scsi/msg90088.html
Signed-off-by: Jack Wang
---
drivers/scsi/mvsas/mv_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
index e2d555c..1960d95 100644
--- a/drivers/scsi/mvsas/mv_init.c
+++ b/drivers/scsi/mvsas/mv_init.c
@@ -641,9 +641,9 @@ static void mvs_pci_remove(struct pci_dev *pdev)
tasklet_kill(&((struct mvs_prv_info *)sha->lldd_ha)->mv_tasklet);
#endif
+ scsi_remove_host(mvi->shost);
sas_unregister_ha(sha);
sas_remove_host(mvi->shost);
- scsi_remove_host(mvi->shost);
MVS_CHIP_DISP->interrupt_disable(mvi);
free_irq(mvi->pdev->irq, sha);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] aic94xx: remove SCSI host before detaching from SAS transport
commit cff549e4860f ("scsi: proper state checking and module refcount
handling in scsi_device_get")
the reference count of scsi device was changed, which could lead to
when rmmod with at least on drive attached, SCSI error handle will
run into infinite loop, and lockup the system.
Fix it by remove scsi host first, this way scsi core will not send
commands down after detaching SAS transport.
This is a follow up fix for Benjamin's fix for pm80xx.
See also:
http://www.spinics.net/lists/linux-scsi/msg90088.html
Signed-off-by: Jack Wang
---
drivers/scsi/aic94xx/aic94xx_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/aic94xx/aic94xx_init.c
b/drivers/scsi/aic94xx/aic94xx_init.c
index f6c336b..4b56976 100644
--- a/drivers/scsi/aic94xx/aic94xx_init.c
+++ b/drivers/scsi/aic94xx/aic94xx_init.c
@@ -704,10 +704,10 @@ static int asd_unregister_sas_ha(struct asd_ha_struct
*asd_ha)
{
int err;
+ scsi_remove_host(asd_ha->sas_ha.core.shost);
err = sas_unregister_ha(&asd_ha->sas_ha);
sas_remove_host(asd_ha->sas_ha.core.shost);
- scsi_remove_host(asd_ha->sas_ha.core.shost);
scsi_host_put(asd_ha->sas_ha.core.shost);
kfree(asd_ha->sas_ha.sas_phy);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] isci: remove SCSI host before detaching from SAS transport
commit cff549e4860f ("scsi: proper state checking and module refcount
handling in scsi_device_get")
, the reference count of scsi device was changed, which could lead to when
rmmod with at least on drive attached, SCSI error handle will
run into infinite loop, and lockup the system.
Fix it by remove scsi host first, this way scsi core will not send
commands down after detaching SAS transport.
This is a follow up fix for Benjamin's fix for pm80xx.
See also:
http://www.spinics.net/lists/linux-scsi/msg90088.html
Signed-off-by: Jack Wang
---
drivers/scsi/isci/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
index 0dfcabe..9e0d069 100644
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isci/init.c
@@ -272,11 +272,11 @@ static void isci_unregister(struct isci_host *isci_host)
if (!isci_host)
return;
+ shost = to_shost(isci_host);
+ scsi_remove_host(shost);
sas_unregister_ha(&isci_host->sas_ha);
- shost = to_shost(isci_host);
sas_remove_host(shost);
- scsi_remove_host(shost);
scsi_host_put(shost);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pm80xx: remove the SCSI host before detaching from SAS transport
2015-10-30 21:01 GMT+01:00 Benjamin Rood :
> Previously, when this module was unloaded via 'rmmod' with at least one
> drive attached, the SCSI error handler thread would become stuck in an
> infinite recovery loop and lockup the system, necessitating a reboot.
>
> Once the SAS layer is detached, the driver will fail any subsequent
> commands since the target devices are removed. However, removing the
> SCSI host generates a SYNCHRONIZE CACHE (10) command, which was failed
> and left the error handler no method of recovery.
>
> This patch simply removes the SCSI host first so that no more commands
> can come down, prior to cleaning up the SAS layer. Note that the stack
> is built up with the SCSI host first, and then the SAS layer. Perhaps
> it should be reversed for symmetry, so that commands cannot be sent to
> the pm80xx driver prior to attaching the SAS layer?
>
> What was really strange about this bug was that it was introduced at
> commit cff549e4860f ("[SCSI]: proper state checking and module refcount
> handling in scsi_device_get"). This commit appears to tinker with how
> the reference counting is performed for SCSI device objects. My theory
> is that prior to this commit, the refcount for a device object was
> blindly incremented at some point during the teardown process which
> coincidentially made the device stick around during the procedure, which
> also coincidentially made any commands sent to the driver not fail
> (since the device was technically still "there"). After this commit was
> applied, my theory is the refcount for the device object is not being
> incremented at a specific point anymore, which makes the device go away,
> and thus made the pm80xx driver fail any subsequent commands.
>
> You may also want to see the following for more details:
>
> [1] http://www.spinics.net/lists/linux-scsi/msg37208.html
> [2] http://marc.info/?l=linux-scsi&m=144416476406993&w=2
>
> Signed-off-by: Benjamin Rood
> ---
> drivers/scsi/pm8001/pm8001_init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index bdc624f..b1b2dd7 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -1096,10 +1096,10 @@ static void pm8001_pci_remove(struct pci_dev *pdev)
> struct pm8001_hba_info *pm8001_ha;
> int i, j;
> pm8001_ha = sha->lldd_ha;
> + scsi_remove_host(pm8001_ha->shost);
> sas_unregister_ha(sha);
> sas_remove_host(pm8001_ha->shost);
> list_del(&pm8001_ha->list);
> - scsi_remove_host(pm8001_ha->shost);
> PM8001_CHIP_DISP->interrupt_disable(pm8001_ha, 0xFF);
> PM8001_CHIP_DISP->chip_soft_rst(pm8001_ha);
>
> --
> 2.4.3
>
Thanks for digging it down. Looks good to me.
Seems other libsas based driver all affected, maybe we should also fix them?
Christoph (cc-ed), could you share your opinion about this fix, as the
commit cff549e4860f is from you?
Regards,
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] pm80xx: avoid a panic if MSI(X) interrupts are disabled
2015-10-30 15:53 GMT+01:00 Benjamin Rood :
> If MSI(X) interrupts are disabled via the kernel command line
> (pci=nomsi), the pm8001 driver will kernel panic because it does not
> detect that MSI interrupts are disabled and will soldier on and attempt to
> configure MSI interrupts anyways. This leads to a kernel panic, most
> likely because a required data structure is not available down the
> line. Using the pci_msi_enabled() function in order to detect if MSI
> interrupts are enabled before configuring them resolves this issue and
> avoids a kernel panic when the module is loaded. Additionally, the
> irq_vector structure must be initialized when legacy interrupts are
> being used otherwise legacy interrupts will simply not function and
> result in another panic.
>
> Signed-off-by: Benjamin Rood
> ---
> drivers/scsi/pm8001/pm8001_init.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index ab99984..bdc624f 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -482,7 +482,8 @@ static struct pm8001_hba_info *pm8001_pci_alloc(struct
> pci_dev *pdev,
>
> #ifdef PM8001_USE_TASKLET
> /* Tasklet for non msi-x interrupt handler */
> - if ((!pdev->msix_cap) || (pm8001_ha->chip_id == chip_8001))
> + if ((!pdev->msix_cap || !pci_msi_enabled())
> + || (pm8001_ha->chip_id == chip_8001))
> tasklet_init(&pm8001_ha->tasklet[0], pm8001_tasklet,
> (unsigned long)&(pm8001_ha->irq_vector[0]));
> else
> @@ -951,7 +952,7 @@ static u32 pm8001_request_irq(struct pm8001_hba_info
> *pm8001_ha)
> pdev = pm8001_ha->pdev;
>
> #ifdef PM8001_USE_MSIX
> - if (pdev->msix_cap)
> + if (pdev->msix_cap && pci_msi_enabled())
> return pm8001_setup_msix(pm8001_ha);
> else {
> PM8001_INIT_DBG(pm8001_ha,
> @@ -962,6 +963,8 @@ static u32 pm8001_request_irq(struct pm8001_hba_info
> *pm8001_ha)
>
> intx:
> /* initialize the INT-X interrupt */
> + pm8001_ha->irq_vector[0].irq_id = 0;
> + pm8001_ha->irq_vector[0].drv_inst = pm8001_ha;
> rc = request_irq(pdev->irq, pm8001_interrupt_handler_intx,
> IRQF_SHARED,
> DRV_NAME, SHOST_TO_SAS_HA(pm8001_ha->shost));
> return rc;
> @@ -1112,7 +1115,8 @@ static void pm8001_pci_remove(struct pci_dev *pdev)
> #endif
> #ifdef PM8001_USE_TASKLET
> /* For non-msix and msix interrupts */
> - if ((!pdev->msix_cap) || (pm8001_ha->chip_id == chip_8001))
> + if ((!pdev->msix_cap || !pci_msi_enabled()) ||
> + (pm8001_ha->chip_id == chip_8001))
> tasklet_kill(&pm8001_ha->tasklet[0]);
> else
> for (j = 0; j < PM8001_MAX_MSIX_VEC; j++)
> @@ -1161,7 +1165,8 @@ static int pm8001_pci_suspend(struct pci_dev *pdev,
> pm_message_t state)
> #endif
> #ifdef PM8001_USE_TASKLET
> /* For non-msix and msix interrupts */
> - if ((!pdev->msix_cap) || (pm8001_ha->chip_id == chip_8001))
> + if ((!pdev->msix_cap || !pci_msi_enabled()) ||
> + (pm8001_ha->chip_id == chip_8001))
> tasklet_kill(&pm8001_ha->tasklet[0]);
> else
> for (j = 0; j < PM8001_MAX_MSIX_VEC; j++)
> @@ -1231,7 +1236,8 @@ static int pm8001_pci_resume(struct pci_dev *pdev)
> goto err_out_disable;
> #ifdef PM8001_USE_TASKLET
> /* Tasklet for non msi-x interrupt handler */
> - if ((!pdev->msix_cap) || (pm8001_ha->chip_id == chip_8001))
> + if ((!pdev->msix_cap || !pci_msi_enabled()) ||
> + (pm8001_ha->chip_id == chip_8001))
> tasklet_init(&pm8001_ha->tasklet[0], pm8001_tasklet,
> (unsigned long)&(pm8001_ha->irq_vector[0]));
> else
> --
> 2.4.3
>
Reviewed-by: Jack Wang
Thanks
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/8] pm80xx: wait a minimum of 500ms before issuing commands to SPCv
2015-10-30 15:53 GMT+01:00 Benjamin Rood :
> The documentation for the 8070 and 8072 SPCv chip explicitly states that
> a minimum of 500ms must elapse before issuing commands, otherwise the
> SPCv may not process them and the firmware may get into an unrecoverable
> state requiring a reboot. While the Linux guys will probably think this
> is 'racy', it is called out in the chip documentation and inserting this
> delay makes power management function properly.
>
> Signed-off-by: Benjamin Rood
> ---
> drivers/scsi/pm8001/pm8001_init.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index a0e55d4..ab99984 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -1190,6 +1190,7 @@ static int pm8001_pci_resume(struct pci_dev *pdev)
> int rc;
> u8 i = 0, j;
> u32 device_state;
> + u32 wait_count;
> DECLARE_COMPLETION_ONSTACK(completion);
> pm8001_ha = sha->lldd_ha;
> device_state = pdev->current_state;
> @@ -1243,6 +1244,17 @@ static int pm8001_pci_resume(struct pci_dev *pdev)
> for (i = 1; i < pm8001_ha->number_of_intr; i++)
> PM8001_CHIP_DISP->interrupt_enable(pm8001_ha, i);
> }
> +
> + if (pm8001_ha->chip_id == chip_8070 ||
> + pm8001_ha->chip_id == chip_8072) {
> + wait_count = 500;
> + do {
> + mdelay(1);
> + } while (--wait_count);
> + }
> +
> + /* Spin up the PHYs */
> +
> pm8001_ha->flags = PM8001F_RUN_TIME;
> for (i = 0; i < pm8001_ha->chip->n_phy; i++) {
> pm8001_ha->phy[i].enable_completion = &completion;
> --
> 2.4.3
>
Could we simply mdelay(500) instead the loop?
Also better to add a comment around.
Thanks,
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] pm80xx: do not examine registers for iButton feature if ATTO adapter
2015-10-30 15:53 GMT+01:00 Benjamin Rood :
> ATTO adapters do not support this feature. If the firmware fails to be
> ready, it should not check the examined registers in order to examine
> the state of the feature in order to prevent undefined behavior.
>
> Signed-off-by: Benjamin Rood
> ---
> drivers/scsi/pm8001/pm80xx_hwi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 29c548b..eb4fee6 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -1267,6 +1267,8 @@ pm80xx_chip_soft_rst(struct pm8001_hba_info *pm8001_ha)
> /* check iButton feature support for motherboard controller */
> if (pm8001_ha->pdev->subsystem_vendor !=
> PCI_VENDOR_ID_ADAPTEC2 &&
> + pm8001_ha->pdev->subsystem_vendor !=
> + PCI_VENDOR_ID_ATTO &&
> pm8001_ha->pdev->subsystem_vendor != 0) {
> ibutton0 = pm8001_cr32(pm8001_ha, 0,
> MSGU_HOST_SCRATCH_PAD_6);
> --
> 2.4.3
>
Reviewed-by: Jack Wang
Thanks
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] pm80xx: set PHY profiles for ATTO 12Gb SAS controllers
+ pm8001_get_external_phy_settings(pm8001_ha, &phycfg_ext);
> + pm8001_get_phy_mask(pm8001_ha, &phymask);
> +
> + for (i = 0; i < pm8001_ha->chip->n_phy; i++) {
> + if (phymask & (1 << i)) {/* Internal PHY */
> + pm8001_set_phy_profile_single(pm8001_ha, i,
> + sizeof(phycfg_int) / sizeof(u32),
> + (u32 *)&phycfg_int);
> +
> + } else { /* External PHY */
> + pm8001_set_phy_profile_single(pm8001_ha, i,
> + sizeof(phycfg_ext) / sizeof(u32),
> + (u32 *)&phycfg_ext);
> + }
> + }
> +
> + return 0;
> +}
> +
> /**
> * pm8001_configure_phy_settings : Configures PHY settings based on vendor
> ID.
> * @pm8001_ha : our hba.
> @@ -740,6 +865,11 @@ static int pm8001_configure_phy_settings(struct
> pm8001_hba_info *pm8001_ha)
> {
> switch (pm8001_ha->pdev->subsystem_vendor) {
> case PCI_VENDOR_ID_ATTO:
> + if (pm8001_ha->pdev->device == 0x0042) /* 6Gb */
> + return 0;
> + else
> + return
> pm8001_set_phy_settings_ven_117c_12G(pm8001_ha);
> +
> case PCI_VENDOR_ID_ADAPTEC2:
> case 0:
> return 0;
> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
> b/drivers/scsi/pm8001/pm8001_sas.h
> index 9fa9705..6628cc3 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.h
> +++ b/drivers/scsi/pm8001/pm8001_sas.h
> @@ -710,6 +710,8 @@ int pm80xx_set_thermal_config(struct pm8001_hba_info
> *pm8001_ha);
> int pm8001_bar4_shift(struct pm8001_hba_info *pm8001_ha, u32 shiftValue);
> void pm8001_set_phy_profile(struct pm8001_hba_info *pm8001_ha,
> u32 length, u8 *buf);
> +void pm8001_set_phy_profile_single(struct pm8001_hba_info *pm8001_ha,
> + u32 phy, u32 length, u32 *buf);
> int pm80xx_bar4_shift(struct pm8001_hba_info *pm8001_ha, u32 shiftValue);
> ssize_t pm80xx_get_fatal_dump(struct device *cdev,
> struct device_attribute *attr, char *buf);
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 9a389f1..29c548b 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -4576,6 +4576,38 @@ void pm8001_set_phy_profile(struct pm8001_hba_info
> *pm8001_ha,
> }
> PM8001_INIT_DBG(pm8001_ha, pm8001_printk("phy settings completed\n"));
> }
> +
> +void pm8001_set_phy_profile_single(struct pm8001_hba_info *pm8001_ha,
> + u32 phy, u32 length, u32 *buf)
> +{
> + u32 tag, opc;
> + int rc, i;
> + struct set_phy_profile_req payload;
> + struct inbound_queue_table *circularQ;
> +
> + memset(&payload, 0, sizeof(payload));
> +
> + rc = pm8001_tag_alloc(pm8001_ha, &tag);
> + if (rc)
> + PM8001_INIT_DBG(pm8001_ha, pm8001_printk("Invalid tag"));
> +
> + circularQ = &pm8001_ha->inbnd_q_tbl[0];
> + opc = OPC_INB_SET_PHY_PROFILE;
> +
> + payload.tag = cpu_to_le32(tag);
> + payload.ppc_phyid = (((SAS_PHY_ANALOG_SETTINGS_PAGE & 0xF) << 8)
> + | (phy & 0xFF));
> +
> + for (i = 0; i < length; i++)
> + payload.reserved[i] = cpu_to_le32(*(buf + i));
> +
> + rc = pm8001_mpi_build_cmd(pm8001_ha, circularQ, opc, &payload, 0);
> + if (rc)
> + pm8001_tag_free(pm8001_ha, tag);
> +
> + PM8001_INIT_DBG(pm8001_ha,
> + pm8001_printk("PHY %d settings applied", phy));
> +}
> const struct pm8001_dispatch pm8001_80xx_dispatch = {
> .name = "pmc80xx",
> .chip_init = pm80xx_chip_init,
> --
> 2.4.3
>
Reviewed-by: Jack Wang
Thanks
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] pm80xx: add support for ATTO devices during SAS address initiailization
2015-11-02 8:53 GMT+01:00 Hannes Reinecke :
> On 10/30/2015 03:53 PM, Benjamin Rood wrote:
>> ATTO SAS controllers retrieve the SAS address from the NVRAM in a location
>> different from non-ATTO PMC Sierra SAS controllers. This patch makes the
>> necessary adjustments in order to retrieve the SAS address on these types
>> of adapters.
>>
>> Signed-off-by: Benjamin Rood
>> ---
>> drivers/scsi/pm8001/pm8001_init.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/scsi/pm8001/pm8001_init.c
>> b/drivers/scsi/pm8001/pm8001_init.c
>> index feaf504..fdbfab6 100644
>> --- a/drivers/scsi/pm8001/pm8001_init.c
>> +++ b/drivers/scsi/pm8001/pm8001_init.c
>> @@ -636,6 +636,11 @@ static void pm8001_init_sas_add(struct pm8001_hba_info
>> *pm8001_ha)
>> payload.minor_function = 0;
>> payload.length = 128;
>> }
>> + } else if ((pm8001_ha->chip_id == chip_8070 ||
>> + pm8001_ha->chip_id == chip_8072) &&
>> + pm8001_ha->pdev->subsystem_vendor == PCI_VENDOR_ID_ATTO) {
>> + payload.minor_function = 4;
>> + payload.length = 4096;
>> } else {
>> payload.minor_function = 1;
>> payload.length = 4096;
>> @@ -662,6 +667,11 @@ static void pm8001_init_sas_add(struct pm8001_hba_info
>> *pm8001_ha)
>> else if (deviceid == 0x0042)
>> pm8001_ha->sas_addr[j] =
>> payload.func_specific[0x010 + i];
>> + } else if ((pm8001_ha->chip_id == chip_8070 ||
>> + pm8001_ha->chip_id == chip_8072) &&
>> + pm8001_ha->pdev->subsystem_vendor == PCI_VENDOR_ID_ATTO) {
>> + pm8001_ha->sas_addr[j] =
>> + payload.func_specific[0x010 + i];
>> } else
>> pm8001_ha->sas_addr[j] =
>> payload.func_specific[0x804 + i];
>>
> The indentation is a bit skewed here.
> Other than that:
>
> Reviewed-by: Hannes Reinecke
>
> Cheers,
>
> Hannes
Agree with Hannes :), please fix this if you post V2.
Reviewed-by: Jack Wang
Thanks
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] pm80xx: add ATTO PCI IDs to pm8001_pci_table
2015-10-30 15:53 GMT+01:00 Benjamin Rood :
> These PCI IDs allow the pm8001 driver to load against ATTO 12Gb SAS
> controllers that use PMC Sierra 8070 and PMC Sierra 8072 SAS chips.
>
> Signed-off-by: Benjamin Rood
> ---
> drivers/scsi/pm8001/pm8001_init.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 2106ac3..feaf504 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -1181,6 +1181,20 @@ static struct pci_device_id pm8001_pci_table[] = {
> PCI_VENDOR_ID_ADAPTEC2, 0x0808, 0, 0, chip_8077 },
> { PCI_VENDOR_ID_ADAPTEC2, 0x8074,
> PCI_VENDOR_ID_ADAPTEC2, 0x0404, 0, 0, chip_8074 },
> + { PCI_VENDOR_ID_ATTO, 0x8070,
> + PCI_VENDOR_ID_ATTO, 0x0070, 0, 0, chip_8070 },
> + { PCI_VENDOR_ID_ATTO, 0x8070,
> + PCI_VENDOR_ID_ATTO, 0x0071, 0, 0, chip_8070 },
> + { PCI_VENDOR_ID_ATTO, 0x8072,
> + PCI_VENDOR_ID_ATTO, 0x0072, 0, 0, chip_8072 },
> + { PCI_VENDOR_ID_ATTO, 0x8072,
> + PCI_VENDOR_ID_ATTO, 0x0073, 0, 0, chip_8072 },
> + { PCI_VENDOR_ID_ATTO, 0x8070,
> + PCI_VENDOR_ID_ATTO, 0x0080, 0, 0, chip_8070 },
> + { PCI_VENDOR_ID_ATTO, 0x8072,
> + PCI_VENDOR_ID_ATTO, 0x0081, 0, 0, chip_8072 },
> + { PCI_VENDOR_ID_ATTO, 0x8072,
> + PCI_VENDOR_ID_ATTO, 0x0082, 0, 0, chip_8072 },
> {} /* terminate list */
> };
>
> --
> 2.4.3
>
Reviewed-by: Jack Wang
Thanks
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] pm80xx: add support for PMC Sierra 8070 and PMC Sierra 8072 SAS controllers
2015-10-30 15:53 GMT+01:00 Benjamin Rood :
> These SAS controllers support speeds up to 12Gb.
>
> Signed-off-by: Benjamin Rood
> ---
> drivers/scsi/pm8001/pm8001_defs.h | 2 ++
> drivers/scsi/pm8001/pm8001_init.c | 4 +++-
> drivers/scsi/pm8001/pm8001_sas.h | 4 +++-
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_defs.h
> b/drivers/scsi/pm8001/pm8001_defs.h
> index f14ec6e..199527d 100644
> --- a/drivers/scsi/pm8001/pm8001_defs.h
> +++ b/drivers/scsi/pm8001/pm8001_defs.h
> @@ -51,6 +51,8 @@ enum chip_flavors {
> chip_8076,
> chip_8077,
> chip_8006,
> + chip_8070,
> + chip_8072
> };
>
> enum phy_speed {
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 8c094fd..2106ac3 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -58,6 +58,8 @@ static const struct pm8001_chip_info pm8001_chips[] = {
> [chip_8076] = {0, 16, &pm8001_80xx_dispatch,},
> [chip_8077] = {0, 16, &pm8001_80xx_dispatch,},
> [chip_8006] = {0, 16, &pm8001_80xx_dispatch,},
> + [chip_8070] = {0, 8, &pm8001_80xx_dispatch,},
> + [chip_8072] = {0, 16, &pm8001_80xx_dispatch,},
> };
> static int pm8001_id;
>
> @@ -1234,7 +1236,7 @@ MODULE_AUTHOR("Anand Kumar Santhanam
> ");
> MODULE_AUTHOR("Sangeetha Gnanasekaran ");
> MODULE_AUTHOR("Nikith Ganigarakoppal ");
> MODULE_DESCRIPTION(
> - "PMC-Sierra PM8001/8006/8081/8088/8089/8074/8076/8077 "
> + "PMC-Sierra
> PM8001/8006/8081/8088/8089/8074/8076/8077/8070/8072 "
> "SAS/SATA controller driver");
> MODULE_VERSION(DRV_VERSION);
> MODULE_LICENSE("GPL");
> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
> b/drivers/scsi/pm8001/pm8001_sas.h
> index e2e97db..9fa9705 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.h
> +++ b/drivers/scsi/pm8001/pm8001_sas.h
> @@ -106,7 +106,9 @@ do {\
> #define DEV_IS_EXPANDER(type) ((type == SAS_EDGE_EXPANDER_DEVICE) || (type
> == SAS_FANOUT_EXPANDER_DEVICE))
> #define IS_SPCV_12G(dev) ((dev->device == 0X8074)\
> || (dev->device == 0X8076) \
> - || (dev->device == 0X8077))
> + || (dev->device == 0X8077) \
> + || (dev->device == 0X8070) \
> + || (dev->device == 0X8072))
>
> #define PM8001_NAME_LENGTH 32/* generic length of strings */
> extern struct list_head hba_list;
> --
> 2.4.3
>
Reviewed-by: Jack Wang
Thanks
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] pm80xx: configure PHY settings based on subsystem vendor ID
Reviewed-by: Jack Wang
Thanks
Jack
2015-10-30 15:53 GMT+01:00 Benjamin Rood :
> Previuosly, all PMC Sierra 80xx controllers are assumed to be a
> motherboard controller, except if the subsystem vendor ID was equal to
> PCI_VENDOR_ID_ADAPTEC. The driver then attempts to load PHY settings
> from NVRAM. While this may be correct behavior for most controllers, it
> does not work with Adaptec and ATTO controllers since they do not store
> PHY settings in NVRAM and choose to use either custom PHY settings or chip
> defaults. Loading random values from NVRAM may cause the controllers to
> malfunction in this edge case.
>
> Signed-off-by: Benjamin Rood
> ---
> drivers/scsi/pm8001/pm8001_init.c | 26 --
> 1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 5c0356f..8c094fd 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -720,6 +720,23 @@ static int pm8001_get_phy_settings_info(struct
> pm8001_hba_info *pm8001_ha)
> return 0;
> }
>
> +/**
> + * pm8001_configure_phy_settings : Configures PHY settings based on vendor
> ID.
> + * @pm8001_ha : our hba.
> + */
> +static int pm8001_configure_phy_settings(struct pm8001_hba_info *pm8001_ha)
> +{
> + switch (pm8001_ha->pdev->subsystem_vendor) {
> + case PCI_VENDOR_ID_ATTO:
> + case PCI_VENDOR_ID_ADAPTEC2:
> + case 0:
> + return 0;
> +
> + default:
> + return pm8001_get_phy_settings_info(pm8001_ha);
> + }
> +}
> +
> #ifdef PM8001_USE_MSIX
> /**
> * pm8001_setup_msix - enable MSI-X interrupt
> @@ -902,12 +919,9 @@ static int pm8001_pci_probe(struct pci_dev *pdev,
>
> pm8001_init_sas_add(pm8001_ha);
> /* phy setting support for motherboard controller */
> - if (pdev->subsystem_vendor != PCI_VENDOR_ID_ADAPTEC2 &&
> - pdev->subsystem_vendor != 0) {
> - rc = pm8001_get_phy_settings_info(pm8001_ha);
> - if (rc)
> - goto err_out_shost;
> - }
> + if (pm8001_configure_phy_settings(pm8001_ha))
> + goto err_out_shost;
> +
> pm8001_post_sas_ha_init(shost, chip);
> rc = sas_register_ha(SHOST_TO_SAS_HA(shost));
> if (rc)
> --
> 2.4.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pm80xx: Don't override ts->stat on IO_OPEN_CNX_ERROR_HW_RESOURCE_BUSY
2015-08-17 15:04 GMT+02:00 Johannes Thumshirn :
> In case XXX returns with a status of IO_OPEN_CNX_ERROR_HW_RESOURCE_BUSY
> ts->stat gets set to SAS_OPEN_REJECT but a missing 'break' statement causes a
> fallthrough to the default handler of the switch statement overriding ts->stat
> to SAS_DEV_NO_RESPONSE.
>
> Signed-off-by: Johannes Thumshirn
Thanks, please feel free to add:
Acked-by: Jack Wang
> ---
> drivers/scsi/pm8001/pm8001_hwi.c | 1 +
> drivers/scsi/pm8001/pm80xx_hwi.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index 96dcc09..d0feec5 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -2642,6 +2642,7 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> ts->resp = SAS_TASK_COMPLETE;
> ts->stat = SAS_OPEN_REJECT;
> ts->open_rej_reason = SAS_OREJ_RSVD_RETRY;
> + break;
> default:
> PM8001_IO_DBG(pm8001_ha,
> pm8001_printk("Unknown status 0x%x\n", status));
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 05cce46..18d4ac4 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -2314,6 +2314,7 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> ts->resp = SAS_TASK_COMPLETE;
> ts->stat = SAS_OPEN_REJECT;
> ts->open_rej_reason = SAS_OREJ_RSVD_RETRY;
> + break;
> default:
> PM8001_IO_DBG(pm8001_ha,
> pm8001_printk("Unknown status 0x%x\n", status));
> --
> 2.5.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MAINTAINERS: update email for pm8001
Company has policy to use company email address, so update my email address to company address. Signed-off-by: Jack Wang --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a226416..c82f964 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8040,7 +8040,7 @@ S:Supported F: drivers/scsi/pmcraid.* PMC SIERRA PM8001 DRIVER -M: xjtu...@gmail.com +M: Jack Wang M: lindar_...@usish.com L: pmc...@pmcs.com L: linux-scsi@vger.kernel.org -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] pm80xx: Driver updates
2015-07-29 8:27 GMT+02:00 : > From: Viswas G > > This patch set contains bug fixes for pm80xx driver. > Please consider these patches for next kernel release. > > Viswas G (8): > pm80xx: Updated link rate > pm80xx: Corrected device state changes in I_T_Nexus_Reset > pm80xx: Update For Thermal Page Code > pm80xx: Fix for Incorrect DMA Unmapping of SG List > pm80xx: Remove unnecessary phy disconnect while link error > pm80xx: Add PORT RECOVERY TIMEOUT support > pm80xx: Handling Invalid SSP Response frame > pm80xx: Bump pm80xx driver version to 0.1.38 > > drivers/scsi/pm8001/pm8001_defs.h |1 + > drivers/scsi/pm8001/pm8001_hwi.c |4 + > drivers/scsi/pm8001/pm8001_sas.c | 15 - > drivers/scsi/pm8001/pm8001_sas.h | 12 +++- > drivers/scsi/pm8001/pm80xx_hwi.c | 111 > +++-- > drivers/scsi/pm8001/pm80xx_hwi.h |5 +- > 6 files changed, 112 insertions(+), 36 deletions(-) > For the whole patchset: Reviewed-by: Jack Wang PS: company policy requests to use the email address of the company, please cc me to above address next time, I will send a patch to update my email in MAINTAINERS file. Thanks Jack -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pm80xx: Added pm8006 controller support
Sorry for delay, I missed this patch.
Acked-by: Jack Wang
2015-02-12 7:34 GMT+01:00 Suresh Thiagarajan :
> Added the pm8006 controller id in pci table
>
> Signed-off-by: Suresh Thiagarajan
> Signed-off-by: Viswas G
> ---
> drivers/scsi/pm8001/pm8001_defs.h |3 ++-
> drivers/scsi/pm8001/pm8001_init.c |5 -
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_defs.h
> b/drivers/scsi/pm8001/pm8001_defs.h
> index 74a4bb9..dc4233b 100644
> --- a/drivers/scsi/pm8001/pm8001_defs.h
> +++ b/drivers/scsi/pm8001/pm8001_defs.h
> @@ -49,7 +49,8 @@ enum chip_flavors {
> chip_8019,
> chip_8074,
> chip_8076,
> - chip_8077
> + chip_8077,
> + chip_8006,
> };
>
> enum phy_speed {
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 691..e1aee58 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -57,6 +57,7 @@ static const struct pm8001_chip_info pm8001_chips[] = {
> [chip_8074] = {0, 8, &pm8001_80xx_dispatch,},
> [chip_8076] = {0, 16, &pm8001_80xx_dispatch,},
> [chip_8077] = {0, 16, &pm8001_80xx_dispatch,},
> + [chip_8006] = {0, 16, &pm8001_80xx_dispatch,},
> };
> static int pm8001_id;
>
> @@ -1108,6 +1109,8 @@ err_out_enable:
> */
> static struct pci_device_id pm8001_pci_table[] = {
> { PCI_VDEVICE(PMC_Sierra, 0x8001), chip_8001 },
> + { PCI_VDEVICE(PMC_Sierra, 0x8006), chip_8006 },
> + { PCI_VDEVICE(ADAPTEC2, 0x8006), chip_8006 },
> { PCI_VDEVICE(ATTO, 0x0042), chip_8001 },
> /* Support for SPC/SPCv/SPCve controllers */
> { PCI_VDEVICE(ADAPTEC2, 0x8001), chip_8001 },
> @@ -1218,7 +1221,7 @@ MODULE_AUTHOR("Anand Kumar Santhanam
> ");
> MODULE_AUTHOR("Sangeetha Gnanasekaran ");
> MODULE_AUTHOR("Nikith Ganigarakoppal ");
> MODULE_DESCRIPTION(
> - "PMC-Sierra PM8001/8081/8088/8089/8074/8076/8077 "
> + "PMC-Sierra PM8001/8006/8081/8088/8089/8074/8076/8077 "
> "SAS/SATA controller driver");
> MODULE_VERSION(DRV_VERSION);
> MODULE_LICENSE("GPL");
> --
> 1.7.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/11] scsi: don't force tagged_supported in drivers
2014-11-04 8:54 GMT+01:00 Christoph Hellwig :
> Now that we also get proper values in cmd->request->tag for untagged
> commands, there is no need to force tagged_supported to on in drivers
> that need host-wide tags.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/fnic/fnic_main.c | 2 --
> drivers/scsi/libsas/sas_scsi_host.c | 1 -
> diff --git a/drivers/scsi/libsas/sas_scsi_host.c
> b/drivers/scsi/libsas/sas_scsi_host.c
> index 56d698a..89e8b68 100644
> --- a/drivers/scsi/libsas/sas_scsi_host.c
> +++ b/drivers/scsi/libsas/sas_scsi_host.c
> @@ -945,7 +945,6 @@ int sas_slave_configure(struct scsi_device *scsi_dev)
> SAS_DPRINTK("device %llx, LUN %llx doesn't support "
> "TCQ\n", SAS_ADDR(dev->sas_addr),
> scsi_dev->lun);
> - scsi_dev->tagged_supported = 0;
> scsi_adjust_queue_depth(scsi_dev, 1);
> }
Hi Christoph,
The commit msg doesn't match for above, is it intentional ?
Regards,
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 85151] pm80xx + 7805H + HP SAS port expander = mpi_smp_completion 2604:smp IO status 0x2 and sas: expander ... discovery failed(0xffffffa6)
Cc pmchba maillist. 2014-09-25 18:20 GMT+02:00 : > https://bugzilla.kernel.org/show_bug.cgi?id=85151 > > --- Comment #6 from Jack Wang --- > Ah, I forgot no bsg node if expander discover failed:( > HBA SAS address is 0, does not matter. > > From my point, this bug clear SMP protocol related, you could report to PMC, I > think they will offer help. > > -- > You are receiving this mail because: > You are watching the assignee of the bug. > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pm8001: Update MAINTAINERS list
If it works, then I'm fine with this, thanks. Please add my ack if needed: Acked-by: Jack Wang 2014-07-31 14:53 GMT+02:00 Suresh Thiagarajan : > > > On Wed, Jul 30, 2014 at 5:42 PM, James Bottomley > wrote: >> On Wed, 2014-07-30 at 17:37 +0530, Suresh Thiagarajan wrote: >>> From: Suresh Thiagarajan >>> >>> Update pmcs mail list for pm8001 driver support >>> >>> Signed-off-by: Suresh Thiagarajan >>> --- >>> MAINTAINERS |1 + >>> 1 files changed, 1 insertions(+), 0 deletions(-) >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 3f2e171..a63259c 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -6987,6 +6987,7 @@ F: drivers/scsi/pmcraid.* >>> PMC SIERRA PM8001 DRIVER >>> M: xjtu...@gmail.com >>> M: lindar_...@usish.com >>> +L: pmc...@pmcs.com >> >> This list doesn't appear to work: > > This is fixed now. My apologies for the inconvenience. > > -Suresh >> >> : host smtp.pmc-sierra.com[216.241.235.148] said: 550 5.1.1 >> : Recipient address rejected: User unknown in local >> recipient table (in reply to RCPT TO command) >> >> James >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 RESEND 18/23] pm8001: Use pci_enable_msix_exact() instead of pci_enable_msix()
Hi Alex,
Looks Ok for me.
Please feel free to add my:
Reviewed-by: Jack Wang
Thanks,
Jack
2014-07-26 10:33 GMT+02:00 Alexander Gordeev :
> On Wed, Jul 16, 2014 at 08:05:22PM +0200, Alexander Gordeev wrote:
>> As result of deprecation of MSI-X/MSI enablement functions
>> pci_enable_msix() and pci_enable_msi_block() all drivers
>> using these two interfaces need to be updated to use the
>> new pci_enable_msi_range() or pci_enable_msi_exact()
>> and pci_enable_msix_range() or pci_enable_msix_exact()
>> interfaces.
>
> Hi Jack, Lindar,
>
> Could you please review this patch?
>
> Thanks!
>
>> Signed-off-by: Alexander Gordeev
>> Cc: xjtu...@gmail.com
>> Cc: lindar_...@usish.com
>> Cc: linux-scsi@vger.kernel.org
>> Cc: linux-...@vger.kernel.org
>> ---
>> drivers/scsi/pm8001/pm8001_init.c | 39
>> +++--
>> 1 files changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/scsi/pm8001/pm8001_init.c
>> b/drivers/scsi/pm8001/pm8001_init.c
>> index e837ece..4057c24 100644
>> --- a/drivers/scsi/pm8001/pm8001_init.c
>> +++ b/drivers/scsi/pm8001/pm8001_init.c
>> @@ -729,34 +729,35 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
>> *pm8001_ha)
>> sizeof(pm8001_ha->msix_entries[0]);
>> for (i = 0; i < max_entry ; i++)
>> pm8001_ha->msix_entries[i].entry = i;
>> - rc = pci_enable_msix(pm8001_ha->pdev, pm8001_ha->msix_entries,
>> + rc = pci_enable_msix_exact(pm8001_ha->pdev, pm8001_ha->msix_entries,
>> number_of_intr);
>> pm8001_ha->number_of_intr = number_of_intr;
>> - if (!rc) {
>> - PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
>> - "pci_enable_msix request ret:%d no of intr %d\n",
>> - rc, pm8001_ha->number_of_intr));
>> + if (rc)
>> + return rc;
>>
>> + PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
>> + "pci_enable_msix_exact request ret:%d no of intr %d\n",
>> + rc, pm8001_ha->number_of_intr));
>>
>> - for (i = 0; i < number_of_intr; i++) {
>> - snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
>> - DRV_NAME"%d", i);
>> - pm8001_ha->irq_vector[i].irq_id = i;
>> - pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
>> + for (i = 0; i < number_of_intr; i++) {
>> + snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
>> + DRV_NAME"%d", i);
>> + pm8001_ha->irq_vector[i].irq_id = i;
>> + pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
>>
>> - rc = request_irq(pm8001_ha->msix_entries[i].vector,
>> - pm8001_interrupt_handler_msix, flag,
>> - intr_drvname[i], &(pm8001_ha->irq_vector[i]));
>> - if (rc) {
>> - for (j = 0; j < i; j++)
>> - free_irq(
>> - pm8001_ha->msix_entries[j].vector,
>> + rc = request_irq(pm8001_ha->msix_entries[i].vector,
>> + pm8001_interrupt_handler_msix, flag,
>> + intr_drvname[i], &(pm8001_ha->irq_vector[i]));
>> + if (rc) {
>> + for (j = 0; j < i; j++) {
>> + free_irq(pm8001_ha->msix_entries[j].vector,
>> &(pm8001_ha->irq_vector[i]));
>> - pci_disable_msix(pm8001_ha->pdev);
>> - break;
>> }
>> + pci_disable_msix(pm8001_ha->pdev);
>> + break;
>> }
>> }
>> +
>> return rc;
>> }
>> #endif
>> --
>> 1.7.7.6
>>
>
> --
> Regards,
> Alexander Gordeev
> agord...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] pm8001: Resend previous patches
On 07/09/2014 01:47 PM, Suresh Thiagarajan wrote: > From: Suresh Thiagarajan > > Updated comments for pm8001: honor return value > Remaining patches are resend > > Suresh Thiagarajan (8): > pm8001: Fix to remove null pointer checks that could never happen > pm8001: Cleaning up uninitialized variables > pm8001: Fix hibernation issue > pm8001: Fix potential null pointer dereference and memory leak. > pm8001: clean bitmap management functions > pm8001: honor return value > pm8001: add a new spinlock to protect the CCB > pm8001: more fixes to honor return value > > drivers/scsi/pm8001/pm8001_ctl.c |5 +++- > drivers/scsi/pm8001/pm8001_hwi.c | 45 +++-- > drivers/scsi/pm8001/pm8001_init.c | 48 +++- > drivers/scsi/pm8001/pm8001_sas.c | 38 ++--- > drivers/scsi/pm8001/pm8001_sas.h |2 +- > drivers/scsi/pm8001/pm80xx_hwi.c | 48 > +++-- > 6 files changed, 125 insertions(+), 61 deletions(-) > The whole patch set looks good to me. Thanks for resending. Acked-by: Jack Wang -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi: pm8001: pm80xx_hwi.c: Cleaning up variable is set more than once
Thanks Rickard, >From my point of view, looks good, but I'd like to get review from Anand (cc-ed). Anand, could you share your opinion? Regards, Jack On 06/25/2014 04:01 PM, Rickard Strandqvist wrote: > A struct member variable is set to different values without having used in > between. > > This was found using a static code analysis program called cppcheck > > Signed-off-by: Rickard Strandqvist > --- > drivers/scsi/pm8001/pm80xx_hwi.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c > b/drivers/scsi/pm8001/pm80xx_hwi.c > index d70587f..2698227 100644 > --- a/drivers/scsi/pm8001/pm80xx_hwi.c > +++ b/drivers/scsi/pm8001/pm80xx_hwi.c > @@ -249,7 +249,6 @@ moreData: > sprintf(pm8001_ha-> > forensic_info.data_buf.direct_data, > "%08x ", 4); > - pm8001_ha->forensic_info.data_buf.read_len = 0x; > pm8001_ha->forensic_info.data_buf.direct_len = 0; > pm8001_ha->forensic_info.data_buf.direct_offset = 0; > pm8001_ha->forensic_info.data_buf.read_len = 0; > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi: pm8001: pm80xx_hwi.c: Cleaning up uninitialized variables
Looks good, thanks Rickard.
Acked-by: Jack Wang
On 06/01/2014 03:13 PM, Rickard Strandqvist wrote:
> There is a risk that the variable will be used without being initialized.
>
> This was largely found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/scsi/pm8001/pm80xx_hwi.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index d70587f..add019b 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -948,7 +948,7 @@ static int
> pm80xx_get_encrypt_info(struct pm8001_hba_info *pm8001_ha)
> {
> u32 scratch3_value;
> - int ret;
> + int ret = -1;
>
> /* Read encryption status from SCRATCH PAD 3 */
> scratch3_value = pm8001_cr32(pm8001_ha, 0, MSGU_SCRATCH_PAD_3);
> @@ -982,7 +982,7 @@ pm80xx_get_encrypt_info(struct pm8001_hba_info *pm8001_ha)
> pm8001_ha->encrypt_info.status = 0x;
> pm8001_ha->encrypt_info.cipher_mode = 0;
> pm8001_ha->encrypt_info.sec_mode = 0;
> - return 0;
> + ret = 0;
> } else if ((scratch3_value & SCRATCH_PAD3_ENC_MASK) ==
> SCRATCH_PAD3_ENC_DIS_ERR) {
> pm8001_ha->encrypt_info.status =
> @@ -1004,7 +1004,6 @@ pm80xx_get_encrypt_info(struct pm8001_hba_info
> *pm8001_ha)
> scratch3_value, pm8001_ha->encrypt_info.cipher_mode,
> pm8001_ha->encrypt_info.sec_mode,
> pm8001_ha->encrypt_info.status));
> - ret = -1;
> } else if ((scratch3_value & SCRATCH_PAD3_ENC_MASK) ==
>SCRATCH_PAD3_ENC_ENA_ERR) {
>
> @@ -1028,7 +1027,6 @@ pm80xx_get_encrypt_info(struct pm8001_hba_info
> *pm8001_ha)
> scratch3_value, pm8001_ha->encrypt_info.cipher_mode,
> pm8001_ha->encrypt_info.sec_mode,
> pm8001_ha->encrypt_info.status));
> - ret = -1;
> }
> return ret;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] pm80xx: Fix hibernation issue
Thanks Brad for testing and fixing.
Acked-by: Jack Wang
On 06/19/2014 05:13 PM, bradley.gr...@gmail.com wrote:
> From: Bradley Grove
>
> During hibernation, the HBA firmware may lose power and forget the device
> id info. This causes the HBA to reject IO upon resume. The fix is
> to call the libsas power management routines to make the domain device
> forgetful.
>
> This fixes bug 76681: https://bugzilla.kernel.org/show_bug.cgi?id=76681
>
> Signed-off-by: Bradley Grove
> ---
> drivers/scsi/pm8001/pm8001_init.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index c4f31b21..86cf03a 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -957,6 +957,7 @@ static int pm8001_pci_suspend(struct pci_dev *pdev,
> pm_message_t state)
> int i, j;
> u32 device_state;
> pm8001_ha = sha->lldd_ha;
> + sas_suspend_ha(sha);
> flush_workqueue(pm8001_wq);
> scsi_block_requests(pm8001_ha->shost);
> if (!pdev->pm_cap) {
> @@ -1006,6 +1007,7 @@ static int pm8001_pci_resume(struct pci_dev *pdev)
> int rc;
> u8 i = 0, j;
> u32 device_state;
> + DECLARE_COMPLETION_ONSTACK(completion);
> pm8001_ha = sha->lldd_ha;
> device_state = pdev->current_state;
>
> @@ -1026,7 +1028,7 @@ static int pm8001_pci_resume(struct pci_dev *pdev)
> rc = pci_go_44(pdev);
> if (rc)
> goto err_out_disable;
> -
> + sas_prep_resume_ha(sha);
> /* chip soft rst only for spc */
> if (pm8001_ha->chip_id == chip_8001) {
> PM8001_CHIP_DISP->chip_soft_rst(pm8001_ha);
> @@ -1058,7 +1060,13 @@ static int pm8001_pci_resume(struct pci_dev *pdev)
> for (i = 1; i < pm8001_ha->number_of_intr; i++)
> PM8001_CHIP_DISP->interrupt_enable(pm8001_ha, i);
> }
> - scsi_unblock_requests(pm8001_ha->shost);
> + pm8001_ha->flags = PM8001F_RUN_TIME;
> + for (i = 0; i < pm8001_ha->chip->n_phy; i++) {
> + pm8001_ha->phy[i].enable_completion = &completion;
> + PM8001_CHIP_DISP->phy_start_req(pm8001_ha, i);
> + wait_for_completion(&completion);
> + }
> + sas_resume_ha(sha);
> return 0;
>
> err_out_disable:
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pm8001: Fix potential null pointer dereference and memory leak.
On 06/17/2014 01:15 PM, Maurizio Lombardi wrote:
> The pm8001_get_phy_settings_info() function does not check
> the kzalloc() return value and does not free the allocated memory.
>
> Signed-off-by: Maurizio Lombardi
Looks good, thanks
Acked-by: Jack Wang
> ---
> drivers/scsi/pm8001/pm8001_init.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index c4f31b21..e90c89f 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -677,7 +677,7 @@ static void pm8001_init_sas_add(struct pm8001_hba_info
> *pm8001_ha)
> * pm8001_get_phy_settings_info : Read phy setting values.
> * @pm8001_ha : our hba.
> */
> -void pm8001_get_phy_settings_info(struct pm8001_hba_info *pm8001_ha)
> +static int pm8001_get_phy_settings_info(struct pm8001_hba_info *pm8001_ha)
> {
>
> #ifdef PM8001_READ_VPD
> @@ -691,11 +691,15 @@ void pm8001_get_phy_settings_info(struct
> pm8001_hba_info *pm8001_ha)
> payload.offset = 0;
> payload.length = 4096;
> payload.func_specific = kzalloc(4096, GFP_KERNEL);
> + if (!payload.func_specific)
> + return -ENOMEM;
> /* Read phy setting values from flash */
> PM8001_CHIP_DISP->get_nvmd_req(pm8001_ha, &payload);
> wait_for_completion(&completion);
> pm8001_set_phy_profile(pm8001_ha, sizeof(u8), payload.func_specific);
> + kfree(payload.func_specific);
> #endif
> + return 0;
> }
>
> #ifdef PM8001_USE_MSIX
> @@ -879,8 +883,11 @@ static int pm8001_pci_probe(struct pci_dev *pdev,
> pm8001_init_sas_add(pm8001_ha);
> /* phy setting support for motherboard controller */
> if (pdev->subsystem_vendor != PCI_VENDOR_ID_ADAPTEC2 &&
> - pdev->subsystem_vendor != 0)
> - pm8001_get_phy_settings_info(pm8001_ha);
> + pdev->subsystem_vendor != 0) {
> + rc = pm8001_get_phy_settings_info(pm8001_ha);
> + if (rc)
> + goto err_out_shost;
> + }
> pm8001_post_sas_ha_init(shost, chip);
> rc = sas_register_ha(SHOST_TO_SAS_HA(shost));
> if (rc)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pm80xx : Fix missing NULL pointer checks and memory leaks
On 05/09/2014 08:01 AM, Suresh Thiagarajan wrote: > Checking return value for the memory allocattion and freeing it > while exiting the function > > Signed-off-by: Viswas G > Signed-off-by: Suresh Thiagarajan > --- > drivers/scsi/pm8001/pm8001_ctl.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/scsi/pm8001/pm8001_ctl.c > b/drivers/scsi/pm8001/pm8001_ctl.c > index 28b4e81..5f68571 100644 > --- a/drivers/scsi/pm8001/pm8001_ctl.c > +++ b/drivers/scsi/pm8001/pm8001_ctl.c > @@ -395,6 +395,8 @@ static ssize_t pm8001_ctl_bios_version_show(struct device > *cdev, > payload.offset = 0; > payload.length = 4096; > payload.func_specific = kzalloc(4096, GFP_KERNEL); > + if (!payload.func_specific) > + return -ENOMEM; > PM8001_CHIP_DISP->get_nvmd_req(pm8001_ha, &payload); > wait_for_completion(&completion); > virt_addr = pm8001_ha->memoryMap.region[NVMD].virt_ptr; > @@ -402,6 +404,7 @@ static ssize_t pm8001_ctl_bios_version_show(struct device > *cdev, > bios_index++) > str += sprintf(str, "%c", > *((u8 *)((u8 *)virt_addr+bios_index))); > + kfree(payload.func_specific); > return str - buf; > } > static DEVICE_ATTR(bios_version, S_IRUGO, pm8001_ctl_bios_version_show, > NULL); > Thanks, looks good. Acked-by: Jack Wang -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/22] pm8001: Use pci_enable_msix_range()
On 02/04/2014 12:17 PM, Alexander Gordeev wrote:
> As result of deprecation of MSI-X/MSI enablement functions
> pci_enable_msix() and pci_enable_msi_block() all drivers
> using these two interfaces need to be updated to use the
> new pci_enable_msi_range() and pci_enable_msix_range()
> interfaces.
>
> Signed-off-by: Alexander Gordeev
> Cc: xjtu...@gmail.com
> Cc: lindar_...@usish.com
> Cc: linux-scsi@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> ---
> drivers/scsi/pm8001/pm8001_init.c | 47
> +++--
> 1 files changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index efffbb9..2d4b06e 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -724,34 +724,35 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
> *pm8001_ha)
> sizeof(pm8001_ha->msix_entries[0]);
> for (i = 0; i < max_entry ; i++)
> pm8001_ha->msix_entries[i].entry = i;
> - rc = pci_enable_msix(pm8001_ha->pdev, pm8001_ha->msix_entries,
> - number_of_intr);
> + rc = pci_enable_msix_range(pm8001_ha->pdev, pm8001_ha->msix_entries,
> + number_of_intr, number_of_intr);
> pm8001_ha->number_of_intr = number_of_intr;
> - if (!rc) {
> - PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
> - "pci_enable_msix request ret:%d no of intr %d\n",
> - rc, pm8001_ha->number_of_intr));
> -
> -
> - for (i = 0; i < number_of_intr; i++) {
> - snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
> - DRV_NAME"%d", i);
> - pm8001_ha->irq_vector[i].irq_id = i;
> - pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
> -
> - rc = request_irq(pm8001_ha->msix_entries[i].vector,
> - pm8001_interrupt_handler_msix, flag,
> - intr_drvname[i], &(pm8001_ha->irq_vector[i]));
> - if (rc) {
> - for (j = 0; j < i; j++)
> - free_irq(
> - pm8001_ha->msix_entries[j].vector,
> + if (rc < 0)
> + return rc;
> +
> + PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
> + "pci_enable_msix request ret:%d no of intr %d\n",
> + rc, pm8001_ha->number_of_intr));
> +
> + for (i = 0; i < number_of_intr; i++) {
> + snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
> + DRV_NAME"%d", i);
> + pm8001_ha->irq_vector[i].irq_id = i;
> + pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
> +
> + rc = request_irq(pm8001_ha->msix_entries[i].vector,
> + pm8001_interrupt_handler_msix, flag,
> + intr_drvname[i], &(pm8001_ha->irq_vector[i]));
> + if (rc) {
> + for (j = 0; j < i; j++) {
> + free_irq(pm8001_ha->msix_entries[j].vector,
> &(pm8001_ha->irq_vector[i]));
> - pci_disable_msix(pm8001_ha->pdev);
> - break;
> }
> + pci_disable_msix(pm8001_ha->pdev);
> + break;
> }
> }
> +
> return rc;
> }
> #endif
>
Thanks, looks fine.
Acked-by: Jack Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/22] pm8001: Fix invalid success return when request_irq() failed
On 02/04/2014 12:17 PM, Alexander Gordeev wrote:
> When enabling MSI-X if a call to request_irq() failed
> pm8001_setup_msix() still returns success. This udate
> fixes the described misbehaviour.
>
> Signed-off-by: Alexander Gordeev
> Cc: xjtu...@gmail.com
> Cc: lindar_...@usish.com
> Cc: linux-scsi@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> ---
> drivers/scsi/pm8001/pm8001_init.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 73a120d..efffbb9 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -739,9 +739,10 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
> *pm8001_ha)
> pm8001_ha->irq_vector[i].irq_id = i;
> pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
>
> - if (request_irq(pm8001_ha->msix_entries[i].vector,
> + rc = request_irq(pm8001_ha->msix_entries[i].vector,
> pm8001_interrupt_handler_msix, flag,
> - intr_drvname[i], &(pm8001_ha->irq_vector[i]))) {
> + intr_drvname[i], &(pm8001_ha->irq_vector[i]));
> + if (rc) {
> for (j = 0; j < i; j++)
> free_irq(
> pm8001_ha->msix_entries[j].vector,
>
Thanks, looks fine.
Acked-by: Jack Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] pm80xx: Spinlock fix
On 01/16/2014 11:15 AM, Viswas G wrote: > From dfaae38ba7b6b7260fb3209d2dd12d70f0a8e306 Mon Sep 17 00:00:00 2001 > From: Suresh Thiagarajan > Date: Thu, 16 Jan 2014 15:26:21 +0530 > Subject: [PATCH V2] pm80xx: Spinlock fix > > spin_lock_irqsave for the HBA lock is called in one function where flag > is local to that function. Another function is called from the first > function where lock has to be released using spin_unlock_irqrestore for > calling task_done of libsas. In the second function also flag is declared > and used. For calling task_done there is no need to enable the irq. So > instead of using spin_lock_irqsave and spin_unlock_irqrestore, spin_lock > and spin_unlock is used now. This also avoids passing the flags across all > the functions where HBA lock is being used. Also removed redundant code. > > > Reported-by: Jason Seba > Signed-off-by: Oleg Nesterov > Signed-off-by: Suresh Thiagarajan > Signed-off-by: Viswas G Looks good to me, thanks. Acked-by: Jack Wang > --- > drivers/scsi/pm8001/pm8001_hwi.c | 84 > ++ > drivers/scsi/pm8001/pm8001_sas.h | 12 + > drivers/scsi/pm8001/pm80xx_hwi.c | 84 > ++ > 3 files changed, 38 insertions(+), 142 deletions(-) > > diff --git a/drivers/scsi/pm8001/pm8001_hwi.c > b/drivers/scsi/pm8001/pm8001_hwi.c > index 46ace52..d6a4b17 100644 > --- a/drivers/scsi/pm8001/pm8001_hwi.c > +++ b/drivers/scsi/pm8001/pm8001_hwi.c > @@ -2502,11 +2502,7 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha, > void *piomb) > IO_OPEN_CNX_ERROR_IT_NEXUS_LOSS); > ts->resp = SAS_TASK_UNDELIVERED; > ts->stat = SAS_QUEUE_FULL; > - pm8001_ccb_task_free(pm8001_ha, t, ccb, tag); > - mb();/*in order to force CPU ordering*/ > - spin_unlock_irq(&pm8001_ha->lock); > - t->task_done(t); > - spin_lock_irq(&pm8001_ha->lock); > + pm8001_ccb_task_free_done(pm8001_ha, t, ccb, tag); > return; > } > break; > @@ -2522,11 +2518,7 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha, > void *piomb) > IO_OPEN_CNX_ERROR_IT_NEXUS_LOSS); > ts->resp = SAS_TASK_UNDELIVERED; > ts->stat = SAS_QUEUE_FULL; > - pm8001_ccb_task_free(pm8001_ha, t, ccb, tag); > - mb();/*ditto*/ > - spin_unlock_irq(&pm8001_ha->lock); > - t->task_done(t); > - spin_lock_irq(&pm8001_ha->lock); > + pm8001_ccb_task_free_done(pm8001_ha, t, ccb, tag); > return; > } > break; > @@ -2550,11 +2542,7 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha, > void *piomb) > IO_OPEN_CNX_ERROR_STP_RESOURCES_BUSY); > ts->resp = SAS_TASK_UNDELIVERED; > ts->stat = SAS_QUEUE_FULL; > - pm8001_ccb_task_free(pm8001_ha, t, ccb, tag); > - mb();/* ditto*/ > - spin_unlock_irq(&pm8001_ha->lock); > - t->task_done(t); > - spin_lock_irq(&pm8001_ha->lock); > + pm8001_ccb_task_free_done(pm8001_ha, t, ccb, tag); > return; > } > break; > @@ -2617,11 +2605,7 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha, > void *piomb) > IO_DS_NON_OPERATIONAL); > ts->resp = SAS_TASK_UNDELIVERED; > ts->stat = SAS_QUEUE_FULL; > - pm8001_ccb_task_free(pm8001_ha, t, ccb, tag); > - mb();/*ditto*/ > - spin_unlock_irq(&pm8001_ha->lock); > - t->task_done(t); > - spin_lock_irq(&pm8001_ha->lock); > + pm8001_ccb_task_free_done(pm8001_ha, t, ccb, tag); > return; > } > break; > @@ -2641,11 +2625,7 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha, > void *piomb) > IO_DS_IN_ERROR); > ts->resp = SAS_TASK_UNDELIVERED; > ts->stat = SAS_QUEUE_FULL; > - pm8001_ccb_task_free(pm8001_ha, t, ccb, tag); > - mb();/*ditto*/
Re: [PATCH] pm80xx: Spinlock fix
On 12/23/2013 03:55 PM, Jason Seba wrote:
> Why is this considered dangerous? I put some thought into it and
> couldn't find any obvious reason why it wouldn't work, but I also
> couldn't find any other drivers that work this way. Is there a
> particular reason to avoid doing it this way?
>
If you use global flags, you may change interrupt state depends on context.
> On Mon, Dec 23, 2013 at 8:45 AM, Suresh Thiagarajan
> wrote:
>>
>>
>> -Original Message-
>> From: Jack Wang [mailto:xjtu...@gmail.com]
>> Sent: Monday, December 23, 2013 7:03 PM
>> To: Tomas Henzl; Viswas G
>> Cc: linux-scsi@vger.kernel.org; jason.seb...@gmail.com;
>> jbottom...@parallels.com; Vasanthalakshmi Tharmarajan; Suresh Thiagarajan
>> Subject: Re: [PATCH] pm80xx: Spinlock fix
>>
>> On 12/23/2013 02:07 PM, Tomas Henzl wrote:
>>> On 12/18/2013 12:28 PM, Viswas G wrote:
>>>> From 9338d4bc92b23b4c283f9bd6812646ab74866a40 Mon Sep 17 00:00:00
>>>> 2001
>>>> From: Suresh Thiagarajan
>>>> Date: Mon, 16 Dec 2013 21:15:20 +0530
>>>> Subject: [PATCH] pm80xx: Spinlock fix
>>>>
>>>> spin_unlock was used instead of spin_unlock_irqrestore. To fix this
>>>> lock_flags per-adapter is added and used across all the places where
>>>> pm8001_ha->lock is used.
>>>
>>> I think this could have been fixed but just using spin_unlock_irqsave
>>> instead of spin_unlock_irq why the change to global lock_flags? I'm not a
>>> spinlock expert, but is this safe?
>>>
>> Agree with Tomas, it's dangerous to change to global lock_flags.
>>
>> Have you reproduce the bug reported from Jason, and verify the patch?
>> I think better just to change the spin_lock_irq to spin_lock_irqsave if that
>> is the cause.
>>
>> Suresh: We could not reproduce this issue and Jason(in CC) also could not
>> reproduce it for now. spin_lock_irqsave and spin_unlock_irqrestore were
>> called from multiple functions. Earlier flags was declared as a local
>> variable wherever spinlock was used. This was not correct since irq
>> information was saved in one function's flag which is a local to that
>> function and restored in other function where again flags was declared as
>> local variable to that function. So the data stored in flags while irq save
>> was not used while restoring. Since we have lock per card, we are
>> associating flag also per card for that lock.
>> -Suresh
>>
>> Jack
>>>>
>>>> Reported-by: Jason Seba
>>>> Signed-off-by: Suresh Thiagarajan
>>>> Signed-off-by: Viswas G
>>>> ---
>>>> drivers/scsi/pm8001/pm8001_hwi.c | 158
>>>> ++
>>>> drivers/scsi/pm8001/pm8001_sas.c | 50 ++--
>>>> drivers/scsi/pm8001/pm8001_sas.h |1 +
>>>> drivers/scsi/pm8001/pm80xx_hwi.c | 69 ++---
>>>> 4 files changed, 160 insertions(+), 118 deletions(-)
>>>>
>>>> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
>>>> b/drivers/scsi/pm8001/pm8001_hwi.c
>>>> index 0a1296a..3901c40 100644
>>>> --- a/drivers/scsi/pm8001/pm8001_hwi.c
>>>> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
>>>> @@ -411,7 +411,6 @@ static void mpi_set_phys_g3_with_ssc(struct
>>>> pm8001_hba_info *pm8001_ha,
>>>> u32 SSCbit)
>>>> {
>>>> u32 value, offset, i;
>>>> -unsigned long flags;
>>>>
>>>> #define SAS2_SETTINGS_LOCAL_PHY_0_3_SHIFT_ADDR 0x0003 #define
>>>> SAS2_SETTINGS_LOCAL_PHY_4_7_SHIFT_ADDR 0x0004 @@ -425,10 +424,10
>>>> @@ static void mpi_set_phys_g3_with_ssc(struct pm8001_hba_info *pm8001_ha,
>>>> * Using shifted destination address 0x3_:0x1074 + 0x4000*N (N=0:3)
>>>> * Using shifted destination address 0x4_:0x1074 + 0x4000*(N-4)
>>>> (N=4:7)
>>>> */
>>>> -spin_lock_irqsave(&pm8001_ha->lock, flags);
>>>> +spin_lock_irqsave(&pm8001_ha->lock, pm8001_ha->lock_flags);
>>>> if (-1 == pm8001_bar4_shift(pm8001_ha,
>>>> SAS2_SETTINGS_LOCAL_PHY_0_3_SHIFT_ADDR)) {
>>>> -spin_unlock_irqrestore(&pm8001_ha->lock, flags);
>>>> +spin_unlock_irqrestore(&pm8001_ha->lock,
>>>> pm8001_ha->lock_flags);
>>>> return;
>>&g
Re: [PATCH] pm80xx: Spinlock fix
On 12/23/2013 02:07 PM, Tomas Henzl wrote:
> On 12/18/2013 12:28 PM, Viswas G wrote:
>> From 9338d4bc92b23b4c283f9bd6812646ab74866a40 Mon Sep 17 00:00:00 2001
>> From: Suresh Thiagarajan
>> Date: Mon, 16 Dec 2013 21:15:20 +0530
>> Subject: [PATCH] pm80xx: Spinlock fix
>>
>> spin_unlock was used instead of spin_unlock_irqrestore. To fix this
>> lock_flags per-adapter is added and used across all the places where
>> pm8001_ha->lock is used.
>
> I think this could have been fixed but just using spin_unlock_irqsave instead
> of spin_unlock_irq
> why the change to global lock_flags? I'm not a spinlock expert, but is this
> safe?
>
Agree with Tomas, it's dangerous to change to global lock_flags.
Have you reproduce the bug reported from Jason, and verify the patch?
I think better just to change the spin_lock_irq to spin_lock_irqsave if
that is the cause.
Jack
>>
>> Reported-by: Jason Seba
>> Signed-off-by: Suresh Thiagarajan
>> Signed-off-by: Viswas G
>> ---
>> drivers/scsi/pm8001/pm8001_hwi.c | 158
>> ++
>> drivers/scsi/pm8001/pm8001_sas.c | 50 ++--
>> drivers/scsi/pm8001/pm8001_sas.h |1 +
>> drivers/scsi/pm8001/pm80xx_hwi.c | 69 ++---
>> 4 files changed, 160 insertions(+), 118 deletions(-)
>>
>> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
>> b/drivers/scsi/pm8001/pm8001_hwi.c
>> index 0a1296a..3901c40 100644
>> --- a/drivers/scsi/pm8001/pm8001_hwi.c
>> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
>> @@ -411,7 +411,6 @@ static void mpi_set_phys_g3_with_ssc(struct
>> pm8001_hba_info *pm8001_ha,
>> u32 SSCbit)
>> {
>> u32 value, offset, i;
>> -unsigned long flags;
>>
>> #define SAS2_SETTINGS_LOCAL_PHY_0_3_SHIFT_ADDR 0x0003
>> #define SAS2_SETTINGS_LOCAL_PHY_4_7_SHIFT_ADDR 0x0004
>> @@ -425,10 +424,10 @@ static void mpi_set_phys_g3_with_ssc(struct
>> pm8001_hba_info *pm8001_ha,
>> * Using shifted destination address 0x3_:0x1074 + 0x4000*N (N=0:3)
>> * Using shifted destination address 0x4_:0x1074 + 0x4000*(N-4)
>> (N=4:7)
>> */
>> -spin_lock_irqsave(&pm8001_ha->lock, flags);
>> +spin_lock_irqsave(&pm8001_ha->lock, pm8001_ha->lock_flags);
>> if (-1 == pm8001_bar4_shift(pm8001_ha,
>> SAS2_SETTINGS_LOCAL_PHY_0_3_SHIFT_ADDR)) {
>> -spin_unlock_irqrestore(&pm8001_ha->lock, flags);
>> +spin_unlock_irqrestore(&pm8001_ha->lock, pm8001_ha->lock_flags);
>> return;
>> }
>>
>> @@ -439,7 +438,7 @@ static void mpi_set_phys_g3_with_ssc(struct
>> pm8001_hba_info *pm8001_ha,
>> /* shift membase 3 for SAS2_SETTINGS_LOCAL_PHY 4 - 7 */
>> if (-1 == pm8001_bar4_shift(pm8001_ha,
>> SAS2_SETTINGS_LOCAL_PHY_4_7_SHIFT_ADDR)) {
>> -spin_unlock_irqrestore(&pm8001_ha->lock, flags);
>> +spin_unlock_irqrestore(&pm8001_ha->lock, pm8001_ha->lock_flags);
>> return;
>> }
>> for (i = 4; i < 8; i++) {
>> @@ -466,7 +465,7 @@ static void mpi_set_phys_g3_with_ssc(struct
>> pm8001_hba_info *pm8001_ha,
>>
>> /*set the shifted destination address to 0x0 to avoid error operation */
>> pm8001_bar4_shift(pm8001_ha, 0x0);
>> -spin_unlock_irqrestore(&pm8001_ha->lock, flags);
>> +spin_unlock_irqrestore(&pm8001_ha->lock, pm8001_ha->lock_flags);
>> return;
>> }
>>
>> @@ -481,7 +480,6 @@ static void mpi_set_open_retry_interval_reg(struct
>> pm8001_hba_info *pm8001_ha,
>> u32 offset;
>> u32 value;
>> u32 i;
>> -unsigned long flags;
>>
>> #define OPEN_RETRY_INTERVAL_PHY_0_3_SHIFT_ADDR 0x0003
>> #define OPEN_RETRY_INTERVAL_PHY_4_7_SHIFT_ADDR 0x0004
>> @@ -490,11 +488,11 @@ static void mpi_set_open_retry_interval_reg(struct
>> pm8001_hba_info *pm8001_ha,
>> #define OPEN_RETRY_INTERVAL_REG_MASK 0x
>>
>> value = interval & OPEN_RETRY_INTERVAL_REG_MASK;
>> -spin_lock_irqsave(&pm8001_ha->lock, flags);
>> +spin_lock_irqsave(&pm8001_ha->lock, pm8001_ha->lock_flags);
>> /* shift bar and set the OPEN_REJECT(RETRY) interval time of PHY 0 -3.*/
>> if (-1 == pm8001_bar4_shift(pm8001_ha,
>> OPEN_RETRY_INTERVAL_PHY_0_3_SHIFT_ADDR)) {
>> -spin_unlock_irqrestore(&pm8001_ha->lock, flags);
>> +spin_unlock_irqrestore(&pm8001_ha->lock, pm8001_ha->lock_flags);
>> return;
>> }
>> for (i = 0; i < 4; i++) {
>> @@ -504,7 +502,7 @@ static void mpi_set_open_retry_interval_reg(struct
>> pm8001_hba_info *pm8001_ha,
>>
>> if (-1 == pm8001_bar4_shift(pm8001_ha,
>> OPEN_RETRY_INTERVAL_PHY_4_7_SHIFT_ADDR)) {
>> -spin_unlock_irqrestore(&pm8001_ha->lock, flags);
>> +spin_unlock_irqrestore(&pm8001_ha->lock, pm8001_ha->lock_flags);
>> return;
>> }
>> for (i = 4; i < 8; i++) {
>> @@ -513,7 +511,7 @@ static void mpi_set_open_retry_
Re: [PATCH 0/2] pm80xx: Fix ATTO pm8001 based HBA support
On 12/19/2013 04:50 PM, Bradley Grove wrote: > Addresses issues that we uncovered during testing with our HBAs. > For the most part, we just enabled code that was already being used > for other vendor's HBAs. > > Bradley Grove (2): > pm80xx: Read saved WWN from NVMD for ATTO pm8001 based HBAs. > pm80xx: Enable BAR shift to avoid BIOS conflict with MPI space for > ATTO pm8001 based HBAs. > > drivers/scsi/pm8001/pm8001_hwi.c | 6 +++--- > drivers/scsi/pm8001/pm8001_init.c | 10 +- > 2 files changed, 8 insertions(+), 8 deletions(-) > Looks fine, thanks Acked-by: Jack Wang -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] pm8001 driver code cleanup
On 11/27/2013 06:40 AM, Viswas G wrote: > We are resubmitting the following patches in the new patch set > > pm80xx : Removing redundant code snippets > pm80xx : Fixed return value issue > > Please discard the previous patches we submitted for the same. > > [PATCH 5/6] pm80xx : Removing redundant code snippets > http://marc.info/?l=linux-scsi&m=138493235925253&w=2 > > [PATCH 6/6] pm80xx : Fixed return value issue > http://marc.info/?l=linux-scsi&m=138493243028701&w=2 > > Sorry for the confusion. > > This patch set has to be applied after the below patch set > submitted by Anand. > > http://marc.info/?l=linux-scsi&m=138434875025909&w=2 > > > Viswas G (2): > pm80xx : Removing redundant code snippets > pm80xx : Fixed return value issue. > > drivers/scsi/pm8001/pm8001_ctl.c | 26 ++ > drivers/scsi/pm8001/pm8001_hwi.c | 15 +-- > 2 files changed, 15 insertions(+), 26 deletions(-) > You can add my reviewed-by if need. Jack -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] pm80xx : Fixed return value issue
On 11/20/2013 08:22 AM, Viswas G wrote:
> pm8001_get_gsm_dump() was returning "1" in error case
> instead of negative error code.
>
> Signed-off-by: Viswas G
Looks good, thanks
Reviewed-by: Jack Wang
> ---
> drivers/scsi/pm8001/pm8001_hwi.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index f6ea277..e2932ef 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -5020,7 +5020,7 @@ pm8001_get_gsm_dump(struct device *cdev, u32 length,
> char* buf)
> /* check max is 1 Mbytes */
> if ((length > 0x10) || (gsm_dump_offset & 3) ||
> ((gsm_dump_offset + length) > 0x100))
> - return 1;
> + return -EINVAL;
>
> if (pm8001_ha->chip_id == chip_8001)
> bar = 2;
> @@ -5048,12 +5048,12 @@ pm8001_get_gsm_dump(struct device *cdev, u32 length,
> char* buf)
> gsm_base = GSM_BASE;
> if (-1 == pm8001_bar4_shift(pm8001_ha,
> (gsm_base + shift_value)))
> - return 1;
> + return -EINVAL;
> } else {
> gsm_base = 0;
> if (-1 == pm80xx_bar4_shift(pm8001_ha,
> (gsm_base + shift_value)))
> - return 1;
> + return -EINVAL;
> }
> gsm_dump_offset = (gsm_dump_offset + offset) &
> 0x;
> @@ -5073,7 +5073,7 @@ pm8001_get_gsm_dump(struct device *cdev, u32 length,
> char* buf)
> }
> /* Shift back to BAR4 original address */
> if (-1 == pm8001_bar4_shift(pm8001_ha, 0))
> - return 1;
> + return -EINVAL;
> pm8001_ha->fatal_forensic_shift_offset += 1024;
>
> if (pm8001_ha->fatal_forensic_shift_offset >= 0x10)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] pm80xx : Removing redundant code snippets
On 11/20/2013 08:21 AM, Viswas G wrote:
> Removed redundant code snipptes in pm8001_hwi.c
> and pm8001_ctl.c
>
> Signed-off-by: Viswas G
Looks good, thanks
Reviewed-by: Jack Wang
> ---
> drivers/scsi/pm8001/pm8001_ctl.c | 22 --
> drivers/scsi/pm8001/pm8001_hwi.c |7 +--
> 2 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_ctl.c
> b/drivers/scsi/pm8001/pm8001_ctl.c
> index a04b4ff..1e055ae 100644
> --- a/drivers/scsi/pm8001/pm8001_ctl.c
> +++ b/drivers/scsi/pm8001/pm8001_ctl.c
> @@ -323,16 +323,13 @@ static ssize_t pm8001_ctl_ib_queue_log_show(struct
> device *cdev,
> int offset;
> char *str = buf;
> int start = 0;
> -#define IB_MEMMAP(c) \
> - (*(u32 *)((u8 *)pm8001_ha-> \
> - memoryMap.region[IB].virt_ptr + \
> +#define IB_MEMMAP(c) \
> + (*(u32 *)((u8 *)pm8001_ha-> \
> + memoryMap.region[IB].virt_ptr + \
> pm8001_ha->evtlog_ib_offset + (c)))
>
> for (offset = 0; offset < IB_OB_READ_TIMES; offset++) {
> - if (pm8001_ha->chip_id != chip_8001)
> - str += sprintf(str, "0x%08x\n", IB_MEMMAP(start));
> - else
> - str += sprintf(str, "0x%08x\n", IB_MEMMAP(start));
> + str += sprintf(str, "0x%08x\n", IB_MEMMAP(start));
> start = start + 4;
> }
> pm8001_ha->evtlog_ib_offset += SYSFS_OFFSET;
> @@ -363,16 +360,13 @@ static ssize_t pm8001_ctl_ob_queue_log_show(struct
> device *cdev,
> int offset;
> char *str = buf;
> int start = 0;
> -#define OB_MEMMAP(c) \
> - (*(u32 *)((u8 *)pm8001_ha-> \
> - memoryMap.region[OB].virt_ptr + \
> +#define OB_MEMMAP(c) \
> + (*(u32 *)((u8 *)pm8001_ha-> \
> + memoryMap.region[OB].virt_ptr + \
> pm8001_ha->evtlog_ob_offset + (c)))
>
> for (offset = 0; offset < IB_OB_READ_TIMES; offset++) {
> - if (pm8001_ha->chip_id != chip_8001)
> - str += sprintf(str, "0x%08x\n", OB_MEMMAP(start));
> - else
> - str += sprintf(str, "0x%08x\n", OB_MEMMAP(start));
> + str += sprintf(str, "0x%08x\n", OB_MEMMAP(start));
> start = start + 4;
> }
> pm8001_ha->evtlog_ob_offset += SYSFS_OFFSET;
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index b23f49d..f6ea277 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -5072,13 +5072,8 @@ pm8001_get_gsm_dump(struct device *cdev, u32 length,
> char* buf)
> direct_data += sprintf(direct_data, "%08x ", value);
> }
> /* Shift back to BAR4 original address */
> - if (pm8001_ha->chip_id == chip_8001) {
> - if (-1 == pm8001_bar4_shift(pm8001_ha, 0))
> + if (-1 == pm8001_bar4_shift(pm8001_ha, 0))
> return 1;
> - } else {
> - if (-1 == pm80xx_bar4_shift(pm8001_ha, 0))
> - return 1;
> - }
> pm8001_ha->fatal_forensic_shift_offset += 1024;
>
> if (pm8001_ha->fatal_forensic_shift_offset >= 0x10)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V1 2/3] pm80xx: Resetting the phy state.
On 11/11/2013 05:24 PM, Anand wrote:
> From 800d934dd22f3ef5d7f52d900295d371d17004bd Mon Sep 17 00:00:00 2001
> From: Nikith Ganigarakoppal
> Date: Wed, 30 Oct 2013 16:23:47 +0530
> Subject: [PATCH V1 2/3] pm80xx: Resetting the phy state.
>
> Setting the phy state for hard reset response.
> After sending hard reset for a device ,phy down event sets
> the phy state to zero but for phy up event it will not set
> the phy state again.This will cause problem to successive
> hard resets.
>
>
> Signed-off-by: anandkumar.santha...@pmcs.com
> Signed-off-by: nikith.ganigarakop...@pmcs.com
Nice catch, Thanks
Reviewed-by: Jack Wang
PS: same about the signed-off chain.
> ---
> drivers/scsi/pm8001/pm8001_hwi.c |2 ++
> drivers/scsi/pm8001/pm8001_hwi.h |4
> drivers/scsi/pm8001/pm80xx_hwi.c |2 ++
> drivers/scsi/pm8001/pm80xx_hwi.h |2 ++
> 4 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index 9961616..b23f49d 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -3403,6 +3403,7 @@ hw_event_sas_phy_up(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> unsigned long flags;
> u8 deviceType = pPayload->sas_identify.dev_type;
> port->port_state = portstate;
> + phy->phy_state = PHY_STATE_LINK_UP_SPC;
> PM8001_MSG_DBG(pm8001_ha,
> pm8001_printk("HW_EVENT_SAS_PHY_UP port id = %d, phy id = %d\n",
> port_id, phy_id));
> @@ -3483,6 +3484,7 @@ hw_event_sata_phy_up(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> pm8001_printk("HW_EVENT_SATA_PHY_UP port id = %d,"
> " phy id = %d\n", port_id, phy_id));
> port->port_state = portstate;
> + phy->phy_state = PHY_STATE_LINK_UP_SPC;
> port->port_attached = 1;
> pm8001_get_lrate_mode(phy, link_rate);
> phy->phy_type |= PORT_TYPE_SATA;
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.h
> b/drivers/scsi/pm8001/pm8001_hwi.h
> index 6d91e24..e4867e6 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.h
> +++ b/drivers/scsi/pm8001/pm8001_hwi.h
> @@ -131,6 +131,10 @@
> #define LINKRATE_30 (0x02 << 8)
> #define LINKRATE_60 (0x04 << 8)
>
> +/* for phy state */
> +
> +#define PHY_STATE_LINK_UP_SPC0x1
> +
> /* for new SPC controllers MEMBASE III is shared between BIOS and DATA */
> #define GSM_SM_BASE 0x4F
> struct mpi_msg_hdr{
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 4ebc79b..41bee62 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -2894,6 +2894,7 @@ hw_event_sas_phy_up(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> unsigned long flags;
> u8 deviceType = pPayload->sas_identify.dev_type;
> port->port_state = portstate;
> + phy->phy_state = PHY_STATE_LINK_UP_SPCV;
> PM8001_MSG_DBG(pm8001_ha, pm8001_printk(
> "portid:%d; phyid:%d; linkrate:%d; "
> "portstate:%x; devicetype:%x\n",
> @@ -2978,6 +2979,7 @@ hw_event_sata_phy_up(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> port_id, phy_id, link_rate, portstate));
>
> port->port_state = portstate;
> + phy->phy_state = PHY_STATE_LINK_UP_SPCV;
> port->port_attached = 1;
> pm8001_get_lrate_mode(phy, link_rate);
> phy->phy_type |= PORT_TYPE_SATA;
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.h
> b/drivers/scsi/pm8001/pm80xx_hwi.h
> index c86816b..9970a38 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.h
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.h
> @@ -215,6 +215,8 @@
> #define SAS_DOPNRJT_RTRY_TMO128
> #define SAS_COPNRJT_RTRY_TMO128
>
> +/* for phy state */
> +#define PHY_STATE_LINK_UP_SPCV 0x2
> /*
>Making ORR bigger than IT NEXUS LOSS which is 200us = 2 second.
>Assuming a bigger value 3 second, 300/128 = 23437.5 where 128
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V1 1/3] pm80xx: Fix for direct attached device.
On 11/11/2013 05:20 PM, Anand wrote:
> From cf6a06ddf571464571f826109bb1e5a0667c7751 Mon Sep 17 00:00:00 2001
> From: Nikith Ganigarakoppal
> Date: Wed, 30 Oct 2013 16:13:22 +0530
> Subject: [PATCH V1 1/3] pm80xx: Fix for direct attached device.
>
> In case of direct attached SATA device delay is not enough.
> It will give crash for set device state command response and
> wait_for_completion is the best solution for this.
>
Nice catch,
Reviewed-by: Jack Wang
PS: the signed-off chain is not right, From author should come first
here Nikith. And please do not mix fix with update module author, you
can do it with another patch.
> Updation of module author.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
> Signed-off-by: nikith.ganigarakop...@pmcs.com
> ---
> drivers/scsi/pm8001/pm8001_init.c |1 +
> drivers/scsi/pm8001/pm8001_sas.c |4 +++-
> 2 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 7b57fcd..17daaa4 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -1170,6 +1170,7 @@ module_exit(pm8001_exit);
> MODULE_AUTHOR("Jack Wang ");
> MODULE_AUTHOR("Anand Kumar Santhanam ");
> MODULE_AUTHOR("Sangeetha Gnanasekaran ");
> +MODULE_AUTHOR("Nikith Ganigarakoppal ");
> MODULE_DESCRIPTION(
> "PMC-Sierra PM8001/8081/8088/8089/8074/8076/8077 "
> "SAS/SATA controller driver");
> diff --git a/drivers/scsi/pm8001/pm8001_sas.c
> b/drivers/scsi/pm8001/pm8001_sas.c
> index f4eb18e..f50ac44 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -1098,15 +1098,17 @@ int pm8001_lu_reset(struct domain_device *dev, u8
> *lun)
> struct pm8001_tmf_task tmf_task;
> struct pm8001_device *pm8001_dev = dev->lldd_dev;
> struct pm8001_hba_info *pm8001_ha = pm8001_find_ha_by_dev(dev);
> + DECLARE_COMPLETION_ONSTACK(completion_setstate);
> if (dev_is_sata(dev)) {
> struct sas_phy *phy = sas_get_local_phy(dev);
> rc = pm8001_exec_internal_task_abort(pm8001_ha, pm8001_dev ,
> dev, 1, 0);
> rc = sas_phy_reset(phy, 1);
> sas_put_local_phy(phy);
> + pm8001_dev->setds_completion = &completion_setstate;
> rc = PM8001_CHIP_DISP->set_dev_state_req(pm8001_ha,
> pm8001_dev, 0x01);
> - msleep(2000);
> + wait_for_completion(&completion_setstate);
> } else {
> tmf_task.tmf = TMF_LU_RESET;
> rc = pm8001_issue_ssp_tmf(dev, lun, &tmf_task);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] pm80xx : gpio feature support for motherboard controllers
Hi James,
About this gpio feature, do you think it's OK to implement with IOCTL or
we can use exist bsg interface in libsas and add another function call?
Regards,
Jack
On 11/11/2013 06:57 AM, Viswas G wrote:
> Hi Jack,
>
> The GPIO feature we implemented here is for controlling and configuring the
> GPIO pins present in the HBA and it is not related to the GPIO registers
> present in the SGPIO. Following is one of the GPIO operations we do from
> application.
>
> When application wants to know the insertion/removal of a SAS cable in any of
> the port, it configures the GPIO for corresponding port to generate event for
> SAS cable insertion or removal using the IOCTL to the HBA driver and waits by
> calling poll function. When driver receives the GPIO event for the SAS cable
> insertion or removal then it intimates the application.
>
> We are using IOCTL instead of sysfs interface since we have to pass
> structures between user space and kernel space. Again, in the kernel space,
> we have to parse user buffer from application and convert it to the
> corresponding data structure. We wanted to avoid the parsing complexity by
> using ioctl interface.
>
> Regards,
> Viswas G
>
>
> -Original Message-
> From: Jack Wang [mailto:xjtu...@gmail.com]
> Sent: Monday, November 04, 2013 4:00 PM
> To: Viswas G
> Cc: linux-scsi@vger.kernel.org; Sangeetha Gnanasekaran; Nikith
> Ganigarakoppal; Anand Kumar Santhanam; Suresh Thiagarajan
> Subject: Re: [PATCH 11/11] pm80xx : gpio feature support for motherboard
> controllers
>
> On 11/04/2013 11:13 AM, Viswas G wrote:
>> Hi Jack,
>>
>> We wanted to control the GPIO in the HBA only. Bsg interface gets created
>> only for enclosure or expander.
>>
>> For our HBA, bsg interface will not be created since it does not have an
>> enclosure target inside. That's why we wanted to use IOCTL. Please advise.
>>
>> Best Regards,
>> Viswas G
>>
> Hi Viswas,
>
> No, bsg interface also support HBA.
> Here is two example output from LSI mpt2sas:
>
> smp_rep_manufacturer /dev/bsg/sas_host0
> Report manufacturer response:
> SAS-1.1 format: 0
> vendor identification: LSI
> product identification: Virtual SMP Port
> product revision level:
> smp_read_gpio /dev/bsg/sas_host0
> Read GPIO register response:
> GPIO_CFG[0]:
> version: 0
> GPIO enable: 1
> cfg register count: 2
> gp register count: 1
> supported drive count: 16
>
> Regards,
> Jack
>
>> -Original Message-
>> From: Jack Wang [mailto:xjtu...@gmail.com]
>> Sent: Tuesday, October 29, 2013 3:49 PM
>> To: Viswas G
>> Cc: linux-scsi@vger.kernel.org; Sangeetha Gnanasekaran; Nikith
>> Ganigarakoppal; Anand Kumar Santhanam
>> Subject: Re: [PATCH 11/11] pm80xx : gpio feature support for motherboard
>> controllers
>>
>> Hi Viswas,
>>
>> As ioctl interface is not welcome for new feature, that's why we removed
>> ioctl interface when pm8001 accepted into mainline.
>>
>> I suggest you use bsg interface for this, see sas_host_smp.c for details.
>>
>> Regards,
>> Jack
>>
>> On 10/22/2013 02:20 PM, Viswas G wrote:
>>>
>>> Signed-off-by: Viswas G
>>> ---
>>> drivers/scsi/pm8001/pm8001_ctl.c | 248
>>> -
>>> drivers/scsi/pm8001/pm8001_ctl.h | 55
>>> drivers/scsi/pm8001/pm8001_init.c | 37 ++
>>> drivers/scsi/pm8001/pm8001_sas.h | 30 +
>>> drivers/scsi/pm8001/pm80xx_hwi.c | 106
>>> drivers/scsi/pm8001/pm80xx_hwi.h | 49 +++
>>> 6 files changed, 524 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/scsi/pm8001/pm8001_ctl.c
>>> b/drivers/scsi/pm8001/pm8001_ctl.c
>>> index 247cb1c..3c9ca21 100644
>>> --- a/drivers/scsi/pm8001/pm8001_ctl.c
>>> +++ b/drivers/scsi/pm8001/pm8001_ctl.c
>>> @@ -40,7 +40,8 @@
>>> #include
>>> #include
>>> #include "pm8001_sas.h"
>>> -#include "pm8001_ctl.h"
>>> +
>>> +int pm8001_major = -1;
>>>
>>> /* scsi host attributes */
>>>
>>> @@ -759,3 +760,248 @@ struct device_attribute *pm8001_host_attrs[] = {
>>> NULL,
>>> };
>>>
>>> +/**
>>> + * pm8001_open - open the configuration file
>>> + * @inode: inode being opened
>>> + * @file: file handle attached
>>> + *
>>> + * Called when the configuration device is opened. Does the neede
Re: [PATCH 11/11] pm80xx : gpio feature support for motherboard controllers
On 11/04/2013 11:13 AM, Viswas G wrote:
> Hi Jack,
>
> We wanted to control the GPIO in the HBA only. Bsg interface gets created
> only for enclosure or expander.
>
> For our HBA, bsg interface will not be created since it does not have an
> enclosure target inside. That's why we wanted to use IOCTL. Please advise.
>
> Best Regards,
> Viswas G
>
Hi Viswas,
No, bsg interface also support HBA.
Here is two example output from LSI mpt2sas:
smp_rep_manufacturer /dev/bsg/sas_host0
Report manufacturer response:
SAS-1.1 format: 0
vendor identification: LSI
product identification: Virtual SMP Port
product revision level:
smp_read_gpio /dev/bsg/sas_host0
Read GPIO register response:
GPIO_CFG[0]:
version: 0
GPIO enable: 1
cfg register count: 2
gp register count: 1
supported drive count: 16
Regards,
Jack
> -----Original Message-
> From: Jack Wang [mailto:xjtu...@gmail.com]
> Sent: Tuesday, October 29, 2013 3:49 PM
> To: Viswas G
> Cc: linux-scsi@vger.kernel.org; Sangeetha Gnanasekaran; Nikith
> Ganigarakoppal; Anand Kumar Santhanam
> Subject: Re: [PATCH 11/11] pm80xx : gpio feature support for motherboard
> controllers
>
> Hi Viswas,
>
> As ioctl interface is not welcome for new feature, that's why we removed
> ioctl interface when pm8001 accepted into mainline.
>
> I suggest you use bsg interface for this, see sas_host_smp.c for details.
>
> Regards,
> Jack
>
> On 10/22/2013 02:20 PM, Viswas G wrote:
>>
>> Signed-off-by: Viswas G
>> ---
>> drivers/scsi/pm8001/pm8001_ctl.c | 248
>> -
>> drivers/scsi/pm8001/pm8001_ctl.h | 55
>> drivers/scsi/pm8001/pm8001_init.c | 37 ++
>> drivers/scsi/pm8001/pm8001_sas.h | 30 +
>> drivers/scsi/pm8001/pm80xx_hwi.c | 106
>> drivers/scsi/pm8001/pm80xx_hwi.h | 49 +++
>> 6 files changed, 524 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/scsi/pm8001/pm8001_ctl.c
>> b/drivers/scsi/pm8001/pm8001_ctl.c
>> index 247cb1c..3c9ca21 100644
>> --- a/drivers/scsi/pm8001/pm8001_ctl.c
>> +++ b/drivers/scsi/pm8001/pm8001_ctl.c
>> @@ -40,7 +40,8 @@
>> #include
>> #include
>> #include "pm8001_sas.h"
>> -#include "pm8001_ctl.h"
>> +
>> +int pm8001_major = -1;
>>
>> /* scsi host attributes */
>>
>> @@ -759,3 +760,248 @@ struct device_attribute *pm8001_host_attrs[] = {
>> NULL,
>> };
>>
>> +/**
>> + * pm8001_open - open the configuration file
>> + * @inode: inode being opened
>> + * @file: file handle attached
>> + *
>> + * Called when the configuration device is opened. Does the needed
>> + * set up on the handle and then returns
>> + *
>> + */
>> +static int pm8001_open(struct inode *inode, struct file *file) {
>> + struct pm8001_hba_info *pm8001_ha;
>> + unsigned minor_number = iminor(inode);
>> + int err = -ENODEV;
>> +
>> + list_for_each_entry(pm8001_ha, &hba_list, list) {
>> + if (pm8001_ha->id == minor_number) {
>> + file->private_data = pm8001_ha;
>> + err = 0;
>> + break;
>> + }
>> + }
>> +
>> + return err;
>> +}
>> +
>> +/**
>> + * pm8001_close - close the configuration file
>> + * @inode: inode being opened
>> + * @file: file handle attached
>> + *
>> + * Called when the configuration device is closed. Does the needed
>> + * set up on the handle and then returns
>> + *
>> + */
>> +static int pm8001_close(struct inode *inode, struct file *file) {
>> + return 0;
>> +}
>> +
>> +static long pm8001_info_ioctl(struct pm8001_hba_info *pm8001_ha,
>> + unsigned long arg) {
>> + u32 ret = 0;
>> + struct ioctl_info_buffer info_buf;
>> + union main_cfg_table main_tbl = pm8001_ha->main_cfg_tbl;
>> +
>> + strcpy(info_buf.information.sz_name, DRV_NAME);
>> +
>> + info_buf.information.usmajor_revision = DRV_MAJOR;
>> + info_buf.information.usminor_revision = DRV_MINOR;
>> + info_buf.information.usbuild_revision = DRV_BUILD;
>> + if (pm8001_ha->chip_id == chip_8001) {
>> + info_buf.information.maxoutstandingIO =
>> + main_tbl.pm8001_tbl.max_out_io;
>> + info_buf.information.maxdevices =
>> + (main_tbl.pm8001_tbl.max_sg
Re: [PATCH 11/11] pm80xx : gpio feature support for motherboard controllers
Hi Viswas,
As ioctl interface is not welcome for new feature, that's why we removed
ioctl interface when pm8001 accepted into mainline.
I suggest you use bsg interface for this, see sas_host_smp.c for details.
Regards,
Jack
On 10/22/2013 02:20 PM, Viswas G wrote:
>
> Signed-off-by: Viswas G
> ---
> drivers/scsi/pm8001/pm8001_ctl.c | 248
> -
> drivers/scsi/pm8001/pm8001_ctl.h | 55
> drivers/scsi/pm8001/pm8001_init.c | 37 ++
> drivers/scsi/pm8001/pm8001_sas.h | 30 +
> drivers/scsi/pm8001/pm80xx_hwi.c | 106
> drivers/scsi/pm8001/pm80xx_hwi.h | 49 +++
> 6 files changed, 524 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_ctl.c
> b/drivers/scsi/pm8001/pm8001_ctl.c
> index 247cb1c..3c9ca21 100644
> --- a/drivers/scsi/pm8001/pm8001_ctl.c
> +++ b/drivers/scsi/pm8001/pm8001_ctl.c
> @@ -40,7 +40,8 @@
> #include
> #include
> #include "pm8001_sas.h"
> -#include "pm8001_ctl.h"
> +
> +int pm8001_major = -1;
>
> /* scsi host attributes */
>
> @@ -759,3 +760,248 @@ struct device_attribute *pm8001_host_attrs[] = {
> NULL,
> };
>
> +/**
> + * pm8001_open - open the configuration file
> + * @inode: inode being opened
> + * @file: file handle attached
> + *
> + * Called when the configuration device is opened. Does the needed
> + * set up on the handle and then returns
> + *
> + */
> +static int pm8001_open(struct inode *inode, struct file *file)
> +{
> + struct pm8001_hba_info *pm8001_ha;
> + unsigned minor_number = iminor(inode);
> + int err = -ENODEV;
> +
> + list_for_each_entry(pm8001_ha, &hba_list, list) {
> + if (pm8001_ha->id == minor_number) {
> + file->private_data = pm8001_ha;
> + err = 0;
> + break;
> + }
> + }
> +
> + return err;
> +}
> +
> +/**
> + * pm8001_close - close the configuration file
> + * @inode: inode being opened
> + * @file: file handle attached
> + *
> + * Called when the configuration device is closed. Does the needed
> + * set up on the handle and then returns
> + *
> + */
> +static int pm8001_close(struct inode *inode, struct file *file)
> +{
> + return 0;
> +}
> +
> +static long pm8001_info_ioctl(struct pm8001_hba_info *pm8001_ha,
> + unsigned long arg)
> +{
> + u32 ret = 0;
> + struct ioctl_info_buffer info_buf;
> + union main_cfg_table main_tbl = pm8001_ha->main_cfg_tbl;
> +
> + strcpy(info_buf.information.sz_name, DRV_NAME);
> +
> + info_buf.information.usmajor_revision = DRV_MAJOR;
> + info_buf.information.usminor_revision = DRV_MINOR;
> + info_buf.information.usbuild_revision = DRV_BUILD;
> + if (pm8001_ha->chip_id == chip_8001) {
> + info_buf.information.maxoutstandingIO =
> + main_tbl.pm8001_tbl.max_out_io;
> + info_buf.information.maxdevices =
> + (main_tbl.pm8001_tbl.max_sgl >> 16) & 0x;
> + } else {
> + info_buf.information.maxoutstandingIO =
> + main_tbl.pm80xx_tbl.max_out_io;
> + info_buf.information.maxdevices =
> + (main_tbl.pm80xx_tbl.max_sgl >> 16) & 0x;
> + }
> + info_buf.header.return_code = ADPT_IOCTL_CALL_SUCCESS;
> +
> + if (copy_to_user((void *)arg, (void *)&info_buf,
> +sizeof(struct ioctl_info_buffer))) {
> + ret = ADPT_IOCTL_CALL_FAILED;
> + }
> +
> + return ret;
> +}
> +
> +static long pm8001_gpio_ioctl(struct pm8001_hba_info *pm8001_ha,
> + unsigned long arg)
> +{
> + struct gpio_buffer buffer;
> + struct pm8001_gpio *payload;
> + struct gpio_ioctl_resp *gpio_resp;
> + DECLARE_COMPLETION_ONSTACK(completion);
> + unsigned long timeout;
> + u32 ret = 0, operation;
> +
> + mutex_lock(&pm8001_ha->ioctl_mutex);
> +
> + if (copy_from_user(&buffer, (struct gpio_buffer *)arg,
> + sizeof(struct gpio_buffer))) {
> + ret = ADPT_IOCTL_CALL_FAILED;
> + goto exit;
> + }
> +
> + pm8001_ha->ioctl_completion = &completion;
> + payload = &buffer.gpio_payload;
> + operation = payload->operation;
> + ret = PM8001_CHIP_DISP->gpio_req(pm8001_ha, payload);
> + if (ret != 0) {
> + ret = ADPT_IOCTL_CALL_FAILED;
> + goto exit;
> + }
> +
> + timeout = (unsigned long)buffer.header.timeout * 1000;
> +
> + mod_timer(&pm8001_ha->ioctl_timer, jiffies +
> msecs_to_jiffies(timeout));
> +
> + wait_for_completion(&completion);
> +
> + if (pm8001_ha->ioctl_timer_expired) {
> + ret = ADPT_IOCTL_CALL_TIMEOUT;
> + goto exit;
> + }
> + gpio_resp = &pm8001_ha->gpio_resp;
> +
> + bu
Re: [PATCH V2 05/10] pm80xx: Phy settings support for motherboard controller.
On 09/26/2013 11:04 AM, Sangeetha Gnanasekaran wrote:
> Phy settings support is only for Motherboard controller. Firmware will
> only initialize default values for all PHY in case of motherboard
> controller. Hence, this is mandatory to add this support in all
> motherboard controllers to configure their own settings.
I still think you'd better add a list for devices know to support phy
setting similar as IS_SPC12G, there are some devices in the driver
support list do not have default setting I suspect.
Jack
>
> -Original Message-
> From: Jack Wang [mailto:xjtu...@gmail.com]
> Sent: Thursday, September 26, 2013 12:27 PM
> To: Anand Kumar Santhanam
> Cc: linux-scsi@vger.kernel.org; Sangeetha Gnanasekaran; Nikith
> Ganigarakoppal; Viswas G
> Subject: Re: [PATCH V2 05/10] pm80xx: Phy settings support for
> motherboard controller.
>
> snip
>> #ifdef PM8001_USE_MSIX
>> /**
>> * pm8001_setup_msix - enable MSI-X interrupt @@ -847,6 +872,9 @@
>> static int pm8001_pci_probe(struct pci_dev *pdev,
>> }
>>
>> pm8001_init_sas_add(pm8001_ha);
>> +/* phy setting support for motherboard controller */
>> +if (pdev->subsystem_vendor != PCI_VENDOR_ID_ADAPTEC2)
>> +pm8001_get_phy_settings_info(pm8001_ha);
>
> Are you sure about this, have you checked all controller except device
> with subsystem_vendorid is PCI_VENDOR_ID_ADAPTEC2 all support this
> get_phy_setting_info funcion?
>
> Jack
>> pm8001_post_sas_ha_init(shost, chip);
>> rc = sas_register_ha(SHOST_TO_SAS_HA(shost));
>> if (rc)
>> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
>> b/drivers/scsi/pm8001/pm8001_sas.h
>> index 68e1147..cbde11a 100644
>> --- a/drivers/scsi/pm8001/pm8001_sas.h
>> +++ b/drivers/scsi/pm8001/pm8001_sas.h
>> @@ -632,7 +632,8 @@ struct pm8001_device *pm8001_find_dev(struct
>> pm8001_hba_info *pm8001_ha, int pm80xx_set_thermal_config(struct
>> pm8001_hba_info *pm8001_ha);
>>
>> int pm8001_bar4_shift(struct pm8001_hba_info *pm8001_ha, u32
>> shiftValue);
>> -
>> +void pm8001_set_phy_profile(struct pm8001_hba_info *pm8001_ha,
>> +u32 length, u8 *buf);
>> /* ctl shared API */
>> extern struct device_attribute *pm8001_host_attrs[];
>>
>> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
>> b/drivers/scsi/pm8001/pm80xx_hwi.c
>> index 99cec5f..e1ab320 100644
>> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
>> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
>> @@ -3131,9 +3131,27 @@ static int mpi_flash_op_ext_resp(struct
>> pm8001_hba_info *pm8001_ha, void *piomb) static int
> mpi_set_phy_profile_resp(struct pm8001_hba_info *pm8001_ha,
>> void *piomb)
>> {
>> -PM8001_MSG_DBG(pm8001_ha,
>> -pm8001_printk("
> pm80xx_addition_functionality\n"));
>> +u8 page_code;
>> +struct set_phy_profile_resp *pPayload =
>> +(struct set_phy_profile_resp *)(piomb + 4);
>> +u32 ppc_phyid = le32_to_cpu(pPayload->ppc_phyid);
>> +u32 status = le32_to_cpu(pPayload->status);
>>
>> +page_code = (u8)((ppc_phyid & 0xFF00) >> 8);
>> +if (status) {
>> +/* status is FAILED */
>> +PM8001_FAIL_DBG(pm8001_ha,
>> +pm8001_printk("PhyProfile command failed with
> status "
>> +"0x%08X \n", status));
>> +return -1;
>> +} else {
>> +if (page_code != SAS_PHY_ANALOG_SETTINGS_PAGE) {
>> +PM8001_FAIL_DBG(pm8001_ha,
>> +pm8001_printk("Invalid page code
> 0x%X\n",
>> +page_code));
>> +return -1;
>> +}
>> +}
>> return 0;
>> }
>>
>> @@ -4128,6 +4146,45 @@ pm80xx_chip_isr(struct pm8001_hba_info
> *pm8001_ha, u8 vec)
>> return IRQ_HANDLED;
>> }
>>
>> +void mpi_set_phy_profile_req(struct pm8001_hba_info *pm8001_ha,
>> +u32 operation, u32 phyid, u32 length, u32 *buf) {
>> +u32 tag , i, j = 0;
>> +int rc;
>> +struct set_phy_profile_req payload;
>> +struct inbound_queue_table *circularQ;
>> +u32 opc = OPC_INB_SET_PHY_PROFILE;
>> +
>> +memset(&payload, 0, sizeof(payload));
>> +rc = pm8001_tag_alloc(pm8001_ha, &tag);
>> +if (rc)
>> +PM8001_FAIL_DBG(pm8001_ha, pm8001_printk("Invalid
> tag\n"));
>> +circularQ = &pm8001_ha->inbn
Re: [PATCH V2 10/10] pm80xx: Firmware logging support
On 09/26/2013 07:43 AM, Anand wrote:
> From ab1b030500a835eacda3d86e5570366099b21311 Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Wed, 4 Sep 2013 12:57:00 +0530
> Subject: [PATCH V2 10/10] pm80xx: Firmware logging support.
>
> Supports below logging facilities,
> Inbound outbound queues dump.
> Non fatal dump in case of IO failures.
> Fatal dump in case of firmware failure.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
Reviewed-by: Jack Wang
> ---
> drivers/scsi/pm8001/pm8001_ctl.c | 129 +
> drivers/scsi/pm8001/pm8001_ctl.h |4 +
> drivers/scsi/pm8001/pm8001_defs.h |3 +-
> drivers/scsi/pm8001/pm8001_hwi.c | 83 ++
> drivers/scsi/pm8001/pm8001_hwi.h |3 +
> drivers/scsi/pm8001/pm8001_init.c |4 +
> drivers/scsi/pm8001/pm8001_sas.h | 68 +++
> drivers/scsi/pm8001/pm80xx_hwi.c | 225
> +
> drivers/scsi/pm8001/pm80xx_hwi.h |2 +
> 9 files changed, 520 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_ctl.c
> b/drivers/scsi/pm8001/pm8001_ctl.c
> index 5a19e19..2ca79a5 100644
> --- a/drivers/scsi/pm8001/pm8001_ctl.c
> +++ b/drivers/scsi/pm8001/pm8001_ctl.c
> @@ -309,6 +309,94 @@ static ssize_t pm8001_ctl_aap_log_show(struct device
> *cdev,
> }
> static DEVICE_ATTR(aap_log, S_IRUGO, pm8001_ctl_aap_log_show, NULL);
> /**
> + * pm8001_ctl_ib_queue_log_show - Out bound Queue log
> + * @cdev:pointer to embedded class device
> + * @buf: the buffer returned
> + * A sysfs 'read-only' shost attribute.
> + */
> +static ssize_t pm8001_ctl_ib_queue_log_show(struct device *cdev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct Scsi_Host *shost = class_to_shost(cdev);
> + struct sas_ha_struct *sha = SHOST_TO_SAS_HA(shost);
> + struct pm8001_hba_info *pm8001_ha = sha->lldd_ha;
> + int offset;
> + char *str = buf;
> + int start = 0;
> +#define IB_MEMMAP(c) \
> + (*(u32 *)((u8 *)pm8001_ha-> \
> + memoryMap.region[IB].virt_ptr + \
> + pm8001_ha->evtlog_ib_offset + (c)))
> +
> +#define IB_MEMMAP_SPC(c) \
> + (*(u32 *)((u8 *)pm8001_ha-> \
> + memoryMap.region[IB].virt_ptr + \
> + pm8001_ha->evtlog_ib_offset + (c)))
> +
> + for (offset = 0; offset < IB_OB_READ_TIMES; offset++) {
> + if (pm8001_ha->chip_id != chip_8001)
> + str += sprintf(str, "0x%08x\n", IB_MEMMAP(start));
> + else
> + str += sprintf(str, "0x%08x\n", IB_MEMMAP_SPC(start));
> + start = start + 4;
> + }
> + pm8001_ha->evtlog_ib_offset += SYSFS_OFFSET;
> + if pm8001_ha->evtlog_ib_offset) % (PM80XX_IB_OB_QUEUE_SIZE)) == 0)
> + && (pm8001_ha->chip_id != chip_8001))
> + pm8001_ha->evtlog_ib_offset = 0;
> + if pm8001_ha->evtlog_ib_offset) % (PM8001_IB_OB_QUEUE_SIZE)) == 0)
> + && (pm8001_ha->chip_id == chip_8001))
> + pm8001_ha->evtlog_ib_offset = 0;
> +
> + return str - buf;
> +}
> +
> +static DEVICE_ATTR(ib_log, S_IRUGO, pm8001_ctl_ib_queue_log_show, NULL);
> +/**
> + * pm8001_ctl_ob_queue_log_show - Out bound Queue log
> + * @cdev:pointer to embedded class device
> + * @buf: the buffer returned
> + * A sysfs 'read-only' shost attribute.
> + */
> +
> +static ssize_t pm8001_ctl_ob_queue_log_show(struct device *cdev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct Scsi_Host *shost = class_to_shost(cdev);
> + struct sas_ha_struct *sha = SHOST_TO_SAS_HA(shost);
> + struct pm8001_hba_info *pm8001_ha = sha->lldd_ha;
> + int offset;
> + char *str = buf;
> + int start = 0;
> +#define OB_MEMMAP(c) \
> + (*(u32 *)((u8 *)pm8001_ha-> \
> + memoryMap.region[OB].virt_ptr + \
> + pm8001_ha->evtlog_ob_offset + (c)))
> +
> +#define OB_MEMMAP_SPC(c) \
> + (*(u32 *)((u8 *)pm8001_ha-> \
> + memoryMap.region[OB].virt_ptr + \
> + pm8001_ha->evtlog_ob_offset + (c)))
> +
> + for (offset = 0; offset < IB_OB_READ_TIMES; offset++) {
> + if (pm8001_ha->chip_id != chip_8001)
> + str += sprintf(str, "0x%08x\n", OB_MEMMAP(start));
> + else
> + str += sprintf(str, "0x%08x\n", OB_MEMMAP_SPC(start));
> +
Re: [PATCH V2 09/10] pm80xx: 4G boundary fix
On 09/26/2013 07:42 AM, Anand wrote:
> From 4715339743d45a6ef862bc0f5d5ec404b4667f94 Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Wed, 18 Sep 2013 11:14:54 +0530
> Subject: [PATCH V2 09/10] pm80xx: 4G boundary fix.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
>
Please give more description why you do this change?
Thanks
Jack
> ---
> drivers/scsi/pm8001/pm80xx_hwi.c | 103
> +-
> 1 files changed, 101 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index ce59d0d..94de2ed 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -3713,7 +3713,8 @@ static int pm80xx_chip_ssp_io_req(struct
> pm8001_hba_info *pm8001_ha,
> struct ssp_ini_io_start_req ssp_cmd;
> u32 tag = ccb->ccb_tag;
> int ret;
> - u64 phys_addr;
> + u64 phys_addr, start_addr, end_addr;
> + u32 end_addr_high, end_addr_low;
> struct inbound_queue_table *circularQ;
> u32 q_index;
> u32 opc = OPC_INB_SSPINIIOSTART;
> @@ -3767,6 +3768,30 @@ static int pm80xx_chip_ssp_io_req(struct
> pm8001_hba_info *pm8001_ha,
> cpu_to_le32(upper_32_bits(dma_addr));
> ssp_cmd.enc_len = cpu_to_le32(task->total_xfer_len);
> ssp_cmd.enc_esgl = 0;
> + /* Check 4G Boundary */
> + start_addr = cpu_to_le64(dma_addr);
> + end_addr = (start_addr + ssp_cmd.enc_len) - 1;
> + end_addr_low = cpu_to_le32(lower_32_bits(end_addr));
> + end_addr_high = cpu_to_le32(upper_32_bits(end_addr));
> + if (end_addr_high != ssp_cmd.enc_addr_high) {
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("The sg list address "
> + "start_addr=0x%016llx data_len=0x%x "
> + "end_addr_high=0x%08x end_addr_low="
> + "0x%08x has crossed 4G boundary\n",
> + start_addr, ssp_cmd.enc_len,
> + end_addr_high, end_addr_low));
> + pm8001_chip_make_sg(task->scatter, 1,
> + ccb->buf_prd);
> + phys_addr = ccb->ccb_dma_handle +
> + offsetof(struct pm8001_ccb_info,
> + buf_prd[0]);
> + ssp_cmd.enc_addr_low =
> + cpu_to_le32(lower_32_bits(phys_addr));
> + ssp_cmd.enc_addr_high =
> + cpu_to_le32(upper_32_bits(phys_addr));
> + ssp_cmd.enc_esgl = cpu_to_le32(1<<31);
> + }
> } else if (task->num_scatter == 0) {
> ssp_cmd.enc_addr_low = 0;
> ssp_cmd.enc_addr_high = 0;
> @@ -3802,6 +3827,30 @@ static int pm80xx_chip_ssp_io_req(struct
> pm8001_hba_info *pm8001_ha,
> cpu_to_le32(upper_32_bits(dma_addr));
> ssp_cmd.len = cpu_to_le32(task->total_xfer_len);
> ssp_cmd.esgl = 0;
> + /* Check 4G Boundary */
> + start_addr = cpu_to_le64(dma_addr);
> + end_addr = (start_addr + ssp_cmd.len) - 1;
> + end_addr_low = cpu_to_le32(lower_32_bits(end_addr));
> + end_addr_high = cpu_to_le32(upper_32_bits(end_addr));
> + if (end_addr_high != ssp_cmd.addr_high) {
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("The sg list address "
> + "start_addr=0x%016llx data_len=0x%x "
> + "end_addr_high=0x%08x end_addr_low="
> + "0x%08x has crossed 4G boundary\n",
> + start_addr, ssp_cmd.len,
> + end_addr_high, end_addr_low));
> + pm8001_chip_make_sg(task->scatter, 1,
> + ccb->buf_prd);
> + phys_addr = ccb->ccb_dma_handle +
> + offsetof(struct pm8001_ccb_info,
> + buf_prd[0]);
> + ssp_cmd.addr_low =
> + cpu_to_le32(lower_32_bits(phys_addr));
> + ssp_cmd.addr_high =
> + cpu_to_le32(upper_32_bits(phys_addr));
> + ssp_cmd.e
Re: [PATCH V2 08/10] pm80xx: Queue rotation logic for inbound and outbound queues
On 09/26/2013 07:40 AM, Anand wrote:
> From 678d8085ace7c471dc140420c41dc4ad70300d60 Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Wed, 18 Sep 2013 11:12:59 +0530
> Subject: [PATCH V2 08/10] pm80xx: Queue rotation logic for inbound and
> outbound queues.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
>
I'd like to know the number of this improved for performance?
Jack
> ---
> drivers/scsi/pm8001/pm80xx_hwi.c | 31 +--
> 1 files changed, 13 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 80a10aa..ce59d0d 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -3715,8 +3715,7 @@ static int pm80xx_chip_ssp_io_req(struct
> pm8001_hba_info *pm8001_ha,
> int ret;
> u64 phys_addr;
> struct inbound_queue_table *circularQ;
> - static u32 inb;
> - static u32 outb;
> + u32 q_index;
> u32 opc = OPC_INB_SSPINIIOSTART;
> memset(&ssp_cmd, 0, sizeof(ssp_cmd));
> memcpy(ssp_cmd.ssp_iu.lun, task->ssp_task.LUN, 8);
> @@ -3735,7 +3734,8 @@ static int pm80xx_chip_ssp_io_req(struct
> pm8001_hba_info *pm8001_ha,
> ssp_cmd.ssp_iu.efb_prio_attr |= (task->ssp_task.task_attr & 7);
> memcpy(ssp_cmd.ssp_iu.cdb, task->ssp_task.cmd->cmnd,
> task->ssp_task.cmd->cmd_len);
> - circularQ = &pm8001_ha->inbnd_q_tbl[0];
> + q_index = (u32) (pm8001_dev->id & 0x00ff) % PM8001_MAX_INB_NUM;
> + circularQ = &pm8001_ha->inbnd_q_tbl[q_index];
>
> /* Check if encryption is set */
> if (pm8001_ha->chip->encrypt &&
> @@ -3783,7 +3783,7 @@ static int pm80xx_chip_ssp_io_req(struct
> pm8001_hba_info *pm8001_ha,
> } else {
> PM8001_IO_DBG(pm8001_ha, pm8001_printk(
> "Sending Normal SAS command 0x%x inb q %x\n",
> - task->ssp_task.cmd->cmnd[0], inb));
> + task->ssp_task.cmd->cmnd[0], q_index));
> /* fill in PRD (scatter/gather) table, if any */
> if (task->num_scatter > 1) {
> pm8001_chip_make_sg(task->scatter, ccb->n_elem,
> @@ -3809,11 +3809,9 @@ static int pm80xx_chip_ssp_io_req(struct
> pm8001_hba_info *pm8001_ha,
> ssp_cmd.esgl = 0;
> }
> }
> - ret = pm8001_mpi_build_cmd(pm8001_ha, circularQ, opc, &ssp_cmd, outb++);
> -
> - /* rotate the outb queue */
> - outb = outb%PM8001_MAX_SPCV_OUTB_NUM;
> -
> + q_index = (u32) (pm8001_dev->id & 0x00ff) % PM8001_MAX_OUTB_NUM;
> + ret = pm8001_mpi_build_cmd(pm8001_ha, circularQ, opc,
> + &ssp_cmd, q_index);
> return ret;
> }
>
> @@ -3825,8 +3823,7 @@ static int pm80xx_chip_sata_req(struct pm8001_hba_info
> *pm8001_ha,
> struct pm8001_device *pm8001_ha_dev = dev->lldd_dev;
> u32 tag = ccb->ccb_tag;
> int ret;
> - static u32 inb;
> - static u32 outb;
> + u32 q_index;
> struct sata_start_req sata_cmd;
> u32 hdr_tag, ncg_tag = 0;
> u64 phys_addr;
> @@ -3836,7 +3833,8 @@ static int pm80xx_chip_sata_req(struct pm8001_hba_info
> *pm8001_ha,
> unsigned long flags;
> u32 opc = OPC_INB_SATA_HOST_OPSTART;
> memset(&sata_cmd, 0, sizeof(sata_cmd));
> - circularQ = &pm8001_ha->inbnd_q_tbl[0];
> + q_index = (u32) (pm8001_ha_dev->id & 0x00ff) % PM8001_MAX_INB_NUM;
> + circularQ = &pm8001_ha->inbnd_q_tbl[q_index];
>
> if (task->data_dir == PCI_DMA_NONE) {
> ATAP = 0x04; /* no data*/
> @@ -3917,7 +3915,7 @@ static int pm80xx_chip_sata_req(struct pm8001_hba_info
> *pm8001_ha,
> } else {
> PM8001_IO_DBG(pm8001_ha, pm8001_printk(
> "Sending Normal SATA command 0x%x inb %x\n",
> - sata_cmd.sata_fis.command, inb));
> + sata_cmd.sata_fis.command, q_index));
> /* dad (bit 0-1) is 0 */
> sata_cmd.ncqtag_atap_dir_m_dad =
> cpu_to_le32(((ncg_tag & 0xff)<<16) |
> @@ -4014,12 +4012,9 @@ static int pm80xx_chip_sata_req(struct pm8001_hba_info
> *pm8001_ha,
> }
> }
> }
> -
> + q_index = (u32) (pm8001_ha_dev->id & 0x00ff) % PM8001_MAX_OUTB_NUM;
> ret = pm8001_mpi_build_cmd(pm8001_ha, circularQ, opc,
> - &sata_cmd, outb++);
> -
> - /* rotate the outb queue */
> - outb = outb%PM8001_MAX_SPCV_OUTB_NUM;
> + &sata_cmd, q_index);
> return ret;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 07/10] pm80xx: Set device state response logic fix.
On 09/26/2013 07:39 AM, Anand wrote:
> From edf018a942e0da4da12bad21e5bf0d48621a18de Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Tue, 17 Sep 2013 16:58:10 +0530
> Subject: [PATCH V2 07/10] pm80xx: Set device state response logic fix.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
>
Reviewed-by: Jack Wang
> ---
> drivers/scsi/pm8001/pm8001_hwi.c |6 --
> drivers/scsi/pm8001/pm8001_sas.c |9 -
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index c9cc744..502c7d6 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -3152,8 +3152,8 @@ void pm8001_mpi_set_dev_state_resp(struct
> pm8001_hba_info *pm8001_ha,
> struct pm8001_device *pm8001_dev = ccb->device;
> u32 status = le32_to_cpu(pPayload->status);
> u32 device_id = le32_to_cpu(pPayload->device_id);
> - u8 pds = le32_to_cpu(pPayload->pds_nds) | PDS_BITS;
> - u8 nds = le32_to_cpu(pPayload->pds_nds) | NDS_BITS;
> + u8 pds = le32_to_cpu(pPayload->pds_nds) & PDS_BITS;
> + u8 nds = le32_to_cpu(pPayload->pds_nds) & NDS_BITS;
> PM8001_MSG_DBG(pm8001_ha, pm8001_printk("Set device id = 0x%x state "
> "from 0x%x to 0x%x status = 0x%x!\n",
> device_id, pds, nds, status));
> @@ -4765,6 +4765,8 @@ int pm8001_chip_ssp_tm_req(struct pm8001_hba_info
> *pm8001_ha,
> sspTMCmd.tmf = cpu_to_le32(tmf->tmf);
> memcpy(sspTMCmd.lun, task->ssp_task.LUN, 8);
> sspTMCmd.tag = cpu_to_le32(ccb->ccb_tag);
> + if (pm8001_ha->chip_id != chip_8001)
> + sspTMCmd.ds_ads_m = 0x08;
> circularQ = &pm8001_ha->inbnd_q_tbl[0];
> ret = pm8001_mpi_build_cmd(pm8001_ha, circularQ, opc, &sspTMCmd, 0);
> return ret;
> diff --git a/drivers/scsi/pm8001/pm8001_sas.c
> b/drivers/scsi/pm8001/pm8001_sas.c
> index a85d73d..f4eb18e 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.c
> +++ b/drivers/scsi/pm8001/pm8001_sas.c
> @@ -447,7 +447,6 @@ static int pm8001_task_exec(struct sas_task *task, const
> int num,
> break;
> case SAS_PROTOCOL_SATA:
> case SAS_PROTOCOL_STP:
> - case SAS_PROTOCOL_SATA | SAS_PROTOCOL_STP:
> rc = pm8001_task_prep_ata(pm8001_ha, ccb);
> break;
> default:
> @@ -704,6 +703,8 @@ static int pm8001_exec_internal_tmf_task(struct
> domain_device *dev,
> int res, retry;
> struct sas_task *task = NULL;
> struct pm8001_hba_info *pm8001_ha = pm8001_find_ha_by_dev(dev);
> + struct pm8001_device *pm8001_dev = dev->lldd_dev;
> + DECLARE_COMPLETION_ONSTACK(completion_setstate);
>
> for (retry = 0; retry < 3; retry++) {
> task = sas_alloc_slow_task(GFP_KERNEL);
> @@ -729,6 +730,12 @@ static int pm8001_exec_internal_tmf_task(struct
> domain_device *dev,
> goto ex_err;
> }
> wait_for_completion(&task->slow_task->completion);
> + if (pm8001_ha->chip_id != chip_8001) {
> + pm8001_dev->setds_completion = &completion_setstate;
> + PM8001_CHIP_DISP->set_dev_state_req(pm8001_ha,
> + pm8001_dev, 0x01);
> + wait_for_completion(&completion_setstate);
> + }
> res = -TMF_RESP_FUNC_FAILED;
> /* Even TMF timed out, return direct. */
> if ((task->task_state_flags & SAS_TASK_STATE_ABORTED)) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 06/10] pm80xx: Print SAS address of IO failed device.
On 09/26/2013 07:37 AM, Anand wrote:
> From 5ddec5ef3033b4fee08dcdc7ba8b434425453e9d Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Tue, 17 Sep 2013 16:47:21 +0530
> Subject: [PATCH V2 06/10] pm80xx: Print SAS address of IO failed device.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
>
> ---
> drivers/scsi/pm8001/pm8001_hwi.c | 65
> ++
> drivers/scsi/pm8001/pm80xx_hwi.c | 65
> ++
> 2 files changed, 130 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index 2fd8c38..c9cc744 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -1868,6 +1868,13 @@ mpi_ssp_completion(struct pm8001_hba_info *pm8001_ha ,
> void *piomb)
> if (unlikely(!t || !t->lldd_task || !t->dev))
> return;
> ts = &t->task_status;
> + /* Print sas address of IO failed device */
> + if ((status != IO_SUCCESS) && (status != IO_OVERFLOW) &&
> + (status != IO_UNDERFLOW))
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("SAS Address of IO Failure Drive:"
> + "%016llx", SAS_ADDR(t->dev->sas_addr)-1));
> +
> switch (status) {
> case IO_SUCCESS:
> PM8001_IO_DBG(pm8001_ha, pm8001_printk("IO_SUCCESS"
> @@ -2276,6 +2283,11 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> u32 param;
> u32 status;
> u32 tag;
> + int i, j;
> + u8 sata_addr_low[4];
> + u32 temp_sata_addr_low;
> + u8 sata_addr_hi[4];
> + u32 temp_sata_addr_hi;
> struct sata_completion_resp *psataPayload;
> struct task_status_struct *ts;
> struct ata_task_resp *resp ;
> @@ -2325,7 +2337,60 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> pm8001_printk("ts null\n"));
> return;
> }
> + /* Print sas address of IO failed device */
> + if ((status != IO_SUCCESS) && (status != IO_OVERFLOW) &&
> + (status != IO_UNDERFLOW)) {
> + if (!((t->dev->parent) &&
> + (DEV_IS_EXPANDER(t->dev->parent->dev_type {
> + for (i = 0 , j = 4 ; j <= 7 && i <= 3 ; i++ , j++)
> + sata_addr_low[i] = pm8001_ha->sas_addr[j];
> + for (i = 0 , j = 0; j <= 3 && i <= 3; i++ , j++)
> + sata_addr_hi[i] = pm8001_ha->sas_addr[j];
> + memcpy(&temp_sata_addr_low, sata_addr_low,
> + sizeof(sata_addr_low));
> + memcpy(&temp_sata_addr_hi, sata_addr_hi,
> + sizeof(sata_addr_hi));
> + temp_sata_addr_hi = (((temp_sata_addr_hi >> 24) & 0xff)
> + |((temp_sata_addr_hi << 8) &
> + 0xff) |
> + ((temp_sata_addr_hi >> 8)
> + & 0xff00) |
> + ((temp_sata_addr_hi << 24) &
> + 0xff00));
> + temp_sata_addr_low = temp_sata_addr_low >> 24)
> + & 0xff) |
> + ((temp_sata_addr_low << 8)
> + & 0xff) |
> + ((temp_sata_addr_low >> 8)
> + & 0xff00) |
> + ((temp_sata_addr_low << 24)
> + & 0xff00)) +
> + pm8001_dev->attached_phy +
> + 0x10);
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("SAS Address of IO Failure Drive:"
> + "%08x%08x", temp_sata_addr_hi,
> + temp_sata_addr_low));
> + } else {
> + for (i = 0 , j = 4 ; j <= 7 && i <= 3; i++ , j++)
> + sata_addr_low[i] = t->dev->sas_addr[j];
> + for (i = 0 , j = 0 ; j <= 3 && i <= 3 ; i++ , j++)
> + sata_addr_hi[i] = t->dev->sas_addr[j];
> + temp_sata_addr_low = (sata_addr_low[0] << 24) |
> + (sata_addr_low[1] << 16) |
> + (sata_addr_low[2] << 8) |
> + (sata_addr_low[3]);
> + temp_sata_addr_hi = (sata_addr_hi[0] << 24)|
> + (sata_addr_hi[1] << 16)|
>
Re: [PATCH V2 05/10] pm80xx: Phy settings support for motherboard controller.
snip
> #ifdef PM8001_USE_MSIX
> /**
> * pm8001_setup_msix - enable MSI-X interrupt
> @@ -847,6 +872,9 @@ static int pm8001_pci_probe(struct pci_dev *pdev,
> }
>
> pm8001_init_sas_add(pm8001_ha);
> + /* phy setting support for motherboard controller */
> + if (pdev->subsystem_vendor != PCI_VENDOR_ID_ADAPTEC2)
> + pm8001_get_phy_settings_info(pm8001_ha);
Are you sure about this, have you checked all controller except device
with subsystem_vendorid is PCI_VENDOR_ID_ADAPTEC2 all support this
get_phy_setting_info funcion?
Jack
> pm8001_post_sas_ha_init(shost, chip);
> rc = sas_register_ha(SHOST_TO_SAS_HA(shost));
> if (rc)
> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
> b/drivers/scsi/pm8001/pm8001_sas.h
> index 68e1147..cbde11a 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.h
> +++ b/drivers/scsi/pm8001/pm8001_sas.h
> @@ -632,7 +632,8 @@ struct pm8001_device *pm8001_find_dev(struct
> pm8001_hba_info *pm8001_ha,
> int pm80xx_set_thermal_config(struct pm8001_hba_info *pm8001_ha);
>
> int pm8001_bar4_shift(struct pm8001_hba_info *pm8001_ha, u32 shiftValue);
> -
> +void pm8001_set_phy_profile(struct pm8001_hba_info *pm8001_ha,
> + u32 length, u8 *buf);
> /* ctl shared API */
> extern struct device_attribute *pm8001_host_attrs[];
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 99cec5f..e1ab320 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -3131,9 +3131,27 @@ static int mpi_flash_op_ext_resp(struct
> pm8001_hba_info *pm8001_ha, void *piomb)
> static int mpi_set_phy_profile_resp(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> {
> - PM8001_MSG_DBG(pm8001_ha,
> - pm8001_printk(" pm80xx_addition_functionality\n"));
> + u8 page_code;
> + struct set_phy_profile_resp *pPayload =
> + (struct set_phy_profile_resp *)(piomb + 4);
> + u32 ppc_phyid = le32_to_cpu(pPayload->ppc_phyid);
> + u32 status = le32_to_cpu(pPayload->status);
>
> + page_code = (u8)((ppc_phyid & 0xFF00) >> 8);
> + if (status) {
> + /* status is FAILED */
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("PhyProfile command failed with status "
> + "0x%08X \n", status));
> + return -1;
> + } else {
> + if (page_code != SAS_PHY_ANALOG_SETTINGS_PAGE) {
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("Invalid page code 0x%X\n",
> + page_code));
> + return -1;
> + }
> + }
> return 0;
> }
>
> @@ -4128,6 +4146,45 @@ pm80xx_chip_isr(struct pm8001_hba_info *pm8001_ha, u8
> vec)
> return IRQ_HANDLED;
> }
>
> +void mpi_set_phy_profile_req(struct pm8001_hba_info *pm8001_ha,
> + u32 operation, u32 phyid, u32 length, u32 *buf)
> +{
> + u32 tag , i, j = 0;
> + int rc;
> + struct set_phy_profile_req payload;
> + struct inbound_queue_table *circularQ;
> + u32 opc = OPC_INB_SET_PHY_PROFILE;
> +
> + memset(&payload, 0, sizeof(payload));
> + rc = pm8001_tag_alloc(pm8001_ha, &tag);
> + if (rc)
> + PM8001_FAIL_DBG(pm8001_ha, pm8001_printk("Invalid tag\n"));
> + circularQ = &pm8001_ha->inbnd_q_tbl[0];
> + payload.tag = cpu_to_le32(tag);
> + payload.ppc_phyid = (((operation & 0xF) << 8) | (phyid & 0xFF));
> + PM8001_INIT_DBG(pm8001_ha,
> + pm8001_printk(" phy profile command for phy %x ,length is %d\n",
> + payload.ppc_phyid, length));
> + for (i = length ; i < (length + PHY_DWORD_LENGTH - 1) ; i++) {
> + payload.reserved[j] = cpu_to_le32(*((u32 *)buf + i));
> + j++;
> + }
> + pm8001_mpi_build_cmd(pm8001_ha, circularQ, opc, &payload, 0);
> +}
> +
> +void pm8001_set_phy_profile(struct pm8001_hba_info *pm8001_ha,
> + u32 length, u8 *buf)
> +{
> + u32 page_code, i;
> +
> + page_code = SAS_PHY_ANALOG_SETTINGS_PAGE;
> + for (i = 0 ; i < pm8001_ha->chip->n_phy ; i++) {
> + mpi_set_phy_profile_req(pm8001_ha,
> + SAS_PHY_ANALOG_SETTINGS_PAGE, i, length, (u32 *)buf);
> + length = length + PHY_DWORD_LENGTH;
> + }
> + PM8001_INIT_DBG(pm8001_ha, pm8001_printk("phy settings completed\n"));
> +}
> const struct pm8001_dispatch pm8001_80xx_dispatch = {
> .name = "pmc80xx",
> .chip_init = pm80xx_chip_init,
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.h
> b/drivers/scsi/pm8001/pm80xx_hwi.h
> index 9a9116d..872d5cf 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.h
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.h
> @@ -170,6 +170,10 @@
> #define LINKRATE_60 (0x06 << 8)
> #define LINKRATE_120 (0x08 << 8)
>
> +/* phy_profile */
> +#define SAS_PHY_ANA
Re: [PATCH V2 04/10] pm80xx: Display controller BIOS version
On 09/26/2013 07:33 AM, Anand wrote:
> From 851461e0998c46ac15fb6eac6e14843e50e9714b Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Wed, 18 Sep 2013 12:54:41 +0530
> Subject: [PATCH V2 04/10] pm80xx: Display controller BIOS version.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
>
As I know no all controller with BIOS support, but it's fine to have this.
Reviewed-by: Jack Wang
> ---
> drivers/scsi/pm8001/pm8001_ctl.c | 34 ++
> drivers/scsi/pm8001/pm8001_ctl.h |2 ++
> 2 files changed, 36 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_ctl.c
> b/drivers/scsi/pm8001/pm8001_ctl.c
> index d99f41c..5a19e19 100644
> --- a/drivers/scsi/pm8001/pm8001_ctl.c
> +++ b/drivers/scsi/pm8001/pm8001_ctl.c
> @@ -309,6 +309,39 @@ static ssize_t pm8001_ctl_aap_log_show(struct device
> *cdev,
> }
> static DEVICE_ATTR(aap_log, S_IRUGO, pm8001_ctl_aap_log_show, NULL);
> /**
> + * pm8001_ctl_bios_version_show - Bios version Display
> + * @cdev:pointer to embedded class device
> + * @buf:the buffer returned
> + * A sysfs 'read-only' shost attribute.
> + */
> +static ssize_t pm8001_ctl_bios_version_show(struct device *cdev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct Scsi_Host *shost = class_to_shost(cdev);
> + struct sas_ha_struct *sha = SHOST_TO_SAS_HA(shost);
> + struct pm8001_hba_info *pm8001_ha = sha->lldd_ha;
> + char *str = buf;
> + void *virt_addr;
> + int bios_index;
> + DECLARE_COMPLETION_ONSTACK(completion);
> + struct pm8001_ioctl_payload payload;
> +
> + pm8001_ha->nvmd_completion = &completion;
> + payload.minor_function = 7;
> + payload.offset = 0;
> + payload.length = 4096;
> + payload.func_specific = kzalloc(4096, GFP_KERNEL);
> + PM8001_CHIP_DISP->get_nvmd_req(pm8001_ha, &payload);
> + wait_for_completion(&completion);
> + virt_addr = pm8001_ha->memoryMap.region[NVMD].virt_ptr;
> + for (bios_index = BIOSOFFSET; bios_index < BIOS_OFFSET_LIMIT;
> + bios_index++)
> + str += sprintf(str, "%c",
> + *((u8 *)((u8 *)virt_addr+bios_index)));
> + return str - buf;
> +}
> +static DEVICE_ATTR(bios_version, S_IRUGO, pm8001_ctl_bios_version_show,
> NULL);
> +/**
> * pm8001_ctl_aap_log_show - IOP event log
> * @cdev: pointer to embedded class device
> * @buf: the buffer returned
> @@ -609,6 +642,7 @@ struct device_attribute *pm8001_host_attrs[] = {
> &dev_attr_sas_spec_support,
> &dev_attr_logging_level,
> &dev_attr_host_sas_address,
> + &dev_attr_bios_version,
> NULL,
> };
>
> diff --git a/drivers/scsi/pm8001/pm8001_ctl.h
> b/drivers/scsi/pm8001/pm8001_ctl.h
> index 63ad4aa..c6d8fdd 100644
> --- a/drivers/scsi/pm8001/pm8001_ctl.h
> +++ b/drivers/scsi/pm8001/pm8001_ctl.h
> @@ -45,6 +45,8 @@
> #define HEADER_LEN 28
> #define SIZE_OFFSET 16
>
> +#define BIOSOFFSET 56
> +#define BIOS_OFFSET_LIMIT61
>
> #define FLASH_OK0x00
> #define FAIL_OPEN_BIOS_FILE 0x000100
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 03/10] pm80xx: Indirect SMP request fix
On 09/26/2013 07:30 AM, Anand wrote: > From adf0140b2a05f51f6cb9ccefd0f82f3905b0692b Mon Sep 17 00:00:00 2001 > From: Anand Kumar Santhanam > Date: Tue, 17 Sep 2013 14:37:14 +0530 > Subject: [PATCH V2 03/10] pm80xx: Indirect SMP request fix. > > Fix for indirect data transfer mode in case of SMP request. > > Signed-off-by: anandkumar.santha...@pmcs.com > Reviewed-by: Jack Wang > --- > drivers/scsi/pm8001/pm80xx_hwi.c |4 +--- > 1 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c > b/drivers/scsi/pm8001/pm80xx_hwi.c > index 912dfec..99cec5f 100644 > --- a/drivers/scsi/pm8001/pm80xx_hwi.c > +++ b/drivers/scsi/pm8001/pm80xx_hwi.c > @@ -3512,8 +3512,6 @@ static int pm80xx_chip_smp_req(struct pm8001_hba_info > *pm8001_ha, > else > pm8001_ha->smp_exp_mode = SMP_INDIRECT; > > - /* DIRECT MODE support only in spcv/ve */ > - pm8001_ha->smp_exp_mode = SMP_DIRECT; > > tmp_addr = cpu_to_le64((u64)sg_dma_address(&task->smp_task.smp_req)); > preq_dma_addr = (char *)phys_to_virt(tmp_addr); > @@ -3529,7 +3527,7 @@ static int pm80xx_chip_smp_req(struct pm8001_hba_info > *pm8001_ha, > /* exclude top 4 bytes for SMP req header */ > smp_cmd.long_smp_req.long_req_addr = > cpu_to_le64((u64)sg_dma_address > - (&task->smp_task.smp_req) - 4); > + (&task->smp_task.smp_req) + 4); > /* exclude 4 bytes for SMP req header and CRC */ > smp_cmd.long_smp_req.long_req_size = > cpu_to_le32((u32)sg_dma_len(&task->smp_task.smp_req)-8); > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 02/10] pm80xx: IButton feature support for motherboard controllers.
On 09/26/2013 07:28 AM, Anand wrote:
> From d6b5e5d88f424b334c9b9c241f988b9eec1a70c7 Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Tue, 17 Sep 2013 14:32:20 +0530
> Subject: [PATCH V2 02/10] pm80xx: IButton feature support for motherboard
> controllers.
>
> IButton security feature support for motherboard controllers.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
Reviewed-by: Jack Wang
>
> ---
> drivers/scsi/pm8001/pm80xx_hwi.c | 22 +-
> 1 files changed, 21 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 8efac42..912dfec 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -967,6 +967,7 @@ pm80xx_chip_soft_rst(struct pm8001_hba_info *pm8001_ha)
> {
> u32 regval;
> u32 bootloader_state;
> + u32 ibutton0, ibutton1;
>
> /* Check if MPI is in ready state to reset */
> if (mpi_uninit_check(pm8001_ha) != 0) {
> @@ -1025,7 +1026,26 @@ pm80xx_chip_soft_rst(struct pm8001_hba_info *pm8001_ha)
> if (-1 == check_fw_ready(pm8001_ha)) {
> PM8001_FAIL_DBG(pm8001_ha,
> pm8001_printk("Firmware is not ready!\n"));
> - return -EBUSY;
> + /* check iButton feature support for motherboard controller */
> + if (pm8001_ha->pdev->subsystem_vendor !=
> + PCI_VENDOR_ID_ADAPTEC2) {
> + ibutton0 = pm8001_cr32(pm8001_ha, 0,
> + MSGU_HOST_SCRATCH_PAD_6);
> + ibutton1 = pm8001_cr32(pm8001_ha, 0,
> + MSGU_HOST_SCRATCH_PAD_7);
> + if (!ibutton0 && !ibutton1) {
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("iButton Feature is"
> + " not Available!!!\n"));
> + return -EBUSY;
> + }
> + if (ibutton0 == 0xdeadbeef && ibutton1 == 0xdeadbeef) {
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("CRC Check for iButton"
> + " Feature Failed!!!\n"));
> + return -EBUSY;
> + }
> + }
> }
> PM8001_INIT_DBG(pm8001_ha,
> pm8001_printk("SPCv soft reset Complete\n"));
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 01/10] pm80xx: Device id changes to support series 8 controllers.
snip >*/ > payload.ase_sh_lm_slr_phyid = cpu_to_le32(SPINHOLD_DISABLE | > LINKMODE_AUTO | LINKRATE_15 | > - LINKRATE_30 | LINKRATE_60 | phy_id); > + LINKRATE_30 | LINKRATE_60 | LINKRATE_120 | phy_id); Is it safe to set 12g linkrate support also on 6g, if so, then : Reviewed-by: Jack Wang > /* SSC Disable and SAS Analog ST configuration */ > /** > payload.ase_sh_lm_slr_phyid = > diff --git a/drivers/scsi/pm8001/pm80xx_hwi.h > b/drivers/scsi/pm8001/pm80xx_hwi.h > index 2b760ba..9a9116d 100644 > --- a/drivers/scsi/pm8001/pm80xx_hwi.h > +++ b/drivers/scsi/pm8001/pm80xx_hwi.h > @@ -168,6 +168,7 @@ > #define LINKRATE_15 (0x01 << 8) > #define LINKRATE_30 (0x02 << 8) > #define LINKRATE_60 (0x06 << 8) > +#define LINKRATE_120 (0x08 << 8) > > /* Thermal related */ > #define THERMAL_ENABLE 0x1 > @@ -1223,10 +1224,10 @@ typedef struct SASProtocolTimerConfig > SASProtocolTimerConfig_t; > > /* MSGU CONFIGURATION TABLE*/ > > -#define SPCv_MSGU_CFG_TABLE_UPDATE 0x01 > -#define SPCv_MSGU_CFG_TABLE_RESET0x02 > -#define SPCv_MSGU_CFG_TABLE_FREEZE 0x04 > -#define SPCv_MSGU_CFG_TABLE_UNFREEZE 0x08 > +#define SPCv_MSGU_CFG_TABLE_UPDATE 0x001 > +#define SPCv_MSGU_CFG_TABLE_RESET0x002 > +#define SPCv_MSGU_CFG_TABLE_FREEZE 0x004 > +#define SPCv_MSGU_CFG_TABLE_UNFREEZE 0x008 > #define MSGU_IBDB_SET0x00 > #define MSGU_HOST_INT_STATUS 0x08 > #define MSGU_HOST_INT_MASK 0x0C > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Drivers: scsi: FLUSH timeout
On 09/21/2013 07:24 AM, KY Srinivasan wrote: > > >> -Original Message- >> From: Greg KH [mailto:gre...@linuxfoundation.org] >> Sent: Friday, September 20, 2013 1:32 PM >> To: KY Srinivasan >> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; >> oher...@suse.com; jbottom...@parallels.com; h...@infradead.org; linux- >> s...@vger.kernel.org >> Subject: Re: Drivers: scsi: FLUSH timeout >> >> On Fri, Sep 20, 2013 at 12:32:27PM -0700, K. Y. Srinivasan wrote: >>> The SD_FLUSH_TIMEOUT value is currently hardcoded. >> >> Hardcoded where? Please, more context. > > This is defined in scsi/sd.h: > > #define SD_FLUSH_TIMEOUT(60 * HZ) >> >>> On our cloud, we sometimes hit this timeout. I was wondering if we >>> could make this a module parameter. If this is acceptable, I can send >>> you a patch for this. >> >> A module parameter don't make sense for a per-device value, does it? > Currently, the 60 second timeout is applied across devices. Ideally, I want > to be > able to control the FLUSH TIMEOUT as we currently do I/O timeout. If this is > acceptable, I can work on a patch for that as well. > > Regards, > > K. Y >> >> greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Hi, Back to 2010, Mike(cc-ed) try to add a flush time out interface, similar to what you want here, no idea why it's just ignored? http://www.spinics.net/lists/linux-scsi/msg45017.html Jack -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bypass block layer and Fill SCSI lower layer driver queue
On 09/18/2013 08:41 AM, Alireza Haghdoost wrote: > Hi > > I am working on a high throughput and low latency application which > does not tolerate block layer overhead to send IO request directly to > fiber channel lower layer SCSI driver. I used to work with libaio but > currently I am looking for a way to by pass the block layer and send > SCSI commands from the application layer directly to the SCSI driver > using /dev/sgX device and ioctl() system call. > > I have noticed that sending IO request through sg device even with > nonblocking and direct IO flags is quite slow and does not fill up > lower layer SCSI driver TCQ queue. i.e IO depth or > /sys/block/sdX/in_flight is always ZERO. Therefore the application > throughput is even lower that sending IO request through block layer > with libaio and io_submit() system call. In both cases I used only one > IO context (or fd) and single threaded. > Hi Alireza, I think what you want is in_flight command scsi dispatch to low level device. I submit a simple patch to export device_busy http://www.spinics.net/lists/linux-scsi/msg68697.html I also notice fio sg engine will not fill queue properly, but haven't look into deeper. Cheers Jack > I have noticed that some well known benchmarking tools like fio does > not support IO depth for sg devices as well. Therefore, I was > wondering if it is feasible to bypass block layer and achieve higher > throughput and lower latency (for sending IO request only). > > > Any comment on my issue is highly appreciated. > > > Thanks > Alireza > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] pm80xx: Print SAS address of IO failed device, 4G boundary fix.
On 09/16/2013 05:58 PM, Anand wrote:
> From 3574b24db1a5472df9cef88010fabad7742351e5 Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Tue, 3 Sep 2013 16:55:54 +0530
> Subject: [PATCH 4/5] pm80xx: Print SAS address of IO failed device, 4G
> boundary fix.
>
> Added queue rotation logic to improve IO performance.
> Print sas address of failed IO device.
> Fix for single SG crossing 4G boundary.
>
Similar here, please split the patch into at least 4:
1 queue rotation logic
2 print sas address support
3 sg boundary fix
4 set device state rsp logic fix
Jack
> Signed-off-by: anandkumar.santha...@pmcs.com
>
> ---
> drivers/scsi/pm8001/pm8001_hwi.c | 71 +-
> drivers/scsi/pm8001/pm8001_init.c |4 +
> drivers/scsi/pm8001/pm8001_sas.c |9 ++-
> drivers/scsi/pm8001/pm80xx_hwi.c | 199
> +
> 4 files changed, 260 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_hwi.c
> b/drivers/scsi/pm8001/pm8001_hwi.c
> index 2fd8c38..502c7d6 100644
> --- a/drivers/scsi/pm8001/pm8001_hwi.c
> +++ b/drivers/scsi/pm8001/pm8001_hwi.c
> @@ -1868,6 +1868,13 @@ mpi_ssp_completion(struct pm8001_hba_info *pm8001_ha ,
> void *piomb)
> if (unlikely(!t || !t->lldd_task || !t->dev))
> return;
> ts = &t->task_status;
> + /* Print sas address of IO failed device */
> + if ((status != IO_SUCCESS) && (status != IO_OVERFLOW) &&
> + (status != IO_UNDERFLOW))
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("SAS Address of IO Failure Drive:"
> + "%016llx", SAS_ADDR(t->dev->sas_addr)-1));
> +
> switch (status) {
> case IO_SUCCESS:
> PM8001_IO_DBG(pm8001_ha, pm8001_printk("IO_SUCCESS"
> @@ -2276,6 +2283,11 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> u32 param;
> u32 status;
> u32 tag;
> + int i, j;
> + u8 sata_addr_low[4];
> + u32 temp_sata_addr_low;
> + u8 sata_addr_hi[4];
> + u32 temp_sata_addr_hi;
> struct sata_completion_resp *psataPayload;
> struct task_status_struct *ts;
> struct ata_task_resp *resp ;
> @@ -2325,7 +2337,60 @@ mpi_sata_completion(struct pm8001_hba_info *pm8001_ha,
> void *piomb)
> pm8001_printk("ts null\n"));
> return;
> }
> + /* Print sas address of IO failed device */
> + if ((status != IO_SUCCESS) && (status != IO_OVERFLOW) &&
> + (status != IO_UNDERFLOW)) {
> + if (!((t->dev->parent) &&
> + (DEV_IS_EXPANDER(t->dev->parent->dev_type {
> + for (i = 0 , j = 4 ; j <= 7 && i <= 3 ; i++ , j++)
> + sata_addr_low[i] = pm8001_ha->sas_addr[j];
> + for (i = 0 , j = 0; j <= 3 && i <= 3; i++ , j++)
> + sata_addr_hi[i] = pm8001_ha->sas_addr[j];
> + memcpy(&temp_sata_addr_low, sata_addr_low,
> + sizeof(sata_addr_low));
> + memcpy(&temp_sata_addr_hi, sata_addr_hi,
> + sizeof(sata_addr_hi));
> + temp_sata_addr_hi = (((temp_sata_addr_hi >> 24) & 0xff)
> + |((temp_sata_addr_hi << 8) &
> + 0xff) |
> + ((temp_sata_addr_hi >> 8)
> + & 0xff00) |
> + ((temp_sata_addr_hi << 24) &
> + 0xff00));
> + temp_sata_addr_low = temp_sata_addr_low >> 24)
> + & 0xff) |
> + ((temp_sata_addr_low << 8)
> + & 0xff) |
> + ((temp_sata_addr_low >> 8)
> + & 0xff00) |
> + ((temp_sata_addr_low << 24)
> + & 0xff00)) +
> + pm8001_dev->attached_phy +
> + 0x10);
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("SAS Address of IO Failure Drive:"
> + "%08x%08x", temp_sata_addr_hi,
> + temp_sata_addr_low));
> + } else {
> + for (i = 0 , j = 4 ; j <= 7 && i <= 3; i++ , j++)
> + sata_addr_low[i] = t->dev->sas_addr[j];
> + for (i = 0 , j = 0 ; j <= 3 && i <= 3 ; i++ , j++)
> + sata_addr_hi[i] = t->dev->sas_addr[j];
> + temp_sata_addr_low =
Re: [PATCH 1/5] pm80xx: Device id changes to support series 8 controllers.
On 09/16/2013 05:52 PM, Anand wrote:
> From 97828e9274b0bd1a26c3161a3297ad4c7d9512be Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Tue, 3 Sep 2013 15:09:42 +0530
> Subject: [PATCH 1/5] pm80xx: Device id changes to support series 8
> controllers.
>
> Updated pci id table with device, vendor, subdevice and subvendor ids
> for 8074, 8076, 8077 SAS/SATA 12G controllers. Added 12G related macros.
>
> Signed-off-by: anandkumar.santha...@pmcs.com
>
> ---
> drivers/scsi/pm8001/pm8001_defs.h |5 -
> drivers/scsi/pm8001/pm8001_init.c | 32 +++-
> drivers/scsi/pm8001/pm8001_sas.h |4
> drivers/scsi/pm8001/pm80xx_hwi.c | 14 +++---
> drivers/scsi/pm8001/pm80xx_hwi.h |9 +
> 5 files changed, 55 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_defs.h
> b/drivers/scsi/pm8001/pm8001_defs.h
> index 479c5a7..4bb304d 100644
> --- a/drivers/scsi/pm8001/pm8001_defs.h
> +++ b/drivers/scsi/pm8001/pm8001_defs.h
> @@ -46,7 +46,10 @@ enum chip_flavors {
> chip_8008,
> chip_8009,
> chip_8018,
> - chip_8019
> + chip_8019,
> + chip_8074,
> + chip_8076,
> + chip_8077
> };
>
> enum phy_speed {
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index 61f5405..09e557b 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -54,6 +54,9 @@ static const struct pm8001_chip_info pm8001_chips[] = {
> [chip_8009] = {1, 8, &pm8001_80xx_dispatch,},
> [chip_8018] = {0, 16, &pm8001_80xx_dispatch,},
> [chip_8019] = {1, 16, &pm8001_80xx_dispatch,},
> + [chip_8074] = {0, 8, &pm8001_80xx_dispatch,},
> + [chip_8076] = {0, 16, &pm8001_80xx_dispatch,},
> + [chip_8077] = {0, 16, &pm8001_80xx_dispatch,},
> };
> static int pm8001_id;
>
> @@ -1037,6 +1040,12 @@ static struct pci_device_id pm8001_pci_table[] = {
> { PCI_VDEVICE(ADAPTEC2, 0x8009), chip_8009 },
> { PCI_VDEVICE(PMC_Sierra, 0x8019), chip_8019 },
> { PCI_VDEVICE(ADAPTEC2, 0x8019), chip_8019 },
> + { PCI_VDEVICE(PMC_Sierra, 0x8074), chip_8074 },
> + { PCI_VDEVICE(ADAPTEC2, 0x8074), chip_8074 },
> + { PCI_VDEVICE(PMC_Sierra, 0x8076), chip_8076 },
> + { PCI_VDEVICE(ADAPTEC2, 0x8076), chip_8076 },
> + { PCI_VDEVICE(PMC_Sierra, 0x8077), chip_8077 },
> + { PCI_VDEVICE(ADAPTEC2, 0x8077), chip_8077 },
> { PCI_VENDOR_ID_ADAPTEC2, 0x8081,
> PCI_VENDOR_ID_ADAPTEC2, 0x0400, 0, 0, chip_8001 },
> { PCI_VENDOR_ID_ADAPTEC2, 0x8081,
> @@ -1057,6 +1066,24 @@ static struct pci_device_id pm8001_pci_table[] = {
> PCI_VENDOR_ID_ADAPTEC2, 0x0016, 0, 0, chip_8019 },
> { PCI_VENDOR_ID_ADAPTEC2, 0x8089,
> PCI_VENDOR_ID_ADAPTEC2, 0x1600, 0, 0, chip_8019 },
> + { PCI_VENDOR_ID_ADAPTEC2, 0x8074,
> + PCI_VENDOR_ID_ADAPTEC2, 0x0800, 0, 0, chip_8074 },
> + { PCI_VENDOR_ID_ADAPTEC2, 0x8076,
> + PCI_VENDOR_ID_ADAPTEC2, 0x1600, 0, 0, chip_8076 },
> + { PCI_VENDOR_ID_ADAPTEC2, 0x8077,
> + PCI_VENDOR_ID_ADAPTEC2, 0x1600, 0, 0, chip_8077 },
> + { PCI_VENDOR_ID_ADAPTEC2, 0x8074,
> + PCI_VENDOR_ID_ADAPTEC2, 0x0008, 0, 0, chip_8074 },
> + { PCI_VENDOR_ID_ADAPTEC2, 0x8076,
> + PCI_VENDOR_ID_ADAPTEC2, 0x0016, 0, 0, chip_8076 },
> + { PCI_VENDOR_ID_ADAPTEC2, 0x8077,
> + PCI_VENDOR_ID_ADAPTEC2, 0x0016, 0, 0, chip_8077 },
> + { PCI_VENDOR_ID_ADAPTEC2, 0x8076,
> + PCI_VENDOR_ID_ADAPTEC2, 0x0808, 0, 0, chip_8076 },
> + { PCI_VENDOR_ID_ADAPTEC2, 0x8077,
> + PCI_VENDOR_ID_ADAPTEC2, 0x0808, 0, 0, chip_8077 },
> + { PCI_VENDOR_ID_ADAPTEC2, 0x8074,
> + PCI_VENDOR_ID_ADAPTEC2, 0x0404, 0, 0, chip_8074 },
> {} /* terminate list */
> };
>
> @@ -1108,8 +1135,11 @@ module_init(pm8001_init);
> module_exit(pm8001_exit);
>
> MODULE_AUTHOR("Jack Wang ");
> +MODULE_AUTHOR("Anand Kumar Santhanam ");
> +MODULE_AUTHOR("Sangeetha Gnanasekaran ");
> MODULE_DESCRIPTION(
> - "PMC-Sierra PM8001/8081/8088/8089 SAS/SATA controller driver");
> + "PMC-Sierra PM8001/8081/8088/8089/8074/8076/8077"
> + "SAS/SATA controller driver");
> MODULE_VERSION(DRV_VERSION);
> MODULE_LICENSE("GPL");
> MODULE_DEVICE_TABLE(pci, pm8001_pci_table);
> diff --git a/drivers/scsi/pm8001/pm8001_sas.h
> b/drivers/scsi/pm8001/pm8001_sas.h
> index 5708194..a4fe235 100644
> --- a/drivers/scsi/pm8001/pm8001_sas.h
> +++ b
Re: [PATCH 2/5] pm80xx: IButton feature support and Indirect SMP fix.
On 09/16/2013 05:53 PM, Anand wrote:
> From db345f70bef0b07655d887f2d0398faf666f4a48 Mon Sep 17 00:00:00 2001
> From: Anand Kumar Santhanam
> Date: Tue, 3 Sep 2013 15:21:29 +0530
> Subject: [PATCH 2/5] pm80xx: IButton feature support and Indirect SMP fix.
>
> IButton security feature support for motherboard controllers.
> Fix for indirect data transfer mode in case of SMP request.
>
You'd better split this into two patches for bisect-able.
Jack
> Signed-off-by: anandkumar.santha...@pmcs.com
>
> ---
> drivers/scsi/pm8001/pm80xx_hwi.c | 26 ++
> 1 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index be0b394..158e91d 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -967,6 +967,7 @@ pm80xx_chip_soft_rst(struct pm8001_hba_info *pm8001_ha)
> {
> u32 regval;
> u32 bootloader_state;
> + u32 ibutton0, ibutton1;
>
> /* Check if MPI is in ready state to reset */
> if (mpi_uninit_check(pm8001_ha) != 0) {
> @@ -1025,7 +1026,26 @@ pm80xx_chip_soft_rst(struct pm8001_hba_info *pm8001_ha)
> if (-1 == check_fw_ready(pm8001_ha)) {
> PM8001_FAIL_DBG(pm8001_ha,
> pm8001_printk("Firmware is not ready!\n"));
> - return -EBUSY;
> + /* check iButton feature support for motherboard controller */
> + if (pm8001_ha->pdev->subsystem_vendor !=
> + PCI_VENDOR_ID_ADAPTEC2) {
> + ibutton0 = pm8001_cr32(pm8001_ha, 0,
> + MSGU_HOST_SCRATCH_PAD_6);
> + ibutton1 = pm8001_cr32(pm8001_ha, 0,
> + MSGU_HOST_SCRATCH_PAD_7);
> + if (!ibutton0 && !ibutton1) {
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("iButton Feature is"
> + " not Available!!!\n"));
> + return -EBUSY;
> + }
> + if (ibutton0 == 0xdeadbeef && ibutton1 == 0xdeadbeef) {
> + PM8001_FAIL_DBG(pm8001_ha,
> + pm8001_printk("CRC Check for iButton"
> + " Feature Failed!!!\n"));
> + return -EBUSY;
> + }
> + }
> }
> PM8001_INIT_DBG(pm8001_ha,
> pm8001_printk("SPCv soft reset Complete\n"));
> @@ -3492,8 +3512,6 @@ static int pm80xx_chip_smp_req(struct pm8001_hba_info
> *pm8001_ha,
> else
> pm8001_ha->smp_exp_mode = SMP_INDIRECT;
>
> - /* DIRECT MODE support only in spcv/ve */
> - pm8001_ha->smp_exp_mode = SMP_DIRECT;
>
> tmp_addr = cpu_to_le64((u64)sg_dma_address(&task->smp_task.smp_req));
> preq_dma_addr = (char *)phys_to_virt(tmp_addr);
> @@ -3509,7 +3527,7 @@ static int pm80xx_chip_smp_req(struct pm8001_hba_info
> *pm8001_ha,
> /* exclude top 4 bytes for SMP req header */
> smp_cmd.long_smp_req.long_req_addr =
> cpu_to_le64((u64)sg_dma_address
> - (&task->smp_task.smp_req) - 4);
> + (&task->smp_task.smp_req) + 4);
> /* exclude 4 bytes for SMP req header and CRC */
> smp_cmd.long_smp_req.long_req_size =
> cpu_to_le32((u32)sg_dma_len(&task->smp_task.smp_req)-8);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]export device_busy for sdev
Hi James,
Attached please find patch for export device_busy for sdev.
The reason I do this is:
Sometime we see doing IO on several devices, on device may starve
others, eg:
I run fio on top the 4 disks exported by scst using srp:
(SRP default can_queue/cmd_per_lun is 62)
/dev/sdb: (g=0): rw=randread, bs=4K-16K/4K-16K/4K-16K, ioenine=libaio,
iodepth=64
/dev/sdc: (g=0): rw=randread, bs=4K-16K/4K-16K/4K-16K, ioengine=libaio,
iodepth=64
/dev/sdd: (g=0): rw=randread, bs=4K-16K/4K-16K/4K-16K, ioengine=libaio,
iodepth=64
> sdb: ios=16393/0, merge=2770/0, ticks=863050/0, in_queue=870110, util=99.43%
> sdc: ios=5896/0, merge=0/0, ticks=997110/0, in_queue=1006470, util=99.52%
> sdd: ios=15976/0, merge=0/0, ticks=978850/0, in_queue=984960, util=99.38%
A monitor to read device_busy every seconds show:
> Sleeping for 1 seconds...
> Getting device busy data for sdb 0(tstamp=20130912172053)...
> Getting device busy data for sdc 62(tstamp=20130912172053)...
> Getting device busy data for sde 0(tstamp=20130912172053)...
>
> Sleeping for 1 seconds...
> Getting device busy data for sdb 0(tstamp=20130912172054)...
> Getting device busy data for sdc 62(tstamp=20130912172054)...
> Getting device busy data for sde 0(tstamp=20130912172054)...
>
> Sleeping for 1 seconds...
> Getting device busy data for sdb 0(tstamp=20130912172055)...
> Getting device busy data for sdc 62(tstamp=20130912172055)...
> Getting device busy data for sde 0(tstamp=20130912172055)...
Which give admin more hint about the situation.
Best regards,
Jack
>From cbca8a40fe3837789129e210365488d329d8a440 Mon Sep 17 00:00:00 2001
From: Jack Wang
Date: Thu, 12 Sep 2013 16:57:16 +0200
Subject: [PATCH] export device_busy for sdev
If you mutiple devices connect to a host, we might be interested in
have an intensive I/O workload on one disk, and notice starvation on others.
This give the user more hint about current infight io for scsi device.
Signed-off-by: Jack Wang
---
drivers/scsi/scsi_sysfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 40c6394..a734710 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -529,6 +529,7 @@ static int scsi_sdev_check_buf_bit(const char *buf)
*/
sdev_rd_attr (device_blocked, "%d\n");
sdev_rd_attr (queue_depth, "%d\n");
+sdev_rd_attr (device_busy, "%d\n");
sdev_rd_attr (type, "%d\n");
sdev_rd_attr (scsi_level, "%d\n");
sdev_rd_attr (vendor, "%.8s\n");
@@ -750,6 +751,7 @@ static struct attribute *scsi_sdev_attrs[] = {
&dev_attr_device_blocked.attr,
&dev_attr_type.attr,
&dev_attr_scsi_level.attr,
+ &dev_attr_device_busy.attr,
&dev_attr_vendor.attr,
&dev_attr_model.attr,
&dev_attr_rev.attr,
--
1.8.4
Re: [PATCHv2] pm80xx: fix Adaptec 71605H hang
On 07/31/2013 05:19 PM, Jack Wang wrote: > On 07/26/2013 06:43 PM, Hans Verkuil wrote: >> The IO command size is 128 bytes for these new controllers as opposed to 64 >> for the old 8001 controller. >> >> The Adaptec out-of-tree driver did this correctly. After comparing the two >> this turned out to be the crucial difference. >> >> So don't hardcode the IO command size, instead use pm8001_ha->iomb_size as >> that is the correct value for both old and new controllers. >> >> Signed-off-by: Hans Verkuil >> Cc: sta...@vger.kernel.org # for v3.10 and up > snip > > Thanks Hans. > Looks good now. > > Acked-by: Jack Wang > > James, > > Could you consider to include this fix into your fixes tree, without > this fix new Adaptec controller support is broken, sorry for that. > > > Jack > Hi, James, Could you include this patch, or you need we resend? KR Jack -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: aic94xx and kernel panic
On 08/19/2013 01:26 PM, Evgeny wrote: > I've tried 3.10.2 and it's also affected. > > Could you recommend something else? Could you enable LIST_DEBUG in your kernel hacking and retry? It looks like it bug_on list not empty as expected, some ascb->list may need &asd_ha->seq.pend_q_lock protection, you need to figure out your self. PS: the aic94xx is out of maintain for some years as I see. You may need to update to newer hardware. Jack > > > 19.08.2013 12:03, Jack Wang пишет: >> On 08/16/2013 10:26 AM, Evgeny wrote: >>> Hello. >>> >>> I've been testing vanilla 3.4.45 (config attached), 3.4.56 kernels on >>> centos 5.9 with Adaptec AIC-9410W SAS controller: >> There's some fix in libsas about error handle , As I remember most of >> patch finally merged in 3.7, could you try newer kernel? >> >> KR >> Jack >>> >>> 09:02.0 RAID bus controller: Adaptec AIC-9410W SAS (Razor ASIC RAID) >>> (rev 09) >>> Subsystem: Super Micro Computer Inc Device 9280 >>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ >>> Stepping- SERR+ FastB2B- DisINTx- >>> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- >>> SERR- >> Latency: 64 (32000ns min, 26750ns max), Cache Line Size: 32 bytes >>> Interrupt: pin A routed to IRQ 18 >>> Region 0: Memory at d830 (64-bit, non-prefetchable) [size=256K] >>> Region 2: Memory at d800 (64-bit, prefetchable) [size=128K] >>> Region 4: I/O ports at 3000 [size=256] >>> [virtual] Expansion ROM at d808 [disabled] [size=512K] >>> Capabilities: [40] PCI-X non-bridge device >>> Command: DPERE- ERO- RBC=4096 OST=8 >>> Status: Dev=09:02.0 64bit+ 133MHz+ SCD- USC- DC=simple >>> DMMRBC=4096 DMOST=8 DMCRS=128 RSCEM- 266MHz- 533MHz- >>> Capabilities: [58] Power Management version 2 >>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA >>> PME(D0-,D1-,D2-,D3hot-,D3cold-) >>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>> Capabilities: [e0] MSI: Enable- Count=1/4 Maskable- 64bit+ >>> Address: Data: >>> Kernel driver in use: aic94xx >>> Kernel modules: aic94xx >>> -- >>> >>> Under a heavy load made by bonnie: >>> >>> -- >>> bonnie++ -d /tmp/test -x 1 -s 24g -u root >>> -- >>> >>> after 8-14 hours system gets kernel panic (log attached). >>> >>> Could anyone help with it? >>> >>> >>> Thanks! >>> Evgeny >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: aic94xx and kernel panic
On 08/16/2013 10:26 AM, Evgeny wrote: > Hello. > > I've been testing vanilla 3.4.45 (config attached), 3.4.56 kernels on > centos 5.9 with Adaptec AIC-9410W SAS controller: There's some fix in libsas about error handle , As I remember most of patch finally merged in 3.7, could you try newer kernel? KR Jack > > > 09:02.0 RAID bus controller: Adaptec AIC-9410W SAS (Razor ASIC RAID) > (rev 09) > Subsystem: Super Micro Computer Inc Device 9280 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- DisINTx- > Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- > SERR- Latency: 64 (32000ns min, 26750ns max), Cache Line Size: 32 bytes > Interrupt: pin A routed to IRQ 18 > Region 0: Memory at d830 (64-bit, non-prefetchable) [size=256K] > Region 2: Memory at d800 (64-bit, prefetchable) [size=128K] > Region 4: I/O ports at 3000 [size=256] > [virtual] Expansion ROM at d808 [disabled] [size=512K] > Capabilities: [40] PCI-X non-bridge device > Command: DPERE- ERO- RBC=4096 OST=8 > Status: Dev=09:02.0 64bit+ 133MHz+ SCD- USC- DC=simple > DMMRBC=4096 DMOST=8 DMCRS=128 RSCEM- 266MHz- 533MHz- > Capabilities: [58] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [e0] MSI: Enable- Count=1/4 Maskable- 64bit+ > Address: Data: > Kernel driver in use: aic94xx > Kernel modules: aic94xx > -- > > Under a heavy load made by bonnie: > > -- > bonnie++ -d /tmp/test -x 1 -s 24g -u root > -- > > after 8-14 hours system gets kernel panic (log attached). > > Could anyone help with it? > > > Thanks! > Evgeny -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] pm80xx: fix Adaptec 71605H hang
On 07/26/2013 06:43 PM, Hans Verkuil wrote: > The IO command size is 128 bytes for these new controllers as opposed to 64 > for the old 8001 controller. > > The Adaptec out-of-tree driver did this correctly. After comparing the two > this turned out to be the crucial difference. > > So don't hardcode the IO command size, instead use pm8001_ha->iomb_size as > that is the correct value for both old and new controllers. > > Signed-off-by: Hans Verkuil > Cc: sta...@vger.kernel.org # for v3.10 and up snip Thanks Hans. Looks good now. Acked-by: Jack Wang James, Could you consider to include this fix into your fixes tree, without this fix new Adaptec controller support is broken, sorry for that. Jack -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SAS Management Protocol (SMP) on Windows
On 07/22/2013 03:43 PM, Douglas Gilbert wrote: > On 13-07-22 04:26 AM, Hugh Chin wrote: >> I'm developing SMP application by Python. I've ran it on Linux, it works >> fine. But now I have to run it on Windows. Of course, it didn't work. >> >> So far I know that Windows seems doesn't have bsg driver. But I'm not >> sure. >> I want to know is there any way can run SMP application on Windows? >> >> My English is poor, so if you had something misunderstanding. Please >> let me >> know. > > My smp_utils package is written for Linux and ported to > FreeBSD using the latter's CAM interface recently expanded > to pass-through SMP commands. I'm not aware of any such > generic SMP pass-through for Windows but I'd be happy > to be corrected. Agree, there is no such generic SMP pass-through interface for Windows, Different Vendor offer their SMP IOCTL interface there own. You can checkout from your hardware vendor. > > Apart from that, this is probably the wrong list to be > discussing this subject. Agree. Jack > > Doug Gilbert > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The pm80xx driver hangs in 3.10 with the Adaptec 71605H HBA
Hi Anand, On 07/15/2013 02:37 PM, Anand Kumar Santhanam wrote: > Hi Hans, > > Pls find responses inline. > > Regards > Anand > > -Original Message- > From: Jack Wang [mailto:xjtu...@gmail.com] > Sent: Monday, July 15, 2013 2:24 PM > To: Hans Verkuil > Cc: Anand Kumar Santhanam; lindar_liu; linux-scsi@vger.kernel.org; > jinpu.w...@profitbricks.com > Subject: Re: The pm80xx driver hangs in 3.10 with the Adaptec 71605H HBA > > Hi Hans, > On 07/14/2013 10:45 AM, Hans Verkuil wrote: >> Hi Anand, >> >> On 07/12/2013 03:14 PM, Anand Kumar Santhanam wrote: >>> Hans, >>> >>> I reviewed the code changes and I did not see major differences >>> except for the fact that in adaptec driver we have 64 interrupt >>> handlers to handle 64 MSI-X. >>> This was optimized in open src driver to use only 1 interrupt > handler. >>> Can you pls make this change to the open src driver (i.e have >>> multiple interrupt handlers for multiple MSI-X) and check? >> >> I've looked at this more closely, and I wonder whether there isn't a >> race condition here. When an interrupt arrives you put the interrupt >> vector in pm8001_ha->int_vector, then schedule the tasklet. But what >> if two interrupts with different vectors arrive in quick succession >> before the tasklet got a chance to run? In that case the tasklet will > only see the second vector, not the first. Rather scary. >> >> I have not actually seen any issues with this, but by definition race >> conditions are hard to reproduce and I haven't done any serious >> testing with this card. For now I will run with the quick and dirty > msi.diff (http://hverkuil.home.xs4all.nl/msi.diff). >> >> I see two solutions: either use the 64 interrupt handlers as done in >> the adaptec driver, or you can change int_vector into a u64 and use it > >> as a bitmask to record all interrupt vectors that have arrived. > Thanks for looking into this, I think second one is what we want, set > the bitmask when interrupt arrived and clear it when it's processed. > > Anand>> Yes. We will go for the second solution. The multiple > interrupt/tasklet handlers for MSI-X got rejected by the community and > hence > We went for the existing approach. I checked with a single controller > and I did not observe any issues. Also pls note that the open source > driver > Supports only one MSI-X for now and this problem will not occur. > >> >> BTW, another difference between the linux kernel driver and the >> adaptec version are several of the defines in pm8001_defs.h: e.g. >> MPI_QUEUE is 256 in the adaptec driver, while it is 1024 in the kernel > driver. There are other differences as well. >> > Different value may reflect different performance character, but both > should works, there is no one for all setting. > > Anand >> I agree with Jack. I will check on the #defines and get back. > >> Are all the changes in the kernel correct? I would like to have a >> confirmation of that before I am going to trust my data to this > driver. >> >> It clearly hasn't been tested with actual hardware :-( >> > :_( > >>> My sincere apologies. I tested the same with single controller and it > worked fine. However I messed up when submitting > The patches. This was my first open source submission and request you to > bear the inconvenience. Never mind, people make mistake, quickly fix that should be fine. I suggest keep minimal difference between your in house driver and in tree driver, it will make us easy to maintain the driver and make it easy to use for user. Best Regards, Jack -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pm80xx: fix Adaptec 71605H hang
On 07/14/2013 10:25 AM, Hans Verkuil wrote:
> The IO command size is 128 bytes for these new controllers as opposed to 64
> for the old 8001 controller.
>
> The Adaptec out-of-tree driver did this correctly. After comparing the two
> this turned out to be the crucial difference.
Thanks Hans for this fix.
We'd better use more meaningful Micro like:
#define MPI_IOMB_SIZE_SPCV 128 and replace current hard coded one.
Thanks,
Jack
>
> Signed-off-by: Hans Verkuil
> Acked-by: anandkumar.santha...@pmcs.com
> Cc: sta...@vger.kernel.org # for v3.10 and up
> ---
> drivers/scsi/pm8001/pm80xx_hwi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm80xx_hwi.c
> b/drivers/scsi/pm8001/pm80xx_hwi.c
> index 302514d..e1db5ca 100644
> --- a/drivers/scsi/pm8001/pm80xx_hwi.c
> +++ b/drivers/scsi/pm8001/pm80xx_hwi.c
> @@ -275,7 +275,7 @@ static void init_default_table_values(struct
> pm8001_hba_info *pm8001_ha)
>
> for (i = 0; i < PM8001_MAX_SPCV_INB_NUM; i++) {
> pm8001_ha->inbnd_q_tbl[i].element_pri_size_cnt =
> - PM8001_MPI_QUEUE | (64 << 16) | (0x00<<30);
> + PM8001_MPI_QUEUE | (128 << 16) | (0x00<<30);
> pm8001_ha->inbnd_q_tbl[i].upper_base_addr =
> pm8001_ha->memoryMap.region[IB + i].phys_addr_hi;
> pm8001_ha->inbnd_q_tbl[i].lower_base_addr =
> @@ -301,7 +301,7 @@ static void init_default_table_values(struct
> pm8001_hba_info *pm8001_ha)
> }
> for (i = 0; i < PM8001_MAX_SPCV_OUTB_NUM; i++) {
> pm8001_ha->outbnd_q_tbl[i].element_size_cnt =
> - PM8001_MPI_QUEUE | (64 << 16) | (0x01<<30);
> + PM8001_MPI_QUEUE | (128 << 16) | (0x01<<30);
> pm8001_ha->outbnd_q_tbl[i].upper_base_addr =
> pm8001_ha->memoryMap.region[OB + i].phys_addr_hi;
> pm8001_ha->outbnd_q_tbl[i].lower_base_addr =
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The pm80xx driver hangs in 3.10 with the Adaptec 71605H HBA
Hi Hans, On 07/14/2013 10:45 AM, Hans Verkuil wrote: > Hi Anand, > > On 07/12/2013 03:14 PM, Anand Kumar Santhanam wrote: >> Hans, >> >> I reviewed the code changes and I did not see major differences except >> for the fact that in adaptec driver we have 64 interrupt handlers to >> handle 64 MSI-X. >> This was optimized in open src driver to use only 1 interrupt handler. >> Can you pls make this change to the open src driver (i.e have multiple >> interrupt handlers for multiple MSI-X) and check? > > I've looked at this more closely, and I wonder whether there isn't a race > condition > here. When an interrupt arrives you put the interrupt vector in > pm8001_ha->int_vector, > then schedule the tasklet. But what if two interrupts with different vectors > arrive > in quick succession before the tasklet got a chance to run? In that case the > tasklet > will only see the second vector, not the first. Rather scary. > > I have not actually seen any issues with this, but by definition race > conditions are > hard to reproduce and I haven't done any serious testing with this card. For > now I > will run with the quick and dirty msi.diff > (http://hverkuil.home.xs4all.nl/msi.diff). > > I see two solutions: either use the 64 interrupt handlers as done in the > adaptec > driver, or you can change int_vector into a u64 and use it as a bitmask to > record > all interrupt vectors that have arrived. Thanks for looking into this, I think second one is what we want, set the bitmask when interrupt arrived and clear it when it's processed. > > BTW, another difference between the linux kernel driver and the adaptec > version are > several of the defines in pm8001_defs.h: e.g. MPI_QUEUE is 256 in the adaptec > driver, > while it is 1024 in the kernel driver. There are other differences as well. > Different value may reflect different performance character, but both should works, there is no one for all setting. > Are all the changes in the kernel correct? I would like to have a > confirmation of > that before I am going to trust my data to this driver. > > It clearly hasn't been tested with actual hardware :-( > :_( Thanks, Jack > Regards, > > Hans > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux boot Support for 4KB sector drives ?
On 07/02/2013 10:58 AM, Aaron Lu wrote: > On 07/02/2013 03:11 PM, Kishore Babu Lukka wrote: >> Adding Asha also. >> >> -Original Message- >> From: Mahesh Rajashekhara >> Sent: Monday, July 01, 2013 11:41 AM >> To: jbottom...@parallels.com; linux-scsi@vger.kernel.org >> Cc: Tony Ruiz; Achim Leubner; Mahesh Rajashekhara; Kishore Babu Lukka >> Subject: Linux boot Support for 4KB sector drives ? >> >> Hello, >> >> Does any of the Linux OS flavors support booting from the 4K sector >> (advanced format) drive in legacy BIOS mode (MBR partitioning scheme) ? > > That depends on boot loader, not Linux I think. > Linux has support for 4k sector drive, but if the boot loader > doesn't, it can't fetch the kernel into memory and load Linux. > > Legacy grub makes use of BIOS interrupt service and thus shouldn't > be able to support 4k sector drive, I don't know the status of grub2. > > Thanks, > Aaron > >> >> Thanks & Regards, >> Mahesh Hello, It also depends on HBA BIOS driver, which need to properly handle 4k sector. Linux kernel do support 4k sector. Regards, Jack -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] scsi/pm8001: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)
On 06/18/2013 10:23 AM, Yijing Wang wrote:
> Pci core has been saved pm cap register offset by pdev->pm_cap in
> pci_pm_init()
> in init path. So we can use pdev->pm_cap instead of using
> pci_find_capability(pdev, PCI_CAP_ID_PM) for better performance and
> simplified code.
>
I think Lindar already replied to you, and tested it on hardware.
So you can add her:
Acked-by or Tested-by
Regards,
Jack
> Signed-off-by: Yijing Wang
> Cc: xjtu...@gmail.com
> Cc: lindar_...@usish.com
> Cc: "James E.J. Bottomley"
> Cc: linux-scsi@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
> drivers/scsi/pm8001/pm8001_init.c |7 +++
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/pm8001/pm8001_init.c
> b/drivers/scsi/pm8001/pm8001_init.c
> index e4b9bc7..3861aa1 100644
> --- a/drivers/scsi/pm8001/pm8001_init.c
> +++ b/drivers/scsi/pm8001/pm8001_init.c
> @@ -912,14 +912,13 @@ static int pm8001_pci_suspend(struct pci_dev *pdev,
> pm_message_t state)
> {
> struct sas_ha_struct *sha = pci_get_drvdata(pdev);
> struct pm8001_hba_info *pm8001_ha;
> - int i , pos;
> + int i;
> u32 device_state;
> pm8001_ha = sha->lldd_ha;
> flush_workqueue(pm8001_wq);
> scsi_block_requests(pm8001_ha->shost);
> - pos = pci_find_capability(pdev, PCI_CAP_ID_PM);
> - if (pos == 0) {
> - printk(KERN_ERR " PCI PM not supported\n");
> + if (!pdev->pm_cap) {
> + dev_err(&pdev->dev, " PCI PM not supported\n");
> return -ENODEV;
> }
> PM8001_CHIP_DISP->interrupt_disable(pm8001_ha, 0xFF);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
