On Thu, 2014-02-13 at 12:00 PM, XinHong Zhu wrote:
> In function pm8001_dev_gone_notify require a tag from bitmap resource and
> later don't free tag resource .So tag resource will be consume fully and
> following request can not be execed because of lack of tags . But in the
> function don't need
In function pm8001_dev_gone_notify require a tag from bitmap resource and later
don't free tag resource .So tag resource will be consume fully and following
request can not be execed because of lack of tags . But in the function don't
need use any tag to issue command of unregistering device .
On 11.2.2014, at 23.22, Maurizio Lombardi wrote:
> When copying the st_modedef structures the devs pointers must be preserved
> in the same way as with the cdevs pointers.
>
> This fixes bug 70271: https://bugzilla.kernel.org/show_bug.cgi?id=70271
>
> [ 135.037052] BUG: unable to handle kerne
On 02/12/2014 01:41 PM, Richard Yao wrote:
> On 02/12/2014 02:25 PM, Dan Williams wrote:
>> On Wed, Feb 12, 2014 at 9:41 AM, Richard Yao wrote:
>>> You should use `git send-email` to send the patch to all of the people
>>> listed by get_maintainer.pl:
>>
>> I see nothing wrong with the patch Joe o
On 02/12/2014 02:25 PM, Dan Williams wrote:
> On Wed, Feb 12, 2014 at 9:41 AM, Richard Yao wrote:
>> You should use `git send-email` to send the patch to all of the people
>> listed by get_maintainer.pl:
>
> I see nothing wrong with the patch Joe originally submitted:
> http://marc.info/?l=linux-
On Wed, Feb 12, 2014 at 9:41 AM, Richard Yao wrote:
> You should use `git send-email` to send the patch to all of the people
> listed by get_maintainer.pl:
I see nothing wrong with the patch Joe originally submitted:
http://marc.info/?l=linux-scsi&m=138609455422179&w=2
>
> richard@desktop ~/deve
Hi Joe, thanks for copying me on that other thread.
On Tue, Dec 3, 2013 at 10:15 AM, Joe Lawrence wrote:
> The recent change in sysfs, bcdde7e221a8750f9b62b6d0bd31b72ea4ad9309
> "sysfs: make __sysfs_remove_dir() recursive" revealed an asymmetric
> rphy device creation/deletion sequence in scsi_tr
You should use `git send-email` to send the patch to all of the people
listed by get_maintainer.pl:
richard@desktop ~/devel/linux $ scripts/get_maintainer.pl --file
drivers/scsi/scsi_transport_sas.c
"James E.J. Bottomley" (maintainer:SCSI
SUBSYSTEM)
linux-scsi@vger.kernel.org (open list:SCSI SUBS
On 2/12/14 10:26 AM, Mike Christie wrote:
On 2/12/14 10:11 AM, Mike Christie wrote:
On 2/12/14 9:29 AM, Hannes Reinecke wrote:
On 02/07/2014 02:54 AM, Mike Christie wrote:
On 02/06/2014 07:24 PM, Mike Christie wrote:
On 01/31/2014 03:29 AM, Hannes Reinecke wrote:
We should be issuing STPG sy
Hi Sreekanth,
There hasn't been much recent activity in
drivers/scsi/scsi_transport_sas.c, so I wasn't sure who could best
review the patch.
Dan Williams added sas_rphy_unlink() back in 2011, perhaps he can
remember why sas_bsg_remove wasn't performed there?
Regards,
-- Joe
On Wed, 12 Feb 201
On 2/12/14 10:11 AM, Mike Christie wrote:
On 2/12/14 9:29 AM, Hannes Reinecke wrote:
On 02/07/2014 02:54 AM, Mike Christie wrote:
On 02/06/2014 07:24 PM, Mike Christie wrote:
On 01/31/2014 03:29 AM, Hannes Reinecke wrote:
We should be issuing STPG synchronously as we need to
evaluate the retu
On 2/12/14 9:29 AM, Hannes Reinecke wrote:
On 02/07/2014 02:54 AM, Mike Christie wrote:
On 02/06/2014 07:24 PM, Mike Christie wrote:
On 01/31/2014 03:29 AM, Hannes Reinecke wrote:
We should be issuing STPG synchronously as we need to
evaluate the return code on failure.
Signed-off-by: Hannes
On Wed, Feb 12, 2014 at 12:40:24PM +0100, Hannes Reinecke wrote:
> On 02/06/2014 07:43 PM, Christoph Hellwig wrote:
> > Avoid a spurious device get/put cycle by using scsi_put_command and folding
> > scsi_unprep_request into scsi_requeue_command.
> >
> > Signed-off-by: Christoph Hellwig
> Makes o
On Wed, Feb 12, 2014 at 12:37:26PM +0100, Hannes Reinecke wrote:
> But this decouples the scsi_device refcount from the number of
> outstanding commands, right?
We still take a reference for each command in scsi_get_cmd_from_req,
which is helper used in each prep_fn, so we still have a reference
f
James,
Not sure if you were waiting for an ack for the third
in this series, since it came from me, but this whole
series is ready to get pulled in.
Acked-by: Brian King
--
Brian King
Power Linux I/O
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe li
On Wed, Feb 12, 2014 at 12:08:35PM +0100, Hannes Reinecke wrote:
> What happens when another CPU is just modifying the starved list
> at this point?
> We probably won't be seeing the update until when the next command
> completed.
That's correct if the last was emptry previous. list_empty won't
r
On Thu, 2014-02-06 at 14:04 +0100, 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.
Can someone please tell
On 02/07/2014 02:54 AM, Mike Christie wrote:
> On 02/06/2014 07:24 PM, Mike Christie wrote:
>> On 01/31/2014 03:29 AM, Hannes Reinecke wrote:
>>> We should be issuing STPG synchronously as we need to
>>> evaluate the return code on failure.
>>>
>>> Signed-off-by: Hannes Reinecke
>>
>> I think we n
Changes done for performance boost-
1) Added code to set SMP IRQ affinity per CPU
2) Removed host lock for queue_command to enable Asynchronous IO submission
3) Pass MSI-x index, while issuing sysPD IO.
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
---
diff --git a/drivers/scsi/megara
If consistent DMA mask is set to 64 bit, fall back to 32bit DMA mask and 32bit
consistent DMA mask.
64bit consistent DMA mask may be set on some 64bit DMA slot, which causes DMA
offset "10" and
MFI_INIT and IOCTL frames will have high memory addresses, leads to firmware
FAULT.
Signe
Few big endian code related fixes.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
---
diff --git a/drivers/scsi/megaraid/megaraid_sas.h
b/drivers/scsi/megaraid/megaraid_sas.h
index 34452ea..a80e13e 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_
Don't wait forever for firmware response for internal DCMDs sent from driver
firmware. Such DCMDs will be posted to firmware with
timeout. Timeout is also introduced for DCMD sent to abort the commands. DCMD
sent via IOCTL path will still be always blocking to
keep the IOCTL design intact.
Signe
MegaRaid driver changes.
Please consider this patch set for next kernel release.
Signed-off-by: Sumit Saxena
Signed-off-by: Kashyap Desai
---
[PATCH 0/4] megaraid_sas : Updates for scsi for-next
[PATCH 1/4] megaraid_sas : Don't wait forever for non-IOCTL DCMDs.
[PATCH 2/4] megaraid_sas : Big en
On 02/06/2014 07:43 PM, Christoph Hellwig wrote:
> Avoid a spurious device get/put cycle by using scsi_put_command and folding
> scsi_unprep_request into scsi_requeue_command.
>
> Signed-off-by: Christoph Hellwig
Makes one wonder why we didn't do this to start with.
Acked-by: Hannes Reinecke
C
On 02/06/2014 07:43 PM, Christoph Hellwig wrote:
> From: Bart Van Assche
>
> Eliminate a get_device() / put_device() pair from scsi_next_command().
> Both are atomic operations hence removing these slightly improves
> performance.
>
> [hch: slight changes due to different context]
>
> Signed-of
On 02/06/2014 07:43 PM, Christoph Hellwig wrote:
> From: Bart Van Assche
>
> SCSI devices may only be removed by calling scsi_remove_device().
> That function must invoke blk_cleanup_queue() before the final put
> of sdev->sdev_gendev. Since blk_cleanup_queue() waits for the
> block queue to drai
On 02/06/2014 07:43 PM, Christoph Hellwig wrote:
> Many callers won't need this and we can optimize them away. In addition
> the handling in the __-prefixed variants was inconsistant to start with.
>
> Based on an earlier patch from Bart Van Assche.
>
But this decouples the scsi_device refcount
On 02/06/2014 07:43 PM, Christoph Hellwig wrote:
> If we don't have starved devices we don't need to take the host lock
> to iterate over them. Also split the function up to be more clear.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/scsi_lib.c | 43 --
On 02/06/2014 07:43 PM, Christoph Hellwig wrote:
> Avoid hitting the host-wide free_list lock unless we need to put a command
> back onto the freelist.
>
> Signed-off-by: Christoph Hellwig
Looks good.
Acked-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries &
Some older devices (most notably tapes) will only report reliable
information in page 0x80 (Unit Serial Number). So export this
in the sysfs attribute 'serial'.
Cc: Doug Gilbert
Cc: Jeremy Linton
Signed-off-by: Hannes Reinecke
---
drivers/scsi/scsi_scan.c | 4 ++-
drivers/scsi/scsi_sysfs.c
Instead of modifying attributes after the device has been created
we should be using the 'is_visible' callback to avoid races.
Signed-off-by: Hannes Reinecke
Reviewed-by: Christoph Hellwig
---
drivers/scsi/scsi_sysfs.c | 184 +++---
1 file changed, 93 ins
Hi all,
This version now includes the review from hch, and I've
added a new patch to display EVPD page 0x80 in sysfs, too.
And some more sanity checks to play nice with broken devices.
Hannes Reinecke (3):
scsi_sysfs: Implement 'is_visible' callback
Add EVPD page 0x83 entries to sysfs
Add E
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.
The page is displayed in its entirety with the attribute
'vpd_pg83', and the individual de
This is to re-notify you that you have $500,000.00 waiting for pick-up at Money
Gram, Contact
Mrs Hillary Florence via email : heritd...@xtra.co.nz for claims.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More maj
On 02/12/2014 09:02 AM, Christoph Hellwig wrote:
> On Tue, Feb 11, 2014 at 03:34:54PM +0100, 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
On Tue, Feb 11, 2014 at 03:34:54PM +0100, 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.
> The page is dis
36 matches
Mail list logo
