Re: Some PPC VM weirdness

["Nathan J. Williams" <nathanw%wasabisystems.com@localhost>]

Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost> writes:

> 0x00425f00: at comintr+0x61c
> 0x00425f50: at ext_intr_openpic+0x23c
> 0x00425fa0: at trapstart+0x8f4
> 0xd999ed90: at spinlock_switchcheck+0x3c
> 0xd999eda0: at Idle+0x24
> 0xd999edb0: at mi_switch+0x198
> 0xd999edf0: at ltsleep+0x460
> 0xd999ee30: at start_init+0x80
> 0xd999ef40: at cpu_switchto+0x44
> 0xd999ef50: at chrp_configuration+0x80793b84
> saved LR(0xfffffffb) is invalid.
> db> 
> 
> Running nm(1) on the kernel image gives this addresses:
> 001002b8 T Idle
> 003dc67c B chrp_configuration
> 00173da4 T comintr
> 00100540 T cpu_switchto
> 00313150 t ext_intr_openpic
> 0025ed4c T ltsleep
> 0025f9b0 T mi_switch
> 0024b978 T spinlock_switchcheck
> 00236cd4 t start_init
> 003aad90 S start_init_exec
> 00100aec T trapstart
> 
> Is this eligible? I always thought kernel text/data/bss is mapped 1:1.
> (I am no VM expert.)

In lines like "0xd999ef40: at cpu_switchto+0x44", the 0xd999ef40 is
the frame address (on the stack), not a numeric representation of the
instruction location.

> Also: The PPC VM stuff uses two 256 MB segments KERNEL_SR and KERNEL2_SR
> for UVM-KVA mappings. port-ofppc uses segments 13 and 14 for this. AFAIK
> (sys/arch/powerpc/include/oea/vmparam.h) So it is correct that a mapping
> done by sys/arch/powerpc/oea/oea_machdep.c:mapiodev() via
> uvm_km_valloc(9) ends in the rage 0xd0000000..0xdfffffff?

0xd0000000 - 0xefffffff, actually.

> There is some other VM interaction with ddb(4). When I do a BAT mapping
> for the PCI memory area where the pcn(4) resides bus_space_mapp(4) skips
> the mapiodev() / uvm_km_valloc(9) part and just returns the pysical
> address, as it is already mapped via BAT. In this case ddb(4) returns to
> its prompt after a "trace" command. When I don't add a BAT mapping for
> the PCI memory area of pcn(4), bus_space_mapp(4) uses mapiodev() /
> uvm_km_valloc(9) to map it into KVA. If uvm_km_valloc(9) is used the
> machines locks up hard and needs to be power cycled after "trace".

No particular ideas here, I'm afraid. I'm suspicious of mapiodev() not
setting any guard or cache flags, but it seems to work for other OEA
ports...

        - Nathan