Subject: Re: Some PPC VM weirdness
To: Jochen Kunz <>
From: Matt Thomas <>
List: port-powerpc
Date: 02/19/2005 01:20:29
On Feb 18, 2005, at 2:17 PM, Jochen Kunz wrote:

> Hi.
> I am trying to bring NetBSB to the IBM RS/6000 43P-150 and B50. This is
> done as a platform inside port-ofppc. I replaced the port-ofppc
> speciffic bus_space(9) code with the generic code from
> sys/arch/powerpc/powerpc/bus_space.c. I imported the whole interrupt
> handling code from port-prep because this code is knowen to work. Some
> PCI and ISA MD bits here and there... At the moment I am tyring to 
> bring
> all this to live and play nicely together.

Good.  I've wanted to kill the ofppc bus_space for awhile now.  (Sorry 

> Now I get to the point where the kernel asks for the root device. When 
> I
> enter "pcn0" it hangs. I can brake into ddb(4) and a traceback give 
> some
> interresting adresses:
> root on pcn0
> nfs_boot: trying DHCP/BOOTP
> ~[MrPomeroy]%b
> Stopped at      netbsd:cpu_Debugger+0x10: lwz     r0, r1, 0x14
> db> t
> 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>

Does it timeout?  Is hardclock firing?  are you getting pcn interrupts? 
  did you tcpdump the network and see packets being transmitted?

> 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.)

What you are seeing is normal.  Remember that interrupts happen on 
their own stack and you seeing the transition to the interrupt stack 
there.  I should ddb about interrupts someday.

> Or is this a bug in ddb(4)? When I use e.g. "print/x start_init" I get
> the correct adresses.

It's normal.

> Also: The PPC VM stuff uses two 256 MB segments KERNEL_SR and 
> for UVM-KVA mappings. port-ofppc uses segments 13 and 14 for this. 
> (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?

Yes.  Though you really should make, if you can, that address range be 
a BAT.  mapiodev() will automatically see it's BAT mapped and return 
that instead.

> 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".

Really?  mapiodev shouldn't cause that to happen.  It locks up doing
the trace?  Or someplace else?

Matt Thomas                     email:
3am Software Foundry              www:
Cupertino, CA              disclaimer: I avow all knowledge of this