EVPD page 0x83 is used to uniquely identify the device.
So instead of having each and every program issue a separate
SG_IO call to retrieve this information it does make far more
sense to display it in sysfs.
Cc: Jeremy Linton
Cc: Doug Gilbert
Cc: Kai Makisara
Cc: Martin K. Petersen
Signed-off
On Wed, Feb 05, 2014 at 04:41:18AM -0800, Christoph Hellwig wrote:
> A git tree is also available at
>
> git://git.infradead.org/users/hch/scsi.git#scsi-mq-wip
I've pushed various fixes to the branch, most importantly the ata_piix
driver including CDROM support has now been tested with blk-mq,
On Thu, Feb 06, 2014 at 08:56:59AM -0800, James Bottomley wrote:
> I'm dubious about replacing a locked set of checks and increments with
> atomics for the simple reason that atomics are pretty expensive on
> non-x86, so you've likely slowed the critical path down for them. Even
> on x86, atomics
On Sun, Feb 09, 2014 at 12:26:48AM -0800, Nicholas A. Bellinger wrote:
> Again, try NOP'ing all REQ_TYPE_FS type commands immediately in
> ->queuecommand() in order to determine a baseline without any other LLD
> overhead involved.
Seems like this duplicates the fake_rw parameter. Removing the ne
On Fri, Feb 07, 2014 at 03:43:55PM -0600, Mike Christie wrote:
> We need something like the attached patch which just prevents scsi-ml
> from creating a host pool when mq is used. Note that when
> scsi_destroy_command_freelist is called shost->cmd_pool will be NULL so
> it will return immediately s
On Mon, Feb 10, 2014 at 12:11:39PM +0100, Hannes Reinecke wrote:
> + int vpd_len = 255;
> + unsigned char *buffer;
> +retry:
> + buffer = kmalloc(vpd_len, GFP_KERNEL);
> + if (!buffer)
> + return;
> +
> + ret = scsi_get_vpd_page(sdev, 0x83, buffer, vpd_len);
> +
On 02/10/2014 03:15 PM, Christoph Hellwig wrote:
> On Mon, Feb 10, 2014 at 12:11:39PM +0100, Hannes Reinecke wrote:
>> +int vpd_len = 255;
>> +unsigned char *buffer;
>> +retry:
>> +buffer = kmalloc(vpd_len, GFP_KERNEL);
>> +if (!buffer)
>> +return;
>> +
>> +ret = scs
The original code always set the upper 32 bits to zero because it was
doing a shift of the wrong variable.
Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other
fixes')
Signed-off-by: Dan Carpenter
---
v2: Add a cast to u64 to avoid a future static checker warning
diff --git
On Mon, 2014-02-10 at 18:18 +0300, Dan Carpenter wrote:
> The original code always set the upper 32 bits to zero because it was
> doing a shift of the wrong variable.
>
> Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other
> fixes')
> Signed-off-by: Dan Carpenter
> ---
> v2
On Mon, Feb 10, 2014 at 07:22:02AM -0800, James Bottomley wrote:
> On Mon, 2014-02-10 at 18:18 +0300, Dan Carpenter wrote:
> > The original code always set the upper 32 bits to zero because it was
> > doing a shift of the wrong variable.
> >
> > Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add
On 2/10/2014 5:11 AM, Hannes Reinecke wrote:
> EVPD page 0x83 is used to uniquely identify the device. So instead of
> having each and every program issue a separate SG_IO call to retrieve this
> information it does make far more sense to display it in sysfs.
Tested-by: Jeremy Linton
So,
On 14-02-10 01:06 PM, Jeremy Linton wrote:
On 2/10/2014 5:11 AM, Hannes Reinecke wrote:
EVPD page 0x83 is used to uniquely identify the device. So instead of
having each and every program issue a separate SG_IO call to retrieve this
information it does make far more sense to display it in sysfs.
On Mon, 2014-02-10 at 03:35 -0800, Christoph Hellwig wrote:
> On Wed, Feb 05, 2014 at 04:41:18AM -0800, Christoph Hellwig wrote:
> > A git tree is also available at
> >
> > git://git.infradead.org/users/hch/scsi.git#scsi-mq-wip
>
> I've pushed various fixes to the branch, most importantly the a
On Mon, 2014-02-10 at 04:09 -0800, Christoph Hellwig wrote:
> On Sun, Feb 09, 2014 at 12:26:48AM -0800, Nicholas A. Bellinger wrote:
> > Again, try NOP'ing all REQ_TYPE_FS type commands immediately in
> > ->queuecommand() in order to determine a baseline without any other LLD
> > overhead involved.
On Mon, Feb 10 2014, Christoph Hellwig wrote:
> > I also think we should be getting more utility out of threading
> > guarantees. So, if there's only one thread active per device we don't
> > need any device counters to be atomic. Likewise, u32 read/write is an
> > atomic operation, so we might b
On Mon, 2014-02-10 at 03:39 -0800, Christoph Hellwig wrote:
> On Thu, Feb 06, 2014 at 08:56:59AM -0800, James Bottomley wrote:
> > I'm dubious about replacing a locked set of checks and increments with
> > atomics for the simple reason that atomics are pretty expensive on
> > non-x86, so you've li
(2014/02/07 15:15), Libo Chen wrote:
On 2014/2/7 13:46, James Bottomley wrote:
On Fri, 2014-02-07 at 09:22 +0900, Eiichi Tsukata wrote:
Currently, scsi error handling in scsi_io_completion() tries to
unconditionally requeue scsi command when device keeps some error state.
For example, UNIT_ATT
Hi Alexander
The changes look good to me. Thanks for taking care of this
-Suma
On 04/02/14 4:46 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
Currently, scsi error handling in scsi_io_completion() tries to
unconditionally requeue scsi command when device keeps some error state.
For example, UNIT_ATTENTION causes infinite retry with
action == ACTION_RETRY.
This is because retryable errors are thought to be temporary and the scsi
device wi
19 matches
Mail list logo
