From: Jan Kara
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===
commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream.
When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we j
Hi Chad,
On Fri, 2014-08-22 at 16:02 -0700, Eddie Wai wrote:
> On Fri, 2014-07-25 at 10:12 +0200, Maurizio Lombardi wrote:
> >
> > On 07/25/2014 10:02 AM, Maurizio Lombardi wrote:
> > > In some cases, the fcoe_rx_list may contains multiple instances
> > > of the same skb (the so called "shared sk
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Thursday, 06 November, 2014 2:31 AM
> To: James Bottomley
> Cc: Christoph Hellwig; Ewan Milne; Elliott, Robert (Server Storage);
> linux-scsi@vger.kernel.org; Hannes Reinecke; linux-
> i...@vger.kernel.org; LKML
>
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Thursday, 06 November, 2014 2:31 AM
> To: James Bottomley
> Cc: Christoph Hellwig; Ewan Milne; Elliott, Robert (Server Storage);
> linux-scsi@vger.kernel.org; Hannes Reinecke
> Subject: [PATCH 01/10] scsi: Rename S
Hello Christoph,
I did the new bisect,
the first bad commit is :
74665016086615bbaa3fa6f83af410a0a4e029ee
scsi: convert host_busy to atomic_t
you can find the bisect log here :
https://bugzilla.kernel.org/attachment.cgi?id=157621
Le 14/11/2014 08:32, Christoph Hellwig a écrit :
> On Thu, Nov
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Thursday, 06 November, 2014 2:31 AM
...
> diff --git a/drivers/scsi/scsi_logging.c
...
> @@ -249,3 +255,146 @@ void scsi_print_command(struct scsi_cmnd *cmd)
> }
> }
> EXPORT_SYMBOL(scsi_print_command);
>
Paul, what's the best way to figure out these CPU stalls?
The second oops is in blk_mq_map_queue() which is a trivial
two level cpu lookup. I wonder if there's something odd about
cpu numbers on these big old sparc systems?
Something like the debug patch below might shed some light on where the
On 11/14/2014 09:58 AM, Christoph Hellwig wrote:
> Paul, what's the best way to figure out these CPU stalls?
>
> The second oops is in blk_mq_map_queue() which is a trivial
> two level cpu lookup. I wonder if there's something odd about
> cpu numbers on these big old sparc systems?
>
> Something
This patch also removes unnecessary printk(KERN_INFO
Signed-off-by: Fabian Frederick
---
V4: remove blank line after memdup_user
V3: memdup_user first argument is already void __user * (thanks to Joe Perches)
typo in title
V2: Remove printk(KERN_INFO (suggested by Alan)
drivers/scsi/bfa/bfa
Hello stable maintainers,
Can you please backport commitid
2cc5bfaf854463d9d1aa52091f60110fbf102a9 ([SCSI] hpsa: fix a race in
cmd_free/scsi_done) to 3.10 stable (and earlier, if applicable)? It
seems to fix an issue that we have run into a couple of times.
Many thanks,
Masoud Sharbiani
--
To unsu
Dear stable maintainers,
Can you please backport commitid
2cc5bfaf854463d9d1aa52091f60110fbf102a9 ([SCSI] hpsa: fix a race in
cmd_free/scsi_done) to 3.10 stable (and earlier, if applicable)? It
seems to fix an issue that we have run into a couple of times.
Many thanks,
Masoud Sharbiani
PS: Apol
> Paul, what's the best way to figure out these CPU stalls?
>
> The second oops is in blk_mq_map_queue() which is a trivial
> two level cpu lookup. I wonder if there's something odd about
> cpu numbers on these big old sparc systems?
CPU numbers are sparse - they are determined by hardware slot
On 11/14/2014 12:35 PM, Meelis Roos wrote:
>> Paul, what's the best way to figure out these CPU stalls?
>>
>> The second oops is in blk_mq_map_queue() which is a trivial
>> two level cpu lookup. I wonder if there's something odd about
>> cpu numbers on these big old sparc systems?
>
> CPU numbers
> "Martin" == Martin K Petersen writes:
Martin> What would you prefer as the default for the ext4 use case? To
Martin> allocate or to discard?
I didn't get a preference for whether sb_issue_zeroout() should discard
or allocate.
But here's an updated patch 3...
commit eb23c9e71e08b7f467cbc3
Maurizio, we've been running this for a little while with no issues so
it's good to go from our perspective.
Acked-by: Chad Dupuis
On Fri, 14 Nov 2014, Maurizio Lombardi wrote:
Hi Chad,
On Fri, 2014-08-22 at 16:02 -0700, Eddie Wai wrote:
On Fri, 2014-07-25 at 10:12 +0200, Maurizio Lombardi
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Thursday, 06 November, 2014 2:31 AM
...
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
...
> diff --git a/drivers/scsi/scsi_logging.c
> b/drivers/scsi/scsi_logging.c
> index 065792a3..e7e7cab 100644
> --- a
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Thursday, 06 November, 2014 2:31 AM
> To: James Bottomley
> Cc: Christoph Hellwig; Ewan Milne; Elliott, Robert (Server Storage);
> linux-scsi@vger.kernel.org; Hannes Reinecke
> Subject: [PATCH 09/10] scsi: Conditio
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Thursday, 06 November, 2014 2:31 AM
> To: James Bottomley
> Cc: Christoph Hellwig; Ewan Milne; Elliott, Robert (Server Storage);
> linux-scsi@vger.kernel.org; Hannes Reinecke
> Subject: [PATCH 10/10] scsi: Do not d
> >> The second oops is in blk_mq_map_queue() which is a trivial
> >> two level cpu lookup. I wonder if there's something odd about
> >> cpu numbers on these big old sparc systems?
> >
> > CPU numbers are sparse - they are determined by hardware slot number and
> > some models only fill every ot
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Thursday, 06 November, 2014 2:30 AM
> To: James Bottomley
> Cc: Christoph Hellwig; Ewan Milne; Elliott, Robert (Server Storage);
> linux-scsi@vger.kernel.org; Hannes Reinecke
> Subject: [PATCHv2 00/10] scsi logging
From: Robert Elliott
RAID-1ADM is unusable with dev_warn called on every command.
Signed-off-by: Robert Elliott
Signed-off-by: Don Brace
Reviewed-by: Stephen M. Cameron
Reviewed-by: Webb Scales
---
drivers/scsi/hpsa.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/scsi/h
Clean up issues reported when running sparse.
Signed-off-by: Don Brace
Reviewed-by: Webb Scales
---
drivers/scsi/hpsa.c | 29 -
drivers/scsi/hpsa.h |6 +++---
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hp
This patch set is based on Linus's tree.
The changes are:
- correct warnings from sparse
- updates for some error handling issues
- general code cleanup
- performance enhancements based on removing spin_locks
---
Don Brace (1):
hpsa: Clean up warnings from sparse.
Nicholas Bellinger (1
From: Stephen M. Cameron
Using bit fields for hardware command fields isn't portable and
relies on assumptions about how the compiler lays out the bits.
We can fix this in the driver's internal command structure, but the
ioctl interface we can't change because it is part of the
userland ABI.
Sig
From: Nicholas Bellinger
There isn't anything in hpsa that requires the host lock to be held
during queuecommand.
Signed-off-by: Don Brace
Signed-off-by: Nicholas Bellinger
Reviewed-by: Stephen M. Cameron
---
drivers/scsi/hpsa.c | 16 +++-
1 file changed, 7 insertions(+), 9 del
From: Stephen M. Cameron
The hardware needs little endian scatter gather addresses and
lengths but we were not bothering to convert from cpu byte
order as we should have been. On Intel, this is all just
a bunch of no-ops macros, but it makes the code endian-clean(er).
Signed-off-by: Don Brace
From: Webb Scales
Correct the size calculation of the chained SG block
Signed-off-by: Don Brace
Signed-off-by: Webb Scales
Reviewed-by: Stephen M. Cameron
Reviewed-by: Don Brace
---
drivers/scsi/hpsa.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/h
From: Stephen M. Cameron
We were allocating roughly double the amount of memory
we should be due to ReportLUNdata and ExtendedReportLUNdata
containing a non-zero sized array but adding extra memory
to allocate as if the array were zero sized.
Track the logical and physical sizes separately.
Allo
From: Stephen M. Cameron
We were printing a lot of useless information before ultimately
just passing things up to the SCSI mid layer. Just let the
midlayer handle it without LLD chatter.
Signed-off-by: Don Brace
Signed-off-by: Stephen M. Cameron
Reviewed-by: Joe Handzik
Reviewed-by: Scott T
From: Robert Elliott
If the kernel is booted with the reset_device parameter, which
is done for kdump, then the driver needs to call pci_set_master
after pci_enable_device to reenable bus mastering (since
the preceding pci_disable_device call disables bus mastering).
Also, place that after pci_r
From: Stephen M. Cameron
Use atomics for commands_outstanding instead of protecting with spin locks.
Signed-off-by: Don Brace
Signed-off-by: Stephen M. Cameron
Reviewed-by: Joe Handzik
---
drivers/scsi/hpsa.c | 26 +-
drivers/scsi/hpsa.h | 27 +++--
From: Stephen M. Cameron
In the case of LUN data changing, the driver will
auto rescan and so it's not even true that "action" is
"required".
Remove "action required" phrases from warning messages and
replace with description phrases.
Signed-off-by: Don Brace
Reviewed-by: Stephen M. Cameron
R
From: Stephen M. Cameron
It is already using atomic test_and_set_bit to do the
allocation.
There is some microscopic chance of starvation, but it is
so microscopic that it should never happen in reality.
Signed-off-by: Don Brace
Reviewed-by: Webb Scales
---
drivers/scsi/hpsa.c | 36 +++
From: Stephen M. Cameron
Fix a couple of pci id table mistakes:
Subdevice ID 0x3323 missing from product[] table
(another name for HP Smart Storage 1210m)
Bogus 0x1925 subdevice id removed from hpsa_pci_device_id[] (no such thing.)
Signed-off-by: Don Brace
Reviewed-by: Webb Scales
---
On 2014-11-14 15:59, Meelis Roos wrote:
The second oops is in blk_mq_map_queue() which is a trivial
two level cpu lookup. I wonder if there's something odd about
cpu numbers on these big old sparc systems?
CPU numbers are sparse - they are determined by hardware slot number and
some models onl
On Wed, Nov 12, 2014 at 09:27:50AM -0800, Christoph Hellwig wrote:
> > +static int stex_reboot_callback(struct notifier_block *self,
> > + unsigned long val,
> > + void *data)
> > +{
> > + if (
Since virtio_scsi has supported multi virtqueue already,
it is natural to map the virtque to hw-queue of blk-mq.
Cc: Paolo Bonzini
Signed-off-by: Ming Lei
---
V1:
- support non-mq too
drivers/scsi/virtio_scsi.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
> On 2014-11-14 15:59, Meelis Roos wrote:
> > > > > The second oops is in blk_mq_map_queue() which is a trivial
> > > > > two level cpu lookup. I wonder if there's something odd about
> > > > > cpu numbers on these big old sparc systems?
> > > >
> > > > CPU numbers are sparse - they are determined
38 matches
Mail list logo
