Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote: This series is against next branch in Bjorn's repo: git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git Currently pci_enable_msi_block() and pci_enable_msix() interfaces return a error code in case of failure, 0 in

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

On Tue, Oct 08, 2013 at 09:33:02AM +0200, Alexander Gordeev wrote: On Tue, Oct 08, 2013 at 03:33:30PM +1100, Michael Ellerman wrote: On Wed, Oct 02, 2013 at 12:29:04PM +0200, Alexander Gordeev wrote: This technique proved to be confusing and error-prone. Vast share of device drivers

kernel BUG at drivers/scsi/scsi_lib.c:1096!

Hi folks, I'm intermittently seeing the following oops on at least one powerpc box. The BUG_ON() is from: static int scsi_init_sgtable(struct request *req, struct scsi_data_buffer *sdb) { ... count = blk_rq_map_sg(req->q, req, sdb->table.sgl); BUG_ON(count >

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On Wed, 2015-11-18 at 09:03 -0500, Mark Salter wrote: > On Wed, 2015-11-18 at 20:18 +1100, Michael Ellerman wrote: > > Hi folks, > > > > I'm intermittently seeing the following oops on at least one powerpc box. > > > > The BUG_ON() is from: > > > >

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On Thu, 2015-11-19 at 00:23 -0800, Christoph Hellwig wrote: > It's pretty much guaranteed a block layer bug, most likely in the > merge bios to request infrastucture where we don't obey the merging > limits properly. > > Does either of you have a known good and first known bad kernel? Not me,

Re: [v2] cxl: remove dead Kconfig options

On Mon, 2016-18-07 at 04:52:57 UTC, Andrew Donnellan wrote: > Remove the CXL_KERNEL_API and CXL_EEH Kconfig options, as they were only > needed to coordinate the merging of the cxlflash driver. Also remove the > stub implementation of cxl_perst_reloads_same_image() in cxlflash which is > only used

Re: [PATCH] ipr: Fix sync scsi scan

Brian King <brk...@linux.vnet.ibm.com> writes: > On 08/08/2016 05:02 AM, Michael Ellerman wrote: >> James Bottomley <james.bottom...@hansenpartnership.com> writes: >> >>> This is seven basic fixes (plus one MAINTAINERS update) which came in >>>

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

Elena Reshetova writes: > refcount_t type and corresponding API should be > used instead of atomic_t when the variable is used as > a reference counter. This allows to avoid accidental > refcounter overflows that might lead to use-after-free > situations. > >

Re: [PATCH] scsi-mq: Always unprepare before requeuing a request

Bart Van Assche <bart.vanass...@wdc.com> writes: > On Thu, 2017-08-10 at 20:32 +1000, Michael Ellerman wrote: >> "Martin K. Petersen" <martin.peter...@oracle.com> writes: >> > > One of the two scsi-mq functions that requeue a request un

Re: [PATCH] Revert "scsi-mq: Always unprepare before requeuing a request"

Bart Van Assche writes: > On Wed, 2017-08-16 at 22:51 -0400, Martin K. Petersen wrote: >> > When I checked earlier today the ipr patch was not yet in linux-next >> >> That's weird. They were both committed two weeks ago. >> >> They appear to be in there now, though: >>

Re: [PATCH] scsi: cxlflash: Select SCSI_SCAN_ASYNC

Vaibhav Jain writes: > The cxlflash driver uses "Asynchronous SCSI scanning" enabled by > CONFIG_SCSI_SCAN_ASYNC. Without this enabled the modprobe of cxlflash > module gets hung with following backtrace: > > Call Trace: > __switch_to+0x2cc/0x470 >

Re: Recent kernels fail to boot on POWER8 with multipath SCSI

r = setup_scsi_dh(p->path.dev->bdev, m, attached_handler_name, > >error); > if (r) { And it does indeed fix the problem. The system boots happily with no warnings. If you like here's a: Tested-by: Michael Ellerman <m...@ellerman.id.au> Any prospect of getting that patch to Linus before the 4.16 release? Yes I realise that's in ~36 hours :) cheers

Re: Recent kernels fail to boot on POWER8 with multipath SCSI

Mike Snitzer <snit...@redhat.com> writes: > On Fri, Mar 30 2018 at 5:04P -0400, > Michael Ellerman <mich...@ellerman.id.au> wrote: ... >> Any prospect of getting that patch to Linus before the 4.16 release? Yes >> I realise that's in ~36 hours :) &