Skip to contentSkip to conversation

parisc: Fix crash due alternative coding for NP iopdir_fdc bit

PATCH In review Helge Deller 5 participants 29 messages May 27, 2019 – Jun 2, 2019 1 message not in the archive PA-RISC architecture

lore
Share & tools
lore

Helge Deller

author maintainer
#0 lore raw

PATCH v3 1/1 parisc: Fix crash due alternative coding for NP iopdir_fdc bit

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 <[email protected]>
Reported-by Carlo Pisani <[email protected]>
Tested-by Sven Schnelle <[email protected]>
Fixes 3847dab77421 ("parisc: Add alternative coding infrastructure")
Signed-off-by Helge Deller <[email protected]>
Cc [email protected] # 5.0+
arch/parisc/kernel/alternative.c +3 -1
index bf2274e01a96..1ac3b4ac73c0 100644
@@ -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? */
#1 lore raw

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

#3 lore raw

Hi Dave,

Quoted 6 lines · John David Anglin
Quoted 4 lines · Carlo Pisani

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.

Quoted 2 lines

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

#4 lore raw
Quoted 1 line · Sven Schnelle

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

Signature · 1 line
John David Anglin  [email protected]
#5 lore raw
In reply to Carlo Pisani

Hi,

Quoted 3 lines · Carlo Pisani

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

#6 lore raw
Quoted 31 lines · Sven Schnelle

Hi,

Quoted 3 lines · Carlo Pisani

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
Quoted 5 lines

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 <[email protected]>
Date: Tue, 28 May 2019 13:03:01 +0200
Subject: [PATCH] parisc: quick hack to read the firmware ROM

Signed-off-by Sven Schnelle <[email protected]>
---
 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
drivers/parisc/Kconfig +13 -0
index 74e119adca01..37a077eb2a29 100644
@@ -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
drivers/parisc/Makefile +1 -0
index 99fa6a89e0b9..a3acda40ca78 100644
@@ -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
drivers/parisc/pdc_firmware.c new file +83 -0

83 lines not on this page · raw message

Signature · 1 line
2.20.1
#7 lore raw
Quoted 5 lines

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!

Quoted 33 lines
drivers/parisc/pdc_firmware.c new file +33 -0
+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:

drivers/parisc/pdc_firmware.c line 68

Quoted 10 lines
drivers/parisc/pdc_firmware.c new file +10 -0
+	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

#8 lore raw

Hi,

Quoted 11 lines · Rolf Eike Beer
Quoted 7 lines

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

author maintainer
#9 lore raw
Quoted 11 lines · Sven Schnelle

Hi,

Quoted 8 lines · Rolf Eike Beer
Quoted 7 lines

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.

Quoted 8 lines
Quoted 3 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

author maintainer
#11 lore raw
Quoted 6 lines · John David Anglin
Quoted 4 lines · Sven Schnelle

This is interesting, because:

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

Quoted 8 lines

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

#12 lore raw

Hi,

Quoted 10 lines · Helge Deller
Quoted 9 lines

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
Quoted 7 lines

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

#13 lore raw
Quoted 7 lines · Sven Schnelle

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

Signature · 1 line
John David Anglin  [email protected]
#14 lore raw

Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:

Quoted 5 lines · Sven Schnelle
Quoted 4 lines

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

Quoted 8 lines
Quoted 5 lines

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

#15 lore raw

Hi,

Quoted 10 lines · Rolf Eike Beer

Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:

Quoted 9 lines · Sven Schnelle
Quoted 8 lines

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.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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

#16 lore raw
Quoted 21 lines · Sven Schnelle

Hi,

Quoted 10 lines · Rolf Eike Beer

Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:

Quoted 9 lines · Sven Schnelle
Quoted 8 lines

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.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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.

Quoted 8 lines

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

Signature · 1 line
John David Anglin  [email protected]
author maintainer
#17 lore raw
Quoted 27 lines · John David Anglin
Quoted 26 lines · Sven Schnelle

Hi,

Quoted 10 lines · Rolf Eike Beer

Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:

Quoted 9 lines · Sven Schnelle
Quoted 8 lines

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.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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

Quoted 7 lines
Quoted 3 lines

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

#18 lore raw
Quoted 25 lines · Helge Deller
Quoted 24 lines · John David Anglin
Quoted 23 lines · Sven Schnelle

Hi,

Quoted 10 lines · Rolf Eike Beer

Am Dienstag, 28. Mai 2019, 19:06:48 CEST schrieb John David Anglin:

Quoted 9 lines · Sven Schnelle
Quoted 8 lines

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.

Quoted 5 lines
Quoted 3 lines
Quoted 1 line

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

Quoted 7 lines
Quoted 6 lines
Quoted 3 lines

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.

Quoted 6 lines

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

Signature · 1 line
John David Anglin  [email protected]
#19 lore raw
In reply to Helge Deller

Hi,

Quoted 13 lines · Helge Deller
Quoted 5 lines
Quoted 5 lines

Exactly. And as:

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

Quoted 7 lines
Quoted 3 lines

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?

Quoted 7 lines

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

#20 lore raw

Hi,

Quoted 24 lines · Sven Schnelle

Hi,

Quoted 13 lines · Helge Deller
Quoted 5 lines
Quoted 5 lines

Exactly. And as:

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

Quoted 7 lines
Quoted 3 lines

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?

Quoted 7 lines

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.

Quoted 4 lines

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

#21 lore raw
Quoted 39 lines · Sven Schnelle

Hi,

Quoted 21 lines · Sven Schnelle

Hi,

Quoted 11 lines · Helge Deller
Quoted 11 lines
Quoted 8 lines

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?

Quoted 7 lines

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.

Quoted 4 lines

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;
Quoted 3 lines

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

Signature · 1 line
John David Anglin  [email protected]
#22 lore raw

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

#23 lore raw
Quoted 4 lines · 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

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

Signature · 1 line
John David Anglin  [email protected]
#24 lore raw
In reply to John David Anglin
Quoted 40 lines · John David Anglin
Quoted 39 lines · Sven Schnelle

Hi,

Quoted 21 lines · Sven Schnelle

Hi,

Quoted 11 lines · Helge Deller
Quoted 11 lines
Quoted 8 lines

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?

Quoted 7 lines

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.

Quoted 4 lines

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;
Quoted 5 lines
Quoted 3 lines

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.

Signature · 1 line
John David Anglin  [email protected]
#25 lore raw
Quoted 47 lines · John David Anglin
Quoted 40 lines · John David Anglin
Quoted 39 lines · Sven Schnelle

Hi,

Quoted 21 lines · Sven Schnelle

Hi,

Quoted 11 lines · Helge Deller
Quoted 11 lines
Quoted 8 lines

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?

Quoted 7 lines

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.

Quoted 4 lines

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;
Quoted 5 lines
Quoted 3 lines

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.

Quoted 8 lines

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

arch/parisc/mm/ioremap.c +1 -2
index 92a9b5f12f98..9baea70e38c4 100644
@@ -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
#26 lore raw
In reply to Helge Deller
Quoted 6 lines · Helge Deller

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

Signature · 1 line
John David Anglin  [email protected]
author maintainer
#27 lore raw
Quoted 15 lines · John David Anglin
Quoted 6 lines · Helge Deller

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

Quoted 8 lines

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

#28 lore raw
Quoted 1 line

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.

#29 lore raw
In reply to Helge Deller
Quoted 18 lines · Helge Deller
Quoted 17 lines · John David Anglin
Quoted 6 lines · Helge Deller

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:

Quoted 8 lines
Quoted 6 lines

                        /*
                        ** 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.

Signature · 1 line
John David Anglin  [email protected]