Re: [PATCH] eata: Convert eata driver as normal PCI and platform device drivers
On 2016/3/2 5:36, Arthur Marsh wrote: > > > Arthur Marsh wrote on 02/03/16 03:57: >> >> >> Christoph Hellwig wrote on 01/03/16 17:22: >>> Hi Jiang. >>> >>> I'd love to see this patch in and abuse of the old PCI API gone. >>> >>> Did you resolve the problems Arthur saw with the previous iteratons >>> of the patch? >>> >> >> I applied Jiang Liu's patch of 1st March 2016 to a clean kernel >> 4.5.0-rc6 source, removed my workaround of removing and re-adding the >> eata module before mounting file-systems that are on disks attached to >> the DPT SCSI card using the eata driver, and was able to kexec from the >> new kernel successfully. >> >> Arthur. > > I spoke too soon, without removing and re-inserting the eata module > before any filesystems on disks attached to the DPT controller were > mounted, I'd get the following messages, similar to ones previously > reported: > > sd 0:0:6:0: tag#0 abort, mbox 1. > EATA0: abort, mbox 1 is in use. > sd 0:0:6:0: tag#0 reset, enter. > EATA0: reset, mbox 1 in reset. > EATA0: reset, board reset done, enabling interrupts. > EATA0: reset, interrupts disabled, loops 100415. > EATA0, reset, mbox 1 locked, DID_RESET, done. > EATA0: reset, exit, done. > > > and so on, finally hanging after printing "kexec_core: Starting new > kernel" (I have a photo of the messages if they're needed). > > So I'm still using the new patch but have to continue to remove and > reinsert eata at start-up before any attempts to mount disks attatched > to the DPT SCSI controller. Hi Authur, Thanks for testing. So current situation is that we have a working driver for normal case, but still have issues during kexec. Per my understanding, we need to implement a PCI device driver shutdown callback to reset the RAID controller. I have once tried to implement the shutdown callback, but it doesn't work. And I have no deep understanding of the RAID controller and have no hardware for experiment too, so have no idea about next step. Maybe one acceptable way is to merge this patch first, so we get a basic working driver, and then ask help from expert to solve the kexec issue. Thanks! Gerry > > Arthur. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] eata: Convert eata driver as normal PCI and platform device drivers
Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
will be called by pci_device_probe() to allocate PCI legacy IRQs
when binding PCI drivers to PCI devices.
But the eata driver directly accesses PCI devices without implementing
corresponding PCI drivers, so pcibios_alloc_irq() won't be called for
those PCI devices and wrong IRQ number may be used to manage the PCI
device.
This patch implements a PCI device driver to manage eata PCI devices,
so eata driver could properly cooperate with the PCI core. It also
provides headroom for PCI hotplug with eata driver.
It also represents non-PCI eata devices as platform devices, so it could
be managed as normal devices.
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: Ballabio, Dario <dario.balla...@emc.com>
Cc: Christoph Hellwig <h...@infradead.org>
---
drivers/scsi/eata.c | 624 ---
1 file changed, 342 insertions(+), 282 deletions(-)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..a27a7201866d 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -486,6 +486,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -503,8 +504,6 @@
#include
#include
-static int eata2x_detect(struct scsi_host_template *);
-static int eata2x_release(struct Scsi_Host *);
static int eata2x_queuecommand(struct Scsi_Host *, struct scsi_cmnd *);
static int eata2x_eh_abort(struct scsi_cmnd *);
static int eata2x_eh_host_reset(struct scsi_cmnd *);
@@ -513,9 +512,9 @@ static int eata2x_bios_param(struct scsi_device *, struct
block_device *,
static int eata2x_slave_configure(struct scsi_device *);
static struct scsi_host_template driver_template = {
+ .module = THIS_MODULE,
+ .proc_name = "eata2x",
.name = "EATA/DMA 2.0x rev. 8.10.00 ",
- .detect = eata2x_detect,
- .release = eata2x_release,
.queuecommand = eata2x_queuecommand,
.eh_abort_handler = eata2x_eh_abort,
.eh_host_reset_handler = eata2x_eh_host_reset,
@@ -818,7 +817,6 @@ struct hostdata {
unsigned int cp_stat[MAX_MAILBOXES];/* FREE, IN_USE, LOCKED,
IN_RESET */
unsigned int last_cp_used; /* Index of last mailbox used */
unsigned int iocount; /* Total i/o done for this board */
- int board_number; /* Number of this board */
char board_name[16];/* Name of this board */
int in_reset; /* True if board is doing a reset */
int target_to[MAX_TARGET][MAX_CHANNEL]; /* N. of timeout errors on
target */
@@ -834,12 +832,9 @@ struct hostdata {
struct mssp sp; /* Local copy of sp buffer */
};
-static struct Scsi_Host *sh[MAX_BOARDS];
static const char *driver_name = "EATA";
-static char sha[MAX_BOARDS];
-
-/* Initialize num_boards so that ihdlr can work while detect is in progress */
-static unsigned int num_boards = MAX_BOARDS;
+static struct platform_device *eata2x_platform_devs[MAX_BOARDS];
+static bool eata2x_platform_driver_registered;
static unsigned long io_port[] = {
@@ -850,10 +845,6 @@ static unsigned long io_port[] = {
/* First ISA */
0x1f0,
- /* Space for MAX_PCI ports possibly reported by PCI_BIOS */
- SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
- SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
-
/* MAX_EISA ports */
0x1c88, 0x2c88, 0x3c88, 0x4c88, 0x5c88, 0x6c88, 0x7c88, 0x8c88,
0x9c88, 0xac88, 0xbc88, 0xcc88, 0xdc88, 0xec88, 0xfc88,
@@ -871,6 +862,18 @@ static unsigned long io_port[] = {
#define H2DEV16(x) cpu_to_be16(x)
#define DEV2H16(x) be16_to_cpu(x)
+#define dev_warn_on(dev, cond, fmt, ...) \
+do { \
+ if (cond) \
+ dev_warn(dev, fmt, ##__VA_ARGS__); \
+} while(0)
+
+#define dev_info_on(dev, cond, fmt, ...) \
+do { \
+ if (cond) \
+ dev_info(dev, fmt, ##__VA_ARGS__); \
+} while(0)
+
/* But transfer orientation from the 16 bit data register is Little Endian */
#define REG2H(x) le16_to_cpu(x)
@@ -1024,90 +1027,43 @@ static int read_pio(unsigned long iobase, ushort *
start, ushort * end)
return 0;
Re: [Bugfix v4 1/2] eata: Convert eata driver as normal PCI and platform device drivers
On 2015/10/8 10:51, Jiang Liu wrote:
> Previously the eata driver just grabs and accesses eata PCI devices
> without implementing a PCI device driver, that causes troubles with
> latest IRQ related
>
> Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
> pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
> for PCI devices on x86 platforms. Instead of allocating PCI legacy
> IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
> will be called by pci_device_probe() to allocate PCI legacy IRQs
> when binding PCI drivers to PCI devices.
>
> But the eata driver directly accesses PCI devices without implementing
> corresponding PCI drivers, so pcibios_alloc_irq() won't be called for
> those PCI devices and wrong IRQ number may be used to manage the PCI
> device.
>
> This patch implements a PCI device driver to manage eata PCI devices,
> so eata driver could properly cooperate with the PCI core. It also
> provides headroom for PCI hotplug with eata driver.
>
> It also represents non-PCI eata devices as platform devices, so it could
> be managed as normal devices.
>
Hi all,
Sorry, should add:
Reported-and-tested-by: Arthur Marsh <arthur.ma...@internode.on.net>
> Signed-off-by: Jiang Liu <jiang@linux.intel.com>
> Cc: Hannes Reinecke <h...@suse.de>
> Cc: Ballabio, Dario <dario.balla...@emc.com>
> Cc: Christoph Hellwig <h...@infradead.org>
> ---
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bugfix v4 1/2] eata: Convert eata driver as normal PCI and platform device drivers
Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
will be called by pci_device_probe() to allocate PCI legacy IRQs
when binding PCI drivers to PCI devices.
But the eata driver directly accesses PCI devices without implementing
corresponding PCI drivers, so pcibios_alloc_irq() won't be called for
those PCI devices and wrong IRQ number may be used to manage the PCI
device.
This patch implements a PCI device driver to manage eata PCI devices,
so eata driver could properly cooperate with the PCI core. It also
provides headroom for PCI hotplug with eata driver.
It also represents non-PCI eata devices as platform devices, so it could
be managed as normal devices.
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: Ballabio, Dario <dario.balla...@emc.com>
Cc: Christoph Hellwig <h...@infradead.org>
---
Hi all,
With this patch applied, we still have issues when doing kexec,
but I think we could treat the kexec failure independently. So it would
be great if we could merge this patch first and then continue on solving
the kexec issues.
v3->v4:
1) refine log messages according to James' suggestion
Thanks!
Gerry
---
drivers/scsi/eata.c | 619 ---
1 file changed, 337 insertions(+), 282 deletions(-)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..7315f8adcf65 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -486,6 +486,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -503,8 +504,6 @@
#include
#include
-static int eata2x_detect(struct scsi_host_template *);
-static int eata2x_release(struct Scsi_Host *);
static int eata2x_queuecommand(struct Scsi_Host *, struct scsi_cmnd *);
static int eata2x_eh_abort(struct scsi_cmnd *);
static int eata2x_eh_host_reset(struct scsi_cmnd *);
@@ -513,9 +512,9 @@ static int eata2x_bios_param(struct scsi_device *, struct
block_device *,
static int eata2x_slave_configure(struct scsi_device *);
static struct scsi_host_template driver_template = {
+ .module = THIS_MODULE,
+ .proc_name = "eata2x",
.name = "EATA/DMA 2.0x rev. 8.10.00 ",
- .detect = eata2x_detect,
- .release = eata2x_release,
.queuecommand = eata2x_queuecommand,
.eh_abort_handler = eata2x_eh_abort,
.eh_host_reset_handler = eata2x_eh_host_reset,
@@ -818,7 +817,6 @@ struct hostdata {
unsigned int cp_stat[MAX_MAILBOXES];/* FREE, IN_USE, LOCKED,
IN_RESET */
unsigned int last_cp_used; /* Index of last mailbox used */
unsigned int iocount; /* Total i/o done for this board */
- int board_number; /* Number of this board */
char board_name[16];/* Name of this board */
int in_reset; /* True if board is doing a reset */
int target_to[MAX_TARGET][MAX_CHANNEL]; /* N. of timeout errors on
target */
@@ -834,12 +832,9 @@ struct hostdata {
struct mssp sp; /* Local copy of sp buffer */
};
-static struct Scsi_Host *sh[MAX_BOARDS];
static const char *driver_name = "EATA";
-static char sha[MAX_BOARDS];
-
-/* Initialize num_boards so that ihdlr can work while detect is in progress */
-static unsigned int num_boards = MAX_BOARDS;
+static struct platform_device *eata2x_platform_devs[MAX_BOARDS];
+static bool eata2x_platform_driver_registered;
static unsigned long io_port[] = {
@@ -850,10 +845,6 @@ static unsigned long io_port[] = {
/* First ISA */
0x1f0,
- /* Space for MAX_PCI ports possibly reported by PCI_BIOS */
- SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
- SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
-
/* MAX_EISA ports */
0x1c88, 0x2c88, 0x3c88, 0x4c88, 0x5c88, 0x6c88, 0x7c88, 0x8c88,
0x9c88, 0xac88, 0xbc88, 0xcc88, 0xdc88, 0xec88, 0xfc88,
@@ -870,6 +861,13 @@ static unsigned long io_port[] = {
#define DEV2H(x) be32_to_cpu(x)
#define H2DEV16(x) cpu_to_be16(x)
#define DEV2H16(x) be16_to_cpu(x)
+#define dev_warn_on(dev, cond, fmt, ...) \
+do { \
+ if (cond) \
+ dev_warn(dev, fmt, ##__VA_ARGS__); \
+} while (0)
+#define dev_info_on(dev, cond, fmt, ...) \
+ if ((cond)) dev_info((dev), (fmt), ##__VA_ARGS__)
/* But transfer orientation from the 16 bit data register is Little Endian */
#
[Bugfix v4 2/2] eata: Ask for help to reset eata controllers for kexec
Arthur Marsh <arthur.ma...@internode.on.net> reported that with the first
patch applied, he still encountered troubles when doing kexec with eata
devices. Quote Arthur's report:
To clarify, if the eata driver gets loaded once and stays loaded, at a
kexec reboot attempt the "Synchronising SCSI cache" message is missing
for the SCSI disk attached to the controller using the eata driver and
eventually other error messages appear as seen in screen images that
I have previously posted at
http://www.users.on.net/~arthur.marsh/20150915547.jpg.
If the eata driver is loaded, unloaded via modprobe -r, then reloaded,
a kexec reboot shows 2 "Synchronising SCSI cache" messages for the SCSI
disk attached to the controller using the eata driver and the kexec
reboot is successful.
For more details, please refer to thread at:
http://www.gossamer-threads.com/lists/linux/kernel/2251833
https://lkml.org/lkml/2015/9/6/165
First I thought we could solve this issue by implementing a shutdown
callback to reset eata controllers when rebooting, but it turns out
that this patch doesn't really help. And due to limited knowledge about
eata controllers and lack of hardware for tests, helps from eata experts
are really welcomed!
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
---
drivers/scsi/eata.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 7315f8adcf65..b83abe283744 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1519,6 +1519,11 @@ static void eata2x_pci_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
+static void eata2x_pci_shutdown(struct pci_dev *pdev)
+{
+ port_remove(>dev);
+}
+
static struct pci_device_id eata2x_tbl[] = {
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SCSI << 8, PCI_ANY_ID) },
{ },
@@ -1530,6 +1535,7 @@ static struct pci_driver eata2x_pci_driver = {
.id_table = eata2x_tbl,
.probe = eata2x_pci_probe,
.remove = eata2x_pci_remove,
+ .shutdown = eata2x_pci_shutdown,
};
static int eata2x_register_pci_driver(void)
@@ -1571,8 +1577,14 @@ static int __exit eata2x_platform_remove(struct
platform_device *pdev)
return 0;
}
+static void eata2x_platform_shutdown(struct platform_device *pdev)
+{
+ port_remove(>dev);
+}
+
static struct platform_driver eata2x_platform_driver = {
.remove = __exit_p(eata2x_platform_remove),
+ .shutdown = eata2x_platform_shutdown,
.driver = {
.name = "eata_plat",
.owner = THIS_MODULE,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT v3] eata: Convert eata driver as normal PCI and platform device drivers
On 2015/9/26 14:27, Arthur Marsh wrote:
>
>
> Arthur Marsh wrote on 24/09/15 15:26:
>>
>>
>> Jiang Liu wrote on 24/09/15 13:58:
>>
>>> Hi James,
>>> Thanks for review. How about the attached patch which addresses
>>> the three suggestions from you?
>>> Thanks!
>>> Gerry
>>
>> I've applied the patch, rebuilt the kernel and verified that it allows
>> unloading of the eata module and reloading it, as well as a successful
>> kexec.
>>
>> Regards,
>>
>> Arthur.
>
> After some more thorough testing I've encountered an ongoing problem
> trying to use kexec with filesystems mounted with the eata driver.
>
> If I boot up and have the eata driver loaded but no filesystem check or
> mounting of filesystems on the disk attached to the DPT2044W controller,
> then attempt a kexec reboot I get the reboot pausing after the
> "synchronizing scsi cache" messages and getting the errors that I have
> included as pictures in my previous reports.
>
> If I do a normal boot which includes eata being loaded, the disk
> attached to the DPT2044W controller having its filesystems checked and
> mounted, then attempt a kexec reboot, I get the reboot pausing after the
> "synchronizing SCSI cache" messages as before.
>
> If I un-mount the filesystems on the disk attached to the DPT2044W
> controller after start-up and try a reboot I get the same problem.
>
> If I do modprobe -r eata after un-mounting the filesystems on the disk
> attached to the DPT2044W controller after a start-up kexec *works fine*.
Hi Arthur,
The above results suggest that we need to shutdown eata
controller for kexec. So could you please try to apply the attached
patch upon the previous two patches?
Thanks!
Gerry
>From 44a7ee9008951684a6ee1482a4445a64da61f54a Mon Sep 17 00:00:00 2001
From: Jiang Liu <jiang@linux.intel.com>
Date: Sat, 3 Oct 2015 15:57:39 +0800
Subject: [PATCH] eata: Implement shutdown callback for eata driver
Implement shutdown callback for eata driver, so eata controllers will
be put into ready state for kexec.
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
---
drivers/scsi/eata.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index ceeba4d7b4ff..f3ef9ac97646 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1517,6 +1517,11 @@ static void eata2x_pci_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
+static void eata2x_pci_shutdown(struct pci_dev *pdev)
+{
+ port_remove(>dev);
+}
+
static struct pci_device_id eata2x_tbl[] = {
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SCSI << 8, PCI_ANY_ID) },
{ },
@@ -1528,6 +1533,7 @@ static struct pci_driver eata2x_pci_driver = {
.id_table = eata2x_tbl,
.probe = eata2x_pci_probe,
.remove = eata2x_pci_remove,
+ .shutdown = eata2x_pci_shutdown,
};
static int eata2x_register_pci_driver(void)
@@ -1569,8 +1575,14 @@ static int __exit eata2x_platform_remove(struct platform_device *pdev)
return 0;
}
+static void eata2x_platform_shutdown(struct platform_device *pdev)
+{
+ port_remove(>dev);
+}
+
static struct platform_driver eata2x_platform_driver = {
.remove = __exit_p(eata2x_platform_remove),
+ .shutdown = eata2x_platform_shutdown,
.driver = {
.name = "eata_plat",
.owner = THIS_MODULE,
--
1.7.10.4
Re: [RFT v3] eata: Convert eata driver as normal PCI and platform device drivers
On 2015/9/23 22:40, James Bottomley wrote:
> On Wed, 2015-09-23 at 20:14 +0930, Arthur Marsh wrote:
>>
>> Jiang Liu wrote on 23/09/15 14:54:
>>
>>> Hi Arthur,
>>> I have found the cause of the warning messages, it's caused
>>> by a flaw in the conversion. But according to my understanding,
>>> it isn't related to the kexec/kdump failure. Could you please help
>>> to test the attached new version?
>>> Thanks!
>>> Gerry
>>>
>>
>> Thanks, the patch worked, I could successfully unload and reload the
>> eata module, and perform a kexec reboot with the eata module loading
>> successfully afterwards.
>
> Great, so the bug was unconditionally unregistering the platform driver
> when it would fail to attach if none of the legacy IO ports were
> detected.
>
> I think the driver needs a bit of a tidy up. There's no need at all to
> use ida_get_simple(): the only reason for a dense array of numbers was
> for storing the hba private data in the array you got rid of; we can now
> simply use shost->host_no ... it's more useful anyway because the
> numbers match those SCSI is using.
>
> Also, if you insist on converting the printk's to dev warn, you no
> longer need to print out the driver name ... dev_printk already prints
> out the device and driver name as the prefix.
>
> The if (error == 0) is usually written as if (!error) but that's minor.
Hi James,
Thanks for review. How about the attached patch which addresses
the three suggestions from you?
Thanks!
Gerry
>
> Thanks for doing the conversion,
>
> James
>
>
>From aeb4859ff2c86434814cfc88f1a36481f3dcbc86 Mon Sep 17 00:00:00 2001
From: Jiang Liu <jiang@linux.intel.com>
Date: Thu, 24 Sep 2015 12:24:33 +0800
Subject: [PATCH]
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
---
drivers/scsi/eata.c | 234 +--
1 file changed, 97 insertions(+), 137 deletions(-)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 11813a72c2e9..ceeba4d7b4ff 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -487,7 +487,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -818,7 +817,6 @@ struct hostdata {
unsigned int cp_stat[MAX_MAILBOXES]; /* FREE, IN_USE, LOCKED, IN_RESET */
unsigned int last_cp_used; /* Index of last mailbox used */
unsigned int iocount; /* Total i/o done for this board */
- int board_number; /* Number of this board */
char board_name[16]; /* Name of this board */
int in_reset; /* True if board is doing a reset */
int target_to[MAX_TARGET][MAX_CHANNEL]; /* N. of timeout errors on target */
@@ -835,7 +833,6 @@ struct hostdata {
};
static const char *driver_name = "EATA";
-static DEFINE_IDA(eata2x_ida);
static struct platform_device *eata2x_platform_devs[MAX_BOARDS];
static bool eata2x_platform_driver_registered;
@@ -864,6 +861,10 @@ static unsigned long io_port[] = {
#define DEV2H(x) be32_to_cpu(x)
#define H2DEV16(x) cpu_to_be16(x)
#define DEV2H16(x) be16_to_cpu(x)
+#define dev_warn_on(dev, cond, fmt, ...) \
+ if (cond) dev_warn(dev, fmt, ##__VA_ARGS__)
+#define dev_info_on(dev, cond, fmt, ...) \
+ if (cond) dev_info(dev, fmt, ##__VA_ARGS__)
/* But transfer orientation from the 16 bit data register is Little Endian */
#define REG2H(x) le16_to_cpu(x)
@@ -1029,47 +1030,32 @@ static int port_detect(unsigned long port_base, struct device *dev)
unsigned char dma_channel_table[4] = { 5, 6, 7, 0 };
struct Scsi_Host *shost;
struct hostdata *ha;
- char name[16];
- int idx, ret = -ENODEV;
-
- idx = ida_simple_get(_ida, 0, MAX_BOARDS, GFP_KERNEL);
- if (idx < 0) {
- ret = idx;
- goto fail;
- }
+ int ret = -ENODEV;
shost = scsi_host_alloc(_template, sizeof(struct hostdata));
if (shost == NULL) {
- dev_warn(dev, "%s: unable to alloc host, detaching.\n",
- driver_name);
+ dev_warn(dev, "unable to alloc host, detaching.\n");
ret = -ENOMEM;
- goto freeid;
+ goto fail;
}
- sprintf(name, "%s%d", driver_name, idx);
-
if (!request_region(port_base, REGION_SIZE, driver_name)) {
-#if defined(DEBUG_DETECT)
- printk("%s: address 0x%03lx in use, skipping probe.\n", name,
- port_base);
-#endif
+ dev_warn_on(dev, config_enabled(DEBUG_DETECT),
+ "address 0x%03lx in use, skipping probe.\n",
+ port_base);
goto freeshost;
}
if (do_dma(port_base, 0, READ_CONFIG_PIO)) {
-#if defined(DEBUG_DETECT)
- printk("%s: detect, do_dma failed at 0x%03lx.\n", name,
- port_base);
-#endif
+ dev_warn_on(dev, config_enabled(DEBUG_DETECT),
+ "detect, do_dma failed at 0x%03lx.\n", port_base);
goto freelock;
}
/* Read the info structure */
if (read_pio(port_base, (ushort *)
Re: [RFT v3] eata: Convert eata driver as normal PCI and platform device drivers
On 2015/9/23 7:36, Arthur Marsh wrote:
> James Bottomley wrote on 23/09/15 08:15:
>> On Wed, 2015-09-23 at 07:55 +0930, Arthur Marsh wrote:
>> It looks to be some problem in shut down. Can you simply remove and
>> re-insert the driver successfully? If it's your root disk driver,
>> you'll have to do this from an initrd so as not to have root mounted
>> from the eata controller.
>>
>> If the remove and reinsert fails, it means we have a problem in the
>> driver shut down. If not, it's likely something kexec related.
>>
>> James
>
> OK, it looks like there was a problem with unloading the driver.
>
> After un-mounting file systems on the disk attached to the SCSI
> controller using the eata driver I could do a:
>
> modprobe -r eata
>
> but received the output of the attached dmesg log.
>
> Attempting to do
>
> modprobe eata
>
> after the previous modprobe -r eata resulted in a complete lock-up.
Hi Arthur,
I have found the cause of the warning messages, it's caused
by a flaw in the conversion. But according to my understanding,
it isn't related to the kexec/kdump failure. Could you please help
to test the attached new version?
Thanks!
Gerry
>
> Arthur.
>From 2231506adf7da0944fac82ec38040cc2f70562f7 Mon Sep 17 00:00:00 2001
From: Jiang Liu <jiang@linux.intel.com>
Date: Tue, 22 Sep 2015 10:16:20 +0800
Subject: [Bugfix v3] eata: Convert eata driver as normal PCI and platform
device drivers
To: Thomas Gleixner <t...@linutronix.de>,
Bjorn Helgaas <bhelg...@google.com>,
Arthur Marsh <arthur.ma...@internode.on.net>,
Hannes Reinecke <h...@suse.de>,
Ballabio, Dario <dario.balla...@emc.com>,
Christoph Hellwig <h...@infradead.org>
Cc: linux-ker...@vger.kernel.org,
linux-...@vger.kernel.org,
linux-scsi@vger.kernel.org,
x...@kernel.org
Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
will be called by pci_device_probe() to allocate PCI legacy IRQs
when binding PCI drivers to PCI devices.
But the eata driver directly accesses PCI devices without implementing
corresponding PCI drivers, so pcibios_alloc_irq() won't be called for
those PCI devices and wrong IRQ number may be used to manage the PCI
device.
This patch implements a PCI device driver to manage eata PCI devices,
so eata driver could properly cooperate with the PCI core. It also
provides headroom for PCI hotplug with eata driver.
It also represents non-PCI eata devices as platform devices, so it could
be managed as normal devices.
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: Ballabio, Dario <dario.balla...@emc.com>
Cc: Christoph Hellwig <h...@infradead.org>
---
drivers/scsi/eata.c | 451 +++
1 file changed, 272 insertions(+), 179 deletions(-)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..11813a72c2e9 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -486,6 +486,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -503,8 +505,6 @@
#include
#include
-static int eata2x_detect(struct scsi_host_template *);
-static int eata2x_release(struct Scsi_Host *);
static int eata2x_queuecommand(struct Scsi_Host *, struct scsi_cmnd *);
static int eata2x_eh_abort(struct scsi_cmnd *);
static int eata2x_eh_host_reset(struct scsi_cmnd *);
@@ -513,9 +513,9 @@ static int eata2x_bios_param(struct scsi_device *, struct block_device *,
static int eata2x_slave_configure(struct scsi_device *);
static struct scsi_host_template driver_template = {
+ .module = THIS_MODULE,
+ .proc_name = "eata2x",
.name = "EATA/DMA 2.0x rev. 8.10.00 ",
- .detect = eata2x_detect,
- .release = eata2x_release,
.queuecommand = eata2x_queuecommand,
.eh_abort_handler = eata2x_eh_abort,
.eh_host_reset_handler = eata2x_eh_host_reset,
@@ -834,12 +834,10 @@ struct hostdata {
struct mssp sp; /* Local copy of sp buffer */
};
-static struct Scsi_Host *sh[MAX_BOARDS];
static const char *driver_name = "EATA";
-static char sha[MAX_BOARDS];
-
-/* Initialize num_boards so that ihdlr can work while detect is in progress */
-static unsigned int num_boards = MAX_BOARDS;
+static DEFINE_IDA(eata2x_ida);
+static struct platform_device *eata2x_platform_devs[MAX_BOARDS];
+static bool eata2x_platform_driver_registered;
static unsigned long io_port[] = {
@@ -850,10 +848,6 @@ s
[RFT v3] eata: Convert eata driver as normal PCI and platform device drivers
Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
will be called by pci_device_probe() to allocate PCI legacy IRQs
when binding PCI drivers to PCI devices.
But the eata driver directly accesses PCI devices without implementing
corresponding PCI drivers, so pcibios_alloc_irq() won't be called for
those PCI devices and wrong IRQ number may be used to manage the PCI
device.
This patch implements a PCI device driver to manage eata PCI devices,
so eata driver could properly cooperate with the PCI core. It also
provides headroom for PCI hotplug with eata driver.
It also represents non-PCI eata devices as platform devices, so it could
be managed as normal devices.
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
Cc: Hannes Reinecke <h...@suse.de>
Cc: Ballabio, Dario <dario.balla...@emc.com>
Cc: Christoph Hellwig <h...@infradead.org>
---
Hi all,
I have no hardware to test the patch set, so it only passing
compilation and module loading tests. Any help to test this patch on
real hardware are welcomed!
Thanks!
Gerry
---
drivers/scsi/eata.c | 441 ++-
1 file changed, 262 insertions(+), 179 deletions(-)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..dc2c76b7873e 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -486,6 +486,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -503,8 +505,6 @@
#include
#include
-static int eata2x_detect(struct scsi_host_template *);
-static int eata2x_release(struct Scsi_Host *);
static int eata2x_queuecommand(struct Scsi_Host *, struct scsi_cmnd *);
static int eata2x_eh_abort(struct scsi_cmnd *);
static int eata2x_eh_host_reset(struct scsi_cmnd *);
@@ -513,9 +513,9 @@ static int eata2x_bios_param(struct scsi_device *, struct
block_device *,
static int eata2x_slave_configure(struct scsi_device *);
static struct scsi_host_template driver_template = {
+ .module = THIS_MODULE,
+ .proc_name = "eata2x",
.name = "EATA/DMA 2.0x rev. 8.10.00 ",
- .detect = eata2x_detect,
- .release = eata2x_release,
.queuecommand = eata2x_queuecommand,
.eh_abort_handler = eata2x_eh_abort,
.eh_host_reset_handler = eata2x_eh_host_reset,
@@ -834,12 +834,9 @@ struct hostdata {
struct mssp sp; /* Local copy of sp buffer */
};
-static struct Scsi_Host *sh[MAX_BOARDS];
static const char *driver_name = "EATA";
-static char sha[MAX_BOARDS];
-
-/* Initialize num_boards so that ihdlr can work while detect is in progress */
-static unsigned int num_boards = MAX_BOARDS;
+static DEFINE_IDA(eata2x_ida);
+static struct platform_device *eata2x_platform_devs[MAX_BOARDS];
static unsigned long io_port[] = {
@@ -850,10 +847,6 @@ static unsigned long io_port[] = {
/* First ISA */
0x1f0,
- /* Space for MAX_PCI ports possibly reported by PCI_BIOS */
- SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
- SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP, SKIP,
-
/* MAX_EISA ports */
0x1c88, 0x2c88, 0x3c88, 0x4c88, 0x5c88, 0x6c88, 0x7c88, 0x8c88,
0x9c88, 0xac88, 0xbc88, 0xcc88, 0xdc88, 0xec88, 0xfc88,
@@ -1024,74 +1017,41 @@ static int read_pio(unsigned long iobase, ushort *
start, ushort * end)
return 0;
}
-static struct pci_dev *get_pci_dev(unsigned long port_base)
-{
-#if defined(CONFIG_PCI)
- unsigned int addr;
- struct pci_dev *dev = NULL;
-
- while ((dev = pci_get_class(PCI_CLASS_STORAGE_SCSI << 8, dev))) {
- addr = pci_resource_start(dev, 0);
-
-#if defined(DEBUG_PCI_DETECT)
- printk("%s: get_pci_dev, bus %d, devfn 0x%x, addr 0x%x.\n",
- driver_name, dev->bus->number, dev->devfn, addr);
-#endif
-
- /* we are in so much trouble for a pci hotplug system with this
driver
-* anyway, so doing this at least lets people unload the driver
and not
-* cause memory problems, but in general this is a bad thing to
do (this
-* driver needs to be converted to the proper PCI api
someday... */
- pci_dev_put(dev);
- if (addr + PCI_BASE_ADDRESS_0 == port_base)
- return dev;
- }
-#endif /* end CONFIG_PCI */
- return NULL;
-}
-
-static void enable_pci_ports(void)
-{
-#if defined(CONFIG_PCI)
- struct pci_dev *dev = NULL;
-
- while ((dev = pci_get_class(PCI_CL
Re: [Bugfix 3/3] eata: Enhance eata driver to support PCI device hot-removal
On 2015/9/16 21:42, Christoph Hellwig wrote: > On Mon, Sep 14, 2015 at 10:21:14AM +0200, Hannes Reinecke wrote: >> Welll ... if you don't have hardware (and I strongly hope you refer to >> 'hardware able to do hotplugging', not 'hardware for the eata driver' >> ...) why add the code at all? >> Chances are no-one will ever need eata PCI hotplug; SCSI parallel >> typically isn't very good at hotplugging, so throwing in PCI hotplug >> will only confuse matters more. >> Plus due to the sheer mechanics involved here I find it very unlikely >> anyone will be using it in real life. > > Because it's used for module removal and we want every driver to use > the standard interface that. > > Jiang, you also need to convert the driver to > scsi_add_host/scsi_remove_host from the legacy scsi_register interface, > otherwise the SCSI layer will be very unhappy. > > Take a look at commit 0d31f8759109cbc1e6fc196d08e6b0e8a9e93b3f for > example, the change should be straight forward. Hi Christoph, I have taken a look at the commit 0d31f8759109cb and it seems that the conversion is not so big. But I have no hardware for testing, so could only ask for help from community. Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugfix 0/3] Convert eata driver to a normal PCI device driver
On 2015/9/16 15:37, Arthur Marsh wrote: > > > Jiang Liu wrote on 16/09/15 14:37: >> On 2015/9/15 15:19, Arthur Marsh wrote: >>> >>> >>> Jiang Liu wrote on 15/09/15 12:01: >>> >>>> HI Arthur, >>>> Really appreciate your help to test the patches. That's >>>> a good sign we have moved forward a bit:) >>>> For kexec, it's always challenging to me. So could you >>>> please help to provide full dmesg logs with working kernels >>>> so I could try to figure out the order among scsi and PCI devices. >>>> It may be shutdown order related. >>>> Thanks! >>>> Gerry >>> >>> OK, attached is the dmesg output from the 4.2.0 kernel where kexec >>> worked. >> Hi Arthur, >> Could you please also help to capture the log messages >> of kexec, I need to those log messages to figure out the order >> to shutdown PCI devices and scsi devices during kexec. >> Thanks! >> Gerry >> > > How would I capture the log messages of kexec (assuming that there are > any, I couldn't see from the manual page entries and haven't seen > anything beyond the screen images that I have already sent you)? Hi Arthur, It would be great if we could capture the text as in the picture posted by you at: http://www.users.on.net/~arthur.marsh/20150915547.jpg I guess a serial console could help us to capture those log messages. To use serial console, we need to setup serial cable, configure grub and kernel to use serial port as console. Thanks! Gerry > > Regards, > > Arthur. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugfix 0/3] Convert eata driver to a normal PCI device driver
On 2015/9/15 15:19, Arthur Marsh wrote: > > > Jiang Liu wrote on 15/09/15 12:01: > >> HI Arthur, >> Really appreciate your help to test the patches. That's >> a good sign we have moved forward a bit:) >> For kexec, it's always challenging to me. So could you >> please help to provide full dmesg logs with working kernels >> so I could try to figure out the order among scsi and PCI devices. >> It may be shutdown order related. >> Thanks! >> Gerry > > OK, attached is the dmesg output from the 4.2.0 kernel where kexec worked. Hi Arthur, Could you please also help to capture the log messages of kexec, I need to those log messages to figure out the order to shutdown PCI devices and scsi devices during kexec. Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugfix 0/3] Convert eata driver to a normal PCI device driver
On 2015/9/15 0:01, Arthur Marsh wrote: > > > Jiang Liu wrote on 14/09/15 12:38: >> Hi Authur, >> As suggested by Bjorn, patch 1-2 set implement a PCI device >> driver to manage eata PCI devices. And patch 3 tries to support PCI >> device hot-removal for eata, but I have no change to test due to >> limited knowledge about scsi subsystem and lacking of hardware for >> tests. >> So you could please help to test patch 1-2? Patch 3 is just >> for comments. >> Thanks! >> Gerry >> >> Jiang Liu (3): >>eata: Use IDA to manage eata board IDs >>eata: Implement PCI driver to manage eata PCI devices >>eata: Enhance eata driver to support PCI device hot-removal >> >> drivers/scsi/eata.c | 232 >> +++ >> 1 file changed, 125 insertions(+), 107 deletions(-) >> > > With patches 1 and 2 applied, I get a successful boot with IRQ mapping: > > [1.147056] EATA0: IRQ 10 mapped to IO-APIC IRQ 17. > [1.160404] EATA/DMA 2.0x: Copyright (C) 1994-2003 Dario Ballabio. > [1.160469] EATA config options -> tm:1, lc:y, mq:16, rs:y, et:n, > ip:n, ep:n, pp:y. > [1.160541] EATA0: 2.0C, PCI 0xd890, IRQ 17, BMST, SG 122, MB 64. > [1.160600] EATA0: wide SCSI support enabled, max_id 16, max_lun 8. > [1.160658] EATA0: SCSI channel 0 enabled, host target ID 7. > [1.161207] scsi host0: EATA/DMA 2.0x rev. 8.10.00 > > > but I still get errors when trying to do a kexec reboot, see > http://www.users.on.net/~arthur.marsh/20150915547.jpg > > roughly it reads (after the synchronising SCSI cache reboot messages) > and a long period of a dark screen: > > sd 0:0:6:0: abort, mbox 63. > EATA0: abort, mbox 63 is in use. > sd 0:0:6:0: reset, enter. > EATA0: reset, mbox 63 in reset. > EATA0: reset, board reset done, enabling interrupts. > EATA0: reset, interrupts disabled, loops 100469. > EATA0: reset, mbox 63 locked, DID_RESET, done. > EATA0: reset, exit, done. > sd 0:0:6:0: qcomm, mbox 0, adapter busy, will start > sd 0:0:6:0: abort, mbox 0. > EATA0: abort, timeout error. > sd 0:0:6:0: reset, enter. > EATA0: reset, exit, timeout error. > sd 0:0:6:0 Device offlinled - not ready after error recovery > sd 0:0:6:0 rejecting I/O to offline device > sd 0:0:6:0 rejecting I/O to offline device > sd 0:0:6:0 [sda] Synchronize Cache(10) failed: Result: > hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK > starting new kernel > > It would be great if this problem could be fixed. HI Arthur, Really appreciate your help to test the patches. That's a good sign we have moved forward a bit:) For kexec, it's always challenging to me. So could you please help to provide full dmesg logs with working kernels so I could try to figure out the order among scsi and PCI devices. It may be shutdown order related. Thanks! Gerry > > Arthur. > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugfix 3/3] eata: Enhance eata driver to support PCI device hot-removal
On 2015/9/14 16:31, Ballabio, Dario wrote:
> Agreed, It does not make sense to have this driver converted to a hot plug
> api.
Thanks, got the point:)
Originally i thought user may trigger PCI device hot-removal by sysfs
interfaces and there's comment mentioning that eata driver breaks
PCI hotplug, so I tried to solve it. If it's no real use, we may
just drop the third patch.
Thanks!
Gerry
>
> Cheers,
>
>
>
> ***
> Ph.D. Dario Ballabio
> Principal Field Support Specialist, EMC EMEA
> Mobile phone: +393487978851
>
>
>
> -Original Message-
> From: Hannes Reinecke [mailto:h...@suse.de]
> Sent: Monday, September 14, 2015 10:21 AM
> To: Jiang Liu; Thomas Gleixner; Bjorn Helgaas; Arthur Marsh; Ballabio, Dario;
> James E.J. Bottomley
> Cc: linux-ker...@vger.kernel.org; linux-...@vger.kernel.org;
> linux-scsi@vger.kernel.org; x...@kernel.org
> Subject: Re: [Bugfix 3/3] eata: Enhance eata driver to support PCI device
> hot-removal
>
> On 09/14/2015 05:08 AM, Jiang Liu wrote:
>> Due to having no hardware for testing, this is just a sample code to
>> support PCI device hot-removal. It just passing compilation, no any
>> tests.
>>
>> Signed-off-by: Jiang Liu <jiang@linux.intel.com>
>> ---
>> drivers/scsi/eata.c | 26 ++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c index
>> b92e6856f909..f3bd7cbf260e 100644
>> --- a/drivers/scsi/eata.c
>> +++ b/drivers/scsi/eata.c
>> @@ -1474,6 +1474,21 @@ static unsigned int port_probe(unsigned long
>> port_base, #ifdef CONFIG_PCI static int eata2x_pci_device_count;
>>
>> +/* TODO: need help here to shutdown the scsi host and release
>> +resources */ static void port_remove(unsigned int id, resource_size_t
>> port_base,
>> +struct pci_dev *pdev)
>> +{
>> +struct Scsi_Host *shost = sh[id];
>> +
>> +/* TODO: stop scsi device */
>> +scsi_unregister(shost);
>> +/* TODO: clean up resources allocated by port_detect() */
>> +clear_bit(id, eata_board_bitmap);
>> +free_irq(shost->irq, [id]);
>> +release_region(port_base, REGION_SIZE);
>> +ida_simple_remove(_ida, id);
>> +}
>> +
>> static int eata2x_pci_probe(struct pci_dev *dev, const struct
>> pci_device_id *id) {
>> int i, ret = -ENXIO;
>> @@ -1521,6 +1536,16 @@ out_error:
>> return ret;
>> }
>>
>> +static void eata2x_pci_remove(struct pci_dev *pdev) {
>> +int id = (int)(long)dev_get_drvdata(>dev);
>> +resource_size_t port_base;
>> +
>> +port_base = pci_resource_start(pdev, 0) + PCI_BASE_ADDRESS_0;
>> +port_remove(id, port_base, pdev);
>> +pci_disable_device(pdev);
>> +}
>> +
>> static struct pci_device_id eata2x_tbl[] = {
>> { PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SCSI << 8, PCI_ANY_ID) },
>> { },
>> @@ -1531,6 +1556,7 @@ static struct pci_driver eata2x_pci_driver = {
>> .name = "eata",
>> .id_table = eata2x_tbl,
>> .probe = eata2x_pci_probe,
>> +.remove = eata2x_pci_remove,
>> };
>>
>> static int eata2x_probe_pci_devices(struct scsi_host_template *tpnt)
>>
> Welll ... if you don't have hardware (and I strongly hope you refer to
> 'hardware able to do hotplugging', not 'hardware for the eata driver'
> ...) why add the code at all?
> Chances are no-one will ever need eata PCI hotplug; SCSI parallel typically
> isn't very good at hotplugging, so throwing in PCI hotplug will only confuse
> matters more.
> Plus due to the sheer mechanics involved here I find it very unlikely anyone
> will be using it in real life.
>
> Cheers,
>
> Hannes
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bugfix 0/3] Convert eata driver to a normal PCI device driver
Hi Authur, As suggested by Bjorn, patch 1-2 set implement a PCI device driver to manage eata PCI devices. And patch 3 tries to support PCI device hot-removal for eata, but I have no change to test due to limited knowledge about scsi subsystem and lacking of hardware for tests. So you could please help to test patch 1-2? Patch 3 is just for comments. Thanks! Gerry Jiang Liu (3): eata: Use IDA to manage eata board IDs eata: Implement PCI driver to manage eata PCI devices eata: Enhance eata driver to support PCI device hot-removal drivers/scsi/eata.c | 232 +++ 1 file changed, 125 insertions(+), 107 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bugfix 1/3] eata: Use IDA to manage eata board IDs
Use IDA to manage eata board IDs, so we could dynamically allocate
and free board IDs later.
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
---
drivers/scsi/eata.c | 46 ++
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..b45d3b532b70 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -491,6 +491,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -837,9 +838,8 @@ struct hostdata {
static struct Scsi_Host *sh[MAX_BOARDS];
static const char *driver_name = "EATA";
static char sha[MAX_BOARDS];
-
-/* Initialize num_boards so that ihdlr can work while detect is in progress */
-static unsigned int num_boards = MAX_BOARDS;
+static DEFINE_IDA(eata_ida);
+static DECLARE_BITMAP(eata_board_bitmap, MAX_BOARDS);
static unsigned long io_port[] = {
@@ -1509,6 +1509,23 @@ static int option_setup(char *str)
return 1;
}
+static unsigned int port_probe(unsigned long port_base,
+ struct scsi_host_template *tpnt)
+{
+ int id;
+
+ id = ida_simple_get(_ida, 0, MAX_BOARDS, GFP_KERNEL);
+ if (id >= 0) {
+ set_bit(id, eata_board_bitmap);
+ if (port_detect(port_base, id, tpnt))
+ return id;
+ clear_bit(id, eata_board_bitmap);
+ ida_simple_remove(_ida, id);
+ }
+
+ return -1;
+}
+
static void add_pci_ports(void)
{
#if defined(CONFIG_PCI)
@@ -1548,7 +1565,7 @@ static void add_pci_ports(void)
static int eata2x_detect(struct scsi_host_template *tpnt)
{
- unsigned int j = 0, k;
+ unsigned int k, count = 0;
tpnt->proc_name = "eata2x";
@@ -1582,17 +1599,12 @@ static int eata2x_detect(struct scsi_host_template
*tpnt)
enable_pci_ports();
}
- for (k = 0; io_port[k]; k++) {
+ for (k = 0; io_port[k]; k++)
+ if (io_port[k] != SKIP &&
+ port_probe(io_port[k], tpnt) >= 0)
+ count++;
- if (io_port[k] == SKIP)
- continue;
-
- if (j < MAX_BOARDS && port_detect(io_port[k], j, tpnt))
- j++;
- }
-
- num_boards = j;
- return j;
+ return count;
}
static void map_dma(unsigned int i, struct hostdata *ha)
@@ -2530,14 +2542,16 @@ static irqreturn_t ihdlr(struct Scsi_Host *shost)
static irqreturn_t do_interrupt_handler(int dummy, void *shap)
{
struct Scsi_Host *shost;
- unsigned int j;
+ unsigned int j = (unsigned int)((char *)shap - sha);
unsigned long spin_flags;
irqreturn_t ret;
/* Check if the interrupt must be processed by this handler */
- if ((j = (unsigned int)((char *)shap - sha)) >= num_boards)
+ if (j >= MAX_BOARDS || !test_bit(j, eata_board_bitmap))
return IRQ_NONE;
shost = sh[j];
+ if (!shost)
+ return IRQ_NONE;
spin_lock_irqsave(shost->host_lock, spin_flags);
ret = ihdlr(shost);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bugfix 3/3] eata: Enhance eata driver to support PCI device hot-removal
Due to having no hardware for testing, this is just a sample code
to support PCI device hot-removal. It just passing compilation,
no any tests.
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
---
drivers/scsi/eata.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index b92e6856f909..f3bd7cbf260e 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1474,6 +1474,21 @@ static unsigned int port_probe(unsigned long port_base,
#ifdef CONFIG_PCI
static int eata2x_pci_device_count;
+/* TODO: need help here to shutdown the scsi host and release resources */
+static void port_remove(unsigned int id, resource_size_t port_base,
+ struct pci_dev *pdev)
+{
+ struct Scsi_Host *shost = sh[id];
+
+ /* TODO: stop scsi device */
+ scsi_unregister(shost);
+ /* TODO: clean up resources allocated by port_detect() */
+ clear_bit(id, eata_board_bitmap);
+ free_irq(shost->irq, [id]);
+ release_region(port_base, REGION_SIZE);
+ ida_simple_remove(_ida, id);
+}
+
static int eata2x_pci_probe(struct pci_dev *dev, const struct pci_device_id
*id)
{
int i, ret = -ENXIO;
@@ -1521,6 +1536,16 @@ out_error:
return ret;
}
+static void eata2x_pci_remove(struct pci_dev *pdev)
+{
+ int id = (int)(long)dev_get_drvdata(>dev);
+ resource_size_t port_base;
+
+ port_base = pci_resource_start(pdev, 0) + PCI_BASE_ADDRESS_0;
+ port_remove(id, port_base, pdev);
+ pci_disable_device(pdev);
+}
+
static struct pci_device_id eata2x_tbl[] = {
{ PCI_DEVICE_CLASS(PCI_CLASS_STORAGE_SCSI << 8, PCI_ANY_ID) },
{ },
@@ -1531,6 +1556,7 @@ static struct pci_driver eata2x_pci_driver = {
.name = "eata",
.id_table = eata2x_tbl,
.probe = eata2x_pci_probe,
+ .remove = eata2x_pci_remove,
};
static int eata2x_probe_pci_devices(struct scsi_host_template *tpnt)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: eata fails to load on post 4.2 kernels
Hi Authur,
Thanks for the updating. Seem Bjorn doesn't like
neither of my two patches. So I'm trying to convert eata
to formal PCI driver, but the change will be much more
bigger and still not sure whether we could achieve that.
Will keep you updated.
Thanks!
Gerry
On 2015/9/10 15:50, Arthur Marsh wrote:
>
>
> Jiang Liu wrote on 08/09/15 14:49:
>> Hi Auhur,
>> Could you please help to apply the test patch
>> against the latest mainstream linux kernel?
>> Thanks!
>> Gerry
> ...
>
>>>>> git bisect good
>>>>> 991de2e59090e55c65a7f59a049142e3c480f7bd is the first bad commit
>>>>> commit 991de2e59090e55c65a7f59a049142e3c480f7bd
>>>>> Author: Jiang Liu <jiang@linux.intel.com>
>>>>> Date: Wed Jun 10 16:54:59 2015 +0800
>>>>>
>>>>> PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()
>>>>>
>>>>> To support IOAPIC hotplug, we need to allocate PCI IRQ
>>>>> resources on
>>>>> demand
>>>>> and free them when not used anymore.
>>>>>
>>>>> Implement pcibios_alloc_irq() and pcibios_free_irq() to
>>>>> dynamically
>>>>> allocate and free PCI IRQs.
>>>>>
>>>>> Remove mp_should_keep_irq(), which is no longer used.
>>>>>
>>>>> [bhelgaas: changelog]
>>>>> Signed-off-by: Jiang Liu <jiang@linux.intel.com>
>>>>> Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
>>>>> Acked-by: Thomas Gleixner <t...@linutronix.de>
>>>>>
>>>>> :04 04 765e2d5232d53247ec260b34b51589c3bccb36ae
>>>>> f680234a27685e94b1a35ae2a7218f8eafa9071a M arch
>>>>> :04 04 d55a682bcde72682e883365e88ad1df6186fd54d
>>>>> f82c470a04a6845fcf5e0aa934512c75628f798d M drivers
>
> I tried to do a kexec shut-down with the first version of your patch:
>
>>From 3085626fb2e677c1d88f158397948935b73f5239 Mon Sep 17 00:00:00 2001
> From: Jiang Liu <jiang@linux.intel.com>
> Date: Tue, 8 Sep 2015 10:41:19 +0800
> Subject: [PATCH]
>
>
> Signed-off-by: Jiang Liu <jiang@linux.intel.com>
> ---
> drivers/pci/pci-driver.c |1 +
> drivers/scsi/eata.c |2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index 52a880ca1768..17d2a0b1de18 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -392,6 +392,7 @@ int __weak pcibios_alloc_irq(struct pci_dev *dev)
> {
> return 0;
> }
> +EXPORT_SYMBOL_GPL(pcibios_alloc_irq);
>
> void __weak pcibios_free_irq(struct pci_dev *dev)
> {
> diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
> index 227dd2c2ec2f..7e6eaf867987 100644
> --- a/drivers/scsi/eata.c
> +++ b/drivers/scsi/eata.c
> @@ -1061,6 +1061,7 @@ static void enable_pci_ports(void)
> driver_name, dev->bus->number, dev->devfn);
> #endif
>
> +pcibios_alloc_irq(dev);
> if (pci_enable_device(dev))
> printk
> ("%s: warning, pci_enable_device failed, bus %d devfn
> 0x%x.\n",
> @@ -1520,6 +1521,7 @@ static void add_pci_ports(void)
> if (!(dev = pci_get_class(PCI_CLASS_STORAGE_SCSI << 8, dev)))
> break;
>
> +pcibios_alloc_irq(dev);
> if (pci_enable_device(dev)) {
> #if defined(DEBUG_PCI_DETECT)
> printk
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugfix] PCI, x86: Correctly allocate IRQs for PCI devices managed by non-PCI drivers
On 2015/9/8 17:03, Arthur Marsh wrote: > > > Jiang Liu wrote on 08/09/15 16:56: > Thanks, I removed the test patch and applied the revised patch and built > and rebooted the kernel and successfully mounted file systems on a disk > attached to the DPT 2044W card using the eata driver: > > [0.00] Linux version 4.2.0+ (root@victoria) (gcc version 5.2.1 > 20150903 > (Debian 5.2.1-16) ) #31 SMP PREEMPT Tue Sep 8 17:36:28 ACST 2015 > ... > > [ 80.691097] EATA0: IRQ 10 mapped to IO-APIC IRQ 17. > [ 80.724519] EATA/DMA 2.0x: Copyright (C) 1994-2003 Dario Ballabio. > [ 80.752035] EATA config options -> tm:1, lc:y, mq:16, rs:y, et:n, > ip:n, ep:n, pp:y. > [ 80.777063] EATA0: 2.0C, PCI 0xd890, IRQ 17, BMST, SG 122, MB 64. > [ 80.802391] EATA0: wide SCSI support enabled, max_id 16, max_lun 8. > [ 80.827959] EATA0: SCSI channel 0 enabled, host target ID 7. > [ 80.853413] scsi host3: EATA/DMA 2.0x rev. 8.10.00 > [ 82.445662] scsi 3:0:6:0: Direct-Access IBM DCAS-34330W > S65A PQ: 0 ANSI: 2 > [ 82.471584] scsi 3:0:6:0: cmds/lun 16, sorted, simple tags. > [ 84.571451] sd 3:0:6:0: Attached scsi generic sg4 type 0 > [ 84.597572] sd 3:0:6:0: [sdd] 8466688 512-byte logical blocks: (4.33 > GB/4.03 GiB) > [ 84.659874] sd 3:0:6:0: [sdd] Write Protect is off > [ 84.688543] sd 3:0:6:0: [sdd] Mode Sense: b3 00 00 08 > [ 84.714021] sd 3:0:6:0: [sdd] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 84.817682] sdd: sdd1 sdd2 < sdd5 > > [ 84.919267] sd 3:0:6:0: [sdd] Attached SCSI disk Hi Arthur, Thanks for testing:) > > Arthur. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: eata fails to load on post 4.2 kernels
On 2015/9/8 14:32, Arthur Marsh wrote: > > > Jiang Liu wrote on 08/09/15 14:49: >> Hi Auhur, >> Could you please help to apply the test patch >> against the latest mainstream linux kernel? >> Thanks! >> Gerry > > Done, and it appears to work properly thanks! Hi Authur, We just got the root cause, and still need to work out a formal patch to fix it. So will send new formal patch to you for testing:) Thanks! Gerry > > Arthur. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bugfix] PCI, x86: Correctly allocate IRQs for PCI devices managed by non-PCI drivers
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
will be called by pci_device_probe() to allocate PCI legacy IRQs
when binding PCI drivers to PCI devices.
But some device drivers, such as eata, directly access PCI devices
without implementing corresponding PCI drivers, so pcibios_alloc_irq()
won't be called for those PCI devices and wrong IRQ number may be
used to manage the PCI device.
So detect such a case in pcibios_enable_device() by checking
pci_dev->driver is NULL and call pcibios_alloc_irq() to allocate PCI
legacy IRQs.
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
---
arch/x86/pci/common.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 09d3afc0a181..60b237783582 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -685,6 +685,16 @@ void pcibios_free_irq(struct pci_dev *dev)
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
+ /*
+* By design, pcibios_alloc_irq() will be called by pci_device_probe()
+* when binding a PCI device to a PCI driver. But some device drivers,
+* such as eata, directly make use of PCI devices without implementing
+* PCI device drivers, so pcibios_alloc_irq() won't be called for those
+* PCI devices.
+*/
+ if (!dev->driver)
+ pcibios_alloc_irq(dev);
+
return pci_enable_resources(dev, mask);
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugfix] PCI, x86: Correctly allocate IRQs for PCI devices managed by non-PCI drivers
On 2015/9/9 0:27, Bjorn Helgaas wrote:
> Hi Jiang,
>
> I object to subject lines like "Correctly do such and such." Nobody
> writes code to do things *incorrectly*, so the word "correctly" takes
> up space without contributing meaning. In this case, it's at least
> debatable whether this is even the "correct" approach; see below.
>
> On Tue, Sep 08, 2015 at 03:26:29PM +0800, Jiang Liu wrote:
>> Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
>> pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
>> for PCI devices on x86 platforms. Instead of allocating PCI legacy
>> IRQs when pcibios_enable_device() gets called, now pcibios_alloc_irq()
>> will be called by pci_device_probe() to allocate PCI legacy IRQs
>> when binding PCI drivers to PCI devices.
>>
>> But some device drivers, such as eata, directly access PCI devices
>> without implementing corresponding PCI drivers, so pcibios_alloc_irq()
>> won't be called for those PCI devices and wrong IRQ number may be
>> used to manage the PCI device.
>
> I'm not sure this is wise.
>
> We normally call pcibios_alloc_irq() from pci_device_probe(), just
> before we call the driver's .probe() method.
>
> The eata driver does not use pci_register_driver(), so there is no
> .probe() method (also no .remove(), .suspend(), etc.) But eata *does*
> use pci_enable_device() and other PCI interfaces. So this patch adds
> code in the x86 pci_enable_device() path for this case.
>
> AFAICT, there's no real reason why eata doesn't register a PCI driver;
> it's just a case of legacy code where nobody has been motivated to
> update it. I'm not in favor of catering to code like that because
> then we have random special cases like this that clutter up the core
> code.
>
> I don't think we should necessarily expect the PCI core to support
> calls to PCI interfaces when it hasn't had a chance to initialize
> itself via driver registration.
>
>> So detect such a case in pcibios_enable_device() by checking
>> pci_dev->driver is NULL and call pcibios_alloc_irq() to allocate PCI
>> legacy IRQs.
>>
>> Signed-off-by: Jiang Liu <jiang@linux.intel.com>
>> ---
>> arch/x86/pci/common.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
>> index 09d3afc0a181..60b237783582 100644
>> --- a/arch/x86/pci/common.c
>> +++ b/arch/x86/pci/common.c
>> @@ -685,6 +685,16 @@ void pcibios_free_irq(struct pci_dev *dev)
>>
>> int pcibios_enable_device(struct pci_dev *dev, int mask)
>> {
>> +/*
>> + * By design, pcibios_alloc_irq() will be called by pci_device_probe()
>> + * when binding a PCI device to a PCI driver. But some device drivers,
>> + * such as eata, directly make use of PCI devices without implementing
>> + * PCI device drivers, so pcibios_alloc_irq() won't be called for those
>> + * PCI devices.
>> + */
>> +if (!dev->driver)
>> +pcibios_alloc_irq(dev);
>
> This is a point fix for x86 only, but I think eata can be built for
> any architecture. Won't other architectures still have the same
> problem?
Hi Bjorn,
We have used another draft version to fix this issue by changing
eata driver as below. But that needs to export pcibios_alloc_irq. And
I'm not sure whether there are other drivers having the same behavior.
If we think it's a legacy behavior and only a few drivers may have
such a behavior, I prefer changing drivers to fix the issue too.
Thanks!
Gerry
---
drivers/pci/pci-driver.c |1 +
drivers/scsi/eata.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 52a880ca1768..17d2a0b1de18 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -392,6 +392,7 @@ int __weak pcibios_alloc_irq(struct pci_dev *dev)
{
return 0;
}
+EXPORT_SYMBOL_GPL(pcibios_alloc_irq);
void __weak pcibios_free_irq(struct pci_dev *dev)
{
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..7e6eaf867987 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1061,6 +1061,7 @@ static void enable_pci_ports(void)
driver_name, dev->bus->number, dev->devfn);
#endif
+ pcibios_alloc_irq(dev);
if (pci_enable_device(dev))
printk
("%s: warning, pci_enable_device failed, bus %d
devfn 0x%x.\n",
@@ -1520,6 +1521,7 @@ static void add_pci_ports(void)
if (!(dev = pci_get_class(PCI_CLASS_STORAGE_SCSI << 8, dev)))
Re: eata fails to load on post 4.2 kernels
Hi Auhur,
Could you please help to apply the test patch
against the latest mainstream linux kernel?
Thanks!
Gerry
On 2015/9/7 14:26, Arthur Marsh wrote:
>
>
> Jiang Liu wrote on 07/09/15 12:36:
>> On 2015/9/7 4:31, Arthur Marsh wrote:
>>> Arthur Marsh wrote on 06/09/15 21:07:
>>>> Arthur Marsh wrote on 06/09/15 18:34:
>>>>> Arthur Marsh wrote on 06/09/15 15:58:
>>>>>> Hi, I'm seeing the following on post 4.2 kernels, am currently
>>>>>> bisecting
>>>>>> to find where it started:
>>>>
>>>> First kernel in the bisection that worked without needing irqpoll:
>>>>
>>>> [ 73.751482] EATA0: IRQ 10 mapped to IO-APIC IRQ 17.
>>>> [ 73.776711] EATA/DMA 2.0x: Copyright (C) 1994-2003 Dario Ballabio.
>>>> [ 73.802005] EATA config options -> tm:1, lc:y, mq:16, rs:y, et:n,
>>>> ip:n, ep:n, pp:y.
>>>> [ 73.829175] EATA0: 2.0C, PCI 0xd890, IRQ 17, BMST, SG 122, MB 64.
>>>> [ 73.82] EATA0: wide SCSI support enabled, max_id 16, max_lun 8.
>>>> [ 73.881125] EATA0: SCSI channel 0 enabled, host target ID 7.
>>>
>>> After a git bisect, I get:
>>>
>>> git bisect good
>>> 991de2e59090e55c65a7f59a049142e3c480f7bd is the first bad commit
>>> commit 991de2e59090e55c65a7f59a049142e3c480f7bd
>>> Author: Jiang Liu <jiang@linux.intel.com>
>>> Date: Wed Jun 10 16:54:59 2015 +0800
>>>
>>> PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()
>>>
>>> To support IOAPIC hotplug, we need to allocate PCI IRQ resources on
>>> demand
>>> and free them when not used anymore.
>>>
>>> Implement pcibios_alloc_irq() and pcibios_free_irq() to dynamically
>>> allocate and free PCI IRQs.
>>>
>>> Remove mp_should_keep_irq(), which is no longer used.
>>>
>>> [bhelgaas: changelog]
>>> Signed-off-by: Jiang Liu <jiang@linux.intel.com>
>>> Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
>>> Acked-by: Thomas Gleixner <t...@linutronix.de>
>>>
>>> :04 04 765e2d5232d53247ec260b34b51589c3bccb36ae
>>> f680234a27685e94b1a35ae2a7218f8eafa9071a M arch
>>> :04 04 d55a682bcde72682e883365e88ad1df6186fd54d
>>> f82c470a04a6845fcf5e0aa934512c75628f798d M drivers
>>>
>>> I'm happy to supply more details if needed.
>> Hi Arthur,
>> Thanks for reporting this. It seems to be an irq misrouting
>> issue. Could you please help to provide:
>> 1) full dmesg with the latest code
>> 2) full dmesg and /proc/interrupts with the latest code and
>> kernel parameter "irqpoll" specified
>> Thanks!
>> Gerry
>
> The pc locks up when loading the eata module so I've attached a photo of
> the monitor screen.
>
> Arthur.
>
>
>From 3085626fb2e677c1d88f158397948935b73f5239 Mon Sep 17 00:00:00 2001
From: Jiang Liu <jiang@linux.intel.com>
Date: Tue, 8 Sep 2015 10:41:19 +0800
Subject: [PATCH]
Signed-off-by: Jiang Liu <jiang@linux.intel.com>
---
drivers/pci/pci-driver.c |1 +
drivers/scsi/eata.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 52a880ca1768..17d2a0b1de18 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -392,6 +392,7 @@ int __weak pcibios_alloc_irq(struct pci_dev *dev)
{
return 0;
}
+EXPORT_SYMBOL_GPL(pcibios_alloc_irq);
void __weak pcibios_free_irq(struct pci_dev *dev)
{
diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 227dd2c2ec2f..7e6eaf867987 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1061,6 +1061,7 @@ static void enable_pci_ports(void)
driver_name, dev->bus->number, dev->devfn);
#endif
+ pcibios_alloc_irq(dev);
if (pci_enable_device(dev))
printk
("%s: warning, pci_enable_device failed, bus %d devfn 0x%x.\n",
@@ -1520,6 +1521,7 @@ static void add_pci_ports(void)
if (!(dev = pci_get_class(PCI_CLASS_STORAGE_SCSI << 8, dev)))
break;
+ pcibios_alloc_irq(dev);
if (pci_enable_device(dev)) {
#if defined(DEBUG_PCI_DETECT)
printk
--
1.7.10.4
Re: eata fails to load on post 4.2 kernels
On 2015/9/7 4:31, Arthur Marsh wrote: > Arthur Marsh wrote on 06/09/15 21:07: >> Arthur Marsh wrote on 06/09/15 18:34: >>> Arthur Marsh wrote on 06/09/15 15:58: >>>> Hi, I'm seeing the following on post 4.2 kernels, am currently >>>> bisecting >>>> to find where it started: >> >> First kernel in the bisection that worked without needing irqpoll: >> >> [ 73.751482] EATA0: IRQ 10 mapped to IO-APIC IRQ 17. >> [ 73.776711] EATA/DMA 2.0x: Copyright (C) 1994-2003 Dario Ballabio. >> [ 73.802005] EATA config options -> tm:1, lc:y, mq:16, rs:y, et:n, >> ip:n, ep:n, pp:y. >> [ 73.829175] EATA0: 2.0C, PCI 0xd890, IRQ 17, BMST, SG 122, MB 64. >> [ 73.82] EATA0: wide SCSI support enabled, max_id 16, max_lun 8. >> [ 73.881125] EATA0: SCSI channel 0 enabled, host target ID 7. > > After a git bisect, I get: > > git bisect good > 991de2e59090e55c65a7f59a049142e3c480f7bd is the first bad commit > commit 991de2e59090e55c65a7f59a049142e3c480f7bd > Author: Jiang Liu <jiang@linux.intel.com> > Date: Wed Jun 10 16:54:59 2015 +0800 > > PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq() > > To support IOAPIC hotplug, we need to allocate PCI IRQ resources on > demand > and free them when not used anymore. > > Implement pcibios_alloc_irq() and pcibios_free_irq() to dynamically > allocate and free PCI IRQs. > > Remove mp_should_keep_irq(), which is no longer used. > > [bhelgaas: changelog] > Signed-off-by: Jiang Liu <jiang@linux.intel.com> > Signed-off-by: Bjorn Helgaas <bhelg...@google.com> > Acked-by: Thomas Gleixner <t...@linutronix.de> > > :04 04 765e2d5232d53247ec260b34b51589c3bccb36ae > f680234a27685e94b1a35ae2a7218f8eafa9071a M arch > :04 04 d55a682bcde72682e883365e88ad1df6186fd54d > f82c470a04a6845fcf5e0aa934512c75628f798d M drivers > > I'm happy to supply more details if needed. Hi Arthur, Thanks for reporting this. It seems to be an irq misrouting issue. Could you please help to provide: 1) full dmesg with the latest code 2) full dmesg and /proc/interrupts with the latest code and kernel parameter "irqpoll" specified Thanks! Gerry > > Regards, > > Arthur. > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] megaraid_sas : Fix bug in handling return value of pci_enable_msix_range()
Function pci_enable_msix_range() may return negative values for error conditions. So it's a bug by checking (pci_enable_msix_range() != 0) for success and causes failure to megaraid driver when MSI is disabled. [ 16.487267] megaraid_sas :02:00.0: Controller type: iMR [ 16.487275] genirq: Flags mismatch irq 0. (megasas) vs. 00015a00 (tii mer) [ 16.487347] megasas: Failed to register IRQ for vector 0. Fixes: 8ae80ed1734b megaraid: Use pci_enable_msix_range() instead of pci_enable_msix() Signed-off-by: Jiang Liu jiang@linux.intel.com Cc: Alexander Gordeev agord...@redhat.com Cc: Bjorn Helgaas bhelg...@google.com Cc: linux-...@vger.kernel.org Cc: sta...@vger.kernel.org # 3.17 --- drivers/scsi/megaraid/megaraid_sas_base.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index f6a69a3b1b3f..5640ad1c8214 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -4453,7 +4453,7 @@ static int megasas_init_fw(struct megasas_instance *instance) instance-msixentry[i].entry = i; i = pci_enable_msix_range(instance-pdev, instance-msixentry, 1, instance-msix_vectors); - if (i) + if (i 0) instance-msix_vectors = i; else instance-msix_vectors = 0; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC Patch V1 20/30] mm, fcoe: Use cpu_to_mem()/numa_mem_id() to support memoryless node
When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id()
may return a node without memory, and later cause system failure/panic
when calling kmalloc_node() and friends with returned node id.
So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with
memory for the/current cpu.
If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id()
is the same as cpu_to_node()/numa_node_id().
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/scsi/fcoe/fcoe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index 00ee0ed642aa..779a7af0e410 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -1257,7 +1257,7 @@ static void fcoe_percpu_thread_create(unsigned int cpu)
p = per_cpu(fcoe_percpu, cpu);
thread = kthread_create_on_node(fcoe_percpu_receive_thread,
- (void *)p, cpu_to_node(cpu),
+ (void *)p, cpu_to_mem(cpu),
fcoethread/%d, cpu);
if (likely(!IS_ERR(thread))) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC Patch V1 18/30] mm, bnx2fc: Use cpu_to_mem()/numa_mem_id() to support memoryless node
When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id()
may return a node without memory, and later cause system failure/panic
when calling kmalloc_node() and friends with returned node id.
So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with
memory for the/current cpu.
If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id()
is the same as cpu_to_node()/numa_node_id().
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 785d0d71781e..144534a51cbb 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -2453,7 +2453,7 @@ static void bnx2fc_percpu_thread_create(unsigned int cpu)
p = per_cpu(bnx2fc_percpu, cpu);
thread = kthread_create_on_node(bnx2fc_percpu_io_thread,
- (void *)p, cpu_to_node(cpu),
+ (void *)p, cpu_to_mem(cpu),
bnx2fc_thread/%d, cpu);
/* bind thread to the cpu */
if (likely(!IS_ERR(thread))) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC Patch V1 19/30] mm, bnx2i: Use cpu_to_mem()/numa_mem_id() to support memoryless node
When CONFIG_HAVE_MEMORYLESS_NODES is enabled, cpu_to_node()/numa_node_id()
may return a node without memory, and later cause system failure/panic
when calling kmalloc_node() and friends with returned node id.
So use cpu_to_mem()/numa_mem_id() instead to get the nearest node with
memory for the/current cpu.
If CONFIG_HAVE_MEMORYLESS_NODES is disabled, cpu_to_mem()/numa_mem_id()
is the same as cpu_to_node()/numa_node_id().
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/scsi/bnx2i/bnx2i_init.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/bnx2i/bnx2i_init.c b/drivers/scsi/bnx2i/bnx2i_init.c
index 80c03b452d61..f67a5a63134e 100644
--- a/drivers/scsi/bnx2i/bnx2i_init.c
+++ b/drivers/scsi/bnx2i/bnx2i_init.c
@@ -423,7 +423,7 @@ static void bnx2i_percpu_thread_create(unsigned int cpu)
p = per_cpu(bnx2i_percpu, cpu);
thread = kthread_create_on_node(bnx2i_percpu_io_thread, (void *)p,
- cpu_to_node(cpu),
+ cpu_to_mem(cpu),
bnx2i_thread/%d, cpu);
/* bind thread to the cpu */
if (likely(!IS_ERR(thread))) {
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
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 dmesg output, BIOS has reserved memory and IOMMU has setup 1:1 mapping for ILO and RAID controller to access this range. Related log messages as below: BIOS-e820: [mem 0x7f61d000-0x8fff] reserved IOMMU: Setting RMRR: IOMMU: Setting identity map for device :03:00.0 [0x7f61e000 - 0x7f61] IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 - 0x7f61] IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] From the screenshot, device :02:00.2 fails to access memory address 0x7f61e000. That indicates IOMMU driver fails to setup 1:1 mapping for Reserved Memory Range for ILO controller. So could you please help to check whether you could observe boot messages like IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] with the failure kernel image? It would be great if boot messages could be saved when failing to boot, so we could get more information from log. BTW, I have double checked related code, and still can't find a reliable explanation for the regression:( Thanks! Gerry On 2014/4/11 0:19, Davidlohr Bueso wrote: On Thu, 2014-04-10 at 08:46 +, Woodhouse, David wrote: On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote: [+ David, VT-d maintainer ] Jiang, David, can you please have a look into this issue? DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 That Present bit in context entry is clear fault means that we have not set up *any* mappings for this PCI device… on this IOMMU. Yes, specifically (finally done bisecting): commit 2e45528930388658603ea24d49cf52867b928d3e Author: Jiang Liu jiang@linux.intel.com Date: Wed Feb 19 14:07:36 2014 +0800 iommu/vt-d: Unify the way to process DMAR device scope array This commit is about how we decide which IOMMU a given PCI device is attached to. Thus, my first guess would be that we are quite happily setting up the requested DMA maps on the *wrong* IOMMU, and then taking faults when the device actually tries to do DMA. However, I'm not 100% convinced of that. The fault address looks suspiciously like a true physical address, not a virtual bus address of the type that we'd normally allocate for a dma_map_* operation. Those would start at 0xf000 and work downwards, typically. Do you have 'iommu=pt' on the kernel command line? No. Can I see the full dmesg as this system boots, and also a copy of the DMAR table? Attaching a dmesg from one of the kernels that boots. It doesn't appear to have much of the related information... is there any debug config option I can enable that might give you more data? -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
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..1f8308c 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -152,7 +152,7 @@ dmar_alloc_pci_notify_info(struct pci_dev *dev,
unsigned long event)
info-seg = pci_domain_nr(dev-bus);
info-level = level;
if (event == BUS_NOTIFY_ADD_DEVICE) {
- for (tmp = dev, level--; tmp; tmp = tmp-bus-self) {
+ for (tmp = dev, level--; tmp; level--, tmp =
tmp-bus-self) {
info-path[level].device = PCI_SLOT(tmp-devfn);
info-path[level].function = PCI_FUNC(tmp-devfn);
if (pci_is_root_bus(tmp-bus))
On 2014/4/11 0:19, Davidlohr Bueso wrote:
On Thu, 2014-04-10 at 08:46 +, Woodhouse, David wrote:
On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote:
[+ David, VT-d maintainer ]
Jiang, David, can you please have a look into this issue?
DMAR:[fault reason 02] Present bit in context entry is clear
dmar: DRHD: handling fault status reg 602
dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000
That Present bit in context entry is clear fault means that we have
not set up *any* mappings for this PCI device… on this IOMMU.
Yes, specifically (finally done bisecting):
commit 2e45528930388658603ea24d49cf52867b928d3e
Author: Jiang Liu jiang@linux.intel.com
Date: Wed Feb 19 14:07:36 2014 +0800
iommu/vt-d: Unify the way to process DMAR device scope array
This commit is about how we decide which IOMMU a given PCI device is
attached to.
Thus, my first guess would be that we are quite happily setting up the
requested DMA maps on the *wrong* IOMMU, and then taking faults when the
device actually tries to do DMA.
However, I'm not 100% convinced of that. The fault address looks
suspiciously like a true physical address, not a virtual bus address of
the type that we'd normally allocate for a dma_map_* operation. Those
would start at 0xf000 and work downwards, typically.
Do you have 'iommu=pt' on the kernel command line?
No.
Can I see the full
dmesg as this system boots, and also a copy of the DMAR table?
Attaching a dmesg from one of the kernels that boots. It doesn't appear
to have much of the related information... is there any debug config
option I can enable that might give you more data?
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hpsa driver bug crack kernel down!
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 : [1D6h 0470 1] Enumeration ID : 00 [1D7h 0471 1] PCI Bus Number : 00 [1D8h 0472 2] PCI Path : 1C,04 [1DAh 0474 2] PCI Path : 00,02 And the patch sent out by me should fix this bug. Could you please help to have a try? Thanks! Gerry On 2014/4/14 23:45, Davidlohr Bueso wrote: 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 information... is there any debug config option I can enable that might give you more data? I'd like the contents of /sys/firmware/acpi/tables/DMAR please. Attached is the disassembly of the raw output. And please could you also apply this patch to both the last-working and first-failing kernels and show me the output in both cases? So I still cannot get around getting the info for the first failing kernel, but below is for the last working. Thanks. Device 0:03:00.0 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f61e000 - 0x7f61] Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f61e000 - 0x7f61] Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.1 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.3 [0x7f7e7000 - 0x7f7ecfff] Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.0 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.0 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.2 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.2 on IOMMU at a800 IOMMU: Setting identity map for device :02:00.4 [0x7f7e7000 - 0x7f7ecfff] Device 0:02:00.4 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 IOMMU: Setting identity map for device :00:1d.7 [0x7f7ee000 - 0x7f7e] Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 IOMMU: Prepare 0-16MiB unity mapping for LPC IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0xff] Device 0:00:1f.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 PCI-DMA: Intel(R) Virtualization Technology for Directed I/O Device 0:00:00.0 on IOMMU at a800 Device 0:00:01.0 on IOMMU at a800 Device 0:00:02.0 on IOMMU at a800 Device 0:00:03.0 on IOMMU at a800 Device 0:00:04.0 on IOMMU at a800 Device 0:00:05.0 on IOMMU at a800 Device 0:00:06.0 on IOMMU at a800 Device 0:00:07.0 on IOMMU at a800 Device 0:00:08.0 on IOMMU at a800 Device 0:00:09.0 on IOMMU at a800 Device 0:00:0a.0 on IOMMU at a800 Device 0:00:14.0 on IOMMU at a800 Device 0:00:1c.0 on IOMMU at a800 Device 0:00:1c.4 on IOMMU at a800 Device 0:00:1d.0 on IOMMU at a800 Device 0:00:1d.1 on IOMMU at a800 Device 0:00:1d.2 on IOMMU at a800 Device 0:00:1d.3 on IOMMU at a800 Device 0:00:1d.7 on IOMMU at a800 Device 0:00:1e.0 on IOMMU at a800 Device 0:00:1f.0 on IOMMU at a800 Device 0:04:00.0 on IOMMU at a800 Device 0:04:00.1 on IOMMU at a800 Device 0:04:00.2 on IOMMU at a800 Device 0:04:00.3 on IOMMU at a800 Device 0:03:00.0 on IOMMU at a800 Device 0:02:00.0 on IOMMU at a800 Device 0:02:00.2 on IOMMU at a800 Device 0:02:00.4 on IOMMU at a800 Device 0:01:03.0 on IOMMU at a800 Device 0:50:00.0 on IOMMU at ac00 Device 0:50:01.0 on IOMMU at ac00 Device 0:50:02.0 on IOMMU at ac00 Device 0:50:03.0 on IOMMU at ac00 Device 0:50:04.0 on IOMMU at ac00 Device 0:50:05.0 on IOMMU at ac00 Device 0:50:06.0 on IOMMU at ac00 Device 0:50:07.0 on IOMMU at ac00 Device 0:50:08.0 on IOMMU at ac00 Device 0:50:09.0 on IOMMU at ac00 Device 0:50:0a.0 on IOMMU at ac00 Device 0:50:14.0 on IOMMU at a800 Device 0:a0:00.0 on IOMMU at b000 Device 0:a0:01.0 on IOMMU at b000 Device 0:a0:02.0 on IOMMU at b000
Re: hpsa driver bug crack kernel down!
Hi Baoquan, Could you please help to give output of lspci -? Is device hpsa :03:00.0 a legacy PCI device(non-PCIe)? It may have relationship with IOMMU driver. Thanks! Gerry On 2014/4/10 12:03, 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, 2014-04-09 at 16:40 -0700, Davidlohr Bueso wrote: On Wed, 2014-04-09 at 16:10 -0700, James Bottomley wrote: On Wed, 2014-04-09 at 16:08 -0700, James Bottomley wrote: [+linux-scsi] On Wed, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote: On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote: Hi, The kernel is 3.14.0+ which is pulled just now. Cc'ing more people. While the hpsa driver appears to be involved in some way, I'm sure if this is a related issue, but as of today's pull I'm getting another problem that causes my DL980 not to come up. *Massive* amounts of: DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 602 dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr 7f61e000 Then: hpsa :03:00.0: Controller lockup detected: 0x ... Workqueue: events hpsa_monitor_ctlr_worker [hpsa] ... Screenshot of the actual LOCKUP: http://stgolabs.net/hpsa-hard-lockup-3.14+.png While I haven't bisected, things worked fine until at least until commit 39de65aa2c3e (April 2nd). Any ideas? Well, it's either a DMA remapping issue or a hpsa one. Your assertion that everything worked fine until 39de65aa2c3e would tend to vindicate hpsa, Hmm here you mean DMA, right? No, it vindicates the hpsa changes ... they don't seem to be causing problems until something goes wrong with dma remapping. because all the hpsa changes went in before that under Missing crucial info: commit 1a0b6abaea78f73d9bc0a2f6df2d9e4c917cade1 Merge: 3e75c6d b2bff6c Author: Linus Torvalds torva...@linux-foundation.org Date: Tue Apr 1 18:49:04 2014 -0700 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi can you revalidate that this commit works OK just to make sure? Ok so I don't see those DMA messages and system starts just fine. I'm thinking perhaps something broke after the IO mmu stuff in commit 3f583bc21977a608908b83d03ee2250426a5695c... could this be indirectly causing the CPU stalls and just blame hpsa in the path as a side effect? /me goes out to try the commit. That's my guess. The DMAR messages are DMA remapping issues caused in the IOMMU. If I had to guess, I'd say the DMAR fault message is indicating the IOMMU is calling for a mapping address before it can satisfy the driver read request, which is causing the hang apparently in the hpsa driver. I've added linux-pci to the cc; I think they deal with iommu issues on x86. So that merge commit appears to be the culprit, I see both the DMA messages and the lockup blaming hpsa... My understanding so far (please correct me if I'm wrong): 39de65aa2c3e OK (Merge branch 'i2c/for-next') 1a0b6abaea78 OK (Merge tag 'scsi-misc') 3f583bc21977 BAD (Merge tag 'iommu-updates-v3.15') -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3, part1 03/10] PCI: Convert alloc_pci_dev(void) to pci_alloc_dev(bus) instead
On Thu 06 Jun 2013 04:07:18 AM CST, Bjorn Helgaas wrote: On Sat, May 25, 2013 at 7:48 AM, Jiang Liu liu...@gmail.com wrote: From: Gu Zheng guz.f...@cn.fujitsu.com Use the new pci_alloc_dev(bus) to replace the existing using of alloc_pci_dev(void). ... diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 26df9c8..d5d18a0 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1130,6 +1130,7 @@ static void pci_release_dev(struct device *dev) struct pci_dev *pci_dev; pci_dev = to_pci_dev(dev); + pci_bus_put(pci_dev-bus); pci_release_capabilities(pci_dev); pci_release_of_node(pci_dev); kfree(pci_dev); I think we should drop the pci_bus reference *last* (before the kfree). Otherwise, we have to audit pci_release_capabilities() and pci_release_of_node() to make sure they don't use pci_dev-bus. I made this change on my branch already; just let me know if you object. Hi Bjorn, You are right, thanks for fixing it. Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3, part1 03/10] PCI: Convert alloc_pci_dev(void) to pci_alloc_dev(bus) instead
From: Gu Zheng guz.f...@cn.fujitsu.com
Use the new pci_alloc_dev(bus) to replace the existing using of
alloc_pci_dev(void).
v2:
Follow Bjorn's correction to move pci_bus_put() to
pci_release_dev() instead.
v3:
release reference to bus on error recovery path
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
Signed-off-by: Jiang Liu jiang@huawei.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: David S. Miller da...@davemloft.net
Cc: David Airlie airl...@linux.ie
Cc: Neela Syam Kolli megaraidli...@lsi.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Yinghai Lu ying...@kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
---
arch/powerpc/kernel/pci_of_scan.c | 3 +--
arch/sparc/kernel/pci.c | 3 +--
drivers/char/agp/alpha-agp.c | 2 +-
drivers/char/agp/parisc-agp.c | 2 +-
drivers/pci/iov.c | 8 +---
drivers/pci/probe.c | 5 +++--
drivers/scsi/megaraid.c | 2 +-
7 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index d2d407d..6b0ba58 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -128,7 +128,7 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
const char *type;
struct pci_slot *slot;
- dev = alloc_pci_dev();
+ dev = pci_alloc_dev(bus);
if (!dev)
return NULL;
type = of_get_property(node, device_type, NULL);
@@ -137,7 +137,6 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
pr_debug(create device, devfn: %x, type: %s\n, devfn, type);
- dev-bus = bus;
dev-dev.of_node = of_node_get(node);
dev-dev.parent = bus-bridge;
dev-dev.bus = pci_bus_type;
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 972892a..b16f624 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -254,7 +254,7 @@ static struct pci_dev *of_create_pci_dev(struct
pci_pbm_info *pbm,
const char *type;
u32 class;
- dev = alloc_pci_dev();
+ dev = pci_alloc_dev(bus);
if (!dev)
return NULL;
@@ -281,7 +281,6 @@ static struct pci_dev *of_create_pci_dev(struct
pci_pbm_info *pbm,
printk(create device, devfn: %x, type: %s\n,
devfn, type);
- dev-bus = bus;
dev-sysdata = node;
dev-dev.parent = bus-bridge;
dev-dev.bus = pci_bus_type;
diff --git a/drivers/char/agp/alpha-agp.c b/drivers/char/agp/alpha-agp.c
index dd84af4..199b8e9 100644
--- a/drivers/char/agp/alpha-agp.c
+++ b/drivers/char/agp/alpha-agp.c
@@ -174,7 +174,7 @@ alpha_core_agp_setup(void)
/*
* Build a fake pci_dev struct
*/
- pdev = alloc_pci_dev();
+ pdev = pci_alloc_dev(NULL);
if (!pdev)
return -ENOMEM;
pdev-vendor = 0x;
diff --git a/drivers/char/agp/parisc-agp.c b/drivers/char/agp/parisc-agp.c
index 94821ab..bf5d247 100644
--- a/drivers/char/agp/parisc-agp.c
+++ b/drivers/char/agp/parisc-agp.c
@@ -333,7 +333,7 @@ parisc_agp_setup(void __iomem *ioc_hpa, void __iomem
*lba_hpa)
struct agp_bridge_data *bridge;
int error = 0;
- fake_bridge_dev = alloc_pci_dev();
+ fake_bridge_dev = pci_alloc_dev(NULL);
if (!fake_bridge_dev) {
error = -ENOMEM;
goto fail;
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index c93071d..2652ca0 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -75,18 +75,20 @@ static int virtfn_add(struct pci_dev *dev, int id, int
reset)
struct pci_dev *virtfn;
struct resource *res;
struct pci_sriov *iov = dev-sriov;
+ struct pci_bus *bus;
- virtfn = alloc_pci_dev();
+ virtfn = pci_alloc_dev(NULL);
if (!virtfn)
return -ENOMEM;
mutex_lock(iov-dev-sriov-lock);
- virtfn-bus = virtfn_add_bus(dev-bus, virtfn_bus(dev, id));
- if (!virtfn-bus) {
+ bus = virtfn_add_bus(dev-bus, virtfn_bus(dev, id));
+ if (!bus) {
kfree(virtfn);
mutex_unlock(iov-dev-sriov-lock);
return -ENOMEM;
}
+ virtfn-bus = pci_bus_get(bus);
virtfn-devfn = virtfn_devfn(dev, id);
virtfn-vendor = dev-vendor;
pci_read_config_word(dev, iov-pos + PCI_SRIOV_VF_DID, virtfn-device);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 26df9c8..d5d18a0 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1130,6 +1130,7 @@ static void pci_release_dev(struct device *dev)
struct pci_dev *pci_dev;
pci_dev
[PATCH v2, part 1 3/9] PCI: Convert alloc_pci_dev(void) to pci_alloc_dev(bus) instead
From: Gu Zheng guz.f...@cn.fujitsu.com
marker to prevent gmail from removing below From:
From: Gu Zheng guz.f...@cn.fujitsu.com
Use the new pci_alloc_dev(bus) to replace the existing using of
alloc_pci_dev(void).
v2:
Follow Bjorn's correction to move pci_bus_put() to
pci_release_dev() instead.
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: David S. Miller da...@davemloft.net
Cc: David Airlie airl...@linux.ie
Cc: Neela Syam Kolli megaraidli...@lsi.com
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Yinghai Lu ying...@kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Jiang Liu jiang@huawei.com
---
arch/powerpc/kernel/pci_of_scan.c | 3 +--
arch/sparc/kernel/pci.c | 3 +--
drivers/char/agp/alpha-agp.c | 2 +-
drivers/char/agp/parisc-agp.c | 2 +-
drivers/pci/iov.c | 8 +---
drivers/pci/probe.c | 4 ++--
drivers/scsi/megaraid.c | 2 +-
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index 2a67e9b..24d01c4 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -128,7 +128,7 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
const char *type;
struct pci_slot *slot;
- dev = alloc_pci_dev();
+ dev = pci_alloc_dev(bus);
if (!dev)
return NULL;
type = of_get_property(node, device_type, NULL);
@@ -137,7 +137,6 @@ struct pci_dev *of_create_pci_dev(struct device_node *node,
pr_debug(create device, devfn: %x, type: %s\n, devfn, type);
- dev-bus = bus;
dev-dev.of_node = of_node_get(node);
dev-dev.parent = bus-bridge;
dev-dev.bus = pci_bus_type;
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index baf4366..e5871fb 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -254,7 +254,7 @@ static struct pci_dev *of_create_pci_dev(struct
pci_pbm_info *pbm,
const char *type;
u32 class;
- dev = alloc_pci_dev();
+ dev = pci_alloc_dev(bus);
if (!dev)
return NULL;
@@ -281,7 +281,6 @@ static struct pci_dev *of_create_pci_dev(struct
pci_pbm_info *pbm,
printk(create device, devfn: %x, type: %s\n,
devfn, type);
- dev-bus = bus;
dev-sysdata = node;
dev-dev.parent = bus-bridge;
dev-dev.bus = pci_bus_type;
diff --git a/drivers/char/agp/alpha-agp.c b/drivers/char/agp/alpha-agp.c
index dd84af4..199b8e9 100644
--- a/drivers/char/agp/alpha-agp.c
+++ b/drivers/char/agp/alpha-agp.c
@@ -174,7 +174,7 @@ alpha_core_agp_setup(void)
/*
* Build a fake pci_dev struct
*/
- pdev = alloc_pci_dev();
+ pdev = pci_alloc_dev(NULL);
if (!pdev)
return -ENOMEM;
pdev-vendor = 0x;
diff --git a/drivers/char/agp/parisc-agp.c b/drivers/char/agp/parisc-agp.c
index 94821ab..bf5d247 100644
--- a/drivers/char/agp/parisc-agp.c
+++ b/drivers/char/agp/parisc-agp.c
@@ -333,7 +333,7 @@ parisc_agp_setup(void __iomem *ioc_hpa, void __iomem
*lba_hpa)
struct agp_bridge_data *bridge;
int error = 0;
- fake_bridge_dev = alloc_pci_dev();
+ fake_bridge_dev = pci_alloc_dev(NULL);
if (!fake_bridge_dev) {
error = -ENOMEM;
goto fail;
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index ee599f2..24134cd 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -75,18 +75,20 @@ static int virtfn_add(struct pci_dev *dev, int id, int
reset)
struct pci_dev *virtfn;
struct resource *res;
struct pci_sriov *iov = dev-sriov;
+ struct pci_bus *bus;
- virtfn = alloc_pci_dev();
+ virtfn = pci_alloc_dev(NULL);
if (!virtfn)
return -ENOMEM;
mutex_lock(iov-dev-sriov-lock);
- virtfn-bus = virtfn_add_bus(dev-bus, virtfn_bus(dev, id));
- if (!virtfn-bus) {
+ bus = virtfn_add_bus(dev-bus, virtfn_bus(dev, id));
+ if (!bus) {
kfree(virtfn);
mutex_unlock(iov-dev-sriov-lock);
return -ENOMEM;
}
+ virtfn-bus = pci_bus_get(bus);
virtfn-devfn = virtfn_devfn(dev, id);
virtfn-vendor = dev-vendor;
pci_read_config_word(dev, iov-pos + PCI_SRIOV_VF_DID, virtfn-device);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 4f0bc0a..bc075a3 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1131,6 +1131,7 @@ static void pci_release_dev(struct device *dev)
struct pci_dev
Re: Fail to probe qla2xxx fiber channel card while doing pci hotplug
Hi Bjorn, We will try to work out a patch for this issue, won't silently ignore it. We also found another issue related to ARI. The steps to reproduce the bug is: 1) Boot with a ARI-capable device connected to ARI-capable port, so ARI will be enabled. 2) Hot-remove the ARI-capable device. 3) Hot-add another non-ARI-capable multifunction device into the same slot. 4) Now only the function 0 of the hot-added device could be enumerated. I think Yijing is going to work on the above two issues. Thanks! Gerry On 09/20/2012 11:46 PM, Bjorn Helgaas wrote: tried any. Does pci=pcie_bus_safe make any difference? -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fail to probe qla2xxx fiber channel card while doing pci hotplug
On 09/19/2012 09:39 PM, Bjorn Helgaas wrote: On Tue, Sep 18, 2012 at 7:50 PM, Yijing Wang wangyij...@huawei.com wrote: On 2012/9/19 1:54, Bjorn Helgaas wrote: On Mon, Sep 17, 2012 at 6:06 AM, Yijing Wang wangyij...@huawei.com wrote: On 2012/9/16 11:30, Bjorn Helgaas wrote: On Sat, Sep 15, 2012 at 4:22 AM, Yijing Wang wangyij...@huawei.com wrote: Hi all, I encountered a very strange problem when I hot plug a fiber channel card(using qla2xxx driver). I did the hotplug in arch x86 machine, using pciehp driver for hotplug, this platform supports pci hot-plug triggering from both sysfs and attention button. If a hot-plug slot is empty when system boot-up, then hotplug FC card in this slot is ok. If a hot-plug slot has been embeded a FC card when system boot-up, hot-remove this card is ok, but hot-add this card will fail. I used #modprobe qla2xxx ql2xextended_error_logging=0x7fff to get all probe info. As bellow: Can anyone give me any suggestion for this problem? It sounds like you did this: 1) Power down system 2) Remove FC card from slot 3) Boot system 4) Hot-add FC card 5) Load qla2xxx driver 6) qla2xxx driver claims FC card 7) FC card works correctly 8) Power down system 9) Install FC card in slot 10) Boot system 11) Load qla2xxx driver 12) qla2xxx driver claims FC card 13) FC card works correctly I rmmod qla2xxx driver here and modprobe qla2xxx ql2xextended_error_logging=0x1e40 again for get errors info Also I modprobe pciehp pciehp_debug=1 for getting debug info 14) Hot-remove card 15) Hot-add card 16) qla2xxx driver claims FC card 17) FC card does not work and I assume the dmesg log you included is just from steps 15 and 16 (correct me if I'm wrong). It would be useful to see the entire log showing all these events so we can compare the working cases with the non-working one. If you use the pciehp_debug module parameter, we should also see some pciehp events that would help me understand that driver. Hi Bjorn, Thanks for your comments very much! My steps: 1) power down system 2) Install FC card in slot 3) Boot system 4) Load qla2xxx driver 5) qla2xxx driver claims FC card 6) FC card works correctly(at least probe return ok, I don't know qla2xxx driver much..) 7) rmmod qla2xxx 8) modprobe qla2xxx ql2xextended_error_logging=0x1e40(for get errors info) 9) modprobe pciehp pciehp_debug=1 10) Hot-remove card 11) Hot-add card 12) qla2xxx driver claims FC card fail(probe return fail, setup chip fail) --so this is failed situation-- --continue to hot-add fc card into empty slot(also support pci hp) 13) Install FC card in empty slot 14) Hot-add card 15) qla2xxx driver claims FC card ok (probe return ok) btw: If fc card firmware version 4.03, everything is ok (hot-plug in any slots(empty or not)) fc card firmware version is 4.04 or 5.04 , situation as same as 1)---12) Thanks. The FW change is a good clue. If everything works with version 4.03, but it doesn't work with version 4.04, it's likely to be a FW problem, not a Linux PCI core problem. Here's what I see from your logs. In slot 4 (bus 08), the card was present before boot, you removed it, re-added it, and it failed after being re-added. Slot 3 (bus 06) was empty at boot, you hot-added a card, and it worked. Here are the resources available on those two buses and the boot-time config of the first device in slot 4: pci :00:07.0: PCI bridge to [bus 06-07] pci :00:07.0: bridge window [io 0xc000-0xcfff] pci :00:07.0: bridge window [mem 0xf900-0xf9ff] pci :00:07.0: bridge window [mem 0xf100-0xf1ff 64bit pref] pci :00:09.0: PCI bridge to [bus 08-09] pci :00:09.0: bridge window [io 0xb000-0xbfff] pci :00:09.0: bridge window [mem 0xf800-0xf8ff] pci :00:09.0: bridge window [mem 0xf000-0xf0ff 64bit pref] pci :08:00.0: [1077:2532] type 00 class 0x0c0400 pci :08:00.0: reg 10: [io 0xb100-0xb1ff] pci :08:00.0: reg 14: [mem 0xf8084000-0xf8087fff 64bit] pci :08:00.0: reg 30: [mem 0xf804-0xf807 pref] After you remove and re-add the card in slot 4, it starts with uninitialized BARs as expected, then we assign resources to it. It's sort of interesting that the BIOS had originally put the ROM (reg 30) in the non-prefetchable window, while after the hot-add, Linux places it in the prefetchable window. Either should work, and in fact the card you added in slot 3 *does* work with its ROM in the prefetchable window. pci :08:00.0: [1077:2532] type 00 class 0x0c0400 pci :08:00.0: reg 10: [io 0x-0x00ff] pci :08:00.0: reg 14: [mem 0x-0x3fff 64bit] pci :08:00.0: reg 30: [mem 0x-0x0003
