* [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit @ 2019-05-27 19:20 Helge Deller 2019-05-27 19:35 ` Carlo Pisani 2019-05-27 19:41 ` John David Anglin 0 siblings, 2 replies; 29+ messages in thread From: Helge Deller @ 2019-05-27 19:20 UTC (permalink / raw) To: linux-parisc, James Bottomley, John David Anglin, Sven Schnelle, Carlo Pisani 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? */ ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 19:20 [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit Helge Deller @ 2019-05-27 19:35 ` Carlo Pisani 2019-05-27 20:13 ` John David Anglin 2019-05-27 20:15 ` Sven Schnelle 2019-05-27 19:41 ` John David Anglin 1 sibling, 2 replies; 29+ messages in thread From: Carlo Pisani @ 2019-05-27 19:35 UTC (permalink / raw) To: Helge Deller Cc: linux-parisc, James Bottomley, John David Anglin, Sven Schnelle isn't possible to burn the flash in the C3600 machine with the firmware of C3750? these two look similar. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 19:35 ` Carlo Pisani @ 2019-05-27 20:13 ` John David Anglin 2019-05-27 20:22 ` Sven Schnelle 2019-05-27 20:15 ` Sven Schnelle 1 sibling, 1 reply; 29+ messages in thread From: John David Anglin @ 2019-05-27 20:13 UTC (permalink / raw) To: Carlo Pisani, Helge Deller; +Cc: linux-parisc, James Bottomley, Sven Schnelle 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 20:13 ` John David Anglin @ 2019-05-27 20:22 ` Sven Schnelle 2019-05-27 20:49 ` John David Anglin 0 siblings, 1 reply; 29+ messages in thread From: Sven Schnelle @ 2019-05-27 20:22 UTC (permalink / raw) To: John David Anglin Cc: Carlo Pisani, Helge Deller, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 20:22 ` Sven Schnelle @ 2019-05-27 20:49 ` John David Anglin 0 siblings, 0 replies; 29+ messages in thread From: John David Anglin @ 2019-05-27 20:49 UTC (permalink / raw) To: Sven Schnelle; +Cc: Carlo Pisani, Helge Deller, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 19:35 ` Carlo Pisani 2019-05-27 20:13 ` John David Anglin @ 2019-05-27 20:15 ` Sven Schnelle 2019-05-28 11:06 ` Sven Schnelle 1 sibling, 1 reply; 29+ messages in thread From: Sven Schnelle @ 2019-05-27 20:15 UTC (permalink / raw) To: Carlo Pisani Cc: Helge Deller, linux-parisc, James Bottomley, John David Anglin 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 20:15 ` Sven Schnelle @ 2019-05-28 11:06 ` Sven Schnelle 2019-05-28 11:28 ` Rolf Eike Beer [not found] ` <e81b7ae4-3126-5fda-58e4-4a83bd4fcfcf@bell.net> 0 siblings, 2 replies; 29+ messages in thread From: Sven Schnelle @ 2019-05-28 11:06 UTC (permalink / raw) To: Carlo Pisani Cc: Helge Deller, linux-parisc, James Bottomley, John David Anglin 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 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-28 11:06 ` Sven Schnelle @ 2019-05-28 11:28 ` Rolf Eike Beer 2019-05-28 15:41 ` Sven Schnelle [not found] ` <e81b7ae4-3126-5fda-58e4-4a83bd4fcfcf@bell.net> 1 sibling, 1 reply; 29+ messages in thread From: Rolf Eike Beer @ 2019-05-28 11:28 UTC (permalink / raw) To: Sven Schnelle Cc: Carlo Pisani, Helge Deller, linux-parisc, James Bottomley, John David Anglin, linux-parisc-owner > 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-28 11:28 ` Rolf Eike Beer @ 2019-05-28 15:41 ` Sven Schnelle 2019-05-28 15:52 ` Helge Deller 0 siblings, 1 reply; 29+ messages in thread From: Sven Schnelle @ 2019-05-28 15:41 UTC (permalink / raw) To: Rolf Eike Beer Cc: Carlo Pisani, Helge Deller, linux-parisc, James Bottomley, John David Anglin, linux-parisc-owner 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-28 15:41 ` Sven Schnelle @ 2019-05-28 15:52 ` Helge Deller 0 siblings, 0 replies; 29+ messages in thread From: Helge Deller @ 2019-05-28 15:52 UTC (permalink / raw) To: Sven Schnelle, Rolf Eike Beer Cc: Carlo Pisani, linux-parisc, James Bottomley, John David Anglin, linux-parisc-owner 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <e81b7ae4-3126-5fda-58e4-4a83bd4fcfcf@bell.net>]
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit [not found] ` <e81b7ae4-3126-5fda-58e4-4a83bd4fcfcf@bell.net> @ 2019-05-28 15:11 ` Helge Deller 2019-05-28 15:38 ` Sven Schnelle 0 siblings, 1 reply; 29+ messages in thread From: Helge Deller @ 2019-05-28 15:11 UTC (permalink / raw) To: John David Anglin, Sven Schnelle, Carlo Pisani Cc: linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-28 15:11 ` Helge Deller @ 2019-05-28 15:38 ` Sven Schnelle 2019-05-28 17:06 ` John David Anglin 0 siblings, 1 reply; 29+ messages in thread From: Sven Schnelle @ 2019-05-28 15:38 UTC (permalink / raw) To: Helge Deller Cc: John David Anglin, Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-28 15:38 ` Sven Schnelle @ 2019-05-28 17:06 ` John David Anglin 2019-05-28 17:24 ` Rolf Eike Beer 0 siblings, 1 reply; 29+ messages in thread From: John David Anglin @ 2019-05-28 17:06 UTC (permalink / raw) To: Sven Schnelle, Helge Deller; +Cc: Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-28 17:06 ` John David Anglin @ 2019-05-28 17:24 ` Rolf Eike Beer 2019-05-28 17:39 ` Sven Schnelle 0 siblings, 1 reply; 29+ messages in thread From: Rolf Eike Beer @ 2019-05-28 17:24 UTC (permalink / raw) To: John David Anglin Cc: Sven Schnelle, Helge Deller, Carlo Pisani, linux-parisc, James Bottomley [-- 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 --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-28 17:24 ` Rolf Eike Beer @ 2019-05-28 17:39 ` Sven Schnelle 2019-05-28 18:40 ` John David Anglin 0 siblings, 1 reply; 29+ messages in thread From: Sven Schnelle @ 2019-05-28 17:39 UTC (permalink / raw) To: Rolf Eike Beer Cc: John David Anglin, Helge Deller, Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-28 17:39 ` Sven Schnelle @ 2019-05-28 18:40 ` John David Anglin 2019-05-29 14:15 ` Helge Deller 0 siblings, 1 reply; 29+ messages in thread From: John David Anglin @ 2019-05-28 18:40 UTC (permalink / raw) To: Sven Schnelle, Rolf Eike Beer Cc: Helge Deller, Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-28 18:40 ` John David Anglin @ 2019-05-29 14:15 ` Helge Deller 2019-05-29 17:01 ` John David Anglin 2019-05-30 19:55 ` Sven Schnelle 0 siblings, 2 replies; 29+ messages in thread From: Helge Deller @ 2019-05-29 14:15 UTC (permalink / raw) To: John David Anglin, Sven Schnelle, Rolf Eike Beer Cc: Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-29 14:15 ` Helge Deller @ 2019-05-29 17:01 ` John David Anglin 2019-05-30 19:55 ` Sven Schnelle 1 sibling, 0 replies; 29+ messages in thread From: John David Anglin @ 2019-05-29 17:01 UTC (permalink / raw) To: Helge Deller, Sven Schnelle, Rolf Eike Beer Cc: Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-29 14:15 ` Helge Deller 2019-05-29 17:01 ` John David Anglin @ 2019-05-30 19:55 ` Sven Schnelle 2019-05-30 20:59 ` Sven Schnelle 1 sibling, 1 reply; 29+ messages in thread From: Sven Schnelle @ 2019-05-30 19:55 UTC (permalink / raw) To: Helge Deller Cc: John David Anglin, Rolf Eike Beer, Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-30 19:55 ` Sven Schnelle @ 2019-05-30 20:59 ` Sven Schnelle 2019-05-31 12:23 ` John David Anglin 0 siblings, 1 reply; 29+ messages in thread From: Sven Schnelle @ 2019-05-30 20:59 UTC (permalink / raw) To: Helge Deller Cc: John David Anglin, Rolf Eike Beer, Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-30 20:59 ` Sven Schnelle @ 2019-05-31 12:23 ` John David Anglin 2019-06-02 10:29 ` Carlo Pisani 2019-06-02 14:38 ` John David Anglin 0 siblings, 2 replies; 29+ messages in thread From: John David Anglin @ 2019-05-31 12:23 UTC (permalink / raw) To: Sven Schnelle, Helge Deller Cc: Rolf Eike Beer, Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-31 12:23 ` John David Anglin @ 2019-06-02 10:29 ` Carlo Pisani 2019-06-02 14:45 ` John David Anglin 2019-06-02 14:38 ` John David Anglin 1 sibling, 1 reply; 29+ messages in thread From: Carlo Pisani @ 2019-06-02 10:29 UTC (permalink / raw) To: John David Anglin Cc: Sven Schnelle, Helge Deller, Rolf Eike Beer, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-06-02 10:29 ` Carlo Pisani @ 2019-06-02 14:45 ` John David Anglin 0 siblings, 0 replies; 29+ messages in thread From: John David Anglin @ 2019-06-02 14:45 UTC (permalink / raw) To: Carlo Pisani Cc: Sven Schnelle, Helge Deller, Rolf Eike Beer, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-31 12:23 ` John David Anglin 2019-06-02 10:29 ` Carlo Pisani @ 2019-06-02 14:38 ` John David Anglin 2019-06-02 16:12 ` John David Anglin 1 sibling, 1 reply; 29+ messages in thread From: John David Anglin @ 2019-06-02 14:38 UTC (permalink / raw) To: Sven Schnelle, Helge Deller Cc: Rolf Eike Beer, Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-06-02 14:38 ` John David Anglin @ 2019-06-02 16:12 ` John David Anglin 0 siblings, 0 replies; 29+ messages in thread From: John David Anglin @ 2019-06-02 16:12 UTC (permalink / raw) To: Sven Schnelle, Helge Deller Cc: Rolf Eike Beer, Carlo Pisani, linux-parisc, James Bottomley 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 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 19:20 [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit Helge Deller 2019-05-27 19:35 ` Carlo Pisani @ 2019-05-27 19:41 ` John David Anglin 2019-05-27 20:11 ` Helge Deller 1 sibling, 1 reply; 29+ messages in thread From: John David Anglin @ 2019-05-27 19:41 UTC (permalink / raw) To: Helge Deller, linux-parisc, James Bottomley, Sven Schnelle, Carlo Pisani 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 19:41 ` John David Anglin @ 2019-05-27 20:11 ` Helge Deller 2019-05-27 20:16 ` Carlo Pisani 2019-05-27 20:45 ` John David Anglin 0 siblings, 2 replies; 29+ messages in thread From: Helge Deller @ 2019-05-27 20:11 UTC (permalink / raw) To: John David Anglin, linux-parisc, James Bottomley, Sven Schnelle, Carlo Pisani, Grant Grundler 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 20:11 ` Helge Deller @ 2019-05-27 20:16 ` Carlo Pisani 2019-05-27 20:45 ` John David Anglin 1 sibling, 0 replies; 29+ messages in thread From: Carlo Pisani @ 2019-05-27 20:16 UTC (permalink / raw) To: Helge Deller Cc: John David Anglin, linux-parisc, James Bottomley, Sven Schnelle, Grant Grundler > 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit 2019-05-27 20:11 ` Helge Deller 2019-05-27 20:16 ` Carlo Pisani @ 2019-05-27 20:45 ` John David Anglin 1 sibling, 0 replies; 29+ messages in thread From: John David Anglin @ 2019-05-27 20:45 UTC (permalink / raw) To: Helge Deller, linux-parisc, James Bottomley, Sven Schnelle, Carlo Pisani, Grant Grundler 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2019-06-02 16:12 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-27 19:20 [PATCH v3] parisc: Fix crash due alternative coding for NP iopdir_fdc bit Helge Deller 2019-05-27 19:35 ` Carlo Pisani 2019-05-27 20:13 ` John David Anglin 2019-05-27 20:22 ` Sven Schnelle 2019-05-27 20:49 ` John David Anglin 2019-05-27 20:15 ` Sven Schnelle 2019-05-28 11:06 ` Sven Schnelle 2019-05-28 11:28 ` Rolf Eike Beer 2019-05-28 15:41 ` Sven Schnelle 2019-05-28 15:52 ` Helge Deller [not found] ` <e81b7ae4-3126-5fda-58e4-4a83bd4fcfcf@bell.net> 2019-05-28 15:11 ` Helge Deller 2019-05-28 15:38 ` Sven Schnelle 2019-05-28 17:06 ` John David Anglin 2019-05-28 17:24 ` Rolf Eike Beer 2019-05-28 17:39 ` Sven Schnelle 2019-05-28 18:40 ` John David Anglin 2019-05-29 14:15 ` Helge Deller 2019-05-29 17:01 ` John David Anglin 2019-05-30 19:55 ` Sven Schnelle 2019-05-30 20:59 ` Sven Schnelle 2019-05-31 12:23 ` John David Anglin 2019-06-02 10:29 ` Carlo Pisani 2019-06-02 14:45 ` John David Anglin 2019-06-02 14:38 ` John David Anglin 2019-06-02 16:12 ` John David Anglin 2019-05-27 19:41 ` John David Anglin 2019-05-27 20:11 ` Helge Deller 2019-05-27 20:16 ` Carlo Pisani 2019-05-27 20:45 ` John David Anglin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.