Date: Thu, 9 May 2019 20:05:48 -0700 From: Mark Millard <marklmi@yahoo.com> To: Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: PowerMac G5's vs. PSL_ME manipulation in the msr: mtmsr ignores it, only rfid can set it? (How to avoid checkstop on the ap's?) Message-ID: <2850A34A-854D-41DB-976D-3D859789D3DB@yahoo.com>
next in thread | raw e-mail | index | archive | help
Quoting: PPC_Vers201_Book3_public.pdf QUOTE The only instruction that can alter MSR.ME is the rfid instruction. END QUOTE (Doing so involves using mtsrr1 before the rfid instruction.) Various places in FreeBSD are trying to control the PDL_ME bit via mtmsr. In fact, most FreeBSD PSL_ME use for the context is associated with mtmsr. So far I only see: enter_idle_powerx sets PSL_ME via mtsrr1 and rfid. kbootentry clears srr1 completely via mtsrr1 before doing ba EXC_RST. Other mtsrr1 usage are just save/restore or do updates not involving PSL_ME changes. How I got into looking at PSL_ME use: How it relates to the hang-up problem investigation . . . Note: CPU 1 never makes it to handle_kernel_slb_spill when the it tries the td_pcb-> access in cpudep_ap_bootstrap. CPU 1 appears to have ended up checkstop'd, not getting other traps either. There are the following dependencies on td_pcb-> access in powerpc/powerpc/trap.c : handle_onfault: td->td_pcb->pcb_onfault trap_pfault: Can use handle_onfault trap for kernel EXC_MCHK: Uses handle_onfault trap for kernel EXC_DSI: Uses trap_pfault trap for kernel EXC_DSE: td->td_pcb->pcb_cpu.aim.usr_vsid fix_unaligned for ESR_SPE: td->td_pcb->pcb_vec.vr[reg] fix_unaligned for EXC_ALI_LFD: td->td_pcb->pcb_fpu.fpr[reg].fp fix_unaligned for EXC_ALI_STFD: td->td_pcb->pcb_fpu.fpr[reg].fp As near as I can tell, for the PowerMac G5's, PDL_ME is as openfirmware or the loader set it for each CPU. But CPU 1 does happen to have the PSL_ME bit enabled. With td_pcb-> access in cpudep_ap_bootstrap failing to get to handle_kernel_slb_spill at all when the slb does not cover the segment, the rest of the above are not likely to work under such conditions ether. slbtrap's and handle_kernel_slb_spill would be involved. My evidence gathering, some notes: I have handle_kernel_slb_spill recording CPU 1 activity but it never reports any activity except before the pcpup->pc_curthread-> access attempt. I also have recording in trap's kernel trap path for CPU 1 and it also reports nothing. (The reporting is to memory, with the bsp looking at what was recorded and reporting based on such via printf's when there is something to report.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2850A34A-854D-41DB-976D-3D859789D3DB>