On 2019-05-25 1:15 p.m., Helge Deller wrote:
> On 25.05.19 16:13, John David Anglin wrote:
>> On 2019-05-25 5:01 a.m., Carlo Pisani wrote:
>>> on kernel 5.1, from the git repository, compiled with SMP
>>>
>>> dmesg | grep altern
>>> [ 2.551002] alternatives: applied 156 out of 175 patches
>>>
>>> this patch has made my day!
>>> It seems the solution for the problem!
>>>
>>> the card is still working after 10 hours of burn-in test!
>>> --- a/arch/parisc/include/asm/cache.h
>>> +++ b/arch/parisc/include/asm/cache.h
>>> @@ -52,7 +52,6 @@ void parisc_setup_cache_timing(void);
>>>
>>> #define asm_io_fdc(addr) asm volatile("fdc %%r0(%0)" \
>>> ALTERNATIVE(ALT_COND_NO_DCACHE, INSN_NOP) \
>>> - ALTERNATIVE(ALT_COND_NO_IOC_FDC, INSN_NOP) \
>>> : : "r" (addr) : "memory")
>>> #define asm_io_sync() asm volatile("sync" \
>>> ALTERNATIVE(ALT_COND_NO_DCACHE, INSN_NOP) \
>> The change isn't fully correct as the alternative should also have been removed from
>> the asm_io_sync() define.
>>
>> If the change actually fixes controller, then there must be a problem with the test in
>> arch/parisc/kernel/alternative.c that determines whether or not to patch out fdc instruction
>> on c3600. See Helge's patch to fix alternative coding for PCX-U CPUs. It would help to
>> print boot_cpu_data.pdc.capabilities and boot_cpu_data.cpu_type on your machine.
> I wonder as well. c3600 seems to have a PA-8600 CPUs (according to openpa.net) which is pcxw_
> (according to arch/parisc/kernel/hardware.c) and it should be fine to replace the fdc by nop
> if the PDC_MODEL_IOPDIR_FDC capabilities bit is not set.
> Carlo, can you run "cat /proc/cpuinfo" and paste the output here?
I'm thinking that machines with Elroy PCI bridges may need flush but I don't know why.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
