On Wed, Jul 16, 2014 at 08:05:13PM +0200, Alexander Gordeev wrote:
> 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
On Wed, Jul 16, 2014 at 08:05:13PM +0200, Alexander Gordeev wrote:
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()
On Mon, Apr 14, 2014 at 10:05:34AM +0200, Alexander Gordeev wrote:
> 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
On Wed, Jul 16, 2014 at 08:05:12PM +0200, Alexander Gordeev wrote:
> 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
On Wed, Jul 16, 2014 at 08:05:12PM +0200, Alexander Gordeev wrote:
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
On Mon, Apr 14, 2014 at 10:05:34AM +0200, Alexander Gordeev wrote:
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()
On Wed, Jul 30, 2014 at 11:46:52PM +0200, Rickard Strandqvist wrote:
> Code clarification using strlcpy instead of strncpy.
> And removed unnecessary memset
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/scsi/hpsa.c | 16 +++-
> 1 file changed, 7 insertions(+), 9
On Wed, Jul 30, 2014 at 11:46:52PM +0200, Rickard Strandqvist wrote:
Code clarification using strlcpy instead of strncpy.
And removed unnecessary memset
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
drivers/scsi/hpsa.c | 16 +++-
1 file
On Wed, Jul 23, 2014 at 08:11:33AM -0700, Randy Dunlap wrote:
> On 07/23/2014 07:41 AM, scame...@beardog.cce.hp.com wrote:
> > On Wed, Jul 23, 2014 at 02:15:29PM +, Benesh, Scott wrote:
> >> From: Nick Krause [mailto:xerofo...@gmail.com]
> >> Sent: Saturday, July 19, 2014 11:51 PM
> >> To:
On Wed, Jul 23, 2014 at 02:15:29PM +, Benesh, Scott wrote:
> From: Nick Krause [mailto:xerofo...@gmail.com]
> Sent: Saturday, July 19, 2014 11:51 PM
> To: mike.mil...@hp.com
> Cc: ISS StorageDev; linux-kernel@vger.kernel.org
> Subject: cciss_scsi.c: Fix me
>
> Hey Mike,
> I seem to be
On Wed, Jul 23, 2014 at 02:15:29PM +, Benesh, Scott wrote:
From: Nick Krause [mailto:xerofo...@gmail.com]
Sent: Saturday, July 19, 2014 11:51 PM
To: mike.mil...@hp.com
Cc: ISS StorageDev; linux-kernel@vger.kernel.org
Subject: cciss_scsi.c: Fix me
Hey Mike,
I seem to be hitting a fix
On Wed, Jul 23, 2014 at 08:11:33AM -0700, Randy Dunlap wrote:
On 07/23/2014 07:41 AM, scame...@beardog.cce.hp.com wrote:
On Wed, Jul 23, 2014 at 02:15:29PM +, Benesh, Scott wrote:
From: Nick Krause [mailto:xerofo...@gmail.com]
Sent: Saturday, July 19, 2014 11:51 PM
To:
On Thu, Jul 03, 2014 at 01:43:48AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 26, 2014 at 09:34:45AM -0500, scame...@beardog.cce.hp.com wrote:
> > Thanks.
>
> Do you plan to include this with the next hpsa update, or should I take
> this as an ACK and apply it?
Take it as an ACK. I should
On Thu, Jul 03, 2014 at 01:43:48AM -0700, Christoph Hellwig wrote:
On Thu, Jun 26, 2014 at 09:34:45AM -0500, scame...@beardog.cce.hp.com wrote:
Thanks.
Do you plan to include this with the next hpsa update, or should I take
this as an ACK and apply it?
Take it as an ACK. I should have
On Thu, Jun 26, 2014 at 03:44:52PM +0200, Arnd Bergmann wrote:
> commit 28e134464734 "[SCSI] hpsa: enable unit attention reporting"
> turns on unit attention notifications, but got the change wrong for
> all architectures other than x86, which now store an uninitialized
> value into the device
On Thu, Jun 26, 2014 at 03:44:52PM +0200, Arnd Bergmann wrote:
commit 28e134464734 [SCSI] hpsa: enable unit attention reporting
turns on unit attention notifications, but got the change wrong for
all architectures other than x86, which now store an uninitialized
value into the device register.
On Wed, Jun 04, 2014 at 05:06:44PM +0200, Julia Lawall wrote:
>
>
> On Wed, 4 Jun 2014, scame...@beardog.cce.hp.com wrote:
>
> > On Wed, Jun 04, 2014 at 11:07:56AM +0200, Julia Lawall wrote:
> > > From: Julia Lawall
> > >
> > > Find_first_zero_bit considers BITS_PER_LONG bits at a time, and
On Wed, Jun 04, 2014 at 11:07:56AM +0200, Julia Lawall wrote:
> From: Julia Lawall
>
> Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
> return a larger number than the maximum position argument if that position
> is not a multiple of BITS_PER_LONG.
>
> The semantic
> Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
> return a larger number than the maximum position argument if that position
> is not a multiple of BITS_PER_LONG.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> //
> @@
Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
return a larger number than the maximum position argument if that position
is not a multiple of BITS_PER_LONG.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
On Wed, Jun 04, 2014 at 11:07:56AM +0200, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Find_first_zero_bit considers BITS_PER_LONG bits at a time, and thus may
return a larger number than the maximum position argument if that position
is not a multiple of BITS_PER_LONG.
The
On Wed, Jun 04, 2014 at 05:06:44PM +0200, Julia Lawall wrote:
On Wed, 4 Jun 2014, scame...@beardog.cce.hp.com wrote:
On Wed, Jun 04, 2014 at 11:07:56AM +0200, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Find_first_zero_bit considers BITS_PER_LONG bits at a time,
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
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,
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,
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
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
---
e:
> > > [] ? SA5_fifo_full+0x20/0x20 [hpsa]
> > > [] ? SA5_ioaccel_mode1_completed+0xd0/0xd0 [hpsa]
> > > [] hpsa_put_ctlr_into_performant_mode+0x186/0x320
> > > [hpsa]
> > > [] ? hpsa_allocate_sg_chain_blocks+0xa2/0xd0 [hpsa]
> > > [] hpsa_init_
+0xc4/0xd0
> > [] pci_device_probe+0x79/0xa0
> > [] ? driver_sysfs_add+0x82/0xb0
> > [] really_probe+0x6c/0x320
> > usb 1-1.6: New USB device found, idVendor=0624, idProduct=0341
> > usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumbe
On Wed, Apr 09, 2014 at 11:32:37PM -0700, Davidlohr Bueso wrote:
> On Wed, 2014-04-09 at 22:03 -0600, Bjorn Helgaas wrote:
> > [+cc Joerg, iommu list]
> >
> > On Wed, Apr 9, 2014 at 6:19 PM, Davidlohr Bueso wrote:
> > > On Wed, 2014-04-09 at 16:50 -0700, James Bottomley wrote:
> > >> On Wed,
On Wed, Apr 09, 2014 at 11:32:37PM -0700, Davidlohr Bueso wrote:
On Wed, 2014-04-09 at 22:03 -0600, Bjorn Helgaas wrote:
[+cc Joerg, iommu list]
On Wed, Apr 9, 2014 at 6:19 PM, Davidlohr Bueso davidl...@hp.com wrote:
On Wed, 2014-04-09 at 16:50 -0700, James Bottomley wrote:
On Wed,
bisect appears to be converging on something else, something
within the hpsa patches that I sent up recently, unfortunately for
me. Will let you all know when it converges.
Converged to this:
[scameron@localhost linux]$ git bisect good
b9af4937e6f5b55b6ffb2a92ec580e79e1401825 is the first bad
-by: Joerg Roedel j...@8bytes.org
My git bisect appears to be converging on something else, something
within the hpsa patches that I sent up recently, unfortunately for
me. Will let you all know when it converges.
Converged to this:
[scameron@localhost linux]$ git bisect good
Without this, you'll see a null pointer dereference in
hpsa_enter_performant_mode().
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
---
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
"Driver probe function returned %d, greater
than 0\n", rc);
+ rc = 0;
+
+ }
}
return rc;
}
And,
[scameron@localhost linux-3.12-rc6]$ dmesg | grep 'Driver probe'
[scameron@localhost linux-3.
0) {
+ dev_warn(dev,
+ Driver probe function returned %d, greater
than 0\n, rc);
+ rc = 0;
+
+ }
}
return rc;
}
And,
[scameron@localhost linux-3.12-rc6]$ dmesg | grep
On Thu, Oct 31, 2013 at 02:42:41PM -0700, Andrew Morton wrote:
> On Tue, 29 Oct 2013 12:58:09 -0600 Jens Axboe wrote:
>
> > On 10/29/2013 12:41 PM, Stephen M. Cameron wrote:
> > > From: Stephen M. Cameron
> > >
> > > A return value of 1 is interpreted as an error
> > >
> > > Signed-off-by:
On Thu, Oct 31, 2013 at 02:42:41PM -0700, Andrew Morton wrote:
On Tue, 29 Oct 2013 12:58:09 -0600 Jens Axboe ax...@kernel.dk wrote:
On 10/29/2013 12:41 PM, Stephen M. Cameron wrote:
From: Stephen M. Cameron scame...@beardog.cce.hp.com
A return value of 1 is interpreted as an error
On Mon, Aug 12, 2013 at 09:33:32AM -0400, John Kacur wrote:
>
>
> - Original Message -
> > * John Kacur | 2013-07-26 16:42:30 [+0200]:
> >
> > >Signed-off-by: John Kacur
> > >Acked-by: Stephen
> >
> > ping.
> >
> > I checked the branches for-next, scsi-fixes, fixes and misc at [0]
On Mon, Aug 12, 2013 at 09:33:32AM -0400, John Kacur wrote:
- Original Message -
* John Kacur | 2013-07-26 16:42:30 [+0200]:
Signed-off-by: John Kacur jka...@redhat.com
Acked-by: Stephen scame...@beardog.cce.hp.com
ping.
I checked the branches for-next, scsi-fixes,
On Fri, Aug 09, 2013 at 09:18:15PM +0100, Steven Whitehouse wrote:
> Hi,
>
> On Fri, 2013-08-09 at 14:09 -0500, scame...@beardog.cce.hp.com wrote:
> > So, I'm working on a block driver using the make_request_fn
> > interface, and have to handle a bio that comes in with
> > (bi_rw & REQ_FLUSH) set
On Fri, Aug 09, 2013 at 02:09:34PM -0500, scame...@beardog.cce.hp.com wrote:
>
> So, I'm working on a block driver using the make_request_fn
> interface, and have to handle a bio that comes in with
> (bi_rw & REQ_FLUSH) set AND data to transfer.
>
> According to
So, I'm working on a block driver using the make_request_fn
interface, and have to handle a bio that comes in with
(bi_rw & REQ_FLUSH) set AND data to transfer.
According to Documentation/block/writeback_cache_control.txt:
The REQ_FLUSH flag can be OR ed into the r/w flags of a
So, I'm working on a block driver using the make_request_fn
interface, and have to handle a bio that comes in with
(bi_rw REQ_FLUSH) set AND data to transfer.
According to Documentation/block/writeback_cache_control.txt:
The REQ_FLUSH flag can be OR ed into the r/w flags of a
On Fri, Aug 09, 2013 at 02:09:34PM -0500, scame...@beardog.cce.hp.com wrote:
So, I'm working on a block driver using the make_request_fn
interface, and have to handle a bio that comes in with
(bi_rw REQ_FLUSH) set AND data to transfer.
According to
On Fri, Aug 09, 2013 at 09:18:15PM +0100, Steven Whitehouse wrote:
Hi,
On Fri, 2013-08-09 at 14:09 -0500, scame...@beardog.cce.hp.com wrote:
So, I'm working on a block driver using the make_request_fn
interface, and have to handle a bio that comes in with
(bi_rw REQ_FLUSH) set AND data
On Fri, Jul 26, 2013 at 06:28:02AM -0400, John Kacur wrote:
>
>
> - Original Message -
> > [Adding missing cc to linux-scsi]
> > On Thu, 2013-07-25 at 23:33 +0200, John Kacur wrote:
> > > Hi
> > >
> > > We're seeing this on a 3.6 kernel with the real-time patch applied, but it
> > >
On Fri, Jul 26, 2013 at 06:28:02AM -0400, John Kacur wrote:
- Original Message -
[Adding missing cc to linux-scsi]
On Thu, 2013-07-25 at 23:33 +0200, John Kacur wrote:
Hi
We're seeing this on a 3.6 kernel with the real-time patch applied, but it
looks like it is
On Tue, Jul 16, 2013 at 02:07:29PM -0700, Nicholas A. Bellinger wrote:
> On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote:
> > On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote:
> > > On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote:
> > > > On Thu, 2013-07-11 at 18:02 -0700,
On Tue, Jul 16, 2013 at 02:07:29PM -0700, Nicholas A. Bellinger wrote:
On Sat, 2013-07-13 at 06:53 +, James Bottomley wrote:
On Fri, 2013-07-12 at 12:52 +0200, Hannes Reinecke wrote:
On 07/12/2013 03:33 AM, Nicholas A. Bellinger wrote:
On Thu, 2013-07-11 at 18:02 -0700, Greg KH
On Wed, May 29, 2013 at 03:03:42PM -0700, Andrew Morton wrote:
> On Fri, 24 May 2013 14:28:41 -0500 "Stephen M. Cameron"
> wrote:
>
> > If a new logical drive is added and the CCISS_REGNEWD ioctl is invoked
> > (as is normal with the Array Configuration Utility) the process
> > will hang as
On Wed, May 29, 2013 at 03:03:42PM -0700, Andrew Morton wrote:
On Fri, 24 May 2013 14:28:41 -0500 Stephen M. Cameron
scame...@beardog.cce.hp.com wrote:
If a new logical drive is added and the CCISS_REGNEWD ioctl is invoked
(as is normal with the Array Configuration Utility) the process
On Thu, Apr 25, 2013 at 02:14:59PM -0700, Tejun Heo wrote:
> Hello,
[...]
> >
> > Right now, if you add a new block driver, if you want grub to be able
> > to boot it, you also have to modify grub. This is true for each new
> > block driver that comes along. This is not the case for SCSI HBA
>
On Thu, Apr 25, 2013 at 01:40:33PM -0700, Tejun Heo wrote:
> Hello,
>
> On Thu, Apr 25, 2013 at 03:22:15PM -0500, Stephen M. Cameron wrote:
> > If block drivers could (optionally) share a common device namespace then
> > grub could be taught about this common namespace once, and any new block
> >
On Thu, Apr 25, 2013 at 01:40:33PM -0700, Tejun Heo wrote:
Hello,
On Thu, Apr 25, 2013 at 03:22:15PM -0500, Stephen M. Cameron wrote:
If block drivers could (optionally) share a common device namespace then
grub could be taught about this common namespace once, and any new block
device
On Thu, Apr 25, 2013 at 02:14:59PM -0700, Tejun Heo wrote:
Hello,
[...]
Right now, if you add a new block driver, if you want grub to be able
to boot it, you also have to modify grub. This is true for each new
block driver that comes along. This is not the case for SCSI HBA
drivers,
gt; dd if=/dev/sop0 of=/dev/null bs=4k iflag=direct
> >
> > with that, I can get 4k bios coming in to the make_request_fn.
> >
> > Driver source is here: https://github.com/HPSmartStorage/scsi-over-pcie
> > (still a work in progress -- that source doesn't do all
do all the blk_queue_*
settings mentioned above, those are just the things I've tried.)
In /sys/block/sop0/queue...
[scameron@localhost queue]$ for x in *
> do
> echo = $x ==
> cat $x
> done
= add_random ==
1
= discard_granularity ==
0
= discard_
*
settings mentioned above, those are just the things I've tried.)
In /sys/block/sop0/queue...
[scameron@localhost queue]$ for x in *
do
echo = $x ==
cat $x
done
= add_random ==
1
= discard_granularity ==
0
= discard_max_bytes ==
0
= discard_zeroes_data
.)
In /sys/block/sop0/queue...
[scameron@localhost queue]$ for x in *
do
echo = $x ==
cat $x
done
= add_random ==
1
= discard_granularity ==
0
= discard_max_bytes ==
0
= discard_zeroes_data ==
0
= hw_sector_size ==
512
On Thu, Mar 14, 2013 at 11:19:45PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> sizeof() when applied to a pointer typed expression gives the
> size of the pointer, not that of the pointed data.
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/block/cciss.c | 2 +-
> 1 file changed, 1
On Thu, Mar 14, 2013 at 11:19:45PM +0800, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
sizeof() when applied to a pointer typed expression gives the
size of the pointer, not that of the pointed data.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
On Wed, Feb 13, 2013 at 03:55:55PM -0700, Shuah Khan wrote:
> Add missing dma mapping error check to fix the following warning from
> dma-debug.
>
> [ 16.614739] hpsa :03:00.0: DMA-API: device driver failed to check map
> error[device address=0x001c2ec0] [size=64 bytes] [mapped as
On Wed, Feb 13, 2013 at 03:55:55PM -0700, Shuah Khan wrote:
Add missing dma mapping error check to fix the following warning from
dma-debug.
[ 16.614739] hpsa :03:00.0: DMA-API: device driver failed to check map
error[device address=0x001c2ec0] [size=64 bytes] [mapped as
On Fri, Sep 07, 2012 at 10:56:51PM +0900, Akinobu Mita wrote:
> The patch cciss-use-check_signature.patch in -mm tree introduced
> a build error:
>
> drivers/built-in.o: In function `CISS_signature_present':
> drivers/block/cciss.c:4270: undefined reference to `check_signature'
>
> Add missing
On Fri, Sep 07, 2012 at 10:56:51PM +0900, Akinobu Mita wrote:
The patch cciss-use-check_signature.patch in -mm tree introduced
a build error:
drivers/built-in.o: In function `CISS_signature_present':
drivers/block/cciss.c:4270: undefined reference to `check_signature'
Add missing
66 matches
Mail list logo
