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?
Helge
