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:
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
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:
>
> ---
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 wi
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:
Y
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:
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 c
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 driv
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 Sco
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
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 :
[1D
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.
>
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.
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 infor
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
>
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 rel
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: Christ
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:
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
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
hp
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_ini
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 b
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..1f830
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
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
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
Abschluss
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
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.
Sign
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 w
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
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 | 1
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)
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 chan
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
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 constructo
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
ind
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 |
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.
Sign
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 cha
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.
Sign
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.
Sign
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.
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.
Sign
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 chan
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.
Sign
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.
Sign
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.
Sign
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.
Sign
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.
Sign
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
--
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
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.
Sign
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.
Sign
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
---
dr
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.
Sign
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. C
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.
Sign
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
58 matches
Mail list logo
