Call rtc_set_ymdhms() from xen/xen/clock.c:xen_rtc_set() for xen3 dom0
kernels as the Xen3 hypervisor doesn't write the new date/time to the CMOS
by itself.
Now a XEN3_DOM0 kernel properly updates the CMOS time.
(ACPI kernel booted under qemu cannot detect devices):
- make MP SCANPCI function for ACPI_SCANPCI and MPBIOS_SCANPCI
return a number of attached PCI busses
- if no valid PCI busses are attached in the MP SCANPCI function,
try to probe and attach pci0 at mainbus as well as kernels
with no SCANPCI options
"Feel free to check it in" from jmcneill@.
Tested in pkgsrc qemu-0.9.1 (both i386 and x86_64) on NetBSD/i386.
Note original jmcneill's patch was posted on March:
http://mail-index.NetBSD.org/port-i386/2009/03/24/msg001281.html
and I also applied it to amd64:
http://mail-index.NetBSD.org/port-i386/2009/03/24/msg001283.html
but x86 MP attach functions have been reorganized by dyoung@ on April:
http://mail-index.NetBSD.org/source-changes/2009/04/17/msg219992.html
so I've modified the original patches to adapt the changes.
(mpacpi_scan_pci() and mpbios_scan_pci() have been merged into
common mp_pci_scan() in new arch/x86/x86/mp.c)
For netbsd-5 and netbsd-5-0 branches, the original patches should be
applied cleanly, and they have been tested by abs@ on a selection of
i386 boxes and in qemu.
config file.
The use of MSGBUGADDR was already prepared in powerpc/oea/pmap.c years ago,
but was never used and missing powerpc/oea/oea_machdep.c. The option will
be used by port amigappc.
could be better, but i just copied them from the old intrnames in locore.
i benchmarked this with a simple test of ircii ./configure && make, to see
if the additional load/store & arith would cause any noticeable degradation
as the change also converts 32 bit counters to 64 bits. amusingly, the
only trend i saw in this was that for both portions, i see a consistent
(across at least 8 runs) benefit of about 0.8% improvement. ie, the newer
larger code size / counter size code actually runs faster for some reason..
maybe there's a cacheline effect in the size of the code?
XXX the current implementation depends on a couple of things:
XXX - ev_count member of evcnt{} is first and has offset 0
XXX - that sizeof(struct evcnt) equals 32
XXX if these are not true, locore.s has #error's to catch it
from tsutsui
- for MP kernels, copy the loop to find the bootcpu in mainbus_attach()
into getcacheinfo_obp() so we can get cache properties on the bootcpu
before calling main()
- in getcpuinfo(), move the call of getmid() before the call to
getcacheinfo() so that the above change to getcacheinfo_obp() can work
- move the struct cpu_info setup to the end of the initial kernel page
setup and don't access this space until after we have switched to the
kernel pagetables
- revive most of the old CPUINFO_VA alignment/congruency code from the
old alloc_cpuinfo_global_va() function, and ensure that all cpuinfo
structures are sanely aligned. this makes hypersparc work again
- introduce a new way to free the wasted pages back to UVM, as we can't
simply uvm_unmap() them this early in bootstrap
i believe that the first used cpuinfo_data page is still being wasted,
but i haven't checked.
