Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed

Kostik Belousov kostikbel at gmail.com
Tue Jun 9 08:50:25 UTC 2009


On Thu, Jun 04, 2009 at 10:46:42AM +0100, Robert Watson wrote:
> On Wed, 3 Jun 2009, Jeff Roberson wrote:
> 
> >I have not tested anything other than amd64.  If you have a !amd64 
> >architecture, in particular any of the embedded architectures, I would 
> >really appreciate it.  Some of the arm boards postincrement the end 
> >address to allocate early memory and some pre-decriment.  Hopefully I got 
> >it right.
> 
> I appear to get an instant reboot early during the kernel startup on i386 
> with this patch applied:
> 
> OK lsmod
>  0x400000: /boot/kernel/kernel (elf kernel, 0xcd8920)
>   modules: elink.1 io.1 hptrr.1 ufs.1 kernel_mac_support.4 krpc.1 
>   nfslockd.1 nfssvc.1 nfsserver.1 nfslock.1 nfs.1 wlan_sta.1 wlan.1 
> wlan_wep.1 wlan_tkip.1 wlan_ccmp.1 wlan_amrr.1 if_gif.1 if_firewire.1 
> if_faith.1 ether.1 sysvshm.1 sysvsem.1 sysvmsg.1 firmware.1 kernel.800096 
> cd9660.1 isa.1 pseudofs.1 procfs.1 msdosfs.1 usb_quirk.1 ucom.1 uvscom.1 
> uslcom.1 uplcom.1 uether.1 cdce.1 usb.1 random.1 ppbus.1 pci.1 pccard.1 
> null.1 mpt_user.1 mpt_raid.1 mpt.1 mpt_cam.1 mpt_core.1 miibus.1 mem.1 
> isp.1 sbp.1 fwip.1 fwe.1 firewire.1 splash.1 exca.1 dcons.2 dcons_crom.1 
> cardbus.1 bt.1 ath.1 ast.1 afd.1 acd.1 ataraid.1 ad.1 ata_via.1 ata_sis.1 
> ata_sii.1 ata_serverworks.1 ata_promise.1 ata_nvidia.1 ata_netcell.1 
> ata_national.1 ata_micron.1 ata_marvell.1 ata_jmicron.1 ata_ite.1 
> ata_intel.1 ata_highpoint.1 ata_cyrix.1 ata_cypress.1 ata_cenatek.1 
> ata_ati.1 ata_amd.1 ata_adaptec.1 ata_ali.1 ata_acard.1 ata_ahci.1 atapci.1 
> ata.1 ahc.1 ahd.1 ahd_pci.1 ahc_pci.1 ahc_isa.1 ahc_eisa.1 agp.1 acpi_pci.1 
> acpi.1 scsi_low.1 cam.1
> OK boot -s
> <reboot>

The reason for the reboot is the fact that memory after physfree is not
mapped, and init386() tries to carve a piece of it for dpcpu for BSP.
Since IDT/exceptions are not initialized yet, generated #pf is translated
into triple fault.

Please, see the patch at
http://people.freebsd.org/~kib/misc/dcpu.1.patch
that allocates area for dpcpu0 using the same technique as the memory
for proc0kstack. Another minor issue is that per-cpu sysmaps were allocated
without clearing corresponding ptes, causing panic in pmap_zero_page etc
due to changed KVA layout.

AMD64 is fine thanks to the direct map.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090609/f02ef29c/attachment.pgp


More information about the freebsd-arch mailing list