[PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Helge Deller]

According to the found documentation, data cache flushes and sync
instructions are needed on the PCX-U+ (PA8200, e.g. C200/C240)
platforms, while PCX-W (PA8500, e.g. C360) platforms don't need those
syncs when changing the IO PDIR data structures.

We have no documentation for PCX-W+ (PA8600) and PCX-W2 (PA8700) CPUs,
but Carlo Pisani reported that his C3600 machine (PCX-W+) fails when the
fdc instructions were removed. His firmware didn't set the NIOP bit, so
we assume it's a firmware bug since other C3750 machines had the bit
set.

Going forward, let's not replace the fdc and sync assembler instructions
by NOPS if:
a) the NP iopdir_fdc bit was set by firmware, or
b) we find a PCX-U or PCX-U+ (PA8000, PA8200) CPU, or
c) we find a PCX-W+ (PA8600) CPU.

This fixes the HPMC crashes on a C240 and C36XX machines. For other
machines we rely on the firmware to set the bit when needed.

In case one finds HPMC issues, people could try to boot their machines
with the "no-alternatives" kernel option to turn off any alternative
patching.

Reported-by: Sven Schnelle <svens@stackframe.org>
Reported-by: Carlo Pisani <carlojpisani@gmail.com>
Tested-by: Sven Schnelle <svens@stackframe.org>
Fixes: 3847dab77421 ("parisc: Add alternative coding infrastructure")
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 5.0+

diff --git a/arch/parisc/kernel/alternative.c b/arch/parisc/kernel/alternative.c
index bf2274e01a96..1ac3b4ac73c0 100644
--- a/arch/parisc/kernel/alternative.c
+++ b/arch/parisc/kernel/alternative.c
@@ -56,7 +56,9 @@ void __init_or_module apply_alternatives(struct alt_instr *start,
 		 * time IO-PDIR is changed in Ike/Astro.
 		 */
 		if ((cond & ALT_COND_NO_IOC_FDC) &&
-			(boot_cpu_data.pdc.capabilities & PDC_MODEL_IOPDIR_FDC))
+			((boot_cpu_data.cpu_type < pcxw) ||
+			 (boot_cpu_data.cpu_type == pcxw_) ||
+			 (boot_cpu_data.pdc.capabilities & PDC_MODEL_IOPDIR_FDC)))
 			continue;

 		/* Want to replace pdtlb by a pdtlb,l instruction? */

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Carlo Pisani]

isn't possible to burn the flash in the C3600 machine with the
firmware of C3750?
these two look similar.

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-05-27 3:20 p.m., Helge Deller wrote:
> This fixes the HPMC crashes on a C240 and C36XX machines. For other
> machines we rely on the firmware to set the bit when needed.
>
> In case one finds HPMC issues, people could try to boot their machines
> with the "no-alternatives" kernel option to turn off any alternative
> patching.
Just wondering about soft fail versus hard fail.  In lba_pci.c, we have soft fail by default:

#if defined(ENABLE_HARDFAIL)
        WRITE_REG32(stat | HF_ENABLE, d->hba.base_addr + LBA_STAT_CTL);
#else
        WRITE_REG32(stat & ~HF_ENABLE, d->hba.base_addr + LBA_STAT_CTL);
#endif

However, in sba_iommu.c, we crash on rope errors:

                        /*
                        ** Make sure the box crashes on rope errors.
                        */
                        WRITE_REG(HF_ENABLE, ioc_hpa + ROPE0_CTL + j);

I suspect Carlo's C3600 HPMC issues must be from rope issue.  Should rope errors be soft
as well?

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Helge Deller]

On 27.05.19 21:41, John David Anglin wrote:
> On 2019-05-27 3:20 p.m., Helge Deller wrote:
>> This fixes the HPMC crashes on a C240 and C36XX machines. For other
>> machines we rely on the firmware to set the bit when needed.
>>
>> In case one finds HPMC issues, people could try to boot their machines
>> with the "no-alternatives" kernel option to turn off any alternative
>> patching.
> Just wondering about soft fail versus hard fail.  In lba_pci.c, we have soft fail by default:
>
> #if defined(ENABLE_HARDFAIL)
>         WRITE_REG32(stat | HF_ENABLE, d->hba.base_addr + LBA_STAT_CTL);
> #else
>         WRITE_REG32(stat & ~HF_ENABLE, d->hba.base_addr + LBA_STAT_CTL);
> #endif
>
> However, in sba_iommu.c, we crash on rope errors:
>
>                         /*
>                         ** Make sure the box crashes on rope errors.
>                         */
>                         WRITE_REG(HF_ENABLE, ioc_hpa + ROPE0_CTL + j);
>
> I suspect Carlo's C3600 HPMC issues must be from rope issue.> Should rope errors be soft as well?

Don't know, but seems logical.
If so, does it then makes sense to a kernel parameter (e.g. "hardfail") too ?

Helge

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-05-27 3:35 p.m., Carlo Pisani wrote:
> isn't possible to burn the flash in the C3600 machine with the
> firmware of C3750?
> these two look similar.
>
Highly doubtful.  Don't know where you would find firmware for either.
Firmware needs to put on bootable device (tape drive!!!):
https://www.manualslib.com/manual/436656/Hp-Visualize-B1000-Workstation.html?page=187#manual

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Sven Schnelle]

Hi,

On Mon, May 27, 2019 at 09:35:54PM +0200, Carlo Pisani wrote:
> isn't possible to burn the flash in the C3600 machine with the
> firmware of C3750?
> these two look similar.

I have a firmware image here that has '9000/785 B,C,J Workstation PDC', built
08/10/1999 in the header. In that firmware, the PDC_MODEL capabilities handler
is pretty simple and static:

  _pdc_model_capabilities
   fffffff0f002588c 081e0601             add                sp, r0, r1
   fffffff0f0025890 73c23fe1             std                rp, -0x10(sp)
   fffffff0f0025894 73c300c8             std,ma             r3, 0x60(sp)
   fffffff0f0025898 73c43f51             std                r4, -0x58(sp)
   fffffff0f002589c 0fc112d1             std                r1, -0x10(sp)
   fffffff0f00258a0 b4210020             addi               0x10, r1, r1
   fffffff0f00258a4 37430000             copy               r26, r3		; load pointer for capabilites word
   fffffff0f00258a8 20800000             ldil               0x0, r4
   fffffff0f00258ac 20200000             ldil               0x0, r1
   fffffff0f00258b0 34840006             ldo                0x3( r4), r4	; OS32|OS64
   fffffff0f00258b4 34210000             copy               r1, r1
   fffffff0f00258b8 f0810c00             depd               r1, 0x1f, 0x20, r4
   fffffff0f00258bc 0c6412c0             std                r4, 0x0(r3)			; store value
   fffffff0f00258c0 341c0000             copy               r0, r28
   fffffff0f00258c4 53c23f21             ldd                -0x70(sp), rp
   fffffff0f00258c8 53c43f51             ldd                -0x58(sp), r4
   fffffff0f00258cc e840d000             bv                 ( rp)
   fffffff0f00258d0 53c33f4d             ldd,mb             -0x60(sp), r3

So at least this version has no clue about the NP bit (or leaves it intentionally
at zero, which would mean it's independent of CPU/Chipset revisions) - it would
be interesting how this function looks in newer firmware revisions. Anyone has
a Firmware update file for any of the B/C/J Class systems flying around? I'll
take it regardless of the version.

Sven

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Carlo Pisani]

> If so, does it then makes sense to a kernel parameter (e.g. "hardfail") too ?

here I am using a Kconfig line to choose the pci-failmode that has to
be compiled when I configure the kernel. It's comfortable.

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Sven Schnelle]

Hi Dave,

On Mon, May 27, 2019 at 04:13:02PM -0400, John David Anglin wrote:
> On 2019-05-27 3:35 p.m., Carlo Pisani wrote:
> > isn't possible to burn the flash in the C3600 machine with the
> > firmware of C3750?
> > these two look similar.
> >
> Highly doubtful.  Don't know where you would find firmware for either.

openpa.net has some, and i also extracted a few versions from HP-UX ISOs.

> Firmware needs to put on bootable device (tape drive!!!):
> https://www.manualslib.com/manual/436656/Hp-Visualize-B1000-Workstation.html?page=187#manual

I upgraded my C240 during the weekend with the latest PDC firmware via LAN. I think
this also worked on 712 (it's been ~15 years when i did that, so not 100% sure).
The firmware files are LIF images, so it's likely that updating via 'boot lan'
works on all machines.

On my C240 i had to set the minimum good memory size, if it is at zero the Firmware
update complains about not enough memory.

Regards
Sven

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-05-27 4:11 p.m., Helge Deller wrote:
> On 27.05.19 21:41, John David Anglin wrote:
>> On 2019-05-27 3:20 p.m., Helge Deller wrote:
>>> This fixes the HPMC crashes on a C240 and C36XX machines. For other
>>> machines we rely on the firmware to set the bit when needed.
>>>
>>> In case one finds HPMC issues, people could try to boot their machines
>>> with the "no-alternatives" kernel option to turn off any alternative
>>> patching.
>> Just wondering about soft fail versus hard fail.  In lba_pci.c, we have soft fail by default:
>>
>> #if defined(ENABLE_HARDFAIL)
>>         WRITE_REG32(stat | HF_ENABLE, d->hba.base_addr + LBA_STAT_CTL);
>> #else
>>         WRITE_REG32(stat & ~HF_ENABLE, d->hba.base_addr + LBA_STAT_CTL);
>> #endif
>>
>> However, in sba_iommu.c, we crash on rope errors:
>>
>>                         /*
>>                         ** Make sure the box crashes on rope errors.
>>                         */
>>                         WRITE_REG(HF_ENABLE, ioc_hpa + ROPE0_CTL + j);
>>
>> I suspect Carlo's C3600 HPMC issues must be from rope issue.> Should rope errors be soft as well?
> Don't know, but seems logical.
> If so, does it then makes sense to a kernel parameter (e.g. "hardfail") too ?
Carlo said that c3600 hpmc'd with sba_iommu.c patched to soft fail.  Maybe pdc overrides?  Anyway, I don't
think it's important.

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-05-27 4:22 p.m., Sven Schnelle wrote:
> openpa.net has some, and i also extracted a few versions from HP-UX ISOs.
It would be good to collect in ftp.parisc-linux.org.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Sven Schnelle]

On Mon, May 27, 2019 at 10:15:38PM +0200, Sven Schnelle wrote:
> Hi,
> 
> On Mon, May 27, 2019 at 09:35:54PM +0200, Carlo Pisani wrote:
> > isn't possible to burn the flash in the C3600 machine with the
> > firmware of C3750?
> > these two look similar.
> 
> I have a firmware image here that has '9000/785 B,C,J Workstation PDC', built
> 08/10/1999 in the header. In that firmware, the PDC_MODEL capabilities handler
> is pretty simple and static:
> 
>   _pdc_model_capabilities
>    fffffff0f002588c 081e0601             add                sp, r0, r1
>    fffffff0f0025890 73c23fe1             std                rp, -0x10(sp)
>    fffffff0f0025894 73c300c8             std,ma             r3, 0x60(sp)
>    fffffff0f0025898 73c43f51             std                r4, -0x58(sp)
>    fffffff0f002589c 0fc112d1             std                r1, -0x10(sp)
>    fffffff0f00258a0 b4210020             addi               0x10, r1, r1
>    fffffff0f00258a4 37430000             copy               r26, r3		; load pointer for capabilites word
>    fffffff0f00258a8 20800000             ldil               0x0, r4
>    fffffff0f00258ac 20200000             ldil               0x0, r1
>    fffffff0f00258b0 34840006             ldo                0x3( r4), r4	; OS32|OS64
>    fffffff0f00258b4 34210000             copy               r1, r1
>    fffffff0f00258b8 f0810c00             depd               r1, 0x1f, 0x20, r4
>    fffffff0f00258bc 0c6412c0             std                r4, 0x0(r3)			; store value
>    fffffff0f00258c0 341c0000             copy               r0, r28
>    fffffff0f00258c4 53c23f21             ldd                -0x70(sp), rp
>    fffffff0f00258c8 53c43f51             ldd                -0x58(sp), r4
>    fffffff0f00258cc e840d000             bv                 ( rp)
>    fffffff0f00258d0 53c33f4d             ldd,mb             -0x60(sp), r3
> 
> So at least this version has no clue about the NP bit (or leaves it intentionally
> at zero, which would mean it's independent of CPU/Chipset revisions) - it would
> be interesting how this function looks in newer firmware revisions. Anyone has
> a Firmware update file for any of the B/C/J Class systems flying around? I'll
> take it regardless of the version.

This is how the PDC_MODEL capabilities function looks in Version 2.0 (My former post
was from Version 3.1)

                         *******************************************************
                         *                      FUNCTION                       *
                         *******************************************************
                         undefined pdc_model_capabilities()
           undefined       r28:1                      <RETURN>
           undefined8      Stack[0x70]:8              local_70                           XREF[1]:   fffffff0f0045c
           undefined8      Stack[-0x10]:8             local_res10                        XREF[1]:   fffffff0f0045c
  pdc_model_capabilities
   fffffff0f0045c94 081e0601             add                sp, r0, r1                                                        XREF[1]:   fffffff0f0045884(c)
   fffffff0f0045c98 73c23fe1             std                rp, -0x10(sp)=>local_res10
   fffffff0f0045c9c 73c300e8             std,ma             r3, 0x70(sp)=>local_70
   fffffff0f0045ca0 73c43f31             std                r4, -0x68(sp)
   fffffff0f0045ca4 73c53f41             std                r5, -0x60(sp)
   fffffff0f0045ca8 73c63f51             std                r6, -0x58(sp)
   fffffff0f0045cac 0fc112d1             std                r1, -0x10(sp)
   fffffff0f0045cb0 b4210040             addi               0x20, r1, r1
   fffffff0f0045cb4 37430000             copy               r26, r3
   fffffff0f0045cb8 20800000             ldil               0x0, r4
   fffffff0f0045cbc 20200000             ldil               0x0, r1
   fffffff0f0045cc0 34840006             ldo                0x3( r4), r4      	      	  ; OS32|OS64                                                                                                         
   fffffff0f0045cc4 34210000             copy               r1, r1
   fffffff0f0045cc8 f0810c00             depd               r1, 0x1f, 0x20, r4
   fffffff0f0045ccc 20a00000             ldil               0x0, r5
   fffffff0f0045cd0 20200000             ldil               0x0, r1
   fffffff0f0045cd4 34a50008             ldo                0x4( r5), r5      	      	  ; NP                                                                                                                
   fffffff0f0045cd8 34210000             copy               r1, r1
   fffffff0f0045cdc f0a10c00             depd               r1, 0x1f, 0x20, r5
   fffffff0f0045ce0 08a40244             or                 r4, r5, r4	      	      	  ; NP|OS32|OS64                                                                                                      
   fffffff0f0045ce4 0c6412c0             std                r4, 0x0(r3)
   fffffff0f0045ce8 341c0000             copy               r0, r28
   fffffff0f0045cec 53c23f01             ldd                -0x80(sp), rp
   fffffff0f0045cf0 53c63f51             ldd                -0x58(sp), r6
   fffffff0f0045cf4 53c53f41             ldd                -0x60(sp), r5
   fffffff0f0045cf8 53c43f31             ldd                -0x68(sp), r4
   fffffff0f0045cfc e840d000             bv                 ( rp)
   fffffff0f0045d00 53c33f2d             _ldd,mb            -0x70(sp), r3


This is interesting, because:

Version 2.0: always sets NP
Version 3.1 and 5.0 always clears that bit

I think all of these versions support B/C/J class systems, but i haven't
tried flashing the C3750 ROM to my J5000. Have to think about a way to recover
if it goes wrong and bricks my J5000.

FWIW, i hacked up a small driver to read the firmware, i'm attaching it to this
Mail. Would be nice if some people could try reading the firmware from their PA-RISC
system so we can collect and archive them. Note that it HPMC's in 32 Bit Mode,
but it worked in 64 Bit mode on my C3750/J5000.

The driver exposes a /sys/firmware/pdcrom file which can be read like every other
file, so copying the firmware should be easy.

Regards
Sven

From 8011a512583926f104431a3c52b9ea5507493b22 Mon Sep 17 00:00:00 2001
From: Sven Schnelle <svens@stackframe.org>
Date: Tue, 28 May 2019 13:03:01 +0200
Subject: [PATCH] parisc: quick hack to read the firmware ROM

Signed-off-by: Sven Schnelle <svens@stackframe.org>
---
 drivers/parisc/Kconfig        | 13 ++++++
 drivers/parisc/Makefile       |  1 +
 drivers/parisc/pdc_firmware.c | 83 +++++++++++++++++++++++++++++++++++
 3 files changed, 97 insertions(+)
 create mode 100644 drivers/parisc/pdc_firmware.c

diff --git a/drivers/parisc/Kconfig b/drivers/parisc/Kconfig
index 74e119adca01..37a077eb2a29 100644
--- a/drivers/parisc/Kconfig
+++ b/drivers/parisc/Kconfig
@@ -155,4 +155,17 @@ config PDC_STABLE
 	  To compile this driver as a module, choose M here.
 	  The module will be called pdc_stable.
 
+config PDC_FIRMWARE
+	tristate "PDC Firmware sysfs support"
+	depends on SYSFS
+	default n
+	help
+	  Say Y here if you want to have the kernel expose a file in sysfs
+	  that contains the content of the PDC ROM.
+
+	  If unusre, say N.
+
+	  To compile this driver as a module, choose M here.
+	  The module will be called pdc_firmware.
+
 endmenu
diff --git a/drivers/parisc/Makefile b/drivers/parisc/Makefile
index 99fa6a89e0b9..a3acda40ca78 100644
--- a/drivers/parisc/Makefile
+++ b/drivers/parisc/Makefile
@@ -21,5 +21,6 @@ obj-$(CONFIG_EISA)		+= eisa.o eisa_enumerator.o eisa_eeprom.o
 obj-$(CONFIG_SUPERIO)		+= superio.o
 obj-$(CONFIG_CHASSIS_LCD_LED)	+= led.o
 obj-$(CONFIG_PDC_STABLE)	+= pdc_stable.o
+obj-$(CONFIG_PDC_FIRMWARE)	+= pdc_firmware.o
 obj-y				+= power.o
 
diff --git a/drivers/parisc/pdc_firmware.c b/drivers/parisc/pdc_firmware.c
new file mode 100644
index 000000000000..b6ec76e44c34
--- /dev/null
+++ b/drivers/parisc/pdc_firmware.c
@@ -0,0 +1,83 @@
+#include <linux/module.h>
+#include <linux/printk.h>
+#include <linux/sysfs.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+
+static struct bin_attribute *pdc_firmware_attr;
+
+static ssize_t pdc_firmware_read_rom(struct file *filp, struct kobject *kobj,
+				     struct bin_attribute *attr, char *buf,
+				     loff_t off, size_t count)
+{
+	int size = attr->size;
+
+	if (off >= size)
+		count = 0;
+	else {
+		if (off + count > size)
+			count = size - off;
+
+		memcpy_fromio(buf, attr->private + off, count);
+	}
+	return count;
+}
+
+static int __init pdc_firmware_register_sysfs(void)
+{
+	struct bin_attribute *attr;
+	int size, err = -ENOMEM;
+
+	attr = kzalloc(sizeof(*attr), 0);
+	if (!attr)
+		return -ENOMEM;
+
+	size = 1048576; // FIXME
+
+	sysfs_bin_attr_init(attr);
+
+	attr->size = size;
+	attr->attr.name = "pdcrom";
+	attr->attr.mode = S_IRUSR;
+	attr->read = pdc_firmware_read_rom;
+#ifdef CONFIG_64BIT
+	attr->private = ioremap(0xfffffff0f0000000, size);
+#else
+	attr->private = ioremap(0xf0000000, size);
+#endif
+	if (!attr->private)
+		goto err_attr;
+
+	err = sysfs_create_bin_file(firmware_kobj, attr);
+	if (err)
+		goto err_unmap;
+
+	pdc_firmware_attr = attr;
+	return 0;
+
+err_unmap:
+	iounmap(attr->private);
+err_attr:
+	kfree(attr);
+	return err;
+}
+
+static int __init pdc_firmware_init(void)
+{
+	return pdc_firmware_register_sysfs();
+}
+
+static void __exit pdc_firmware_exit(void)
+{
+	struct pdc_firmware_priv *priv = pdc_firmware_attr->private;
+
+	sysfs_remove_bin_file(firmware_kobj, pdc_firmware_attr);
+	iounmap(pdc_firmware_attr->private);
+	kfree(priv);
+	kfree(pdc_firmware_attr);
+}
+
+module_init(pdc_firmware_init);
+module_exit(pdc_firmware_exit);
+MODULE_AUTHOR("Sven Schnelle <svens@stackframe.org>");
+MODULE_LICENSE("GPL");
-- 
2.20.1

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Rolf Eike Beer]

> FWIW, i hacked up a small driver to read the firmware, i'm attaching it 
> to this
> Mail. Would be nice if some people could try reading the firmware from
> their PA-RISC
> system so we can collect and archive them. Note that it HPMC's in 32 
> Bit Mode,
> but it worked in 64 Bit mode on my C3750/J5000.

Nice!

> +static int __init pdc_firmware_register_sysfs(void)
> +{
> +	struct bin_attribute *attr;
> +	int size, err = -ENOMEM;
> +
> +	attr = kzalloc(sizeof(*attr), 0);
> +	if (!attr)
> +		return -ENOMEM;
> +
> +	size = 1048576; // FIXME
> +
> +	sysfs_bin_attr_init(attr);
> +
> +	attr->size = size;
> +	attr->attr.name = "pdcrom";
> +	attr->attr.mode = S_IRUSR;
> +	attr->read = pdc_firmware_read_rom;
> +#ifdef CONFIG_64BIT
> +	attr->private = ioremap(0xfffffff0f0000000, size);
> +#else
> +	attr->private = ioremap(0xf0000000, size);
> +#endif
> +	if (!attr->private)
> +		goto err_attr;
> +
> +	err = sysfs_create_bin_file(firmware_kobj, attr);
> +	if (err)
> +		goto err_unmap;
> +
> +	pdc_firmware_attr = attr;
> +	return 0;
> +
> +err_unmap:
> +	iounmap(attr->private);
> +err_attr:
> +	kfree(attr);
> +	return err;
> +}
> +
> +static int __init pdc_firmware_init(void)
> +{
> +	return pdc_firmware_register_sysfs();
> +}

Any particular reason you are not simply using BIN_ATTR_RO?

Eike

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Helge Deller]

On 28.05.19 14:11, John David Anglin wrote:
> On 2019-05-28 7:06 a.m., Sven Schnelle wrote:
>> This is interesting, because:
>>
>> Version 2.0: always sets NP
>> Version 3.1 and 5.0 always clears that bit
>
> My c3750 prints "Firmware 2.0" and NP is set, but it might also be 3.1?
>
> [    0.000000] Initialized PDC Console for debugging.
> [    0.000000] Determining PDC firmware type: System Map.
> [    0.000000] model 00005dc0 00000481 00000000 00000002 77e45e84 100000f0 00000008 000000b2 000000b2
> [    0.000000] vers  00000301
> [    0.000000] CPUID vers 19 rev 11 (0x0000026b)
> [    0.000000] capabilities 0x7

Same as Dave: My C3700 prints "Firmware 2.0" and NP is set, but it might also be 3.1?
[    0.000000] model 00005dc0 00000481 00000000 00000002 777c3e84 100000f0 00000008 000000b2 000000b2
[    0.000000] vers  00000301
[    0.000000] CPUID vers 19 rev 11 (0x0000026b)
[    0.000000] capabilities 0x7
[    0.000000] model 9000/785/C3700

Helge

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Sven Schnelle]

Hi,

On Tue, May 28, 2019 at 05:11:36PM +0200, Helge Deller wrote:
> >
> > My c3750 prints "Firmware 2.0" and NP is set, but it might also be 3.1?
> >
> > [    0.000000] Initialized PDC Console for debugging.
> > [    0.000000] Determining PDC firmware type: System Map.
> > [    0.000000] model 00005dc0 00000481 00000000 00000002 77e45e84 100000f0 00000008 000000b2 000000b2
> > [    0.000000] vers  00000301
> > [    0.000000] CPUID vers 19 rev 11 (0x0000026b)
> > [    0.000000] capabilities 0x7
> 
> Same as Dave: My C3700 prints "Firmware 2.0" and NP is set, but it might also be 3.1?
> [    0.000000] model 00005dc0 00000481 00000000 00000002 777c3e84 100000f0 00000008 000000b2 000000b2
> [    0.000000] vers  00000301
> [    0.000000] CPUID vers 19 rev 11 (0x0000026b)
> [    0.000000] capabilities 0x7
> [    0.000000] model 9000/785/C3700
> 

Interesting. Now that you mention it i see that my C3750 reports the same. Google
returned the following page https://support.hpe.com/hpsc/swd/public/detail?swItemId=PF_CCJ70020

Which is 2.0, and only mentions "C3650/C3700/C3750/J6700/J6750 firmware" So maybe
these machines have NP set, and machines "below" (like C3600) don't have it set.

I wonder what happens if you try to flash a 5.0 firmware to such a box.

BTW, i figured out that register 0xf05f1038 bit 0 seems to be the FLASH write
enable. So it's basically just a matter of writing some code to send correct
commands to the flash chip, and being crazy enough to actually erase and reprogram
the flash.

I'm not sure whether that would actually be of help if we know that the NP bit goes
away with a 5.0 firmware on a C3750.

Regards
Sven

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Sven Schnelle]

Hi,

On Tue, May 28, 2019 at 01:28:12PM +0200, Rolf Eike Beer wrote:
> > FWIW, i hacked up a small driver to read the firmware, i'm attaching it
> > to this
> > Mail. Would be nice if some people could try reading the firmware from
> > their PA-RISC
> > system so we can collect and archive them. Note that it HPMC's in 32 Bit
> > Mode,
> > but it worked in 64 Bit mode on my C3750/J5000.
> 
> Nice!
> [..]
> Any particular reason you are not simply using BIN_ATTR_RO?

The reason is just my missing experience with Kernel APIs. If anyone says such
a driver is helpful in the upstream kernel, we could clean it up. But for now
i just wanted to get the contents of the flash, no matter how nice the code is

:-)

Regards
Sven

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Helge Deller]

On 28.05.19 17:41, Sven Schnelle wrote:
> Hi,
>
> On Tue, May 28, 2019 at 01:28:12PM +0200, Rolf Eike Beer wrote:
>>> FWIW, i hacked up a small driver to read the firmware, i'm attaching it
>>> to this
>>> Mail. Would be nice if some people could try reading the firmware from
>>> their PA-RISC
>>> system so we can collect and archive them. Note that it HPMC's in 32 Bit
>>> Mode,
>>> but it worked in 64 Bit mode on my C3750/J5000.
>>
>> Nice!
>> [..]
>> Any particular reason you are not simply using BIN_ATTR_RO?
>
> The reason is just my missing experience with Kernel APIs. If anyone says such
> a driver is helpful in the upstream kernel, we could clean it up. But for now
> i just wanted to get the contents of the flash, no matter how nice the code is
> :-)

I think it's helpful, and I'm happy to include it if someone cleans it up :-)
I suggest to let it build by default (but as module).
Helge

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-05-28 11:38 a.m., Sven Schnelle wrote:
> Interesting. Now that you mention it i see that my C3750 reports the same. Google
> returned the following page https://support.hpe.com/hpsc/swd/public/detail?swItemId=PF_CCJ70020
>
> Which is 2.0, and only mentions "C3650/C3700/C3750/J6700/J6750 firmware" So maybe
> these machines have NP set, and machines "below" (like C3600) don't have it set.
>
> I wonder what happens if you try to flash a 5.0 firmware to such a box.
From what I see, the "C3650/C3700/C3750/J6700/J6750" and "HP 9000 Model B1000/C3000/J5000/J7000"
use different firmware.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:
> On 2019-05-28 11:38 a.m., Sven Schnelle wrote:
> > Interesting. Now that you mention it i see that my C3750 reports the same.
> > Google returned the following page
> > https://support.hpe.com/hpsc/swd/public/detail?swItemId=PF_CCJ70020
> > 
> > Which is 2.0, and only mentions "C3650/C3700/C3750/J6700/J6750 firmware"
> > So maybe these machines have NP set, and machines "below" (like C3600)
> > don't have it set.
> > 
> > I wonder what happens if you try to flash a 5.0 firmware to such a box.
> 
> From what I see, the "C3650/C3700/C3750/J6700/J6750" and "HP 9000 Model
> B1000/C3000/J5000/J7000" use different firmware.

Which makes sense as the former have use a 8600 CPU, while the latter have 
8700 ones.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Sven Schnelle]

Hi,

On Tue, May 28, 2019 at 07:24:29PM +0200, Rolf Eike Beer wrote:
> Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:
> > On 2019-05-28 11:38 a.m., Sven Schnelle wrote:
> > > Interesting. Now that you mention it i see that my C3750 reports the same.
> > > Google returned the following page
> > > https://support.hpe.com/hpsc/swd/public/detail?swItemId=PF_CCJ70020
> > > 
> > > Which is 2.0, and only mentions "C3650/C3700/C3750/J6700/J6750 firmware"
> > > So maybe these machines have NP set, and machines "below" (like C3600)
> > > don't have it set.
> > > 
> > > I wonder what happens if you try to flash a 5.0 firmware to such a box.
> > 
> > From what I see, the "C3650/C3700/C3750/J6700/J6750" and "HP 9000 Model
> > B1000/C3000/J5000/J7000" use different firmware.
> 
> Which makes sense as the former have use a 8600 CPU, while the latter have 
> 8700 ones.

Exactly. And as:

a) All C3600 PDC versions clear the NP bit
b) All C37XX/J5000 PDC version set the NP bit

i don't think there's some bug in the PDC. I would guess that the patch Carlo
reported to fix issues is just hiding the real problem. Would be interesting
to run Carlo's Test on a C37XX.

Sven

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-05-28 1:39 p.m., Sven Schnelle wrote:
> Hi,
> 
> On Tue, May 28, 2019 at 07:24:29PM +0200, Rolf Eike Beer wrote:
>> Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:
>>> On 2019-05-28 11:38 a.m., Sven Schnelle wrote:
>>>> Interesting. Now that you mention it i see that my C3750 reports the same.
>>>> Google returned the following page
>>>> https://support.hpe.com/hpsc/swd/public/detail?swItemId=PF_CCJ70020
>>>>
>>>> Which is 2.0, and only mentions "C3650/C3700/C3750/J6700/J6750 firmware"
>>>> So maybe these machines have NP set, and machines "below" (like C3600)
>>>> don't have it set.
>>>>
>>>> I wonder what happens if you try to flash a 5.0 firmware to such a box.
>>>
>>> From what I see, the "C3650/C3700/C3750/J6700/J6750" and "HP 9000 Model
>>> B1000/C3000/J5000/J7000" use different firmware.
>>
>> Which makes sense as the former have use a 8600 CPU, while the latter have 
>> 8700 ones.
> 
> Exactly. And as:
> 
> a) All C3600 PDC versions clear the NP bit
> b) All C37XX/J5000 PDC version set the NP bit
> 
> i don't think there's some bug in the PDC. I would guess that the patch Carlo
> reported to fix issues is just hiding the real problem. Would be interesting
> to run Carlo's Test on a C37XX.

Probably, hardware cache coherent I/O is not implemented correctly for Elroy based systems.
https://www.hpl.hp.com/hpjournal/96feb/feb96a6.pdf

Does it work on C360?

Dave
-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Helge Deller]

On 28.05.19 20:40, John David Anglin wrote:
> On 2019-05-28 1:39 p.m., Sven Schnelle wrote:
>> Hi,
>>
>> On Tue, May 28, 2019 at 07:24:29PM +0200, Rolf Eike Beer wrote:
>>> Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:
>>>> On 2019-05-28 11:38 a.m., Sven Schnelle wrote:
>>>>> Interesting. Now that you mention it i see that my C3750 reports the same.
>>>>> Google returned the following page
>>>>> https://support.hpe.com/hpsc/swd/public/detail?swItemId=PF_CCJ70020
>>>>>
>>>>> Which is 2.0, and only mentions "C3650/C3700/C3750/J6700/J6750 firmware"
>>>>> So maybe these machines have NP set, and machines "below" (like C3600)
>>>>> don't have it set.
>>>>>
>>>>> I wonder what happens if you try to flash a 5.0 firmware to such a box.
>>>>
>>>> From what I see, the "C3650/C3700/C3750/J6700/J6750" and "HP 9000 Model
>>>> B1000/C3000/J5000/J7000" use different firmware.
>>>
>>> Which makes sense as the former have use a 8600 CPU, while the latter have
>>> 8700 ones.
>>
>> Exactly. And as:
>>
>> a) All C3600 PDC versions clear the NP bit
>> b) All C37XX/J5000 PDC version set the NP bit
>>
>> i don't think there's some bug in the PDC. I would guess that the patch Carlo
>> reported to fix issues is just hiding the real problem. Would be interesting
>> to run Carlo's Test on a C37XX.
>
> Probably, hardware cache coherent I/O is not implemented correctly for Elroy based systems.
> https://www.hpl.hp.com/hpjournal/96feb/feb96a6.pdf
> Does it work on C360?

I slowly start to get confused...
Just thinking about another possibility: Maybe we can rely on the value of the
NP iopdir_fdc bit only on machines with >= PA8700 CPUs?
For older machines (which would need opdir_fdc) HP-UX or other operating
systems decides on the found CPU.
This would explain why it's not  set on Carlo's C3600, and if Sven's C240
(with a PA8200 CPU) doesn't has the bit set too, then this could explain this theory.

Helge

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-05-29 10:15 a.m., Helge Deller wrote:
> On 28.05.19 20:40, John David Anglin wrote:
>> On 2019-05-28 1:39 p.m., Sven Schnelle wrote:
>>> Hi,
>>>
>>> On Tue, May 28, 2019 at 07:24:29PM +0200, Rolf Eike Beer wrote:
>>>> Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:
>>>>> On 2019-05-28 11:38 a.m., Sven Schnelle wrote:
>>>>>> Interesting. Now that you mention it i see that my C3750 reports the same.
>>>>>> Google returned the following page
>>>>>> https://support.hpe.com/hpsc/swd/public/detail?swItemId=PF_CCJ70020
>>>>>>
>>>>>> Which is 2.0, and only mentions "C3650/C3700/C3750/J6700/J6750 firmware"
>>>>>> So maybe these machines have NP set, and machines "below" (like C3600)
>>>>>> don't have it set.
>>>>>>
>>>>>> I wonder what happens if you try to flash a 5.0 firmware to such a box.
>>>>> From what I see, the "C3650/C3700/C3750/J6700/J6750" and "HP 9000 Model
>>>>> B1000/C3000/J5000/J7000" use different firmware.
>>>> Which makes sense as the former have use a 8600 CPU, while the latter have
>>>> 8700 ones.
>>> Exactly. And as:
>>>
>>> a) All C3600 PDC versions clear the NP bit
>>> b) All C37XX/J5000 PDC version set the NP bit
>>>
>>> i don't think there's some bug in the PDC. I would guess that the patch Carlo
>>> reported to fix issues is just hiding the real problem. Would be interesting
>>> to run Carlo's Test on a C37XX.
>> Probably, hardware cache coherent I/O is not implemented correctly for Elroy based systems.
>> https://www.hpl.hp.com/hpjournal/96feb/feb96a6.pdf
>> Does it work on C360?
> I slowly start to get confused...
Ditto.
> Just thinking about another possibility: Maybe we can rely on the value of the
> NP iopdir_fdc bit only on machines with >= PA8700 CPUs?
> For older machines (which would need opdir_fdc) HP-UX or other operating
> systems decides on the found CPU.
> This would explain why it's not  set on Carlo's C3600, and if Sven's C240
> (with a PA8200 CPU) doesn't has the bit set too, then this could explain this theory.
We have this comment in ccio-dma.c:

        /* FIXME: PCX_W platforms don't need FDC/SYNC. (eg C360)
        **        PCX-U/U+ do. (eg C200/C240)
        **        PCX-T'? Don't know. (eg C110 or similar K-class)
        **
        ** See PDC_MODEL/option 0/SW_CAP word for "Non-coherent IO-PDIR bit".
        **
        ** "Since PCX-U employs an offset hash that is incompatible with
        ** the real mode coherence index generation of U2, the PDIR entry
        ** must be flushed to memory to retain coherence."
        */

The NP bit is set in C3700 series, C8000 and rp3440.  It needs to be set in PCX-U/U+ because the
PCX-U employs an offset hash that is incompatible with the real mode coherence index generation
of U2.

The above states that C360 doesn't need FDC/SYNC.  It would be interesting to test C360.  The comment
seems wrong since openpa states C200/C240 use the UTurn I/O adapter Runway to GSC bridge.

The C3000 and up use Astro instead of UTurn.  The NP bit suggests the C3000 to C3600 don't need to
flush.  Yet latter versions C3650-C3750 need to flush.  This seems like a strange regression as HP went
to some trouble to do coherent I/O.

Anyway, I'm wondering if this has something to do with offset relationship of physical to virtual memory
in the kernel space.  It seems to me that the I/O adapter has to generate virtual addresses that are
compatible with the kernel.

Do we have ERS for one of the Cxxxx machines?

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Sven Schnelle]

Hi,

On Wed, May 29, 2019 at 04:15:03PM +0200, Helge Deller wrote:
> >> Exactly. And as:
> >>
> >> a) All C3600 PDC versions clear the NP bit
> >> b) All C37XX/J5000 PDC version set the NP bit
> >>
> >> i don't think there's some bug in the PDC. I would guess that the patch Carlo
> >> reported to fix issues is just hiding the real problem. Would be interesting
> >> to run Carlo's Test on a C37XX.
> >
> > Probably, hardware cache coherent I/O is not implemented correctly for Elroy based systems.
> > https://www.hpl.hp.com/hpjournal/96feb/feb96a6.pdf
> > Does it work on C360?
> 
> I slowly start to get confused...
> Just thinking about another possibility: Maybe we can rely on the value of the
> NP iopdir_fdc bit only on machines with >= PA8700 CPUs?
> For older machines (which would need opdir_fdc) HP-UX or other operating
> systems decides on the found CPU.
> This would explain why it's not  set on Carlo's C3600, and if Sven's C240
> (with a PA8200 CPU) doesn't has the bit set too, then this could explain this theory.

I just re-tested my kexec branch, and the HPMC i was seeing when kexec'ing a new
kernel on my J5000 is now gone with Helge's patch. J5000 also has PCX-W. It was
only triggered when i had SMP enabled, but this is somehow not suprising given
the fact that a cache flush was missing.

Regards
Sven

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Sven Schnelle]

Hi,

On Thu, May 30, 2019 at 09:55:43PM +0200, Sven Schnelle wrote:
> Hi,
> 
> On Wed, May 29, 2019 at 04:15:03PM +0200, Helge Deller wrote:
> > >> Exactly. And as:
> > >>
> > >> a) All C3600 PDC versions clear the NP bit
> > >> b) All C37XX/J5000 PDC version set the NP bit
> > >>
> > >> i don't think there's some bug in the PDC. I would guess that the patch Carlo
> > >> reported to fix issues is just hiding the real problem. Would be interesting
> > >> to run Carlo's Test on a C37XX.
> > >
> > > Probably, hardware cache coherent I/O is not implemented correctly for Elroy based systems.
> > > https://www.hpl.hp.com/hpjournal/96feb/feb96a6.pdf
> > > Does it work on C360?
> > 
> > I slowly start to get confused...
> > Just thinking about another possibility: Maybe we can rely on the value of the
> > NP iopdir_fdc bit only on machines with >= PA8700 CPUs?
> > For older machines (which would need opdir_fdc) HP-UX or other operating
> > systems decides on the found CPU.
> > This would explain why it's not  set on Carlo's C3600, and if Sven's C240
> > (with a PA8200 CPU) doesn't has the bit set too, then this could explain this theory.
> 
> I just re-tested my kexec branch, and the HPMC i was seeing when kexec'ing a new
> kernel on my J5000 is now gone with Helge's patch. J5000 also has PCX-W. It was
> only triggered when i had SMP enabled, but this is somehow not suprising given
> the fact that a cache flush was missing.

Looks like i'm also confused now. My J5000 crashed with the kexec stuff again.
It's much less than before, only 1 out of 10 times.

The patch does:

                if ((cond & ALT_COND_NO_IOC_FDC) &&
                       ((boot_cpu_data.cpu_type < pcxw) ||
                        (boot_cpu_data.cpu_type == pcxw_) ||
                        (boot_cpu_data.pdc.capabilities & PDC_MODEL_IOPDIR_FDC)))
                        continue;

So there should be no change for PCX-W and my statement that this fixes anything
on my J5000 is wrong. I think i'll disable the patching and see whether the problem
disappears.

Regards
Sven

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-05-30 4:59 p.m., Sven Schnelle wrote:
> Hi,
>
> On Thu, May 30, 2019 at 09:55:43PM +0200, Sven Schnelle wrote:
>> Hi,
>>
>> On Wed, May 29, 2019 at 04:15:03PM +0200, Helge Deller wrote:
>>>>> Exactly. And as:
>>>>>
>>>>> a) All C3600 PDC versions clear the NP bit
>>>>> b) All C37XX/J5000 PDC version set the NP bit
>>>>>
>>>>> i don't think there's some bug in the PDC. I would guess that the patch Carlo
>>>>> reported to fix issues is just hiding the real problem. Would be interesting
>>>>> to run Carlo's Test on a C37XX.
>>>> Probably, hardware cache coherent I/O is not implemented correctly for Elroy based systems.
>>>> https://www.hpl.hp.com/hpjournal/96feb/feb96a6.pdf
>>>> Does it work on C360?
>>> I slowly start to get confused...
>>> Just thinking about another possibility: Maybe we can rely on the value of the
>>> NP iopdir_fdc bit only on machines with >= PA8700 CPUs?
>>> For older machines (which would need opdir_fdc) HP-UX or other operating
>>> systems decides on the found CPU.
>>> This would explain why it's not  set on Carlo's C3600, and if Sven's C240
>>> (with a PA8200 CPU) doesn't has the bit set too, then this could explain this theory.
>> I just re-tested my kexec branch, and the HPMC i was seeing when kexec'ing a new
>> kernel on my J5000 is now gone with Helge's patch. J5000 also has PCX-W. It was
>> only triggered when i had SMP enabled, but this is somehow not suprising given
>> the fact that a cache flush was missing.
> Looks like i'm also confused now. My J5000 crashed with the kexec stuff again.
> It's much less than before, only 1 out of 10 times.
>
> The patch does:
>
>                 if ((cond & ALT_COND_NO_IOC_FDC) &&
>                        ((boot_cpu_data.cpu_type < pcxw) ||
>                         (boot_cpu_data.cpu_type == pcxw_) ||
>                         (boot_cpu_data.pdc.capabilities & PDC_MODEL_IOPDIR_FDC)))
>                         continue;
>
> So there should be no change for PCX-W and my statement that this fixes anything
> on my J5000 is wrong. I think i'll disable the patching and see whether the problem
> disappears.
Is it possible that we are running in a mode where the cache/TLB does not issue coherent
operations?  There is a PDC_CACHE call to set the coherence state.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[Carlo Pisani]

guys, can someone help me to create patches for solving the
PCI-problem on kernel 4.20?
currently, I am on kernel 5.1.*, but I also need to have a working 4.20

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-05-31 8:23 a.m., John David Anglin wrote:
> On 2019-05-30 4:59 p.m., Sven Schnelle wrote:
>> Hi,
>>
>> On Thu, May 30, 2019 at 09:55:43PM +0200, Sven Schnelle wrote:
>>> Hi,
>>>
>>> On Wed, May 29, 2019 at 04:15:03PM +0200, Helge Deller wrote:
>>>>>> Exactly. And as:
>>>>>>
>>>>>> a) All C3600 PDC versions clear the NP bit
>>>>>> b) All C37XX/J5000 PDC version set the NP bit
>>>>>>
>>>>>> i don't think there's some bug in the PDC. I would guess that the patch Carlo
>>>>>> reported to fix issues is just hiding the real problem. Would be interesting
>>>>>> to run Carlo's Test on a C37XX.
>>>>> Probably, hardware cache coherent I/O is not implemented correctly for Elroy based systems.
>>>>> https://www.hpl.hp.com/hpjournal/96feb/feb96a6.pdf
>>>>> Does it work on C360?
>>>> I slowly start to get confused...
>>>> Just thinking about another possibility: Maybe we can rely on the value of the
>>>> NP iopdir_fdc bit only on machines with >= PA8700 CPUs?
>>>> For older machines (which would need opdir_fdc) HP-UX or other operating
>>>> systems decides on the found CPU.
>>>> This would explain why it's not  set on Carlo's C3600, and if Sven's C240
>>>> (with a PA8200 CPU) doesn't has the bit set too, then this could explain this theory.
>>> I just re-tested my kexec branch, and the HPMC i was seeing when kexec'ing a new
>>> kernel on my J5000 is now gone with Helge's patch. J5000 also has PCX-W. It was
>>> only triggered when i had SMP enabled, but this is somehow not suprising given
>>> the fact that a cache flush was missing.
>> Looks like i'm also confused now. My J5000 crashed with the kexec stuff again.
>> It's much less than before, only 1 out of 10 times.
>>
>> The patch does:
>>
>>                 if ((cond & ALT_COND_NO_IOC_FDC) &&
>>                        ((boot_cpu_data.cpu_type < pcxw) ||
>>                         (boot_cpu_data.cpu_type == pcxw_) ||
>>                         (boot_cpu_data.pdc.capabilities & PDC_MODEL_IOPDIR_FDC)))
>>                         continue;
>>
>> So there should be no change for PCX-W and my statement that this fixes anything
>> on my J5000 is wrong. I think i'll disable the patching and see whether the problem
>> disappears.
> Is it possible that we are running in a mode where the cache/TLB does not issue coherent
> operations?  There is a PDC_CACHE call to set the coherence state.

I checked the machines that I have and they all have coherent caches and TLBs.  I think
flush and sync are required on all machines with write-back caches.  This makes write
visible to I/O adapter (memory).  The c3600 has a write-back data cache.  See "PDC Procedures"
page 4-21.

This might be affected by the TLB U bit.  Possibly, the U bit is not set for pages in the
I/O address region (IO-PDIR) and we need flush/sync as a result.

-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-06-02 6:29 a.m., Carlo Pisani wrote:
> guys, can someone help me to create patches for solving the
> PCI-problem on kernel 4.20?
> currently, I am on kernel 5.1.*, but I also need to have a working 4.20
> 
As a hack, change this line
	ioc_needs_fdc = boot_cpu_data.pdc.capabilities & PDC_MODEL_IOPDIR_FDC;
in drivers/parisc/sba_iommu.c to
	ioc_needs_fdc = 1;

Dave
-- 
John David Anglin  dave.anglin@bell.net

Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit

[John David Anglin]

On 2019-06-02 10:38 a.m., John David Anglin wrote:
> On 2019-05-31 8:23 a.m., John David Anglin wrote:
>> On 2019-05-30 4:59 p.m., Sven Schnelle wrote:
>>> Hi,
>>>
>>> On Thu, May 30, 2019 at 09:55:43PM +0200, Sven Schnelle wrote:
>>>> Hi,
>>>>
>>>> On Wed, May 29, 2019 at 04:15:03PM +0200, Helge Deller wrote:
>>>>>>> Exactly. And as:
>>>>>>>
>>>>>>> a) All C3600 PDC versions clear the NP bit
>>>>>>> b) All C37XX/J5000 PDC version set the NP bit
>>>>>>>
>>>>>>> i don't think there's some bug in the PDC. I would guess that the patch Carlo
>>>>>>> reported to fix issues is just hiding the real problem. Would be interesting
>>>>>>> to run Carlo's Test on a C37XX.
>>>>>> Probably, hardware cache coherent I/O is not implemented correctly for Elroy based systems.
>>>>>> https://www.hpl.hp.com/hpjournal/96feb/feb96a6.pdf
>>>>>> Does it work on C360?
>>>>> I slowly start to get confused...
>>>>> Just thinking about another possibility: Maybe we can rely on the value of the
>>>>> NP iopdir_fdc bit only on machines with >= PA8700 CPUs?
>>>>> For older machines (which would need opdir_fdc) HP-UX or other operating
>>>>> systems decides on the found CPU.
>>>>> This would explain why it's not  set on Carlo's C3600, and if Sven's C240
>>>>> (with a PA8200 CPU) doesn't has the bit set too, then this could explain this theory.
>>>> I just re-tested my kexec branch, and the HPMC i was seeing when kexec'ing a new
>>>> kernel on my J5000 is now gone with Helge's patch. J5000 also has PCX-W. It was
>>>> only triggered when i had SMP enabled, but this is somehow not suprising given
>>>> the fact that a cache flush was missing.
>>> Looks like i'm also confused now. My J5000 crashed with the kexec stuff again.
>>> It's much less than before, only 1 out of 10 times.
>>>
>>> The patch does:
>>>
>>>                 if ((cond & ALT_COND_NO_IOC_FDC) &&
>>>                        ((boot_cpu_data.cpu_type < pcxw) ||
>>>                         (boot_cpu_data.cpu_type == pcxw_) ||
>>>                         (boot_cpu_data.pdc.capabilities & PDC_MODEL_IOPDIR_FDC)))
>>>                         continue;
>>>
>>> So there should be no change for PCX-W and my statement that this fixes anything
>>> on my J5000 is wrong. I think i'll disable the patching and see whether the problem
>>> disappears.
>> Is it possible that we are running in a mode where the cache/TLB does not issue coherent
>> operations?  There is a PDC_CACHE call to set the coherence state.
> 
> I checked the machines that I have and they all have coherent caches and TLBs.  I think
> flush and sync are required on all machines with write-back caches.  This makes write
> visible to I/O adapter (memory).  The c3600 has a write-back data cache.  See "PDC Procedures"
> page 4-21.
> 
> This might be affected by the TLB U bit.  Possibly, the U bit is not set for pages in the
> I/O address region (IO-PDIR) and we need flush/sync as a result.
> 

Possibly, this change will fix the alternative coding NP IO-PDIR optimization on
machines that don't need to flush/sync.

It's boot tested on c8000 but it needs testing on c3600 and j5000, etc, to make sure
it resolves the issue on machines that don't need to flush/sync the IO-PDIR.

Dave

diff --git a/arch/parisc/mm/ioremap.c b/arch/parisc/mm/ioremap.c
index 92a9b5f12f98..9baea70e38c4 100644
--- a/arch/parisc/mm/ioremap.c
+++ b/arch/parisc/mm/ioremap.c
@@ -38,7 +38,6 @@ void __iomem * __ioremap(unsigned long phys_addr, unsigned long size, unsigned l
 	if ((phys_addr >= 0x00080000 && end < 0x000fffff) ||
 	    (phys_addr >= 0x00500000 && end < 0x03bfffff)) {
 		phys_addr |= F_EXTEND(0xfc000000);
-		flags |= _PAGE_NO_CACHE;
 	}
 #endif

@@ -65,7 +64,7 @@ void __iomem * __ioremap(unsigned long phys_addr, unsigned long size, unsigned l
 	}

 	pgprot = __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY |
-			  _PAGE_ACCESSED | flags);
+			  _PAGE_ACCESSED | _PAGE_NO_CACHE | flags);

 	/*
 	 * Mappings have to be page-aligned