On 2012/9/19 1:54, Bjorn Helgaas wrote:
On Mon, Sep 17, 2012 at 6:06 AM, Yijing Wang wangyij...@huawei.com wrote:
On 2012/9/16 11:30, Bjorn Helgaas wrote:
On Sat, Sep 15, 2012 at 4:22 AM, Yijing Wang wangyij...@huawei.com wrote:
Hi all,
I encountered a very strange problem when I hot plug
From: Roland Dreier rol...@purestorage.com
The qla2xxx firmware actually expects the task management response
code in a CTIO IOCB with SCSI status mode 1 to be in little-endian
byte order, ie the response code should be the first byte in the
sense_data[] array. The old code erroneously
v2:
Introduced a new flag sync_before_stop as scsi_stop =
ata_flush_cache + ata_standby_immediate. This flag specifies
that when stop command is to send to this device, please issue
an additional synchronize cache command to it before the stop
command.
Put device into stop power condition on
When scsi device received stop command, it will take care of its
internal cache before enters stopped power condition. This command is
translated to standby immediate in libata-scsi, but standby doesn't
imply flush cache for ATA device, so to issue stop command to ATA
device, an additional flush
On runtime suspend, put device into stop power condition.
For standard scsi device, no need to synchronize cache.
For ata devices, issue synchronize cache before enter standby state
as reflected by the sync_before_stop flag.
Signed-off-by: Aaron Lu aaron...@intel.com
---
Hard disk may also be runtime powered off, so set can_power_off flag
for it too if condition satisfies so that the may_power_off sysfs file
will be created for it to give user a chance to disable runtime power
off.
Signed-off-by: Aaron Lu aaron...@intel.com
Acked-by: Jeff Garzik
The ready_to_power_off flag is used to give indication to ATA layer
if this device's power can be removed after runtime suspended from the
perspective of scsi driver.
It is introduced to support zero power ODD. When ODD is runtime
suspended, it may not be OK to remove its power.
But for disk,
On Tuesday 18 September 2012 15:00:28 Aaron Lu wrote:
When scsi device received stop command, it will take care of its
internal cache before enters stopped power condition. This command is
translated to standby immediate in libata-scsi, but standby doesn't
imply flush cache for ATA device, so
On Tue, Sep 18, 2012 at 09:30:11AM +0200, Oliver Neukum wrote:
On Tuesday 18 September 2012 15:00:28 Aaron Lu wrote:
When scsi device received stop command, it will take care of its
internal cache before enters stopped power condition. This command is
translated to standby immediate in
On Tue, 2012-09-18 at 15:00 +0800, Aaron Lu wrote:
When scsi device received stop command, it will take care of its
internal cache before enters stopped power condition. This command is
translated to standby immediate in libata-scsi, but standby doesn't
imply flush cache for ATA device, so to
On Tue, Sep 18, 2012 at 08:56:55AM +0100, James Bottomley wrote:
On Tue, 2012-09-18 at 15:00 +0800, Aaron Lu wrote:
When scsi device received stop command, it will take care of its
internal cache before enters stopped power condition. This command is
translated to standby immediate in
On Tue, 2012-09-18 at 16:09 +0800, Aaron Lu wrote:
On Tue, Sep 18, 2012 at 08:56:55AM +0100, James Bottomley wrote:
On Tue, 2012-09-18 at 15:00 +0800, Aaron Lu wrote:
When scsi device received stop command, it will take care of its
internal cache before enters stopped power condition.
On Tue, Sep 18, 2012 at 09:20:20AM +0100, James Bottomley wrote:
On Tue, 2012-09-18 at 16:09 +0800, Aaron Lu wrote:
On Tue, Sep 18, 2012 at 08:56:55AM +0100, James Bottomley wrote:
On Tue, 2012-09-18 at 15:00 +0800, Aaron Lu wrote:
When scsi device received stop command, it will take
On Monday 17 September 2012, Russell King - ARM Linux wrote:
In both of my replies, I've said as x86 does. We need to follow
x86's behaviour here, which is as I've quoted - it's not a matter
that I need to make up my mind - my mind is already well made up.
That is, we need to follow x86 here.
On Tue, 2012-09-18 at 09:54 +0530, Naresh Kumar Inna wrote:
Hi James,
Could you please consider merging version V4 of the driver patches, if
you think they are in good shape now?
Well, definitely not yet; you seem to have missed the memo on readq:
CC [M]
On 09/18/2012 11:30 AM, Douglas Gilbert wrote:
On 12-09-18 11:04 AM, Hannes Reinecke wrote:
Hi all,
I recently got my hands on some weird drives, insisting on having
been formatted with protection type 7:
# sg_readcap --16 /dev/sdb
Read Capacity results:
Protection: prot_en=1,
On 12-09-18 11:35 AM, Hannes Reinecke wrote:
On 09/18/2012 11:30 AM, Douglas Gilbert wrote:
On 12-09-18 11:04 AM, Hannes Reinecke wrote:
Hi all,
I recently got my hands on some weird drives, insisting on having
been formatted with protection type 7:
# sg_readcap --16 /dev/sdb
Read Capacity
From: Martin K. Petersen martin.peter...@oracle.com
- blk_check_merge_flags() verifies that cmd_flags / bi_rw are
compatible. This function is called for both req-req and req-bio
merging.
- blk_rq_get_max_sectors() and blk_queue_get_max_sectors() can be used
to query the maximum
From: Martin K. Petersen martin.peter...@oracle.com
If the device supports WRITE SAME, use that to optimize zeroing of
blocks. If the device does not support WRITE SAME or if the operation
fails, fall back to writing zeroes the old-fashioned way.
Signed-off-by: Martin K. Petersen
From: Martin K. Petersen martin.peter...@oracle.com
Remove special-casing of non-rw fs style requests (discard). The nomerge
flags are consolidated in blk_types.h, and rq_mergeable() and
bio_mergeable() have been modified to use them.
bio_is_rw() is used in place of bio_has_data() a few places.
From: Martin K. Petersen martin.peter...@oracle.com
Introduce a BLKZEROOUT ioctl which can be used to clear block ranges by
way of blkdev_issue_zeroout().
Signed-off-by: Martin K. Petersen martin.peter...@oracle.com
Acked-by: Mike Snitzer snit...@redhat.com
---
block/ioctl.c | 27
From: Martin K. Petersen martin.peter...@oracle.com
The REPORT SUPPORTED OPERATION CODES command can be used to query
whether a given opcode is supported by a device. Add a helper function
that allows us to look up commands.
We only issue RSOC if the device reports compliance with SPC-3 or
From: Martin K. Petersen martin.peter...@oracle.com
The WRITE SAME command supported on some SCSI devices allows the same
block to be efficiently replicated throughout a block range. Only a
single logical block is transferred from the host and the storage device
writes the same data to all blocks
From: Martin K. Petersen martin.peter...@oracle.com
Implement support for WRITE SAME(10) and WRITE SAME(16) in the SCSI disk
driver.
- We set the default maximum to 0x because there are several
devices out there that only support two-byte block counts even with
WRITE SAME(16). We only
On 9/18/2012 2:06 PM, James Bottomley wrote:
On Tue, 2012-09-18 at 09:54, Naresh Kumar Inna wrote:
Hi James,
Could you please consider merging version V4 of the driver patches, if
you think they are in good shape now?
Well, definitely not yet; you seem to have missed the memo on readq:
On Mon, Sep 17, 2012 at 6:06 AM, Yijing Wang wangyij...@huawei.com wrote:
On 2012/9/16 11:30, Bjorn Helgaas wrote:
On Sat, Sep 15, 2012 at 4:22 AM, Yijing Wang wangyij...@huawei.com wrote:
Hi all,
I encountered a very strange problem when I hot plug a fiber channel
card(using qla2xxx
On Tue, Sep 18 2012 at 12:19pm -0400,
Martin K. Petersen martin.peter...@oracle.com wrote:
From: Martin K. Petersen martin.peter...@oracle.com
- blk_check_merge_flags() verifies that cmd_flags / bi_rw are
compatible. This function is called for both req-req and req-bio
merging.
-
From: Roland Dreier rol...@purestorage.com
The qla2xxx firmware actually expects the task management response
code in a CTIO IOCB with SCSI status mode 1 to be in little-endian
byte order, ie the response code should be the first byte in the
sense_data[] array. The old code erroneously
On Tue, 2012-09-18 at 15:10 -0700, Roland Dreier wrote:
From: Roland Dreier rol...@purestorage.com
The qla2xxx firmware actually expects the task management response
code in a CTIO IOCB with SCSI status mode 1 to be in little-endian
byte order, ie the response code should be the first byte
https://bugzilla.kernel.org/show_bug.cgi?id=47701
Summary: When too many disks fall out at the same time, RCU
hangs
Product: IO/Storage
Version: 2.5
Kernel Version: 3.5.4
Platform: All
OS/Version: Linux
Tree:
30 matches
Mail list logo
