On 12/03/2013 05:32 AM, rkuo wrote:
On Mon, Dec 02, 2013 at 06:14:33PM +0800, Chen Gang wrote:
If one issue occurs, normally, both sides need improvement.
For our issue:
- need try to keep uapi no touch (arch/hexagon/uapi/asm/registers.h).
- improving our module is much easier than
On 12/03/13 00:38, James Bottomley wrote:
Well this would be because we don't guarantee order at any granularity
below barriers. We won't reorder across barriers but below them we can
reorder the commands and, of course, we use simple tags for queuing
which entitles the underlying storage
On 12/02/13 23:12, Alireza Haghdoost wrote:
Note that we are using kernel 3.11 and libaio to perform async IO.
I think libaio can reorder commands before these reach the SCSI core.
Bart.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to
On Tue, 2013-12-03 at 13:26 +0100, Bart Van Assche wrote:
On 12/03/13 00:38, James Bottomley wrote:
Well this would be because we don't guarantee order at any granularity
below barriers. We won't reorder across barriers but below them we can
reorder the commands and, of course, we use
On Tue, 2013-11-19 at 23:05 -0800, vmo...@brocade.com wrote:
From: Vijaya Mohan Guvva vmo...@brocade.com
This patch fixes a crash when tried setting symbolic name for an offline
vport through sysfs. Crash is due to uninitialized pointer lport-ns,
which gets initialized only on linkup (port
On Tue, 2013-11-19 at 23:05 -0800, vmo...@brocade.com wrote:
From: Vijaya Mohan Guvva vmo...@brocade.com
This patch fixes a crash when tried setting symbolic name for an
offline vport through sysfs. Crash is due to uninitialized pointer
lport-ns, which gets initialized only on linkup
On Tue, 2013-12-03 at 07:38 -0700, Vijaya Mohan Guvva wrote:
On Tue, 2013-11-19 at 23:05 -0800, vmo...@brocade.com wrote:
From: Vijaya Mohan Guvva vmo...@brocade.com
This patch fixes a crash when tried setting symbolic name for an
offline vport through sysfs. Crash is due to
From: Alan gno...@lxorguk.ukuu.org.uk
Missing check on scsi_register
Signed-off-by: Alan Cox gno...@lxorguk.ukuu.org.uk
---
drivers/scsi/mac_scsi.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/mac_scsi.c b/drivers/scsi/mac_scsi.c
index 8580757..f5cdc68 100644
---
On resume, the ATA port driver currently waits until the AHCI controller
finishes executing the port wakeup command. This patch changes the
ata_port_resume callback to issue the wakeup and then return immediately,
thus allowing the next device in the pm queue to resume. Any commands issued
to
On resume, the SD driver currently waits until the block driver finishes
executing a disk start command with blk_execute_rq. This patch changes the
sd_resume callback to use blk_execute_rq_nowait instead, which allows it to
return immediately, thus allowing the next device in the pm queue to
Hi James, can you give me some feedback on this patch set? It includes
changes based on your feedback to v1.
The essential issue behind hard disks' lengthy resume time is the ata port
driver blocking until the ATA port hardware is finished coming online. So
the kernel isn't really doing
thus allowing the UI to come online sooner. There may be a short period after
resume where the disks are still spinning up in the background, but the user
shouldn't notice since the OS can function with the data left in RAM.
I wonder how many marginal power supplies this will find 8)
I
rc is set in the loop, and it isn't set back to zero anywhere
this patch fixes it
Signed-off-by: Tomas Henzl the...@redhat.com
---
drivers/scsi/hpsa.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index fb5a898..e46b609 100644
---
On 13-12-03 05:25 PM, Todd E Brandt wrote:
Hi James, can you give me some feedback on this patch set? It includes
changes based on your feedback to v1.
The essential issue behind hard disks' lengthy resume time is the ata port
driver blocking until the ATA port hardware is finished coming
On Tue, Dec 3, 2013 at 6:09 AM, Bart Van Assche bvanass...@acm.org wrote:
I think libaio can reorder commands before these reach the SCSI core.
Thanks for your comments. I think the libaio is above the block layer.
Therefore, since we observed the ordering is maintained in the block
layer, I
On 28/11/13 13:29, Hannes Reinecke wrote:
On 11/26/2013 05:26 PM, Douglas Gilbert wrote:
On 13-11-26 11:06 AM, Benjamin ESTRABAUD wrote:
[ .. ]
rescan-scsi-bus.sh did detect new LUN, but apparently not
removed ones.
However I need to test it on a system with a compatible bash shell
as I
On Sat, Nov 30, 2013 at 03:48:44PM -0500, James Bottomley wrote:
On Sat, 2013-11-30 at 13:56 -0500, Konrad Rzeszutek Wilk wrote:
My theory is that the SWIOTLB is not full - it is just that the request
is for a compound page that is more than 512kB. Please note that
SWIOTLB highest chunk of
On Tue, 2013-12-03 at 12:33 -0500, Konrad Rzeszutek Wilk wrote:
On Sat, Nov 30, 2013 at 03:48:44PM -0500, James Bottomley wrote:
On Sat, 2013-11-30 at 13:56 -0500, Konrad Rzeszutek Wilk wrote:
My theory is that the SWIOTLB is not full - it is just that the request
is for a compound page
On Tue, Dec 3, 2013 at 7:25 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
Well, no, we could have used Ordered instead of Simple tags ... that
would preserve submission order according to spec. This wouldn't really
work for SATA because NCQ only has simple tags.
Thanks a
On Mon, 25 Nov 2013 11:23:39 -0500
Joe Lawrence joe.lawre...@stratus.com wrote:
On Wed, 20 Nov 2013 14:08:40 -0500
Joe Lawrence joe.lawre...@stratus.com wrote:
Starting in 3.12, when loading and unloading the mpt2sas driver, I see
the following warning:
[ cut here
The recent change in sysfs, bcdde7e221a8750f9b62b6d0bd31b72ea4ad9309
sysfs: make __sysfs_remove_dir() recursive revealed an asymmetric
rphy device creation/deletion sequence in scsi_transport_sas:
modprobe mpt2sas
sas_rphy_add
device_add A rphy-dev
device_add B
On Tue, 2013-12-03 at 11:46 -0600, Alireza Haghdoost wrote:
On Tue, Dec 3, 2013 at 7:25 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
Well, no, we could have used Ordered instead of Simple tags ... that
would preserve submission order according to spec. This wouldn't
Hi Douglas
Thanks!
I am using MIPs CPU on embedded system, after cross-compliled sg3_utils
package,
I will try to use sg_senddiag to send ses command.
I'm not sure what you expect from the ses driver
in the kernel. If it likes an SES device (and it
doesn't like some of them) then you will
the macro SP is too common to make conflict with others, so recommend
to use another more readable and non-conflict macro SG_POOL instead of
(and recommend others do not use SP either).
The related warning (with allmodconfig for hexagon):
CC [M] drivers/scsi/scsi_lib.o
24 matches
Mail list logo
