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@xxxxxxxx
