Re: [PATCH] aic79xx: fix misuse of static variables
On 30 March 2014 15:30, Mathias Krause wrote:
> The format strings for various printk()s make use of a temporary
> variable that is declared 'static'. This is probably not intended,
> so fix those.
>
> Found in the PaX patch, written by the PaX Team.
>
> Cc: PaX Team
> Cc: Hannes Reinecke
> Cc: "James E.J. Bottomley"
> Signed-off-by: Mathias Krause
> ---
>
> Remark: Compile tested only! I've no such hardware.
>
> drivers/scsi/aic7xxx/aic79xx_pci.c | 18 +-
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/scsi/aic7xxx/aic79xx_pci.c
> b/drivers/scsi/aic7xxx/aic79xx_pci.c
> index 14b5f8d0e7..cc9bd26f5d 100644
> --- a/drivers/scsi/aic7xxx/aic79xx_pci.c
> +++ b/drivers/scsi/aic7xxx/aic79xx_pci.c
> @@ -827,7 +827,7 @@ ahd_pci_intr(struct ahd_softc *ahd)
> for (bit = 0; bit < 8; bit++) {
>
> if ((pci_status[i] & (0x1 << bit)) != 0) {
> - static const char *s;
> + const char *s;
>
> s = pci_status_strings[bit];
> if (i == 7/*TARG*/ && bit == 3)
> @@ -887,23 +887,15 @@ ahd_pci_split_intr(struct ahd_softc *ahd, u_int intstat)
>
> for (bit = 0; bit < 8; bit++) {
>
> - if ((split_status[i] & (0x1 << bit)) != 0) {
> - static const char *s;
> -
> - s = split_status_strings[bit];
> - printk(s, ahd_name(ahd),
> + if ((split_status[i] & (0x1 << bit)) != 0)
> + printk(split_status_strings[bit],
> ahd_name(ahd),
>split_status_source[i]);
> - }
>
> if (i > 1)
> continue;
>
> - if ((sg_split_status[i] & (0x1 << bit)) != 0) {
> - static const char *s;
> -
> - s = split_status_strings[bit];
> - printk(s, ahd_name(ahd), "SG");
> - }
> + if ((sg_split_status[i] & (0x1 << bit)) != 0)
> + printk(split_status_strings[bit],
> ahd_name(ahd), "SG");
> }
> }
> /*
> --
> 1.7.10.4
>
Ping? James, Hannes? How to proceed with this patch?
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 2] mvsas: Recognise device/subsystem 9485/9485 as 88SE9485
On Wed, 2014-02-19 at 01:06 +, Ben Hutchings wrote:
> Matt Taggart reported that mvsas didn't bind to the Marvell
> SAS controller on a Supermicro AOC-SAS2LP-MV8 board.
>
> lspci reports it as:
>
> 01:00.0 RAID bus controller [0104]: Marvell Technology Group Ltd. Device
> [1b4b:9485] (rev 03)
> Subsystem: Marvell Technology Group Ltd. Device [1b4b:9485]
> [...]
>
> Add it to the device table as chip_9485.
Adding Marvell maintainer to cc. Can we get an ack on this ... or is
mvsas dead and I can just apply it anyway?
Thanks,
James
> Reported-by: Matt Taggart
> Tested-by: Matt Taggart
> Signed-off-by: Ben Hutchings
> ---
> drivers/scsi/mvsas/mv_init.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
> index 7b7381d..83fa5f8 100644
> --- a/drivers/scsi/mvsas/mv_init.c
> +++ b/drivers/scsi/mvsas/mv_init.c
> @@ -729,6 +729,15 @@ static struct pci_device_id mvs_pci_table[] = {
> .class_mask = 0,
> .driver_data= chip_9485,
> },
> + {
> + .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> + .device = 0x9485,
> + .subvendor = PCI_ANY_ID,
> + .subdevice = 0x9485,
> + .class = 0,
> + .class_mask = 0,
> + .driver_data= chip_9485,
> + },
> { PCI_VDEVICE(OCZ, 0x1021), chip_9485}, /* OCZ RevoDrive3 */
> { PCI_VDEVICE(OCZ, 0x1022), chip_9485}, /* OCZ RevoDrive3/zDriveR4
> (exact model unknown) */
> { PCI_VDEVICE(OCZ, 0x1040), chip_9485}, /* OCZ RevoDrive3/zDriveR4
> (exact model unknown) */
>
>
> --
> Ben Hutchings
> One of the nice things about standards is that there are so many of them.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.15-mw: Oops Workqueue: writeback bdi_writeback_workfn (flush-8:16) RIP: e030:[] [] kobject_put+0x11/0x70
On Mon, 14 Apr 2014 04:30:15 -0700
Christoph Hellwig wrote:
> On Sat, Apr 12, 2014 at 01:34:31PM +0200, Sander Eikelenboom wrote:
> > Hi,
> >
> > I just ran into the oops belowafter some uptime.
>
> Classic use after free introduced by my recent changes, sorry.
>
> This should fix it:
>
> ---
> From: Christoph Hellwig
> Subject: scsi: don't reference freed command in scsi_init_sgtable
>
> When scsi_init_io fails we have to release our device reference, but
> we do this trying to reference the just freed command. Add a local
> scsi_device pointer to fix this.
>
> Reported-by: Sander Eikelenboom
> Signed-off-by: Christoph Hellwig
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 65a123d..54eff6a 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1044,6 +1044,7 @@ static int scsi_init_sgtable(struct request *req,
> struct scsi_data_buffer *sdb,
> */
> int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
> {
> + struct scsi_device *sdev = cmd->device;
> struct request *rq = cmd->request;
>
> int error = scsi_init_sgtable(rq, &cmd->sdb, gfp_mask);
> @@ -1091,7 +1092,7 @@ err_exit:
> scsi_release_buffers(cmd);
> cmd->request->special = NULL;
> scsi_put_command(cmd);
> - put_device(&cmd->device->sdev_gendev);
> + put_device(&sdev->sdev_gendev);
> return error;
> }
> EXPORT_SYMBOL(scsi_init_io);
Hi Christoph,
I hit a similar crash last week on a franken-kernel here (3.14 + scsi
misc + qlogic patches + out of tree drivers + terriblethingsIknow). I
think there is one other similar use-after-free that's been in place
for a while now:
int scsi_prep_return(struct request_queue *q, struct request *req, int ret)
{
struct scsi_device *sdev = q->queuedata;
switch (ret) {
case BLKPREP_KILL:
req->errors = DID_NO_CONNECT << 16;
/* release the command and kill it */
if (req->special) {
struct scsi_cmnd *cmd = req->special;
scsi_release_buffers(cmd);
scsi_put_command(cmd);<<
put_device(&cmd->device->sdev_gendev);<<
req->special = NULL;
}
break;
...
and the backtrace looked like:
general protection fault: [#1] SMP
Modules linked in: ccmod(POF) ftmod(OF) ipmi_devintf ipmi_msghandler bonding sg
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel ixgbe(OF) aesni_intel igb(OF) ptp lrw pps_core gf128mul
glue_helper i2c_algo_bit mdio ablk_helper cryptd pcspkr dca ntb i2c_core
matroxfb(OF) videosw(OF) nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c
dm_service_time sd_mod(OF) crc_t10dif crct10dif_common qla2xxx(OF)
scsi_transport_fc mpt2sas(OF) raid_class scsi_tgt scsi_transport_sas dm_mirror
dm_region_hash dm_log dm_multipath dm_mod
CPU: 8 PID: 23976 Comm: systemd-udevd Tainted: PF W O 3.14.0+ #2
Hardware name: Stratus ftServer 6400/G7LAY, BIOS BIOS Version 6.3:57 12/25/2013
task: 880420b3d7c0 ti: 880729138000 task.ti: 880729138000
RIP: 0010:[] [] kobject_put+0xd/0x60
RSP: 0018:880729139a80 EFLAGS: 00010002
RAX: RBX: 6b6b6b6b6b6b6ce3 RCX: 0001002e0003
RDX: 002e RSI: ea0021370400 RDI: 6b6b6b6b6b6b6ce3
RBP: 880729139a88 R08: 88084dc16300 R09: 0001002e0002
R10: 88104f603a80 R11: ea0021370400 R12: 88084dc16300
R13: 0001 R14: 881026935388 R15: 880ff56b3a18
FS: 7f2eed940880() GS:88085fd0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f2eed0e2c20 CR3: 00084d6c8000 CR4: 000407e0
Stack:
88076248d0a8 880729139a98 813e57d7 880729139ac0
8141bf3e 00018141be66 88076248d0a8 88104def6840
880729139b20 a00a46e0 88104def6840 88076248d0a8
Call Trace:
[] put_device+0x17/0x20
[] scsi_prep_return+0x9e/0xc0
[] sd_prep_fn+0x70/0xcd0 [sd_mod]
[] blk_peek_request+0x12f/0x250
[] scsi_request_fn+0x48/0x570
[] __blk_run_queue+0x33/0x40
[] queue_unplugged+0x2a/0xa0
[] blk_flush_plug_list+0x1d8/0x230
[] blk_finish_plug+0x14/0x40
[] __do_page_cache_readahead+0x209/0x290
[] force_page_cache_readahead+0x6d/0xa0
[] page_cache_sync_readahead+0x43/0x50
[] generic_file_aio_read+0x4f5/0x720
[] blkdev_aio_read+0x4b/0x70
[] do_sync_read+0x67/0xa0
[] vfs_read+0x9b/0x160
[] SyS_read+0x55/0xd0
[] system_call_fastpath+0x16/0x1b
Regards,
-- Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hpsa: fix NULL dereference in hpsa_put_ctlr_into_performant_mode()
Initialize local variable trans_support before it is used rather
than after. It is supposed to contain the value of a register on the
controller containing bits that describe which transport modes the
controller supports (e.g. "performant", "ioaccel1", "ioaccel2"). A
NULL pointer dereference will almost certainly occur if trans_support
is not initialized at the right point. If for example the uninitialized
trans_support value does not have the bit set for ioaccel2 support when it
should be, then ioaccel2_alloc_cmds_and_bft() will not get called as it
should be and the h->ioaccel2_blockFetchTable array will remain NULL
instead of being allocated. Too late, trans_support finally gets
initialized with the correct value with ioaccel2 mode bit set,
which later causes calc_bucket_map() to be called to fill in
h->ioaccel2_blockFetchTable[]. However h->ioaccel2_blockFetchTable
is NULL because it didn't get allocated because earlier trans_support
wasn't initialized at the right point.
Signed-off-by: Stephen M. Cameron
---
drivers/scsi/hpsa.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..9a6e4a2 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
if (hpsa_simple_mode)
return;
+ trans_support = readl(&(h->cfgtable->TransportSupport));
+ if (!(trans_support & PERFORMANT_MODE))
+ return;
+
/* Check for I/O accelerator mode support */
if (trans_support & CFGTBL_Trans_io_accel1) {
transMethod |= CFGTBL_Trans_io_accel1 |
@@ -7479,10 +7483,6 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
}
/* TODO, check that this next line h->nreply_queues is correct */
- trans_support = readl(&(h->cfgtable->TransportSupport));
- if (!(trans_support & PERFORMANT_MODE))
- return;
-
h->nreply_queues = h->msix_vector > 0 ? h->msix_vector : 1;
hpsa_get_max_perf_mode_cmds(h);
/* Performant mode ring buffer and supporting data structures */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.15-mw: Oops Workqueue: writeback bdi_writeback_workfn (flush-8:16) RIP: e030:[] [] kobject_put+0x11/0x70
On Mon, Apr 14, 2014 at 02:57:00PM -0400, Joe Lawrence wrote: > I hit a similar crash last week on a franken-kernel here (3.14 + scsi > misc + qlogic patches + out of tree drivers + terriblethingsIknow). I > think there is one other similar use-after-free that's been in place > for a while now: Yes, that looks the same. I'll fix it and prepare a patch that consolidates this duplicate code while at it. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Pv-drivers] [PATCH] VMW_PVSCSI: Fix the issue of DMA-API related warnings.
Hi James,
Could you please help getting this in?
Thanks!
Arvind
- Original Message -
From: "Arvind Kumar"
To: jbottom...@parallels.com, linux-scsi@vger.kernel.org
Cc: pv-driv...@vmware.com, "Josh Boyer"
Sent: Friday, March 21, 2014 11:08:32 AM
Subject: [Pv-drivers] [PATCH] VMW_PVSCSI: Fix the issue of DMA-API related
warnings.
The driver is missing calls to pci_dma_mapping_error() after
performing the DMA mapping, which caused DMA-API warning to
show up in dmesg's output. Though that happens only when
DMA_API_DEBUG option is enabled. This change fixes the issue
and makes pvscsi_map_buffers() function more robust.
Signed-off-by: Arvind Kumar
Cc: Josh Boyer
---
drivers/scsi/vmw_pvscsi.c | 45 +++--
drivers/scsi/vmw_pvscsi.h |2 +-
2 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index c88e146..9478a00 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -349,9 +349,9 @@ static void pvscsi_create_sg(struct pvscsi_ctx *ctx,
* Map all data buffers for a command into PCI space and
* setup the scatter/gather list if needed.
*/
-static void pvscsi_map_buffers(struct pvscsi_adapter *adapter,
- struct pvscsi_ctx *ctx, struct scsi_cmnd *cmd,
- struct PVSCSIRingReqDesc *e)
+static int pvscsi_map_buffers(struct pvscsi_adapter *adapter,
+ struct pvscsi_ctx *ctx, struct scsi_cmnd *cmd,
+ struct PVSCSIRingReqDesc *e)
{
unsigned count;
unsigned bufflen = scsi_bufflen(cmd);
@@ -360,18 +360,30 @@ static void pvscsi_map_buffers(struct pvscsi_adapter
*adapter,
e->dataLen = bufflen;
e->dataAddr = 0;
if (bufflen == 0)
- return;
+ return 0;
sg = scsi_sglist(cmd);
count = scsi_sg_count(cmd);
if (count != 0) {
int segs = scsi_dma_map(cmd);
- if (segs > 1) {
+
+ if (segs == -ENOMEM) {
+ scmd_printk(KERN_ERR, cmd,
+ "vmw_pvscsi: Failed to map cmd sglist for
DMA.\n");
+ return -1;
+ } else if (segs > 1) {
pvscsi_create_sg(ctx, sg, segs);
e->flags |= PVSCSI_FLAG_CMD_WITH_SG_LIST;
ctx->sglPA = pci_map_single(adapter->dev, ctx->sgl,
SGL_SIZE, PCI_DMA_TODEVICE);
+ if (pci_dma_mapping_error(adapter->dev, ctx->sglPA)) {
+ scmd_printk(KERN_ERR, cmd,
+ "vmw_pvscsi: Failed to map ctx
sglist for DMA.\n");
+ scsi_dma_unmap(cmd);
+ ctx->sglPA = 0;
+ return -1;
+ }
e->dataAddr = ctx->sglPA;
} else
e->dataAddr = sg_dma_address(sg);
@@ -382,8 +394,15 @@ static void pvscsi_map_buffers(struct pvscsi_adapter
*adapter,
*/
ctx->dataPA = pci_map_single(adapter->dev, sg, bufflen,
cmd->sc_data_direction);
+ if (pci_dma_mapping_error(adapter->dev, ctx->dataPA)) {
+ scmd_printk(KERN_ERR, cmd,
+ "vmw_pvscsi: Failed to map direct data
buffer for DMA.\n");
+ return -1;
+ }
e->dataAddr = ctx->dataPA;
}
+
+ return 0;
}
static void pvscsi_unmap_buffers(const struct pvscsi_adapter *adapter,
@@ -712,6 +731,12 @@ static int pvscsi_queue_ring(struct pvscsi_adapter
*adapter,
ctx->sensePA = pci_map_single(adapter->dev, cmd->sense_buffer,
SCSI_SENSE_BUFFERSIZE,
PCI_DMA_FROMDEVICE);
+ if (pci_dma_mapping_error(adapter->dev, ctx->sensePA)) {
+ scmd_printk(KERN_ERR, cmd,
+ "vmw_pvscsi: Failed to map sense buffer for
DMA.\n");
+ ctx->sensePA = 0;
+ return -1;
+ }
e->senseAddr = ctx->sensePA;
e->senseLen = SCSI_SENSE_BUFFERSIZE;
} else {
@@ -737,7 +762,15 @@ static int pvscsi_queue_ring(struct pvscsi_adapter
*adapter,
else
e->flags = 0;
- pvscsi_map_buffers(adapter, ctx, cmd, e);
+ if (pvscsi_map_buffers(adapter, ctx, cmd, e) != 0) {
+ if (cmd->sense_buffer) {
+ pci_unmap_single(adapter->dev, ctx->sensePA,
+SCSI_SENSE_BUFFERSIZE,
+PCI_DMA_FROMD
Re: hpsa driver bug crack kernel down!
On Mon, 2014-04-14 at 16:57 +0800, Jiang Liu wrote: > Hi all, > I guess I found the root cause. It's a bug in matching > device scope, variable 'level' should be decreased when walking up PCI > topology. > Could you please help to test following patch? > Thanks! > Gerry Worked like a charm -- I no longer see all those DMAR messages and the hpsa hard lockup is gone, thanks. Feel free to add my: Reported-and-tested-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
On Mon, 2014-04-14 at 09:47 -0700, Davidlohr Bueso wrote: > On Mon, 2014-04-14 at 09:44 -0700, Davidlohr Bueso wrote: > > On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote: > > > Hi Davidlohr, > > > Thanks for providing the DMAR table. According to the DMAR > > > table, one bug in the iommu driver fails to handle this entry: > > > [1D2h 0466 1] Device Scope Entry Type : 01 > > > [1D3h 0467 1] Entry Length : 0A > > > [1D4h 0468 2] Reserved : > > > [1D6h 0470 1] Enumeration ID : 00 > > > [1D7h 0471 1] PCI Bus Number : 00 > > > [1D8h 0472 2] PCI Path : 1C,04 > > > [1DAh 0474 2] PCI Path : 00,02 > > > > > > And the patch sent out by me should fix this bug. Could you please help > > > to have a try? > > > > Sorry, I am unable to find any patches from you regarding this issue... > > I must be missing something. Could you please point me to the lkml link? > > Never mind, I got it internally. I'll let you know as soon as I can > test it later today. Thanks. Jiang, if you can then let me have a copy with a signed-off-by I'll shepherd it upstream along with your other patch which is already in my iommu-2.6.git tree. -- Sent with Evolution's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
Re: hpsa driver bug crack kernel down!
On Mon, 2014-04-14 at 09:44 -0700, Davidlohr Bueso wrote: > On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote: > > Hi Davidlohr, > > Thanks for providing the DMAR table. According to the DMAR > > table, one bug in the iommu driver fails to handle this entry: > > [1D2h 0466 1] Device Scope Entry Type : 01 > > [1D3h 0467 1] Entry Length : 0A > > [1D4h 0468 2] Reserved : > > [1D6h 0470 1] Enumeration ID : 00 > > [1D7h 0471 1] PCI Bus Number : 00 > > [1D8h 0472 2] PCI Path : 1C,04 > > [1DAh 0474 2] PCI Path : 00,02 > > > > And the patch sent out by me should fix this bug. Could you please help > > to have a try? > > Sorry, I am unable to find any patches from you regarding this issue... > I must be missing something. Could you please point me to the lkml link? Never mind, I got it internally. I'll let you know as soon as I can test it later today. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote: > Hi Davidlohr, > Thanks for providing the DMAR table. According to the DMAR > table, one bug in the iommu driver fails to handle this entry: > [1D2h 0466 1] Device Scope Entry Type : 01 > [1D3h 0467 1] Entry Length : 0A > [1D4h 0468 2] Reserved : > [1D6h 0470 1] Enumeration ID : 00 > [1D7h 0471 1] PCI Bus Number : 00 > [1D8h 0472 2] PCI Path : 1C,04 > [1DAh 0474 2] PCI Path : 00,02 > > And the patch sent out by me should fix this bug. Could you please help > to have a try? Sorry, I am unable to find any patches from you regarding this issue... I must be missing something. Could you please point me to the lkml link? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
Hi Davidlohr, Thanks for providing the DMAR table. According to the DMAR table, one bug in the iommu driver fails to handle this entry: [1D2h 0466 1] Device Scope Entry Type : 01 [1D3h 0467 1] Entry Length : 0A [1D4h 0468 2] Reserved : [1D6h 0470 1] Enumeration ID : 00 [1D7h 0471 1] PCI Bus Number : 00 [1D8h 0472 2] PCI Path : 1C,04 [1DAh 0474 2] PCI Path : 00,02 And the patch sent out by me should fix this bug. Could you please help to have a try? Thanks! Gerry On 2014/4/14 23:45, Davidlohr Bueso wrote: > Sorry for the delay, I've been having to take turns for this box. > > On Fri, 2014-04-11 at 09:18 +, Woodhouse, David wrote: >> On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote: >>> Attaching a dmesg from one of the kernels that boots. It doesn't appear >>> to have much of the related information... is there any debug config >>> option I can enable that might give you more data? >> >> I'd like the contents of /sys/firmware/acpi/tables/DMAR please. > > Attached is the disassembly of the raw output. > >> And >> please could you also apply this patch to both the last-working and >> first-failing kernels and show me the output in both cases? > > So I still cannot get around getting the info for the first failing > kernel, but below is for the last working. Thanks. > > Device 0:03:00.0 on IOMMU at a800 > Device 0:03:00.0 on IOMMU at a800 > IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 - 0x7f61] > Device 0:02:00.0 on IOMMU at a800 > Device 0:02:00.0 on IOMMU at a800 > IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] > Device 0:02:00.2 on IOMMU at a800 > Device 0:02:00.2 on IOMMU at a800 > IOMMU: Setting identity map for device :00:1d.0 [0x7f7e7000 - 0x7f7ecfff] > Device 0:00:1d.0 on IOMMU at a800 > Device 0:00:1d.0 on IOMMU at a800 > IOMMU: Setting identity map for device :00:1d.1 [0x7f7e7000 - 0x7f7ecfff] > Device 0:00:1d.1 on IOMMU at a800 > Device 0:00:1d.1 on IOMMU at a800 > IOMMU: Setting identity map for device :00:1d.2 [0x7f7e7000 - 0x7f7ecfff] > Device 0:00:1d.2 on IOMMU at a800 > Device 0:00:1d.2 on IOMMU at a800 > IOMMU: Setting identity map for device :00:1d.3 [0x7f7e7000 - 0x7f7ecfff] > Device 0:00:1d.3 on IOMMU at a800 > Device 0:00:1d.3 on IOMMU at a800 > IOMMU: Setting identity map for device :02:00.0 [0x7f7e7000 - 0x7f7ecfff] > Device 0:02:00.0 on IOMMU at a800 > IOMMU: Setting identity map for device :02:00.2 [0x7f7e7000 - 0x7f7ecfff] > Device 0:02:00.2 on IOMMU at a800 > IOMMU: Setting identity map for device :02:00.4 [0x7f7e7000 - 0x7f7ecfff] > Device 0:02:00.4 on IOMMU at a800 > Device 0:02:00.4 on IOMMU at a800 > IOMMU: Setting identity map for device :00:1d.7 [0x7f7ee000 - 0x7f7e] > Device 0:00:1d.7 on IOMMU at a800 > Device 0:00:1d.7 on IOMMU at a800 > IOMMU: Prepare 0-16MiB unity mapping for LPC > IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff] > Device 0:00:1f.0 on IOMMU at a800 > Device 0:00:1f.0 on IOMMU at a800 > PCI-DMA: Intel(R) Virtualization Technology for Directed I/O > Device 0:00:00.0 on IOMMU at a800 > Device 0:00:01.0 on IOMMU at a800 > Device 0:00:02.0 on IOMMU at a800 > Device 0:00:03.0 on IOMMU at a800 > Device 0:00:04.0 on IOMMU at a800 > Device 0:00:05.0 on IOMMU at a800 > Device 0:00:06.0 on IOMMU at a800 > Device 0:00:07.0 on IOMMU at a800 > Device 0:00:08.0 on IOMMU at a800 > Device 0:00:09.0 on IOMMU at a800 > Device 0:00:0a.0 on IOMMU at a800 > Device 0:00:14.0 on IOMMU at a800 > Device 0:00:1c.0 on IOMMU at a800 > Device 0:00:1c.4 on IOMMU at a800 > Device 0:00:1d.0 on IOMMU at a800 > Device 0:00:1d.1 on IOMMU at a800 > Device 0:00:1d.2 on IOMMU at a800 > Device 0:00:1d.3 on IOMMU at a800 > Device 0:00:1d.7 on IOMMU at a800 > Device 0:00:1e.0 on IOMMU at a800 > Device 0:00:1f.0 on IOMMU at a800 > Device 0:04:00.0 on IOMMU at a800 > Device 0:04:00.1 on IOMMU at a800 > Device 0:04:00.2 on IOMMU at a800 > Device 0:04:00.3 on IOMMU at a800 > Device 0:03:00.0 on IOMMU at a800 > Device 0:02:00.0 on IOMMU at a800 > Device 0:02:00.2 on IOMMU at a800 > Device 0:02:00.4 on IOMMU at a800 > Device 0:01:03.0 on IOMMU at a800 > Device 0:50:00.0 on IOMMU at ac00 > Device 0:50:01.0 on IOMMU at ac00 > Device 0:50:02.0 on IOMMU at ac00 > Device 0:50:03.0 on IOMMU at ac00 > Device 0:50:04.0 on IOMMU at ac00 > Device 0:50:05.0 on IOMMU at ac00 > Device 0:50:06.0 on IOMMU at ac00 > Device 0:50:07.0 on IOMMU at ac00 > Device 0:50:08.0 on IOMMU at ac00 > Device 0:50:09.0 on IOMMU at ac00 > Device 0:50:0a.0 on IOMMU at ac00 > Device 0:50:14.0 on IOMMU at a800 > Device
Re: [PATCH] sd: medium access timeout counter fails to reset
On Thu, 2014-04-10 at 11:08 -0400, David Jeffery wrote:
> There is an error with the medium access timeout feature of the sd driver. The
> sdkp->medium_access_timed_out value is reset to zero in sd_done() in the wrong
> place. Currently it is reset to zero only when a command returns sense data.
> This can result in cases where the medium access check falsely triggers from
> timed out commands which are hours or days apart.
>
> For example, an I/O command times out and is aborted. It then retries and
> succeeds. But with no sense data generated and returned, the
> medium_access_timed_out value is not reset. If no sd command returns sense
> data, then the next command to time out (however far in time from the first
> failure) will trigger the medium access timeout and put the device offline.
>
> The resetting of sdkp->medium_access_timed_out should occur before the check
> for sense data.
>
> Signed-off-by: David Jeffery
>
> ---
>
> To reproduce using scsi_debug, use SCSI_DEBUG_OPT_TIMEOUT or
> SCSI_DEBUG_OPT_MAC_TIMEOUT to force an I/O command to timeout. Then, remove
> the opt value so the I/O will succeed on retry. Perform more I/O as desired.
> Finally, repeat the process to make a new I/O command time out. Without the
> patch, the device will be marked offline even though many I/O commands have
> succeeded between the 2 instances of timed out commands.
>
>
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 470954a..a41e68e 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -1689,12 +1689,12 @@ static int sd_done(struct scsi_cmnd *SCpnt)
> sshdr.ascq));
> }
> #endif
> + sdkp->medium_access_timed_out = 0;
> +
> if (driver_byte(result) != DRIVER_SENSE &&
> (!sense_valid || sense_deferred))
> goto out;
>
> - sdkp->medium_access_timed_out = 0;
> -
> switch (sshdr.sense_key) {
> case HARDWARE_ERROR:
> case MEDIUM_ERROR:
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hey James-
Is there some reason why this patch was never accepted? David posted it
a couple of times last year and Martin ack'ed it, but I don't see it in
your tree, and I don't see any other comments on it.
It seems like something that ought to be fixed.
Reviewed-by: Ewan D. Milne
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hpsa: fix uninitialized trans_support in hpsa_put_ctlr_into_performant_mode()
On Mon, Apr 14, 2014 at 08:45:16AM -0700, James Bottomley wrote:
> Your subject line is very tame. It should be the one line summary of
> why we apply the patch, so it should read something like
>
> hpsa: fix NULL deref in performant mode
>
> On Thu, 2014-04-10 at 17:17 -0500, scame...@beardog.cce.hp.com wrote:
> > Without this, you'll see a null pointer dereference in
> > hpsa_enter_performant_mode().
>
> The description should be more comprehensible.
>
> I'm clear that the use before initialisation is a bug ... I'm less clear
> on why it causes an oops.
>
> > Signed-off-by: Stephen M. Cameron
> > ---
> > drivers/scsi/hpsa.c |4
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> > index 8cf4a0c..ef4dfdd 100644
> > --- a/drivers/scsi/hpsa.c
> > +++ b/drivers/scsi/hpsa.c
> > @@ -7463,6 +7463,10 @@ static void
> > hpsa_put_ctlr_into_performant_mode(struct ctlr_info *h)
> > if (hpsa_simple_mode)
> > return;
> >
> > + trans_support = readl(&(h->cfgtable->TransportSupport));
> > + if (!(trans_support & PERFORMANT_MODE))
> > + return;
> > +
> > /* Check for I/O accelerator mode support */
> > if (trans_support & CFGTBL_Trans_io_accel1) {
> > transMethod |= CFGTBL_Trans_io_accel1 |
>
> Shouldn't you be moving this check from its previous location, rather
> than adding a new one that makes the original obsolete?
Oh... I didn't notice that. So that's what happened to that hunk.
Yes, that is what should be done.
I will resend the patch after fixing up this and the commit message.
-- steve
>
> James
>
> ---
>
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 8cf4a0c..9a6e4a2 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
> ctlr_info *h)
> if (hpsa_simple_mode)
> return;
>
> + trans_support = readl(&(h->cfgtable->TransportSupport));
> + if (!(trans_support & PERFORMANT_MODE))
> + return;
> +
> /* Check for I/O accelerator mode support */
> if (trans_support & CFGTBL_Trans_io_accel1) {
> transMethod |= CFGTBL_Trans_io_accel1 |
> @@ -7479,10 +7483,6 @@ static void hpsa_put_ctlr_into_performant_mode(struct
> ctlr_info *h)
> }
>
> /* TODO, check that this next line h->nreply_queues is correct */
> - trans_support = readl(&(h->cfgtable->TransportSupport));
> - if (!(trans_support & PERFORMANT_MODE))
> - return;
> -
> h->nreply_queues = h->msix_vector > 0 ? h->msix_vector : 1;
> hpsa_get_max_perf_mode_cmds(h);
> /* Performant mode ring buffer and supporting data structures */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
Sorry for the delay, I've been having to take turns for this box. On Fri, 2014-04-11 at 09:18 +, Woodhouse, David wrote: > On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote: > > Attaching a dmesg from one of the kernels that boots. It doesn't appear > > to have much of the related information... is there any debug config > > option I can enable that might give you more data? > > I'd like the contents of /sys/firmware/acpi/tables/DMAR please. Attached is the disassembly of the raw output. > And > please could you also apply this patch to both the last-working and > first-failing kernels and show me the output in both cases? So I still cannot get around getting the info for the first failing kernel, but below is for the last working. Thanks. Device 0:03:00.0 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 - 0x7f61] Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.1 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.3 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.4 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.4 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.7 [0x7f7ee000 - 0x7f7e] Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 IOMMU: Prepare 0-16MiB unity mapping for LPC IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff] Device 0:00:1f.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 PCI-DMA: Intel(R) Virtualization Technology for Directed I/O Device 0:00:00.0 on IOMMU at a800 Device 0:00:01.0 on IOMMU at a800 Device 0:00:02.0 on IOMMU at a800 Device 0:00:03.0 on IOMMU at a800 Device 0:00:04.0 on IOMMU at a800 Device 0:00:05.0 on IOMMU at a800 Device 0:00:06.0 on IOMMU at a800 Device 0:00:07.0 on IOMMU at a800 Device 0:00:08.0 on IOMMU at a800 Device 0:00:09.0 on IOMMU at a800 Device 0:00:0a.0 on IOMMU at a800 Device 0:00:14.0 on IOMMU at a800 Device 0:00:1c.0 on IOMMU at a800 Device 0:00:1c.4 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1e.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 Device 0:04:00.0 on IOMMU at a800 Device 0:04:00.1 on IOMMU at a800 Device 0:04:00.2 on IOMMU at a800 Device 0:04:00.3 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 Device 0:01:03.0 on IOMMU at a800 Device 0:50:00.0 on IOMMU at ac00 Device 0:50:01.0 on IOMMU at ac00 Device 0:50:02.0 on IOMMU at ac00 Device 0:50:03.0 on IOMMU at ac00 Device 0:50:04.0 on IOMMU at ac00 Device 0:50:05.0 on IOMMU at ac00 Device 0:50:06.0 on IOMMU at ac00 Device 0:50:07.0 on IOMMU at ac00 Device 0:50:08.0 on IOMMU at ac00 Device 0:50:09.0 on IOMMU at ac00 Device 0:50:0a.0 on IOMMU at ac00 Device 0:50:14.0 on IOMMU at a800 Device 0:a0:00.0 on IOMMU at b000 Device 0:a0:01.0 on IOMMU at b000 Device 0:a0:02.0 on IOMMU at b000 Device 0:a0:03.0 on IOMMU at b000 Device 0:a0:04.0 on IOMMU at b000 Device 0:a0:05.0 on IOMMU at b000 Device 0:a0:06.0 on IOMMU at b000 Device 0:a0:07.0 on IOMMU at b000 Device 0:a0:08.0 on IOMMU at b000 Device 0:a0:09.0 on IOMMU at b000 Device 0:a0:0a.0 on IOMMU at b000 Device 0:a0:14.0 on IOMMU at a800 Device 0:7c:00.0 on IOMMU at a800 Device 0:7c:08.0 on IOMMU at a800 Device 0:82:00.0 on IOMMU at a800 Device 0:82:08.0 on IOMMU at a800 /* * Intel ACPI Component Architecture * AML Disassembler version 20140325-64 [Apr 11 2014] * Copyright (c) 2000 - 2014 Intel Corporation * * Disassembly of DMAR.raw, Fri Apr 11 09:10:10 2014 * * ACPI Data Table [DMAR] * * Fo
Re: [PATCH] hpsa: fix uninitialized trans_support in hpsa_put_ctlr_into_performant_mode()
Your subject line is very tame. It should be the one line summary of
why we apply the patch, so it should read something like
hpsa: fix NULL deref in performant mode
On Thu, 2014-04-10 at 17:17 -0500, scame...@beardog.cce.hp.com wrote:
> Without this, you'll see a null pointer dereference in
> hpsa_enter_performant_mode().
The description should be more comprehensible.
I'm clear that the use before initialisation is a bug ... I'm less clear
on why it causes an oops.
> Signed-off-by: Stephen M. Cameron
> ---
> drivers/scsi/hpsa.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 8cf4a0c..ef4dfdd 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
> ctlr_info *h)
> if (hpsa_simple_mode)
> return;
>
> + trans_support = readl(&(h->cfgtable->TransportSupport));
> + if (!(trans_support & PERFORMANT_MODE))
> + return;
> +
> /* Check for I/O accelerator mode support */
> if (trans_support & CFGTBL_Trans_io_accel1) {
> transMethod |= CFGTBL_Trans_io_accel1 |
Shouldn't you be moving this check from its previous location, rather
than adding a new one that makes the original obsolete?
James
---
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..9a6e4a2 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
if (hpsa_simple_mode)
return;
+ trans_support = readl(&(h->cfgtable->TransportSupport));
+ if (!(trans_support & PERFORMANT_MODE))
+ return;
+
/* Check for I/O accelerator mode support */
if (trans_support & CFGTBL_Trans_io_accel1) {
transMethod |= CFGTBL_Trans_io_accel1 |
@@ -7479,10 +7483,6 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
}
/* TODO, check that this next line h->nreply_queues is correct */
- trans_support = readl(&(h->cfgtable->TransportSupport));
- if (!(trans_support & PERFORMANT_MODE))
- return;
-
h->nreply_queues = h->msix_vector > 0 ? h->msix_vector : 1;
hpsa_get_max_perf_mode_cmds(h);
/* Performant mode ring buffer and supporting data structures */
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPSA related kernel panic on boot in 3.15 rc1 on Proliant with P420i
Hi,
i've found that patch, but somehow relevant thread was showing only on
http://www.spinics.net/lists/linux-scsi/msg73770.html but not on
marc.info
Anyway, after applying patch, my system passes HPSA initialization,
...but goes boom with unknown FS on block 0,0 error, but it is
probably not related, as somehow i see initrd generated, even if
config was copied from 3.14 where there was non.
http://tinypic.com/r/311qvc3/8
Looking into this problem, but probably not HPSA related, sorry for
repeat bug report.
Thanks for help,
Darius.
On Mon, Apr 14, 2014 at 4:03 PM, wrote:
> On Mon, Apr 14, 2014 at 2:33 PM, Darius D. wrote:
>> Hi,
>>
>> on P420i (2GB FBWC) with latest(5.22?) FW, and 2 SSD smart path
>> enabled RAID0 arrays (1 and 3 SSD), i get panic on initialization.
>> What is sad, i can't capture complete stack trace and it is deep in
>> kernel worker, but top items are:
>>
>> SA5_performant_intr_mask+0x30/0x30
>> spin_unlock_irqrestore
>> hpsa_unit_one
>> local_pci_probe
>> ... kthread worker stuff
>>
>>
>> RIP is calc_bucket_map+0x30/0x3a.
>>
>>
>> Anyone got idea what is going on? 3.14 was working fine with exact
>> config, so i suspect it could be HPSA smart path code related.
>
> Try the patch below, and see also: http://marc.info/?t=13970113551&r=1&w=2
>
> -- steve
>
>
> From f6b44f25c451d32cca5cf2e9825e0636132e69cf Mon Sep 17 00:00:00 2001
> From: Stephen M. Cameron
> Date: Thu, 10 Apr 2014 16:44:59 -0500
> Subject: [PATCH] hpsa: fix uninitialized variable in
> hpsa_put_ctlr_into_performant_mode()
>
> Without this, you'll see a null pointer dereference in
> hpsa_enter_performant_mode().
>
> Signed-off-by: Stephen M. Cameron
> ---
> drivers/scsi/hpsa.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 8cf4a0c..ef4dfdd 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
> ctlr_info *h)
> if (hpsa_simple_mode)
> return;
>
> + trans_support = readl(&(h->cfgtable->TransportSupport));
> + if (!(trans_support & PERFORMANT_MODE))
> + return;
> +
> /* Check for I/O accelerator mode support */
> if (trans_support & CFGTBL_Trans_io_accel1) {
> transMethod |= CFGTBL_Trans_io_accel1 |
> --
> 1.7.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.15-mw: Oops Workqueue: writeback bdi_writeback_workfn (flush-8:16) RIP: e030:[] [] kobject_put+0x11/0x70
Monday, April 14, 2014, 1:30:15 PM, you wrote:
> On Sat, Apr 12, 2014 at 01:34:31PM +0200, Sander Eikelenboom wrote:
>> Hi,
>>
>> I just ran into the oops belowafter some uptime.
> Classic use after free introduced by my recent changes, sorry.
> This should fix it:
Thx !
> ---
> From: Christoph Hellwig
> Subject: scsi: don't reference freed command in scsi_init_sgtable
> When scsi_init_io fails we have to release our device reference, but
> we do this trying to reference the just freed command. Add a local
> scsi_device pointer to fix this.
> Reported-by: Sander Eikelenboom
> Signed-off-by: Christoph Hellwig
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 65a123d..54eff6a 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1044,6 +1044,7 @@ static int scsi_init_sgtable(struct request *req,
> struct scsi_data_buffer *sdb,
> */
> int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
> {
> + struct scsi_device *sdev = cmd->device;
> struct request *rq = cmd->request;
>
> int error = scsi_init_sgtable(rq, &cmd->sdb, gfp_mask);
> @@ -1091,7 +1092,7 @@ err_exit:
> scsi_release_buffers(cmd);
> cmd->request->special = NULL;
> scsi_put_command(cmd);
> - put_device(&cmd->device->sdev_gendev);
> + put_device(&sdev->sdev_gendev);
> return error;
> }
> EXPORT_SYMBOL(scsi_init_io);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPSA related kernel panic on boot in 3.15 rc1 on Proliant with P420i
On Mon, Apr 14, 2014 at 2:33 PM, Darius D. wrote:
> Hi,
>
> on P420i (2GB FBWC) with latest(5.22?) FW, and 2 SSD smart path
> enabled RAID0 arrays (1 and 3 SSD), i get panic on initialization.
> What is sad, i can't capture complete stack trace and it is deep in
> kernel worker, but top items are:
>
> SA5_performant_intr_mask+0x30/0x30
> spin_unlock_irqrestore
> hpsa_unit_one
> local_pci_probe
> ... kthread worker stuff
>
>
> RIP is calc_bucket_map+0x30/0x3a.
>
>
> Anyone got idea what is going on? 3.14 was working fine with exact
> config, so i suspect it could be HPSA smart path code related.
Try the patch below, and see also: http://marc.info/?t=13970113551&r=1&w=2
-- steve
>From f6b44f25c451d32cca5cf2e9825e0636132e69cf Mon Sep 17 00:00:00 2001
From: Stephen M. Cameron
Date: Thu, 10 Apr 2014 16:44:59 -0500
Subject: [PATCH] hpsa: fix uninitialized variable in
hpsa_put_ctlr_into_performant_mode()
Without this, you'll see a null pointer dereference in
hpsa_enter_performant_mode().
Signed-off-by: Stephen M. Cameron
---
drivers/scsi/hpsa.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..ef4dfdd 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7463,6 +7463,10 @@ static void hpsa_put_ctlr_into_performant_mode(struct
ctlr_info *h)
if (hpsa_simple_mode)
return;
+ trans_support = readl(&(h->cfgtable->TransportSupport));
+ if (!(trans_support & PERFORMANT_MODE))
+ return;
+
/* Check for I/O accelerator mode support */
if (trans_support & CFGTBL_Trans_io_accel1) {
transMethod |= CFGTBL_Trans_io_accel1 |
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HPSA related kernel panic on boot in 3.15 rc1 on Proliant with P420i
After minor googling found vga= option for kernel and managed to capture full stack trace, like i suspected it is HPSA performant mode related. uploaded pic: http://tinypic.com/r/2j68rwx/8 BR, Darius. On Mon, Apr 14, 2014 at 2:33 PM, Darius D. wrote: > Hi, > > on P420i (2GB FBWC) with latest(5.22?) FW, and 2 SSD smart path > enabled RAID0 arrays (1 and 3 SSD), i get panic on initialization. > What is sad, i can't capture complete stack trace and it is deep in > kernel worker, but top items are: > > SA5_performant_intr_mask+0x30/0x30 > spin_unlock_irqrestore > hpsa_unit_one > local_pci_probe > ... kthread worker stuff > > > RIP is calc_bucket_map+0x30/0x3a. > > > Anyone got idea what is going on? 3.14 was working fine with exact > config, so i suspect it could be HPSA smart path code related. > > > Best regards, > > Darius. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
HPSA related kernel panic on boot in 3.15 rc1 on Proliant with P420i
Hi, on P420i (2GB FBWC) with latest(5.22?) FW, and 2 SSD smart path enabled RAID0 arrays (1 and 3 SSD), i get panic on initialization. What is sad, i can't capture complete stack trace and it is deep in kernel worker, but top items are: SA5_performant_intr_mask+0x30/0x30 spin_unlock_irqrestore hpsa_unit_one local_pci_probe ... kthread worker stuff RIP is calc_bucket_map+0x30/0x3a. Anyone got idea what is going on? 3.14 was working fine with exact config, so i suspect it could be HPSA smart path code related. Best regards, Darius. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.15-mw: Oops Workqueue: writeback bdi_writeback_workfn (flush-8:16) RIP: e030:[] [] kobject_put+0x11/0x70
On Sat, Apr 12, 2014 at 01:34:31PM +0200, Sander Eikelenboom wrote:
> Hi,
>
> I just ran into the oops belowafter some uptime.
Classic use after free introduced by my recent changes, sorry.
This should fix it:
---
From: Christoph Hellwig
Subject: scsi: don't reference freed command in scsi_init_sgtable
When scsi_init_io fails we have to release our device reference, but
we do this trying to reference the just freed command. Add a local
scsi_device pointer to fix this.
Reported-by: Sander Eikelenboom
Signed-off-by: Christoph Hellwig
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 65a123d..54eff6a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1044,6 +1044,7 @@ static int scsi_init_sgtable(struct request *req, struct
scsi_data_buffer *sdb,
*/
int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
{
+ struct scsi_device *sdev = cmd->device;
struct request *rq = cmd->request;
int error = scsi_init_sgtable(rq, &cmd->sdb, gfp_mask);
@@ -1091,7 +1092,7 @@ err_exit:
scsi_release_buffers(cmd);
cmd->request->special = NULL;
scsi_put_command(cmd);
- put_device(&cmd->device->sdev_gendev);
+ put_device(&sdev->sdev_gendev);
return error;
}
EXPORT_SYMBOL(scsi_init_io);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
Hi Dave,
When this bit is set, the 53CF94/96 can receive 3-byte messages
during
bus-initiated Select With ATN. This feature is also enabled by
setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
Agreed. ESP_CONFIG2_SCSI2ENAB might do more than we intend, and have
unintended side effects. It's just easier to test whether this fixes
our problem.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per
ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/
NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
That's what I understood from the bits Kars quoted, yes. And in the
Amiga driver cases, it will always be the 3 byte message feature
controlled by that bit, as far as I can see.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
That would be even easier than setting it explicitly in the Zorro
driver, thanks,
Michael
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong
Reported-by: Michael Schmitz
Signed-off-by: David S. Miller
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp->rev = ESP100;
} else {
- esp->config2 = 0;
+ esp->config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp->prev_cfg3 = 5;
esp_write8(esp->config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp->rev = ESP236;
}
- esp->config2 = 0;
- esp_write8(esp->config2, ESP_CFG2);
}
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
Hi all,
I guess I found the root cause. It's a bug in matching
device scope, variable 'level' should be decreased when walking up PCI
topology.
Could you please help to test following patch?
Thanks!
Gerry
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index f445c10..1f8308c 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -152,7 +152,7 @@ dmar_alloc_pci_notify_info(struct pci_dev *dev,
unsigned long event)
info->seg = pci_domain_nr(dev->bus);
info->level = level;
if (event == BUS_NOTIFY_ADD_DEVICE) {
- for (tmp = dev, level--; tmp; tmp = tmp->bus->self) {
+ for (tmp = dev, level--; tmp; level--, tmp =
tmp->bus->self) {
info->path[level].device = PCI_SLOT(tmp->devfn);
info->path[level].function = PCI_FUNC(tmp->devfn);
if (pci_is_root_bus(tmp->bus))
On 2014/4/11 0:19, Davidlohr Bueso wrote:
> On Thu, 2014-04-10 at 08:46 +, Woodhouse, David wrote:
>> On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote:
>>> [+ David, VT-d maintainer ]
>>>
>>> Jiang, David, can you please have a look into this issue?
>>>
>>
>>> DMAR:[fault reason 02] Present bit in context entry is clear
>>> dmar: DRHD: handling fault status reg 602
>>> dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000
>>
>> That "Present bit in context entry is clear" fault means that we have
>> not set up *any* mappings for this PCI device… on this IOMMU.
>>
Yes, specifically (finally done bisecting):
commit 2e45528930388658603ea24d49cf52867b928d3e
Author: Jiang Liu
Date: Wed Feb 19 14:07:36 2014 +0800
iommu/vt-d: Unify the way to process DMAR device scope array
>>
>> This commit is about how we decide which IOMMU a given PCI device is
>> attached to.
>>
>> Thus, my first guess would be that we are quite happily setting up the
>> requested DMA maps on the *wrong* IOMMU, and then taking faults when the
>> device actually tries to do DMA.
>>
>> However, I'm not 100% convinced of that. The fault address looks
>> suspiciously like a true physical address, not a virtual bus address of
>> the type that we'd normally allocate for a dma_map_* operation. Those
>> would start at 0xf000 and work downwards, typically.
>>
>> Do you have 'iommu=pt' on the kernel command line?
>
> No.
>
>> Can I see the full
>> dmesg as this system boots, and also a copy of the DMAR table?
>
> Attaching a dmesg from one of the kernels that boots. It doesn't appear
> to have much of the related information... is there any debug config
> option I can enable that might give you more data?
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
Hi Tuomas,
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per
ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/
NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong
Reported-by: Michael Schmitz
Signed-off-by: David S. Miller
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp->rev = ESP100;
} else {
- esp->config2 = 0;
+ esp->config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp->prev_cfg3 = 5;
esp_write8(esp->config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp->rev = ESP236;
}
- esp->config2 = 0;
- esp_write8(esp->config2, ESP_CFG2);
}
}
}
I'll test these out soon.
Michael, where can I pull the latest version of zorro_esp?
Not sure my patch had ever made it into Geert's m68k-queue - except for
the patch in my previous mail, my zorro_esp.c is still the same as I
got from you in October last year. The project has been on the back
burner for too long ...
I'll look into setting up pull access to my repository. zorro_esp.c as
of today attached for now.
Cheers,
Michael
/* zorrro_esp.c: ESP front-end for Amiga ZORRO SCSI systems.
*
* Copyright (C) 1996 Jesper Skov (js...@cygnus.co.uk)
*
* Copyright (C) 2011 Michael Schmitz (schm...@debian.org) for
* migration to ESP SCSI core
*/
/*
* ZORRO bus code from:
*/
/*
* Detection routine for the NCR53c710 based Amiga SCSI Controllers for Linux.
* Amiga MacroSystemUS WarpEngine SCSI controller.
* Amiga Technologies/DKB A4091 SCSI controller.
*
* Written 1997 by Alan Hourihane
* plus modifications of the 53c7xx.c driver to support the Amiga.
*
* Rewritten to use 53c700.c by Kars de Jong
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "esp_scsi.h"
MODULE_AUTHOR("Michael Schmitz ");
MODULE_DESCRIPTION("Amiga Zorro NCR5C9x (ESP) driver");
MODULE_LICENSE("GPL");
#define DMA_WRITE 0x8000
static struct zorro_driver_data {
const char *name;
unsigned long offset;
unsigned long dma_offset;
int absolute;
int zorro3; /* offset is absolute address */
} zorro_esp_driver_data[] = {
{ .name = "CyberStormI", .offset = 0xf400, .dma_offset = 0xf800,
.absolute = 0, .zorro3 = 0 },
{ .name = "CyberStormII", .offset = 0x1ff03, .dma_offset = 0x1ff43,
.absolute = 0, .zorro3 = 0 },
{ .name = "Blizzard 2060", .offset = 0x1ff00, .dma_offset = 0x1ffe0,
.absolute = 0, .zorro3 = 0 },
{ .name = "Blizzard 1230", .offset = 0x8000, .dma_offset = 0x1,
.absolute = 0, .zorro3 = 0 },
{ .name = "Blizzard 1230II", .offset = 0x1, .dma_offset = 0x10021,
.absolute = 0, .zorro3 = 0 },
{ .name = "Fastlane", .offset = 0x101, .dma_offset = 0x141,
.absolute = 0, .zorro3 = 1 },
{ 0 }
};
static struct zorro_device_id zorro_esp_zorro_tbl[] = {
{
.id = ZORRO_PROD_PHASE5_BLIZZARD_1220_CYBERSTORM,
.driver_data = (unsigned long)&zorro_esp_driver_data[0],
},
{
.id =
ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
.driver_data = (unsigned long)&zorro_esp_driver_data[0],
},
{
.id = ZORRO_PROD_PHASE5_CYBERSTORM_MK_II,
.driver_da
[Bug 74011] New: strange observation, the queue depth is (64) meanwhile fw queue depth (65)
https://bugzilla.kernel.org/show_bug.cgi?id=74011 Bug ID: 74011 Summary: strange observation, the queue depth is (64) meanwhile fw queue depth (65) Product: IO/Storage Version: 2.5 Kernel Version: 3.2 to 3.14.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: SCSI Assignee: linux-scsi@vger.kernel.org Reporter: rbli...@gmail.com Regression: No Created attachment 132121 --> https://bugzilla.kernel.org/attachment.cgi?id=132121&action=edit System information I get this error on the disk containing the root partition This happens on recent kernels, but not on the 2.6.32.61 kernel. The code generating these messages is however identical in 2.6.32.61 and newer kernels. This doesn't especially happen when the system is under high load. This happens on both our production and stand-by server. Production server was switched back to 2.6.32.61. Attached file contains system information of the stand-by server running kernel 3.14.0 (cpuinfo.txt lspci.txt meminfo.txt proc_scsi_scsi.txt ver_linux.txt). I can provide more info and perform tests if needed. -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Vertraulich //
Guten Abend, Ich bin Herr Juan Morato, der Auditor General von Unicaja Bank- Madrid. Im Zuge meiner Abschlussprüfung, entdeckte ich eine schwimmende Fonds auf einem Konto, das 1990 bei der Cam Bank eröffnet wurde, bevor der Besitz von Unicaja Gruppe gekauft wurde, ich bin der Abschlussprüfer der einem toten Ausländer Herr Kenny, der im Jahr 2004 starb, zugeteilt wurde. Jede Anstrengung, ein Mitglied seiner Familie oder einen nächsten Angehörigen zu Ermitteln sind gescheitert. Bei meinen Ermittlungen habe ich festgestellt, dass Sie zu den nächsten Angehörigen gehören, da Sie den gleichen Nachnamen tragen. Er verstarb ohne Nachkommen oder einen Testament. Meine Absicht ist es, diese Summe von 5,5 Mio. von den oben genannten Konto auf ein sicheres Konto zu überweisen. Ich schlage daher vor, dass ich Sie als stillen Teilhaber eintrage und Sie mir ein Konto zur Verfügung stellen, oder ein neues Konto eröffnen um dieses Geld dorthin zu überweisen. Für Ihre Unterstützung bei diesem Vorhaben, bin ich bereit, mit einem guten Prozentsatz des gesamten Fonds zu trennen. Beim durchsehen der Aufzeichnungen und Akten der verstorbenen Person, entdeckte ich, dass: (1) Niemand dieses Konto seit 2004 betrieben hat (2) Er starb ohne Erben, daher das Geld weiter floss. (3) Keine andere Person über dieses Konto bescheid weiß und auch kein Empfänger eingetragen ist Wenn ich mich nicht schnellstens dieser Angelegenheit annehme, wird dieses Geld verfallen und anschließend in Gesellschaftsmitteln fließen, von denen nur die Regisseure meiner Firma profitieren werden. Ich kann Ihnen dieses Geld rechtlich zukommen lassen, wenn Sie einige notwendigen Genehmigungen ,die auf Ihren Namen zugelassen sind ausfüllen,wobei ich Ihnen selbstverständlich behilflich sein werde. Bitte geben Sie mir eine Antwort auf meine private E -Mail- juan.mora...@1email.eu oder Fax + 34 917 692 656, so dass ich Ihnen detaillierte Informationen über die Modalitäten meines Vorschlages zu senden kann. Ich bitte Sie eingehend dieses Schreiben absolut vertraulich zu behandeln. Bitte senden Sie mir Ihre Telefonnummer auf der sie leicht zu erreichen sind. Ich freue mich auf Ihre baldige Antwort. Mit freundlichen Grüßen Herr Juan Morato Tel.: + 34 631 178 660 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 00/23] scsi: Use pci_enable_msix_range() instead of pci_enable_msix()
Hello, This series is against 3.15-rc1. As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. There are no major changes in this series since I posted it last time. Thanks! Cc: iss_storage...@hp.com Cc: intel-linux-...@intel.com Cc: supp...@lsi.com Cc: dl-mptfusionli...@lsi.com Cc: qla2xxx-upstr...@qlogic.com Cc: iscsi-dri...@qlogic.com Cc: pv-driv...@vmware.com Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org Alexander Gordeev (23): be2iscsi: Use pci_enable_msix_exact() instead of pci_enable_msix() bfa: Do not call pci_enable_msix() after it failed once bfa: Cleanup bfad_setup_intr() function bfa: Use pci_enable_msix_exact() instead of pci_enable_msix() csiostor: Remove superfluous call to pci_disable_msix() csiostor: Use pci_enable_msix_range() instead of pci_enable_msix() fnic: Use pci_enable_msix_exact() instead of pci_enable_msix() isci: Use pci_enable_msix_exact() instead of pci_enable_msix() hpsa: Fallback to MSI rather than to INTx if MSI-X failed hpsa: Use pci_enable_msix_range() instead of pci_enable_msix() lpfc: Remove superfluous call to pci_disable_msix() lpfc: Use pci_enable_msix_range() instead of pci_enable_msix() megaraid: Fail resume if MSI-X re-initialization failed megaraid: Use pci_enable_msix_range() instead of pci_enable_msix() mpt2sas: Use pci_enable_msix_exact() instead of pci_enable_msix() mpt3sas: Use pci_enable_msix_exact() instead of pci_enable_msix() pm8001: Fix invalid return when request_irq() failed pm8001: Use pci_enable_msix_exact() instead of pci_enable_msix() pmcraid: Get rid of a redundant assignment pmcraid: Use pci_enable_msix_range() instead of pci_enable_msix() qla2xxx: Use pci_enable_msix_range() instead of pci_enable_msix() qla4xxx: Use pci_enable_msix_exact() instead of pci_enable_msix() vmw_pvscsi: Use pci_enable_msix_exact() instead of pci_enable_msix() drivers/scsi/be2iscsi/be_main.c |6 +-- drivers/scsi/bfa/bfad.c | 62 - drivers/scsi/csiostor/csio_hw.h |2 +- drivers/scsi/csiostor/csio_isr.c | 24 --- drivers/scsi/fnic/fnic_isr.c |4 +- drivers/scsi/hpsa.c | 30 ++ drivers/scsi/isci/init.c |2 +- drivers/scsi/lpfc/lpfc_init.c | 47 +++--- drivers/scsi/megaraid/megaraid_sas_base.c | 24 +-- drivers/scsi/mpt2sas/mpt2sas_base.c |6 +- drivers/scsi/mpt3sas/mpt3sas_base.c |4 +- drivers/scsi/pm8001/pm8001_init.c | 44 +++-- drivers/scsi/pmcraid.c| 14 +-- drivers/scsi/qla2xxx/qla_isr.c| 27 +--- drivers/scsi/qla4xxx/ql4_nx.c |2 +- drivers/scsi/vmw_pvscsi.c |2 +- 16 files changed, 129 insertions(+), 171 deletions(-) -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 01/23] be2iscsi: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. Signed-off-by: Alexander Gordeev Cc: Jayamohan Kallickal Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org Acked-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be_main.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c index 0d82229..279b2f9 100644 --- a/drivers/scsi/be2iscsi/be_main.c +++ b/drivers/scsi/be2iscsi/be_main.c @@ -5282,12 +5282,10 @@ static void beiscsi_msix_enable(struct beiscsi_hba *phba) for (i = 0; i <= phba->num_cpus; i++) phba->msix_entries[i].entry = i; - status = pci_enable_msix(phba->pcidev, phba->msix_entries, -(phba->num_cpus + 1)); + status = pci_enable_msix_exact(phba->pcidev, phba->msix_entries, + phba->num_cpus + 1); if (!status) phba->msix_enabled = true; - - return; } /* -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] blk-mq: make ->flush_rq fully transparent to drivers
Drivers shouldn't have to care about the block layer setting aside a
request to implement the flush state machine. We already override the
mq context and tag to make it more transparent, but so far haven't deal
with the driver private data in the request. Make sure to override this
as well, and while we're at it add a proper helper sitting in blk-mq.c
that implements the full impersonation.
Signed-off-by: Christoph Hellwig
---
block/blk-flush.c | 12 ++--
block/blk-mq.c| 20
block/blk-mq.h|2 ++
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/block/blk-flush.c b/block/blk-flush.c
index 9a0c427..b218f61 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -307,16 +307,8 @@ static bool blk_kick_flush(struct request_queue *q)
q->flush_pending_idx ^= 1;
blk_rq_init(q, q->flush_rq);
- if (q->mq_ops) {
- /*
-* Reuse the tag value from the fist waiting request,
-* with blk-mq the tag is generated during request
-* allocation and drivers can rely on it being inside
-* the range they asked for.
-*/
- q->flush_rq->mq_ctx = first_rq->mq_ctx;
- q->flush_rq->tag = first_rq->tag;
- }
+ if (q->mq_ops)
+ blk_mq_clone_flush_request(q->flush_rq, first_rq);
q->flush_rq->cmd_type = REQ_TYPE_FS;
q->flush_rq->cmd_flags = WRITE_FLUSH | REQ_FLUSH_SEQ;
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 747feb9..67859e9 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -272,6 +272,26 @@ void blk_mq_free_request(struct request *rq)
__blk_mq_free_request(hctx, ctx, rq);
}
+/*
+ * Clone all relevant state from a request that has been put on hold in
+ * the flush state machine into the preallocated flush request that hangs
+ * off the request queue.
+ *
+ * For a driver the flush request should be invisible, that's why we are
+ * impersonating the original request here.
+ */
+void blk_mq_clone_flush_request(struct request *flush_rq,
+ struct request *orig_rq)
+{
+ struct blk_mq_hw_ctx *hctx =
+ orig_rq->q->mq_ops->map_queue(orig_rq->q, orig_rq->mq_ctx->cpu);
+
+ flush_rq->mq_ctx = orig_rq->mq_ctx;
+ flush_rq->tag = orig_rq->tag;
+ memcpy(blk_mq_rq_to_pdu(flush_rq), blk_mq_rq_to_pdu(orig_rq),
+ hctx->cmd_size);
+}
+
bool blk_mq_end_io_partial(struct request *rq, int error, unsigned int
nr_bytes)
{
if (blk_update_request(rq, error, blk_rq_bytes(rq)))
diff --git a/block/blk-mq.h b/block/blk-mq.h
index 238379a..7964dad 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -27,6 +27,8 @@ void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool
async);
void blk_mq_init_flush(struct request_queue *q);
void blk_mq_drain_queue(struct request_queue *q);
void blk_mq_free_queue(struct request_queue *q);
+void blk_mq_clone_flush_request(struct request *flush_rq,
+ struct request *orig_rq);
/*
* CPU hotplug helpers
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 03/23] bfa: Cleanup bfad_setup_intr() function
Signed-off-by: Alexander Gordeev
Cc: Anil Gurumurthy
Cc: Vijaya Mohan Guvva
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Anil Gurumurthy
---
drivers/scsi/bfa/bfad.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index 972ff8d..e7e4774 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1219,7 +1219,7 @@ bfad_install_msix_handler(struct bfad_s *bfad)
int
bfad_setup_intr(struct bfad_s *bfad)
{
- int error = 0;
+ int error;
u32 mask = 0, i, num_bit = 0, max_bit = 0;
struct msix_entry msix_entries[MAX_MSIX_ENTRY];
struct pci_dev *pdev = bfad->pcidev;
@@ -1279,20 +1279,18 @@ bfad_setup_intr(struct bfad_s *bfad)
bfad->bfad_flags |= BFAD_MSIX_ON;
- return error;
+ return 0;
}
line_based:
- error = 0;
- if (request_irq
- (bfad->pcidev->irq, (irq_handler_t) bfad_intx, BFAD_IRQ_FLAGS,
-BFAD_DRIVER_NAME, bfad) != 0) {
- /* Enable interrupt handler failed */
- return 1;
- }
+ error = request_irq(bfad->pcidev->irq, (irq_handler_t)bfad_intx,
+ BFAD_IRQ_FLAGS, BFAD_DRIVER_NAME, bfad);
+ if (error)
+ return error;
+
bfad->bfad_flags |= BFAD_INTX_ON;
- return error;
+ return 0;
}
void
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] blk-mq: do not initialize req->special
Drivers can reach their private data easily using the blk_mq_rq_to_pdu
helper and don't need req->special. By not initializing it code can
be simplified nicely, and we also shave off a few more instructions from
the I/O path.
Signed-off-by: Christoph Hellwig
---
block/blk-flush.c | 10 ++
block/blk-mq.c | 15 ++-
block/blk-mq.h |1 -
drivers/block/null_blk.c |4 ++--
drivers/block/virtio_blk.c |6 +++---
5 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/block/blk-flush.c b/block/blk-flush.c
index 43e6b47..9a0c427 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -306,22 +306,16 @@ static bool blk_kick_flush(struct request_queue *q)
*/
q->flush_pending_idx ^= 1;
+ blk_rq_init(q, q->flush_rq);
if (q->mq_ops) {
- struct blk_mq_ctx *ctx = first_rq->mq_ctx;
- struct blk_mq_hw_ctx *hctx = q->mq_ops->map_queue(q, ctx->cpu);
-
- blk_mq_rq_init(hctx, q->flush_rq);
- q->flush_rq->mq_ctx = ctx;
-
/*
* Reuse the tag value from the fist waiting request,
* with blk-mq the tag is generated during request
* allocation and drivers can rely on it being inside
* the range they asked for.
*/
+ q->flush_rq->mq_ctx = first_rq->mq_ctx;
q->flush_rq->tag = first_rq->tag;
- } else {
- blk_rq_init(q, q->flush_rq);
}
q->flush_rq->cmd_type = REQ_TYPE_FS;
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c1f4736..747feb9 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -248,24 +248,13 @@ struct request *blk_mq_alloc_reserved_request(struct
request_queue *q, int rw,
}
EXPORT_SYMBOL(blk_mq_alloc_reserved_request);
-/*
- * Re-init and set pdu, if we have it
- */
-void blk_mq_rq_init(struct blk_mq_hw_ctx *hctx, struct request *rq)
-{
- blk_rq_init(hctx->queue, rq);
-
- if (hctx->cmd_size)
- rq->special = blk_mq_rq_to_pdu(rq);
-}
-
static void __blk_mq_free_request(struct blk_mq_hw_ctx *hctx,
struct blk_mq_ctx *ctx, struct request *rq)
{
const int tag = rq->tag;
struct request_queue *q = rq->q;
- blk_mq_rq_init(hctx, rq);
+ blk_rq_init(hctx->queue, rq);
blk_mq_put_tag(hctx->tags, tag);
blk_mq_queue_exit(q);
@@ -1143,7 +1132,7 @@ static int blk_mq_init_rq_map(struct blk_mq_hw_ctx *hctx,
left -= to_do * rq_size;
for (j = 0; j < to_do; j++) {
hctx->rqs[i] = p;
- blk_mq_rq_init(hctx, hctx->rqs[i]);
+ blk_rq_init(hctx->queue, hctx->rqs[i]);
p += rq_size;
i++;
}
diff --git a/block/blk-mq.h b/block/blk-mq.h
index ebbe6ba..238379a 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -27,7 +27,6 @@ void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool
async);
void blk_mq_init_flush(struct request_queue *q);
void blk_mq_drain_queue(struct request_queue *q);
void blk_mq_free_queue(struct request_queue *q);
-void blk_mq_rq_init(struct blk_mq_hw_ctx *hctx, struct request *rq);
/*
* CPU hotplug helpers
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index 091b9ea..71df69d 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -226,7 +226,7 @@ static void null_cmd_end_timer(struct nullb_cmd *cmd)
static void null_softirq_done_fn(struct request *rq)
{
- end_cmd(rq->special);
+ end_cmd(blk_mq_rq_to_pdu(rq));
}
static inline void null_handle_cmd(struct nullb_cmd *cmd)
@@ -311,7 +311,7 @@ static void null_request_fn(struct request_queue *q)
static int null_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *rq)
{
- struct nullb_cmd *cmd = rq->special;
+ struct nullb_cmd *cmd = blk_mq_rq_to_pdu(rq);
cmd->rq = rq;
cmd->nq = hctx->driver_data;
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 6d8a87f..c7d02bc 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -112,7 +112,7 @@ static int __virtblk_add_req(struct virtqueue *vq,
static inline void virtblk_request_done(struct request *req)
{
- struct virtblk_req *vbr = req->special;
+ struct virtblk_req *vbr = blk_mq_rq_to_pdu(req);
int error = virtblk_result(vbr);
if (req->cmd_type == REQ_TYPE_BLOCK_PC) {
@@ -154,7 +154,7 @@ static void virtblk_done(struct virtqueue *vq)
static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req)
{
struct virtio_blk *vblk = hctx->queue->queuedata;
- struct virtblk_req *vbr = req->special;
+ struct virtblk_req *vbr = blk_mq_rq_to_pdu(req);
unsigned long flags;
unsigned int num;
const bool last = (req->cmd_flags & R
[PATCH 1/7] blk-mq: initialize resid_len
Signed-off-by: Christoph Hellwig --- block/blk-mq.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-mq.c b/block/blk-mq.c index 1d2a9bd..c1f4736 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -350,6 +350,8 @@ static void blk_mq_start_request(struct request *rq, bool last) trace_block_rq_issue(q, rq); + rq->resid_len = blk_rq_bytes(rq); + /* * Just mark start time and set the started bit. Due to memory * ordering, we know we'll see the correct deadline as long as -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] blk-mq: initialize request on allocation
If we want to share tag and request allocation between queues we cannot
initialize the request at init/free time, but need to initialize it
at allocation time as it might get used for different queues over its
lifetime.
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index ef7acc0..1cb7618 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -82,6 +82,7 @@ static struct request *__blk_mq_alloc_request(struct
blk_mq_hw_ctx *hctx,
tag = blk_mq_get_tag(hctx->tags, gfp, reserved);
if (tag != BLK_MQ_TAG_FAIL) {
rq = hctx->rqs[tag];
+ blk_rq_init(hctx->queue, rq);
rq->tag = tag;
return rq;
@@ -254,9 +255,7 @@ static void __blk_mq_free_request(struct blk_mq_hw_ctx
*hctx,
const int tag = rq->tag;
struct request_queue *q = rq->q;
- blk_rq_init(hctx->queue, rq);
blk_mq_put_tag(hctx->tags, tag);
-
blk_mq_queue_exit(q);
}
@@ -1100,7 +1099,6 @@ static int blk_mq_init_rq_map(struct blk_mq_hw_ctx *hctx,
left -= to_do * rq_size;
for (j = 0; j < to_do; j++) {
hctx->rqs[i] = p;
- blk_rq_init(hctx->queue, hctx->rqs[i]);
if (reg->ops->init_request) {
error = reg->ops->init_request(driver_data,
hctx, hctx->rqs[i], i);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
This is the majority of the blk-mq work still required for switching over SCSI. There are a few more bits for I/O completion and requeueing pending, but they will need further work. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] blk-mq: add ->init_request and ->exit_request methods
The current blk_mq_init_commands/blk_mq_free_commands interface has a two
problems:
1) Because only the constructor is passed to blk_mq_init_commands there
is no easy way to clean up when a comman initialization failed. The
current code simply leaks the allocations done in the constructor.
2) There is no good place to call blk_mq_free_commands: before
blk_cleanup_queue there is no guarantee that all outstanding commands
have completed, so we can't free them yet. After blk_cleanup_queue
the queue has usually been freed. This can be worked around by
grabbing an unconditional reference before calling blk_cleanup_queue
and dropping it after blk_mq_free_commands is done, although that's
not exatly pretty and driver writers are guaranteed to get it wrong
sooner or later.
Both issues are easily fixed by making the request constructor and
destructor normal blk_mq_ops methods.
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c | 105 ++--
drivers/block/virtio_blk.c | 23 +-
include/linux/blk-mq.h | 14 +-
3 files changed, 55 insertions(+), 87 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 67859e9..ef7acc0 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1009,74 +1009,20 @@ static void blk_mq_hctx_notify(void *data, unsigned
long action,
blk_mq_run_hw_queue(hctx, true);
}
-static int blk_mq_init_hw_commands(struct blk_mq_hw_ctx *hctx,
- int (*init)(void *, struct blk_mq_hw_ctx *,
- struct request *, unsigned int),
- void *data)
+static void blk_mq_free_rq_map(struct blk_mq_hw_ctx *hctx, void *driver_data)
{
- unsigned int i;
- int ret = 0;
-
- for (i = 0; i < hctx->queue_depth; i++) {
- struct request *rq = hctx->rqs[i];
-
- ret = init(data, hctx, rq, i);
- if (ret)
- break;
- }
-
- return ret;
-}
-
-int blk_mq_init_commands(struct request_queue *q,
-int (*init)(void *, struct blk_mq_hw_ctx *,
- struct request *, unsigned int),
-void *data)
-{
- struct blk_mq_hw_ctx *hctx;
- unsigned int i;
- int ret = 0;
-
- queue_for_each_hw_ctx(q, hctx, i) {
- ret = blk_mq_init_hw_commands(hctx, init, data);
- if (ret)
- break;
- }
-
- return ret;
-}
-EXPORT_SYMBOL(blk_mq_init_commands);
-
-static void blk_mq_free_hw_commands(struct blk_mq_hw_ctx *hctx,
- void (*free)(void *, struct blk_mq_hw_ctx *,
- struct request *, unsigned int),
- void *data)
-{
- unsigned int i;
+ struct page *page;
- for (i = 0; i < hctx->queue_depth; i++) {
- struct request *rq = hctx->rqs[i];
+ if (hctx->rqs && hctx->queue->mq_ops->exit_request) {
+ int i;
- free(data, hctx, rq, i);
+ for (i = 0; i < hctx->queue_depth; i++) {
+ if (!hctx->rqs[i])
+ continue;
+ hctx->queue->mq_ops->exit_request(driver_data, hctx,
+ hctx->rqs[i], i);
+ }
}
-}
-
-void blk_mq_free_commands(struct request_queue *q,
- void (*free)(void *, struct blk_mq_hw_ctx *,
- struct request *, unsigned int),
- void *data)
-{
- struct blk_mq_hw_ctx *hctx;
- unsigned int i;
-
- queue_for_each_hw_ctx(q, hctx, i)
- blk_mq_free_hw_commands(hctx, free, data);
-}
-EXPORT_SYMBOL(blk_mq_free_commands);
-
-static void blk_mq_free_rq_map(struct blk_mq_hw_ctx *hctx)
-{
- struct page *page;
while (!list_empty(&hctx->page_list)) {
page = list_first_entry(&hctx->page_list, struct page, lru);
@@ -1101,10 +1047,12 @@ static size_t order_to_size(unsigned int order)
}
static int blk_mq_init_rq_map(struct blk_mq_hw_ctx *hctx,
- unsigned int reserved_tags, int node)
+ struct blk_mq_reg *reg, void *driver_data, int node)
{
+ unsigned int reserved_tags = reg->reserved_tags;
unsigned int i, j, entries_per_page, max_order = 4;
size_t rq_size, left;
+ int error;
INIT_LIST_HEAD(&hctx->page_list);
@@ -1153,14 +1101,23 @@ static int blk_mq_init_rq_map(struct blk_mq_hw_ctx
*hctx,
for (j = 0; j < to_do; j++) {
hctx->rqs[i] = p;
blk_rq_init(hctx->queue, hctx->rqs[i]);
+ if (reg->ops->init_request) {
+ error = reg->ops->ini
[PATCH 7/7] block: all blk-mq requests are tagged
Instead of setting the REQ_QUEUED flag on each of them just take it into account in the only macro checking it. Signed-off-by: Christoph Hellwig --- include/linux/blkdev.h |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 99617cf..7c0e72f 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -1102,7 +1102,8 @@ static inline bool blk_needs_flush_plug(struct task_struct *tsk) /* * tag stuff */ -#define blk_rq_tagged(rq) ((rq)->cmd_flags & REQ_QUEUED) +#define blk_rq_tagged(rq) \ + ((rq)->mq_ctx || ((rq)->cmd_flags & REQ_QUEUED)) extern int blk_queue_start_tag(struct request_queue *, struct request *); extern struct request *blk_queue_find_tag(struct request_queue *, int); extern void blk_queue_end_tag(struct request_queue *, struct request *); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] blk-mq: split out tag initialization, support shared tags
Add a new blk_mq_tag_set structure that gets set up before we initialize
the queue. A single blk_mq_tag_set structure can be shared by multiple
queues.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-cpumap.c |6 +-
block/blk-mq-tag.c | 14 ---
block/blk-mq-tag.h | 19 +++-
block/blk-mq.c | 242
block/blk-mq.h |5 +-
drivers/block/null_blk.c | 92 ++---
drivers/block/virtio_blk.c | 48 +
include/linux/blk-mq.h | 34 +++
8 files changed, 260 insertions(+), 200 deletions(-)
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 0979213..5d0f93c 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -80,17 +80,17 @@ int blk_mq_update_queue_map(unsigned int *map, unsigned int
nr_queues)
return 0;
}
-unsigned int *blk_mq_make_queue_map(struct blk_mq_reg *reg)
+unsigned int *blk_mq_make_queue_map(struct blk_mq_tag_set *set)
{
unsigned int *map;
/* If cpus are offline, map them to first hctx */
map = kzalloc_node(sizeof(*map) * num_possible_cpus(), GFP_KERNEL,
- reg->numa_node);
+ set->numa_node);
if (!map)
return NULL;
- if (!blk_mq_update_queue_map(map, reg->nr_hw_queues))
+ if (!blk_mq_update_queue_map(map, set->nr_hw_queues))
return map;
kfree(map);
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 83ae96c..7a799c4 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -1,25 +1,11 @@
#include
#include
-#include
#include
#include "blk.h"
#include "blk-mq.h"
#include "blk-mq-tag.h"
-/*
- * Per tagged queue (tag address space) map
- */
-struct blk_mq_tags {
- unsigned int nr_tags;
- unsigned int nr_reserved_tags;
- unsigned int nr_batch_move;
- unsigned int nr_max_cache;
-
- struct percpu_ida free_tags;
- struct percpu_ida reserved_tags;
-};
-
void blk_mq_wait_for_tags(struct blk_mq_tags *tags)
{
int tag = blk_mq_get_tag(tags, __GFP_WAIT, false);
diff --git a/block/blk-mq-tag.h b/block/blk-mq-tag.h
index 947ba2c..b602e3f 100644
--- a/block/blk-mq-tag.h
+++ b/block/blk-mq-tag.h
@@ -1,7 +1,24 @@
#ifndef INT_BLK_MQ_TAG_H
#define INT_BLK_MQ_TAG_H
-struct blk_mq_tags;
+#include
+
+/*
+ * Tag address space map.
+ */
+struct blk_mq_tags {
+ unsigned int nr_tags;
+ unsigned int nr_reserved_tags;
+ unsigned int nr_batch_move;
+ unsigned int nr_max_cache;
+
+ struct percpu_ida free_tags;
+ struct percpu_ida reserved_tags;
+
+ struct request **rqs;
+ struct list_head page_list;
+};
+
extern struct blk_mq_tags *blk_mq_init_tags(unsigned int nr_tags, unsigned int
reserved_tags, int node);
extern void blk_mq_free_tags(struct blk_mq_tags *tags);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 1cb7618..c3b1810 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -81,7 +81,7 @@ static struct request *__blk_mq_alloc_request(struct
blk_mq_hw_ctx *hctx,
tag = blk_mq_get_tag(hctx->tags, gfp, reserved);
if (tag != BLK_MQ_TAG_FAIL) {
- rq = hctx->rqs[tag];
+ rq = hctx->tags->rqs[tag];
blk_rq_init(hctx->queue, rq);
rq->tag = tag;
@@ -401,6 +401,12 @@ static void blk_mq_requeue_request(struct request *rq)
rq->nr_phys_segments--;
}
+struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags, unsigned int tag)
+{
+ return tags->rqs[tag];
+}
+EXPORT_SYMBOL(blk_mq_tag_to_rq);
+
struct blk_mq_timeout_data {
struct blk_mq_hw_ctx *hctx;
unsigned long *next;
@@ -422,12 +428,13 @@ static void blk_mq_timeout_check(void *__data, unsigned
long *free_tags)
do {
struct request *rq;
- tag = find_next_zero_bit(free_tags, hctx->queue_depth, tag);
- if (tag >= hctx->queue_depth)
+ tag = find_next_zero_bit(free_tags, hctx->tags->nr_tags, tag);
+ if (tag >= hctx->tags->nr_tags)
break;
- rq = hctx->rqs[tag++];
-
+ rq = blk_mq_tag_to_rq(hctx->tags, tag++);
+ if (rq->q != hctx->queue)
+ continue;
if (!test_bit(REQ_ATOM_STARTED, &rq->atomic_flags))
continue;
@@ -947,11 +954,11 @@ struct blk_mq_hw_ctx *blk_mq_map_queue(struct
request_queue *q, const int cpu)
}
EXPORT_SYMBOL(blk_mq_map_queue);
-struct blk_mq_hw_ctx *blk_mq_alloc_single_hw_queue(struct blk_mq_reg *reg,
+struct blk_mq_hw_ctx *blk_mq_alloc_single_hw_queue(struct blk_mq_tag_set *set,
unsigned int hctx_index)
{
return kmalloc_node(sizeof(struct blk_mq_hw_ctx),
- GFP_KERNEL | __GFP_ZERO, reg->numa_node);
+
[PATCH v2 RESEND 07/23] fnic: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Hiral Patel
Cc: Suma Ramars
Cc: Brian Uchino
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/fnic/fnic_isr.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/fnic/fnic_isr.c b/drivers/scsi/fnic/fnic_isr.c
index 7d9b54a..a0dd1b6 100644
--- a/drivers/scsi/fnic/fnic_isr.c
+++ b/drivers/scsi/fnic/fnic_isr.c
@@ -257,8 +257,8 @@ int fnic_set_intr_mode(struct fnic *fnic)
fnic->raw_wq_count >= m &&
fnic->wq_copy_count >= o &&
fnic->cq_count >= n + m + o) {
- if (!pci_enable_msix(fnic->pdev, fnic->msix_entry,
- n + m + o + 1)) {
+ if (!pci_enable_msix_exact(fnic->pdev, fnic->msix_entry,
+ n + m + o + 1)) {
fnic->rq_count = n;
fnic->raw_wq_count = m;
fnic->wq_copy_count = o;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 05/23] csiostor: Remove superfluous call to pci_disable_msix()
There is no need to call pci_disable_msix() in case
the previous call to pci_enable_msix() failed
Signed-off-by: Alexander Gordeev
Cc: Naresh Kumar Inna
Cc: Arvind Bhushan
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/csiostor/csio_isr.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_isr.c b/drivers/scsi/csiostor/csio_isr.c
index 7ee9777..91ba91d 100644
--- a/drivers/scsi/csiostor/csio_isr.c
+++ b/drivers/scsi/csiostor/csio_isr.c
@@ -529,10 +529,8 @@ csio_enable_msix(struct csio_hw *hw)
csio_reduce_sqsets(hw, cnt - extra);
}
} else {
- if (rv > 0) {
- pci_disable_msix(hw->pdev);
+ if (rv > 0)
csio_info(hw, "Not using MSI-X, remainder:%d\n", rv);
- }
kfree(entries);
return -ENOMEM;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 04/23] bfa: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Anil Gurumurthy
Cc: Vijaya Mohan Guvva
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/bfa/bfad.c | 20 ++--
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index e7e4774..839c81c 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1234,29 +1234,21 @@ bfad_setup_intr(struct bfad_s *bfad)
if ((bfa_asic_id_ctc(pdev->device) && !msix_disable_ct) ||
(bfa_asic_id_cb(pdev->device) && !msix_disable_cb)) {
- error = pci_enable_msix(bfad->pcidev, msix_entries, bfad->nvec);
+ error = pci_enable_msix_exact(bfad->pcidev,
+ msix_entries, bfad->nvec);
/* In CT1 & CT2, try to allocate just one vector */
- if (error > 0 && bfa_asic_id_ctc(pdev->device)) {
+ if (error == -ENOSPC && bfa_asic_id_ctc(pdev->device)) {
printk(KERN_WARNING "bfa %s: trying one msix "
"vector failed to allocate %d[%d]\n",
bfad->pci_name, bfad->nvec, error);
bfad->nvec = 1;
- error = pci_enable_msix(bfad->pcidev,
- msix_entries, bfad->nvec);
+ error = pci_enable_msix_exact(bfad->pcidev,
+ msix_entries, 1);
}
- /*
-* Only error number of vector is available.
-* We don't have a mechanism to map multiple
-* interrupts into one vector, so even if we
-* can try to request less vectors, we don't
-* know how to associate interrupt events to
-* vectors. Linux doesn't duplicate vectors
-* in the MSIX table for this case.
-*/
if (error) {
printk(KERN_WARNING "bfad%d: "
- "pci_enable_msix failed (%d), "
+ "pci_enable_msix_exact failed (%d), "
"use line based.\n",
bfad->inst_no, error);
goto line_based;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 06/23] csiostor: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Naresh Kumar Inna
Cc: Arvind Bhushan
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/csiostor/csio_hw.h |2 +-
drivers/scsi/csiostor/csio_isr.c | 22 +-
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
index 49b1daa..5db2d85 100644
--- a/drivers/scsi/csiostor/csio_hw.h
+++ b/drivers/scsi/csiostor/csio_hw.h
@@ -94,7 +94,7 @@ enum {
};
struct csio_msix_entries {
- unsigned short vector; /* Vector assigned by pci_enable_msix */
+ unsigned short vector; /* Assigned MSI-X vector */
void*dev_id;/* Priv object associated w/ this msix*/
chardesc[24]; /* Description of this vector */
};
diff --git a/drivers/scsi/csiostor/csio_isr.c b/drivers/scsi/csiostor/csio_isr.c
index 91ba91d..a8c748a 100644
--- a/drivers/scsi/csiostor/csio_isr.c
+++ b/drivers/scsi/csiostor/csio_isr.c
@@ -499,7 +499,7 @@ csio_reduce_sqsets(struct csio_hw *hw, int cnt)
static int
csio_enable_msix(struct csio_hw *hw)
{
- int rv, i, j, k, n, min, cnt;
+ int i, j, k, n, min, cnt;
struct csio_msix_entries *entryp;
struct msix_entry *entries;
int extra = CSIO_EXTRA_VECS;
@@ -521,19 +521,15 @@ csio_enable_msix(struct csio_hw *hw)
csio_dbg(hw, "FW supp #niq:%d, trying %d msix's\n", hw->cfg_niq, cnt);
- while ((rv = pci_enable_msix(hw->pdev, entries, cnt)) >= min)
- cnt = rv;
- if (!rv) {
- if (cnt < (hw->num_sqsets + extra)) {
- csio_dbg(hw, "Reducing sqsets to %d\n", cnt - extra);
- csio_reduce_sqsets(hw, cnt - extra);
- }
- } else {
- if (rv > 0)
- csio_info(hw, "Not using MSI-X, remainder:%d\n", rv);
-
+ cnt = pci_enable_msix_range(hw->pdev, entries, min, cnt);
+ if (cnt < 0) {
kfree(entries);
- return -ENOMEM;
+ return cnt;
+ }
+
+ if (cnt < (hw->num_sqsets + extra)) {
+ csio_dbg(hw, "Reducing sqsets to %d\n", cnt - extra);
+ csio_reduce_sqsets(hw, cnt - extra);
}
/* Save off vectors */
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 02/23] bfa: Do not call pci_enable_msix() after it failed once
Function pci_enable_msix() should not be called in case
it threw a negative errno from a previous call.
Signed-off-by: Alexander Gordeev
Cc: Anil Gurumurthy
Cc: Vijaya Mohan Guvva
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Anil Gurumurthy
---
drivers/scsi/bfa/bfad.c | 48 ++
1 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index cc0fbcd..972ff8d 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -1235,33 +1235,31 @@ bfad_setup_intr(struct bfad_s *bfad)
(bfa_asic_id_cb(pdev->device) && !msix_disable_cb)) {
error = pci_enable_msix(bfad->pcidev, msix_entries, bfad->nvec);
- if (error) {
- /* In CT1 & CT2, try to allocate just one vector */
- if (bfa_asic_id_ctc(pdev->device)) {
- printk(KERN_WARNING "bfa %s: trying one msix "
- "vector failed to allocate %d[%d]\n",
- bfad->pci_name, bfad->nvec, error);
- bfad->nvec = 1;
- error = pci_enable_msix(bfad->pcidev,
+ /* In CT1 & CT2, try to allocate just one vector */
+ if (error > 0 && bfa_asic_id_ctc(pdev->device)) {
+ printk(KERN_WARNING "bfa %s: trying one msix "
+ "vector failed to allocate %d[%d]\n",
+ bfad->pci_name, bfad->nvec, error);
+ bfad->nvec = 1;
+ error = pci_enable_msix(bfad->pcidev,
msix_entries, bfad->nvec);
- }
+ }
- /*
-* Only error number of vector is available.
-* We don't have a mechanism to map multiple
-* interrupts into one vector, so even if we
-* can try to request less vectors, we don't
-* know how to associate interrupt events to
-* vectors. Linux doesn't duplicate vectors
-* in the MSIX table for this case.
-*/
- if (error) {
- printk(KERN_WARNING "bfad%d: "
- "pci_enable_msix failed (%d), "
- "use line based.\n",
- bfad->inst_no, error);
- goto line_based;
- }
+ /*
+* Only error number of vector is available.
+* We don't have a mechanism to map multiple
+* interrupts into one vector, so even if we
+* can try to request less vectors, we don't
+* know how to associate interrupt events to
+* vectors. Linux doesn't duplicate vectors
+* in the MSIX table for this case.
+*/
+ if (error) {
+ printk(KERN_WARNING "bfad%d: "
+ "pci_enable_msix failed (%d), "
+ "use line based.\n",
+ bfad->inst_no, error);
+ goto line_based;
}
/* Disable INTX in MSI-X mode */
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 08/23] isci: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions pci_enable_msix() and pci_enable_msi_block() all drivers using these two interfaces need to be updated to use the new pci_enable_msi_range() or pci_enable_msi_exact() and pci_enable_msix_range() or pci_enable_msix_exact() interfaces. Signed-off-by: Alexander Gordeev Cc: Lukasz Dorau Cc: Maciej Patelczyk Cc: Dave Jiang Cc: intel-linux-...@intel.com Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org --- drivers/scsi/isci/init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c index 695b34e..4198e45 100644 --- a/drivers/scsi/isci/init.c +++ b/drivers/scsi/isci/init.c @@ -356,7 +356,7 @@ static int isci_setup_interrupts(struct pci_dev *pdev) for (i = 0; i < num_msix; i++) pci_info->msix_entries[i].entry = i; - err = pci_enable_msix(pdev, pci_info->msix_entries, num_msix); + err = pci_enable_msix_exact(pdev, pci_info->msix_entries, num_msix); if (err) goto intx; -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 11/23] lpfc: Remove superfluous call to pci_disable_msix()
There is no need to call pci_disable_msix() in case
the previous call to pci_enable_msix() failed
Signed-off-by: Alexander Gordeev
Cc: James Smart
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: James Smart
---
drivers/scsi/lpfc/lpfc_init.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 635eeb3..7163f37 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8131,7 +8131,7 @@ lpfc_sli_enable_msix(struct lpfc_hba *phba)
if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0420 PCI enable MSI-X failed (%d)\n", rc);
- goto msi_fail_out;
+ goto vec_fail_out;
}
for (i = 0; i < LPFC_MSIX_VECTORS; i++)
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
@@ -8209,6 +8209,8 @@ irq_fail_out:
msi_fail_out:
/* Unconfigure MSI-X capability structure */
pci_disable_msix(phba->pcidev);
+
+vec_fail_out:
return rc;
}
@@ -8701,7 +8703,7 @@ enable_msix_vectors:
} else if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0484 PCI enable MSI-X failed (%d)\n", rc);
- goto msi_fail_out;
+ goto vec_fail_out;
}
/* Log MSI-X vector assignment */
@@ -8764,9 +8766,10 @@ cfg_fail_out:
&phba->sli4_hba.fcp_eq_hdl[index]);
}
-msi_fail_out:
/* Unconfigure MSI-X capability structure */
pci_disable_msix(phba->pcidev);
+
+vec_fail_out:
return rc;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 12/23] lpfc: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: James Smart
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/lpfc/lpfc_init.c | 38 +-
1 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 7163f37..b109adc 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8100,9 +8100,9 @@ lpfc_sli4_pci_mem_unset(struct lpfc_hba *phba)
* @phba: pointer to lpfc hba data structure.
*
* This routine is invoked to enable the MSI-X interrupt vectors to device
- * with SLI-3 interface specs. The kernel function pci_enable_msix() is
- * called to enable the MSI-X vectors. Note that pci_enable_msix(), once
- * invoked, enables either all or nothing, depending on the current
+ * with SLI-3 interface specs. The kernel function pci_enable_msix_exact()
+ * is called to enable the MSI-X vectors. Note that pci_enable_msix_exact(),
+ * once invoked, enables either all or nothing, depending on the current
* availability of PCI vector resources. The device driver is responsible
* for calling the individual request_irq() to register each MSI-X vector
* with a interrupt handler, which is done in this function. Note that
@@ -8126,8 +8126,8 @@ lpfc_sli_enable_msix(struct lpfc_hba *phba)
phba->msix_entries[i].entry = i;
/* Configure MSI-X capability structure */
- rc = pci_enable_msix(phba->pcidev, phba->msix_entries,
- ARRAY_SIZE(phba->msix_entries));
+ rc = pci_enable_msix_exact(phba->pcidev, phba->msix_entries,
+ ARRAY_SIZE(phba->msix_entries));
if (rc) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0420 PCI enable MSI-X failed (%d)\n", rc);
@@ -8664,15 +8664,13 @@ out:
* @phba: pointer to lpfc hba data structure.
*
* This routine is invoked to enable the MSI-X interrupt vectors to device
- * with SLI-4 interface spec. The kernel function pci_enable_msix() is called
- * to enable the MSI-X vectors. Note that pci_enable_msix(), once invoked,
- * enables either all or nothing, depending on the current availability of
- * PCI vector resources. The device driver is responsible for calling the
- * individual request_irq() to register each MSI-X vector with a interrupt
- * handler, which is done in this function. Note that later when device is
- * unloading, the driver should always call free_irq() on all MSI-X vectors
- * it has done request_irq() on before calling pci_disable_msix(). Failure
- * to do so results in a BUG_ON() and a device will be left with MSI-X
+ * with SLI-4 interface spec. The kernel function pci_enable_msix_range()
+ * is called to enable the MSI-X vectors. The device driver is responsible
+ * for calling the individual request_irq() to register each MSI-X vector
+ * with a interrupt handler, which is done in this function. Note that later
+ * when device is unloading, the driver should always call free_irq() on all
+ * MSI-X vectors it has done request_irq() on before calling pci_disable_msix()
+ * Failure to do so results in a BUG_ON() and a device will be left with MSI-X
* enabled and leaks its vectors.
*
* Return codes
@@ -8694,18 +8692,16 @@ lpfc_sli4_enable_msix(struct lpfc_hba *phba)
phba->sli4_hba.msix_entries[index].entry = index;
vectors++;
}
-enable_msix_vectors:
- rc = pci_enable_msix(phba->pcidev, phba->sli4_hba.msix_entries,
-vectors);
- if (rc > 1) {
- vectors = rc;
- goto enable_msix_vectors;
- } else if (rc) {
+
+ rc = pci_enable_msix_range(phba->pcidev, phba->sli4_hba.msix_entries,
+ 2, vectors);
+ if (rc < 0) {
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0484 PCI enable MSI-X failed (%d)\n", rc);
goto vec_fail_out;
}
+ vectors = rc;
/* Log MSI-X vector assignment */
for (index = 0; index < vectors; index++)
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 15/23] mpt2sas: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Nagalakshmi Nandigama
Cc: Sreekanth Reddy
Cc: supp...@lsi.com
Cc: dl-mptfusionli...@lsi.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/mpt2sas/mpt2sas_base.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index bde63f7..984b605 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1432,10 +1432,10 @@ _base_enable_msix(struct MPT2SAS_ADAPTER *ioc)
for (i = 0, a = entries; i < ioc->reply_queue_count; i++, a++)
a->entry = i;
- r = pci_enable_msix(ioc->pdev, entries, ioc->reply_queue_count);
+ r = pci_enable_msix_exact(ioc->pdev, entries, ioc->reply_queue_count);
if (r) {
- dfailprintk(ioc, printk(MPT2SAS_INFO_FMT "pci_enable_msix "
- "failed (r=%d) !!!\n", ioc->name, r));
+ dfailprintk(ioc, printk(MPT2SAS_INFO_FMT
+ "pci_enable_msix_exact failed (r=%d) !!!\n", ioc->name, r));
kfree(entries);
goto try_ioapic;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 14/23] megaraid: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Neela Syam Kolli
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/megaraid/megaraid_sas_base.c | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 2df717c..26f89d4 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -4106,17 +4106,11 @@ static int megasas_init_fw(struct megasas_instance
*instance)
(unsigned int)num_online_cpus());
for (i = 0; i < instance->msix_vectors; i++)
instance->msixentry[i].entry = i;
- i = pci_enable_msix(instance->pdev, instance->msixentry,
- instance->msix_vectors);
- if (i >= 0) {
- if (i) {
- if (!pci_enable_msix(instance->pdev,
-instance->msixentry, i))
- instance->msix_vectors = i;
- else
- instance->msix_vectors = 0;
- }
- } else
+ i = pci_enable_msix_range(instance->pdev, instance->msixentry,
+ 1, instance->msix_vectors);
+ if (i)
+ instance->msix_vectors = i;
+ else
instance->msix_vectors = 0;
dev_info(&instance->pdev->dev, "[scsi%d]: FW supports"
@@ -5136,8 +5130,8 @@ megasas_resume(struct pci_dev *pdev)
/* Now re-enable MSI-X */
if (instance->msix_vectors &&
- pci_enable_msix(instance->pdev, instance->msixentry,
- instance->msix_vectors))
+ pci_enable_msix_exact(instance->pdev, instance->msixentry,
+ instance->msix_vectors))
goto fail_reenable_msix;
switch (instance->pdev->device) {
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 16/23] mpt3sas: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Nagalakshmi Nandigama
Cc: Sreekanth Reddy
Cc: supp...@lsi.com
Cc: dl-mptfusionli...@lsi.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/mpt3sas/mpt3sas_base.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 0cf4f70..7b65ec2 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1747,10 +1747,10 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
for (i = 0, a = entries; i < ioc->reply_queue_count; i++, a++)
a->entry = i;
- r = pci_enable_msix(ioc->pdev, entries, ioc->reply_queue_count);
+ r = pci_enable_msix_exact(ioc->pdev, entries, ioc->reply_queue_count);
if (r) {
dfailprintk(ioc, pr_info(MPT3SAS_FMT
- "pci_enable_msix failed (r=%d) !!!\n",
+ "pci_enable_msix_exact failed (r=%d) !!!\n",
ioc->name, r));
kfree(entries);
goto try_ioapic;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 20/23] pmcraid: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Anil Ravindranath
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/pmcraid.c | 13 ++---
1 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index c06af7f..6d0f208 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4698,19 +4698,10 @@ pmcraid_register_interrupt_handler(struct
pmcraid_instance *pinstance)
for (i = 0; i < PMCRAID_NUM_MSIX_VECTORS; i++)
entries[i].entry = i;
- rc = pci_enable_msix(pdev, entries, num_hrrq);
- if (rc < 0)
+ num_hrrq = pci_enable_msix_range(pdev, entries, 1, num_hrrq);
+ if (num_hrrq < 0)
goto pmcraid_isr_legacy;
- /* Check how many MSIX vectors are allocated and register
-* msi-x handlers for each of them giving appropriate buffer
-*/
- if (rc > 0) {
- num_hrrq = rc;
- if (pci_enable_msix(pdev, entries, num_hrrq))
- goto pmcraid_isr_legacy;
- }
-
for (i = 0; i < num_hrrq; i++) {
pinstance->hrrq_vector[i].hrrq_id = i;
pinstance->hrrq_vector[i].drv_inst = pinstance;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 19/23] pmcraid: Get rid of a redundant assignment
Signed-off-by: Alexander Gordeev Cc: Anil Ravindranath Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org --- drivers/scsi/pmcraid.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c index be8ce54..c06af7f 100644 --- a/drivers/scsi/pmcraid.c +++ b/drivers/scsi/pmcraid.c @@ -4746,7 +4746,6 @@ pmcraid_isr_legacy: pinstance->hrrq_vector[0].drv_inst = pinstance; pinstance->hrrq_vector[0].vector = pdev->irq; pinstance->num_hrrq = 1; - rc = 0; rc = request_irq(pdev->irq, pmcraid_isr, IRQF_SHARED, PMCRAID_DRIVER_NAME, &pinstance->hrrq_vector[0]); -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 21/23] qla2xxx: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Log message code 0x00c6 preserved, although it is reported
after successful call to pci_enable_msix_range(), not before
possibly unsuccessful call to pci_enable_msix(). Consumers
of the error code should not notice the difference.
Signed-off-by: Alexander Gordeev
Cc: qla2xxx-upstr...@qlogic.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/qla2xxx/qla_isr.c | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 95314ef..41eb0dc 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2918,27 +2918,22 @@ qla24xx_enable_msix(struct qla_hw_data *ha, struct
rsp_que *rsp)
for (i = 0; i < ha->msix_count; i++)
entries[i].entry = i;
- ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
- if (ret) {
- if (ret < MIN_MSIX_COUNT)
- goto msix_failed;
-
+ ret = pci_enable_msix_range(ha->pdev,
+ entries, MIN_MSIX_COUNT, ha->msix_count);
+ if (ret < 0) {
+ ql_log(ql_log_fatal, vha, 0x00c7,
+ "MSI-X: Failed to enable support, "
+ "giving up -- %d/%d.\n",
+ ha->msix_count, ret);
+ goto msix_out;
+ } else if (ret < ha->msix_count) {
ql_log(ql_log_warn, vha, 0x00c6,
"MSI-X: Failed to enable support "
"-- %d/%d\n Retry with %d vectors.\n",
ha->msix_count, ret, ret);
- ha->msix_count = ret;
- ret = pci_enable_msix(ha->pdev, entries, ha->msix_count);
- if (ret) {
-msix_failed:
- ql_log(ql_log_fatal, vha, 0x00c7,
- "MSI-X: Failed to enable support, "
- "giving up -- %d/%d.\n",
- ha->msix_count, ret);
- goto msix_out;
- }
- ha->max_rsp_queues = ha->msix_count - 1;
}
+ ha->msix_count = ret;
+ ha->max_rsp_queues = ha->msix_count - 1;
ha->msix_entries = kzalloc(sizeof(struct qla_msix_entry) *
ha->msix_count, GFP_KERNEL);
if (!ha->msix_entries) {
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 18/23] pm8001: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/pm8001/pm8001_init.c | 39 +++--
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/pm8001/pm8001_init.c
b/drivers/scsi/pm8001/pm8001_init.c
index df421f5..1d3c02d 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -725,34 +725,35 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
*pm8001_ha)
sizeof(pm8001_ha->msix_entries[0]);
for (i = 0; i < max_entry ; i++)
pm8001_ha->msix_entries[i].entry = i;
- rc = pci_enable_msix(pm8001_ha->pdev, pm8001_ha->msix_entries,
+ rc = pci_enable_msix_exact(pm8001_ha->pdev, pm8001_ha->msix_entries,
number_of_intr);
pm8001_ha->number_of_intr = number_of_intr;
- if (!rc) {
- PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
- "pci_enable_msix request ret:%d no of intr %d\n",
- rc, pm8001_ha->number_of_intr));
+ if (rc)
+ return rc;
+ PM8001_INIT_DBG(pm8001_ha, pm8001_printk(
+ "pci_enable_msix_exact request ret:%d no of intr %d\n",
+ rc, pm8001_ha->number_of_intr));
- for (i = 0; i < number_of_intr; i++) {
- snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
- DRV_NAME"%d", i);
- pm8001_ha->irq_vector[i].irq_id = i;
- pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
+ for (i = 0; i < number_of_intr; i++) {
+ snprintf(intr_drvname[i], sizeof(intr_drvname[0]),
+ DRV_NAME"%d", i);
+ pm8001_ha->irq_vector[i].irq_id = i;
+ pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
- rc = request_irq(pm8001_ha->msix_entries[i].vector,
- pm8001_interrupt_handler_msix, flag,
- intr_drvname[i], &(pm8001_ha->irq_vector[i]));
- if (rc) {
- for (j = 0; j < i; j++)
- free_irq(
- pm8001_ha->msix_entries[j].vector,
+ rc = request_irq(pm8001_ha->msix_entries[i].vector,
+ pm8001_interrupt_handler_msix, flag,
+ intr_drvname[i], &(pm8001_ha->irq_vector[i]));
+ if (rc) {
+ for (j = 0; j < i; j++) {
+ free_irq(pm8001_ha->msix_entries[j].vector,
&(pm8001_ha->irq_vector[i]));
- pci_disable_msix(pm8001_ha->pdev);
- break;
}
+ pci_disable_msix(pm8001_ha->pdev);
+ break;
}
}
+
return rc;
}
#endif
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 23/23] vmw_pvscsi: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Arvind Kumar
Cc: pv-driv...@vmware.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Arvind Kumar
---
drivers/scsi/vmw_pvscsi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index c88e146..598f65e 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -1194,7 +1194,7 @@ static int pvscsi_setup_msix(const struct pvscsi_adapter
*adapter,
struct msix_entry entry = { 0, PVSCSI_VECTOR_COMPLETION };
int ret;
- ret = pci_enable_msix(adapter->dev, &entry, 1);
+ ret = pci_enable_msix_exact(adapter->dev, &entry, 1);
if (ret)
return ret;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 17/23] pm8001: Fix invalid return when request_irq() failed
When a call to request_irq() failed pm8001_setup_msix()
still returns the success. This udate fixes the described
misbehaviour.
Signed-off-by: Alexander Gordeev
Cc: xjtu...@gmail.com
Cc: lindar_...@usish.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
Acked-by: Jack Wang
---
drivers/scsi/pm8001/pm8001_init.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/pm8001/pm8001_init.c
b/drivers/scsi/pm8001/pm8001_init.c
index c4f31b21..df421f5 100644
--- a/drivers/scsi/pm8001/pm8001_init.c
+++ b/drivers/scsi/pm8001/pm8001_init.c
@@ -740,9 +740,10 @@ static u32 pm8001_setup_msix(struct pm8001_hba_info
*pm8001_ha)
pm8001_ha->irq_vector[i].irq_id = i;
pm8001_ha->irq_vector[i].drv_inst = pm8001_ha;
- if (request_irq(pm8001_ha->msix_entries[i].vector,
+ rc = request_irq(pm8001_ha->msix_entries[i].vector,
pm8001_interrupt_handler_msix, flag,
- intr_drvname[i], &(pm8001_ha->irq_vector[i]))) {
+ intr_drvname[i], &(pm8001_ha->irq_vector[i]));
+ if (rc) {
for (j = 0; j < i; j++)
free_irq(
pm8001_ha->msix_entries[j].vector,
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 10/23] hpsa: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: "Stephen M. Cameron"
Cc: iss_storage...@hp.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/hpsa.c | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 3284edb..36bb1e4 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -6144,26 +6144,23 @@ static void hpsa_interrupt_mode(struct ctlr_info *h)
goto default_int_mode;
if (pci_find_capability(h->pdev, PCI_CAP_ID_MSIX)) {
dev_info(&h->pdev->dev, "MSIX\n");
- h->msix_vector = MAX_REPLY_QUEUES;
- err = pci_enable_msix(h->pdev, hpsa_msix_entries,
- h->msix_vector);
- if (err > 0) {
+ err = pci_enable_msix_range(h->pdev, hpsa_msix_entries,
+ 1, MAX_REPLY_QUEUES);
+ if (err < 0) {
+ dev_warn(&h->pdev->dev, "MSI-X init failed %d\n", err);
+ h->msix_vector = 0;
+ goto single_msi_mode;
+ } else if (err < MAX_REPLY_QUEUES) {
dev_warn(&h->pdev->dev, "only %d MSI-X vectors "
"available\n", err);
- h->msix_vector = err;
- err = pci_enable_msix(h->pdev, hpsa_msix_entries,
- h->msix_vector);
- }
- if (!err) {
- for (i = 0; i < h->msix_vector; i++)
- h->intr[i] = hpsa_msix_entries[i].vector;
- return;
- } else {
- dev_warn(&h->pdev->dev, "MSI-X init failed %d\n",
- err);
- h->msix_vector = 0;
}
+
+ h->msix_vector = err;
+ for (i = 0; i < h->msix_vector; i++)
+ h->intr[i] = hpsa_msix_entries[i].vector;
+ return;
}
+single_msi_mode:
if (pci_find_capability(h->pdev, PCI_CAP_ID_MSI)) {
dev_info(&h->pdev->dev, "MSI\n");
if (!pci_enable_msi(h->pdev))
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 09/23] hpsa: Fallback to MSI rather than to INTx if MSI-X failed
Currently the driver falls back to INTx mode when MSI-X
initialization failed. This is a suboptimal behaviour
for chips that also support MSI. This update changes that
behaviour and falls back to MSI mode in case MSI-X mode
initialization failed.
Signed-off-by: Alexander Gordeev
Cc: "Stephen M. Cameron"
Cc: iss_storage...@hp.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/hpsa.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8cf4a0c..3284edb 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -6162,7 +6162,6 @@ static void hpsa_interrupt_mode(struct ctlr_info *h)
dev_warn(&h->pdev->dev, "MSI-X init failed %d\n",
err);
h->msix_vector = 0;
- goto default_int_mode;
}
}
if (pci_find_capability(h->pdev, PCI_CAP_ID_MSI)) {
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND 22/23] qla4xxx: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev
Cc: Vikas Chaudhary
Cc: iscsi-dri...@qlogic.com
Cc: linux-scsi@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/scsi/qla4xxx/ql4_nx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_nx.c b/drivers/scsi/qla4xxx/ql4_nx.c
index 63328c8..a3e69e6 100644
--- a/drivers/scsi/qla4xxx/ql4_nx.c
+++ b/drivers/scsi/qla4xxx/ql4_nx.c
@@ -3787,7 +3787,7 @@ qla4_8xxx_enable_msix(struct scsi_qla_host *ha)
for (i = 0; i < QLA_MSIX_ENTRIES; i++)
entries[i].entry = qla4_8xxx_msix_entries[i].entry;
- ret = pci_enable_msix(ha->pdev, entries, ARRAY_SIZE(entries));
+ ret = pci_enable_msix_exact(ha->pdev, entries, ARRAY_SIZE(entries));
if (ret) {
ql4_printk(KERN_WARNING, ha,
"MSI-X: Failed to enable support -- %d/%d\n",
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
Hi Davidlohr, Thanks for the information! According to lspci output, device :02:00.2 is HP ILO controller, device :03:00.0 is RAID controller. Both ILO and RAID controllers need to access reserved memory range [0x7f61e000 - 0x7f61] in physical mode. According to dmesg output, BIOS has reserved memory and IOMMU has setup 1:1 mapping for ILO and RAID controller to access this range. Related log messages as below: BIOS-e820: [mem 0x7f61d000-0x8fff] reserved IOMMU: Setting RMRR: IOMMU: Setting identity map for device :03:00.0 [0x7f61e000 - 0x7f61] IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 - 0x7f61] IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] From the screenshot, device :02:00.2 fails to access memory address 0x7f61e000. That indicates IOMMU driver fails to setup 1:1 mapping for Reserved Memory Range for ILO controller. So could you please help to check whether you could observe boot messages like "IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61]" with the failure kernel image? It would be great if boot messages could be saved when failing to boot, so we could get more information from log. BTW, I have double checked related code, and still can't find a reliable explanation for the regression:( Thanks! Gerry On 2014/4/11 0:19, Davidlohr Bueso wrote: > On Thu, 2014-04-10 at 08:46 +, Woodhouse, David wrote: >> On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote: >>> [+ David, VT-d maintainer ] >>> >>> Jiang, David, can you please have a look into this issue? >>> >> >>> DMAR:[fault reason 02] Present bit in context entry is clear >>> dmar: DRHD: handling fault status reg 602 >>> dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 >> >> That "Present bit in context entry is clear" fault means that we have >> not set up *any* mappings for this PCI device… on this IOMMU. >> Yes, specifically (finally done bisecting): commit 2e45528930388658603ea24d49cf52867b928d3e Author: Jiang Liu Date: Wed Feb 19 14:07:36 2014 +0800 iommu/vt-d: Unify the way to process DMAR device scope array >> >> This commit is about how we decide which IOMMU a given PCI device is >> attached to. >> >> Thus, my first guess would be that we are quite happily setting up the >> requested DMA maps on the *wrong* IOMMU, and then taking faults when the >> device actually tries to do DMA. >> >> However, I'm not 100% convinced of that. The fault address looks >> suspiciously like a true physical address, not a virtual bus address of >> the type that we'd normally allocate for a dma_map_* operation. Those >> would start at 0xf000 and work downwards, typically. >> >> Do you have 'iommu=pt' on the kernel command line? > > No. > >> Can I see the full >> dmesg as this system boots, and also a copy of the DMAR table? > > Attaching a dmesg from one of the kernels that boots. It doesn't appear > to have much of the related information... is there any debug config > option I can enable that might give you more data? > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
