Date: Mon, 20 Jun 2011 13:22:31 -0400 From: Andrew Duane <aduane@juniper.net> To: "mips@freebsd.org" <mips@freebsd.org> Subject: Changes to cpu_mask in octeon_mp.c Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB57ECF8509@EMBX01-WF.jnpr.net>
next in thread | raw e-mail | index | archive | help
I'm merging in some changes that were recently made to octeon_mp.c, and wan= t to clean it up. I had changed the platform_cpu_mask to return the Cavium = hardware register, rather than octeon_bootinfo->core_mask. This was part of= my cleanup to remove octeon_bootinfo from anywhere besides the boot code (= for bootstrap agnosticity). I was a little uncomfortable with returning ALL= cores that existed, in case core_mask was set to some sparse mask. I see i= n the log comments that this very topic was discussed. I can put in a check to see if octeon_bootinfo supplied a core_mask at boot= time, and mask the hardware register with that. IIRC, Cavium didn't really= say whether having non-contiguous cores was a possibility (e.g. a 12 core = CPU where 1 or 2 cores failed DVT and were masked out and sold as a 10-core= ). If this is a concern, I will figure something out for my octeon_mp.c; octeo= n_bootinfo will no longer exist outside the octeon_machdep.c file. BTW, Oleksandr had said he had committed my version, but the merge seems to= be broken here which indicates he didn't? ................................... Andrew Duane Juniper Networks o +1 978 589 0551 m +1 603-770-7088 aduane@juniper.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC6674AB7BC78549BB231821ABF7A9AEB57ECF8509>