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
drivers/scsi/scsi_li
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 wi
On Tue, 2013-12-03 at 11:46 -0600, Alireza Haghdoost wrote:
> On Tue, Dec 3, 2013 at 7:25 AM, James Bottomley
> 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
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 Mon, 25 Nov 2013 11:23:39 -0500
Joe Lawrence wrote:
> On Wed, 20 Nov 2013 14:08:40 -0500
> Joe Lawrence wrote:
>
> > Starting in 3.12, when loading and unloading the mpt2sas driver, I see
> > the following warning:
> >
> > [ cut here ]
> > WARNING: CPU: 20 PID: 19096
On Tue, Dec 3, 2013 at 7:25 AM, James Bottomley
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 lot James for your comments. Is it po
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 compoun
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 "ch
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 wasn
On Tue, Dec 3, 2013 at 6:09 AM, Bart Van Assche 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 don't think libaio re
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 online
rc is set in the loop, and it isn't set back to zero anywhere
this patch fixes it
Signed-off-by: Tomas Henzl
---
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
--- a/drivers/scsi/hp
> 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 st
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 anything
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 res
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 t
From: Alan
Missing check on scsi_register
Signed-off-by: Alan Cox
---
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
--- a/drivers/scsi/mac_scsi.c
+++ b/drivers/scsi/mac_scsi.c
@@
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
> > >
> > > This patch fixes a crash when tried setting symbolic name for an
> > > offline vport through sysfs. Crash is due to uninitialized
> On Tue, 2013-11-19 at 23:05 -0800, vmo...@brocade.com wrote:
> > From: Vijaya Mohan Guvva
> >
> > 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 onl
On Tue, 2013-11-19 at 23:05 -0800, vmo...@brocade.com wrote:
> From: Vijaya Mohan Guvva
>
> 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 online).
This
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 us
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 majord
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/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 e
24 matches
Mail list logo
