Re: [PATCH v3] scsi: ufs-msm: add UFS controller support for Qualcomm MSM chips
On Thu, Aug 14, 2014 at 05:22:18PM +0300, Yaniv Gardi wrote: > diff --git a/drivers/scsi/ufs/ufs-msm.h b/drivers/scsi/ufs/ufs-msm.h > new file mode 100644 > index 000..6e93f1e > --- /dev/null > +++ b/drivers/scsi/ufs/ufs-msm.h > @@ -0,0 +1,158 @@ [...] > +}; > + > +static LIST_HEAD(phy_list); > + Just noticed this via a quick glance - Seems that this variable is not referenced by any of the compilation units, what's the purpose of it? And as a static global in a shared private, each of the including compilation units gets a copy, which I am not sure was intended anyway. -- Dan Aloni -- 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: Some NCQ numbers...
On Wed, Jul 04, 2007 at 08:17:35PM +0400, Michael Tokarev wrote: > Dan Aloni wrote: > > On Thu, Jun 28, 2007 at 02:51:58PM +0400, Michael Tokarev wrote: > >> [..] > >> Test machine was using MPTSAS driver for the following card: > >> SCSI storage controller: LSI Logic / Symbios Logic SAS1064E PCI-Express > >> Fusion-MPT SAS (rev 02) > >> > >> Pretty similar results were obtained on an AHCI controller: > >> SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA > >> Storage Controller AHCI (rev 01) > >> on another machines. > > > > Are you sure that NCQ was enabled between the controller and drive? > > Did you verify this? I know about some versions that disable NCQ > > support internally in their firmware (something to do with bugs in > > error handling). > > The next obvious question is: how to check/verify this? On the lowest level, it's possible using a protocol analyzer. If you don't have one, you need to be familiar with the controller's driver or its firmware. If the driver is based on libata, I think it's possible to get this information easier. Otherwise, such as in the case of mptsas, it can be completely hidden by the firmware. -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add two SCSI command opcodes
On Thu, Apr 19, 2007 at 05:47:43PM +0200, Jan-Benedict Glaw wrote: > On Thu, 2007-04-19 18:10:54 +0300, Dan Aloni <[EMAIL PROTECTED]> wrote: > > diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h > > index 5c0e979..dff842a 100644 > > --- a/include/scsi/scsi.h > > +++ b/include/scsi/scsi.h > > @@ -103,6 +103,7 @@ extern const unsigned char scsi_command_size[8]; > > #define READ_12 0xa8 > > #define WRITE_12 0xaa > > #define WRITE_VERIFY_12 0xae > > +#define VERIFY_12 0xaf > > #define SEARCH_HIGH_120xb0 > > #define SEARCH_EQUAL_12 0xb1 > > #define SEARCH_LOW_12 0xb2 > > @@ -111,6 +112,7 @@ extern const unsigned char scsi_command_size[8]; > > #define WRITE_LONG_2 0xea > > #define READ_16 0x88 > > #define WRITE_16 0x8a > > +#define WRITE_VERIFY_16 0x8e > > #define VERIFY_160x8f > > #define SERVICE_ACTION_IN 0x9e > > /* values for service action in */ > > Where's the user? A privately maintained kernel driver. Do we _must_ have in-tree users? I'd consider the change for completion's sake. -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] add two SCSI command opcodes
Applies for 2.6.20.7 and beyond. Signed-off-by: Dan Aloni <[EMAIL PROTECTED]> diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h index 5c0e979..dff842a 100644 --- a/include/scsi/scsi.h +++ b/include/scsi/scsi.h @@ -103,6 +103,7 @@ extern const unsigned char scsi_command_size[8]; #define READ_12 0xa8 #define WRITE_12 0xaa #define WRITE_VERIFY_12 0xae +#define VERIFY_12 0xaf #define SEARCH_HIGH_120xb0 #define SEARCH_EQUAL_12 0xb1 #define SEARCH_LOW_12 0xb2 @@ -111,6 +112,7 @@ extern const unsigned char scsi_command_size[8]; #define WRITE_LONG_2 0xea #define READ_16 0x88 #define WRITE_16 0x8a +#define WRITE_VERIFY_16 0x8e #define VERIFY_160x8f #define SERVICE_ACTION_IN 0x9e /* values for service action in */ -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LSI Logic 40919o fibre channel: scsi works ip not
Mario Giammarco wrote: Hello, I have two lsi logic 40919o 2gbit connected to a 2gbit switch. They see hard disks but when I try to use them as ip card I obtain a partial failure: packets sometimes arrives sometimes no and on dmesg I see: mptlan: ioc0/fc0: WARNING - IOC out of buckets! (priv->buckets_out = 126) mptlan Mismatch between driver's buckets_out count and fw's BucketsRemaining count has crossed the threshold, issuing a LanReset to clear the fw's hashtable. You may want to check your /var/log/messages for "CRC error" event notifications. mptlan: ioc0/fc0: WARNING - IOC out of buckets! (priv->buckets_out = AFAIK these messages occur as a result of bad frame tx/rx, and it doesn't get handled by the hardware/firmware very well, and I'm quite sure it never did. Now regarding the whole thing surrounding mptlan, I don't think that LSI officially supports that feature any more or willing to fix any bugs for it in their firmware or driver. Is that right? If so, we might as well remove that driver from the kernel. -- Dan Aloni - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi_execute_async() should add to the tail of the queue
Steven Hayter wrote: Dan Aloni wrote: Hello, scsi_execute_async() has replaced scsi_do_req() a few versions ago, but it also incurred a change of behavior. I noticed that over-queuing a SCSI device using that function causes I/Os to be starved from low-level queuing for no justified reason. I think it makes much more sense to perserve the original behaviour of scsi_do_req() and add the request to the tail of the queue. As far as I'm aware the way in which scsi_do_req() was to insert at the head of the queue, leading to projects like SCST to come up with scsi_do_req_fifo() as queuing multiple commands using scsi_do_req() with constant head insertion might lead to out of order execution. Just thought I'd throw some light on the history and what others have done in the past. In Linux 2.4.31 scsi_do_req() still inserts at the tail. This was also valid until 2.6.5. James, is the change you inserted in Linux 2.6.5 still relevant in 2.6 today? <[EMAIL PROTECTED]> [PATCH] add device quiescing to the SCSI API This patch adds the ability to quiesce a SCSI device. The idea is that user issued commands (including filesystem ones) would get blocked, while mid-layer and device issued ones would be allowed to proceed. This is for things like Domain Validation which like to operate on an otherwise quiet device. There is one big change: to get all of this to happen correctly, scsi_do_req() has to queue on the *head* of the request queue, not the tail as it was doing previously. The reason is that deferred requests block the queue, so anything needing executing after a deferred request has to go in front of it. I don't think there are any untoward consequences of this. -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi_execute_async() should add to the tail of the queue
Arjan van de Ven wrote: On Tue, 2006-12-19 at 10:35 +0200, Dan Aloni wrote: Hello, scsi_execute_async() has replaced scsi_do_req() a few versions ago, but it also incurred a change of behavior. I noticed that over-queuing a SCSI device using that function causes I/Os to be starved from low-level queuing for no justified reason. I think it makes much more sense to perserve the original behaviour of scsi_do_req() and add the request to the tail of the queue. Hi, some things should really be added to the head of the queue, like maintenance requests and error handling requests. Are you sure this is the right change? At least I'd expect 2 apis, one for a head and one for a "normal" queueing... Since a user of scsi_execute_async() would most likely want to have control over this, it would be better to add a parameter and fix the current users of the function. However, if we take this route we might have duplicate code across mid-layer drivers (sg, st, osst), because they may choose to prioritize I/Os in similar ways. So instead of adding a parameter, we can make scsi_execute_async() decide for itself based on the SCSI command, with read/write I/Os taking the lowest priority. Suggestions? - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi_execute_async() should add to the tail of the queue
Hello, scsi_execute_async() has replaced scsi_do_req() a few versions ago, but it also incurred a change of behavior. I noticed that over-queuing a SCSI device using that function causes I/Os to be starved from low-level queuing for no justified reason. I think it makes much more sense to perserve the original behaviour of scsi_do_req() and add the request to the tail of the queue. Signed-off-by: Dan Aloni <[EMAIL PROTECTED]> diff -p -urN a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c --- a/drivers/scsi/scsi_lib.c 2006-12-19 01:48:50.0 +0200 +++ b/drivers/scsi/scsi_lib.c 2006-12-19 01:49:35.0 +0200 @@ -421,7 +421,7 @@ int scsi_execute_async(struct scsi_devic sioc->data = privdata; sioc->done = done; - blk_execute_rq_nowait(req->q, NULL, req, 1, scsi_end_async); + blk_execute_rq_nowait(req->q, NULL, req, 0, scsi_end_async); return 0; free_req: -- Dan Aloni XIV, http://www.xivstorage.com - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi_execute_async() should add to the tail of the queue
Hello, scsi_execute_async() has replaced scsi_do_req() a few versions ago, but it also incurred a change of behavior. I noticed that over-queuing a SCSI device using that function causes I/Os to be starved from low-level queuing for no justified reason. I think it makes much more sense to perserve the original behaviour of scsi_do_req() and add the request to the tail of the queue. Signed-off-by: Dan Aloni <[EMAIL PROTECTED]> diff -p -urN a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c --- a/drivers/scsi/scsi_lib.c 2006-12-19 01:48:50.0 +0200 +++ b/drivers/scsi/scsi_lib.c 2006-12-19 01:49:35.0 +0200 @@ -421,7 +421,7 @@ int scsi_execute_async(struct scsi_devic sioc->data = privdata; sioc->done = done; - blk_execute_rq_nowait(req->q, NULL, req, 1, scsi_end_async); + blk_execute_rq_nowait(req->q, NULL, req, 0, scsi_end_async); return 0; free_req: - Dan - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
