On Sat, 21 Oct 2017, Fredrik Noring wrote: > > > Still left to explain is why the kernel stumbles on registers during > > > initialisation, before user applications are invoked. > > > > Good luck! > > The problem was with the inq and outq macros in the Graphics Synthesizer > driver. A 32-bit kernel now works with 32-bit register save/restore and o32 > applications, as intended. Many thanks for all your help in finding this! Great, and you are welcome! > I've found an unrelated curiosity. With CONFIG_CPU_HAS_MSA undefined, > handle_msa_fpe_int, do_msa_fpe, etc. are still generated with nonsensical > instructions: > > 80025128 <handle_msa_fpe_int>: > 80025128: 787e0859 lq s8,2137(v1) <<<----- > 8002512c: 00202821 move a1,at > 80025130: 0000040f sync.p > 80025134: 40086000 mfc0 t0,c0_sr > ... > > 80030f08 <do_msa_fpe>: > 80030f08: 27bdffd8 addiu sp,sp,-40 > 80030f0c: afb0001c sw s0,28(sp) > 80030f10: 00808021 move s0,a0 > ... > 80030f70: 02228824 and s1,s1,v0 > 80030f74: 02200821 move at,s1 > 80030f78: 783e0859 lq s8,2137(at) <<<----- > 80030f7c: 0000040f sync.p > 80030f80: 40016000 mfc0 at,c0_sr > ... > > I disabled both with the patch below (there seems to be more opportunities > for size reductions overall). Perhaps the MSA and the MSAFPE exception handlers could be improved somehow for configurations known not to support the MSA ASE, however your change as it stands will make the MSA exception handler default to `do_reserved', which in turn will cause MSA software to cause a kernel panic rather than sending SIGILL if run with CPU_HAS_MSA disabled on MSA hardware. This would be rather nasty IMO. Maciej
