https://bugzilla.kernel.org/show_bug.cgi?id=91711
Orion ad...@e-blokos.com changed:
What|Removed |Added
Component|SCSI|Other
Without a shutdown handler, some cards behave very badly after a kexec.
During probe, pending DMA writes will corrupt kernel memory, for
example.
Using the remove handler guarantees we will use a well tested path.
With this patch I applied, I managed to use kexec multiple times and
probe and
There are few drivers using magic numbers when operating with PCIe
capabilities and PCI_EXP_DEVCTL_READRQ. Define known values to allow
cleaning their code a bit.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
include/uapi/linux/pci_regs.h | 4
1 file changed, 4 insertions(+)
diff --git
On Mon, 26 Jan 2015, Christoph Hellwig wrote:
On Thu, Jan 15, 2015 at 02:40:31PM -0500, Tejun Heo wrote:
If a method is registered by the driver, then the driver will
unregister it when the -remove routine runs. I don't know for
certain, but I would expect that the sysfs/kernfs core
On Thu, Jan 15, 2015 at 02:40:31PM -0500, Tejun Heo wrote:
If a method is registered by the driver, then the driver will
unregister it when the -remove routine runs. I don't know for
certain, but I would expect that the sysfs/kernfs core will make sure
that any existing method calls
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/scsi/esas2r/esas2r_init.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/esas2r/esas2r_init.c
b/drivers/scsi/esas2r/esas2r_init.c
index 6776931..c0b37a5 100644
--- a/drivers/scsi/esas2r/esas2r_init.c
On Fri, Jan 23, 2015 at 10:42:47AM -0800, James Bottomley wrote:
To that point, Rusty's patch just keeps the status quo in the new
module_refcount() environment, so it's the quick bandaid.
I think the use case you're worrying about is what happens if someone
tries to use a device after
I was wondering if anyone had any feedback or had any chance to review the
changes?
-Original Message-
From: linux-scsi-ow...@vger.kernel.org
[mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Seymour, Shane M
Sent: Tuesday, January 13, 2015 2:43 PM
To: linux-scsi@vger.kernel.org
On Mon, Jan 26, 2015 at 06:05:22PM +0100, Rafał Miłecki wrote:
There are few drivers using magic numbers when operating with PCIe
capabilities and PCI_EXP_DEVCTL_READRQ. Define known values to allow
cleaning their code a bit.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
I applied this
On 01/23/15 14:12, Christoph Hellwig wrote:
On Fri, Jan 23, 2015 at 01:05:30PM +0100, Bart Van Assche wrote:
There is some confusion in the SCSI core and in SCSI LLDs around the
meaning of sc_data_direction and whether or not this member can have the
value DMA_BIDIRECTIONAL. Clear up this
https://bugzilla.kernel.org/show_bug.cgi?id=81861
--- Comment #21 from Nathan R nathan.renniewaldock+kernelb...@gmail.com ---
(In reply to Nathan R from comment #20)
There seems to be various issues with this driver. After reverting that
commit, I can load the driver, but insmod takes a long
The owner module reference of the ahci platform's scsi_host is
initialized to libahci_platform's one, because these drivers use a
scsi_host_template defined in libahci_platform. So these drivers can
be unloaded even if the scsi device is being accessed.
This fixes it by pushing the
The owner module reference of the pata_of_platform's scsi_host is
initialized to pata_platform's one, because pata_of_platform driver
use a scsi_host_template defined in pata_platform. So this drivers
can be unloaded even if the scsi device is being accessed.
This fixes it by propagating the
https://bugzilla.kernel.org/show_bug.cgi?id=81861
--- Comment #22 from Nathan R nathan.renniewaldock+kernelb...@gmail.com ---
Created attachment 164841
-- https://bugzilla.kernel.org/attachment.cgi?id=164841action=edit
Patched mvsas dmesg in kernel 3.18.3
--
You are receiving this mail
14 matches
Mail list logo
