On Wed, 4 Apr 2018 15:51:38 +0900
Damien Le Moal wrote:
> With the introduction of commit e39a97353e53 ("scsi: core: return
> BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command
> that failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but
> lacking additional sense informat
With the introduction of commit e39a97353e53 ("scsi: core: return
BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"), a command that
failed with hostbyte=DID_OK and driverbyte=DRIVER_SENSE but lacking
additional sense information will have a return code set to BLK_STS_OK.
This results in the
In function mvs_pci_init(), the memory allocated by
scsi_host_alloc() is not released on the error path that mvi,
which holds the return value of mvs_pci_alloc(), is NULL.
This will result in a memory leak bug.
Signed-off-by: Xidong Wang
---
drivers/scsi/mvsas/mv_init.c | 4 +++-
1 file changed,
In function mvs_pci_init(), the memory allocated by
scsi_host_alloc() is not released on the error path that mvi,
which holds the return value of mvs_pci_alloc(), is NULL.
This will result in a memory leak bug.
Signed-off-by: Xidong Wang
---
drivers/scsi/mvsas/mv_init.c | 1 +
1 file changed, 1
On Tue, 3 Apr 2018, Christoph Hellwig wrote:
> > +static void zorro_esp_send_pio_cmd(struct esp *esp, u32 addr, u32
> > esp_count,
> > +u32 dma_count, int write, u8 cmd)
> > +{
> > + struct zorro_esp_priv *zep = dev_get_drvdata(esp->dev);
> > + u8 __iomem *fifo = e
If a recursive IOP_RESET is invoked, usually due to the eh_thread handling
errors after the first reset, be sure we flag that the command thread has
been stopped to avoid an Oops of the form;
[ 336.620256] CPU: 28 PID: 1193 Comm: scsi_eh_0 Kdump: loaded Not tainted
4.14.0-49.el7a.ppc64le #1
[
On Sun, 2018-04-01 at 14:27 -0400, Wakko Warner wrote:
> Wakko Warner wrote:
> > Wakko Warner wrote:
> > > I tested 4.14.32 last night with the same oops. 4.9.91 works fine.
> > > From the initiator, if I do cat /dev/sr1 > /dev/null it works. If I mount
> > > /dev/sr1 and then do find -type f | x
On 2018-04-02 07:10 AM, Mahesh Rajashekhara wrote:
Hello,
I am RAID HBA driver engineer here at Microsemi. We are working on linux driver
development for Microsemi SAS/SATA RAID HBA controllers.
As per our understanding, while a drive is processing the SANITIZE command:
- The drive should stil
On Tue, 2018-04-03 at 10:11 +0530, Sreekanth Reddy wrote:
> [SR] No, driver calls _scsih_flush_running_cmds during Host reset time
> and during host reset time driver will set 'ioc->shost_recovery' flag.
> So in the scsih_qcmd() driver will return the incoming SCSI cmds with
> "SCSI_MLQUEUE_HOST_BU
On 2018/4/3 14:04, Wen Yang wrote:
There would be so many same lines printed by frequent printk if one
disk went wrong, like,
[ 546.185242] sd 0:1:0:0: rejecting I/O to offline device
[ 546.185258] sd 0:1:0:0: rejecting I/O to offline device
[ 546.185280] sd 0:1:0:0: rejecting I/O to offline
Smatch marks skb->data as untrusted so it complains that there is a
potential overflow here:
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:2111 t4_uld_rx_handler()
error: buffer overflow 'cxgb4i_cplhandlers' 239 <= 255.
In this case, skb->data comes from the hardware or firmware so it's not
On Tue, 3 Apr 2018, Christoph Hellwig wrote:
>
> > +
> > + if (zep->zorro3) {
> > + /* Only Fastlane Z3 for now - add switch for correct struct
> > +* dma_registers size if adding any more
> > +*/
> > + esp->dma_regs = ioremap_nocache(dmaaddr,
> > +
On Sat, Mar 31, 2018 at 01:03:46PM +0200, Hannes Reinecke wrote:
> Actually I would propose to have a 'management' LUN at LUN0, who could
> handle all the device-wide commands (eg things like START STOP UNIT,
> firmware update, or even SMART commands), and ignoring them for the
> remaining LUNs.
T
Just a few style comments:
> +static int zorro_esp_irq_pending(struct esp *);
> +static int cyber_esp_irq_pending(struct esp *);
> +static int fastlane_esp_irq_pending(struct esp *);
Please avoid forward declarations wherever possible.
> +struct zorro_driver_data {
> + const char *name;
> +
On Mon, 2018-04-02 at 13:53 +, Bart Van Assche wrote:
> A similar patch has already been queued by Martin. See also
> https://patchwork.kernel.org/patch/10313569/.
Ah OK, fine then :-)
--
Johannes Thumshirn Storage
jthumsh...@suse.de
15 matches
Mail list logo
