Date: Wed, 15 May 2019 21:24:51 -0700 From: Mark Millard <marklmi@yahoo.com> To: Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: PowerMac G5's and such: Should HIOR save/restore be involved in ofw_save_trap_vec and ofw_restore_trap_vec? Message-ID: <C23700C6-CB04-46CA-85CF-56CE1194F5B3@yahoo.com>
next in thread | raw e-mail | index | archive | help
With the recent discovery that for the IBM970 family
in sys/powerpc/aim/mp_cpudep.c :
/* Set HIOR to 0 */
__asm __volatile("mtspr 311,%0" :: "r"(0));
powerpc_sync();
needed to be in cpudep_ap_early_bootstrap in order to
avoid use of openfirmware's exception/trap handlers
in powerpc64 FreeBSD, there is the question:
For IBM970 family in aim (or at least PowerMac), should
ofw_save_trap_vec and ofw_restore_trap_vec be managing
HIOR instead of copying around vector code that is from
low memory?
This goes along with the modern DMAP address range placement
and what address ranges are invalid vs. valid when
openfirmware_core is in use. Currently (unless usefdt mode
is in use), ofwdump use (such as ofwdump -ap) produces:
timeout stopping cpus
[ thread pid 11 tid 100003 ]
Stopped at k_trap+0x28: stdu r31, r1, 0xfd50
db> bt
Tracing pid 11 tid 100003 td 0xc000000002251000
KDB: reentering
KDB: stack backtrace:
0x000000000119b370: at .kdb_backtrace+0x5c
0x000000000119b4a0: at .kdb_reenter+0x44
0x000000000119b520: at .trap+0x74
0x000000000119b6c0: at .powerpc_interrupt+0x2cc
0x000000000119b760: kernel DSI read trap @ 0xffffffffffb7f400 by =
.db_backtrace+0x40: srr1=3D0x9000000000001032
r1=3D0x119ba10 cr=3D0x24001044 xer=3D0 ctr=3D0x60cd24 =
r2=3D0x1583af0 sr=3D0x40000000 frame=3D0x119b790
0x000000000119ba10: at 0x1e95014
0x000000000119baa0: at .db_trace_thread+0x38
0x000000000119bb30: at .db_stack_trace+0x124
0x000000000119bbc0: at .db_command+0x3a8
0x000000000119bcf0: at .db_command_loop+0x74
0x000000000119bd70: at .db_trap+0x138
0x000000000119bef0: at .kdb_trap+0x194
0x000000000119bfc0: at .db_trap_glue+0x94
0x000000000119c040: at dbtrap+0x144
KDB: reentering
KDB: stack backtrace:
. . .
where it turns out that .db_backtrace+0x40 was for
the code:
/*
* Locate the next frame by grabbing the backchain ptr
* from frame[0]
*/
stackframe =3D *(db_addr_t *)stackframe;
So, the 0xffffffffffb7f400 seems to possibly be an
openfirmware stack address (backchain pointer) that
FreeBSD seems to be disallowing.
There could be implications of needing to switch how
address ranges are handled as part of ofw_save_trap_vec
and ofw_restore_trap_vec. (At least if ofwdump is to
be supported.)
=3D=3D=3D
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?C23700C6-CB04-46CA-85CF-56CE1194F5B3>