- Addresses the issue described in PR/38828.
- Some simplification in threading and sleepq subsystems.
- Eliminates pmap_collect() and, as a side note, allows pmap optimisations.
- Eliminates XS_CTL_DATA_ONSTACK in scsipi code.
- Avoids few scans on LWP list and thus potentially long holds of proc_lock.
- Cuts ~1.5k lines of code. Reduces amd64 kernel size by ~4k.
- Removes __SWAP_BROKEN cases.
Tested on x86, mips, acorn32 (thanks <mpumford>) and partly tested on
acorn26 (thanks to <bjh21>).
Discussed on <tech-kern>, reviewed by <ad>.
Import acpiwmi(4) from Jukka Ruohonen. From the PR:
Attached is a driver that implements ACPI WMI API:
http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx
The WMI is used to provide a generic interface for OEMs to use certain
platform/laptop-specific additions to the standard ACPI in a somewhat
portable way. These can be hotkeys for additional buttons, different event
handlers (wireless kill switch, lid switch, etc.), and so on. At least HP
and Acer use it by default nowadays.
The benefit of this interface would be portability. For an example, instead
of hpqlb(4) that works only with certain HP models, we could have a generic
HP WMI-driver that should work in theory across all HP laptops. On many new
laptops WMI may also be the only way to access laptop/manufacturer-specific
features.
It will replace azalia(4) after testing.
To use, comment out azalia in your kernel configuration and uncomment the
hdaudio and hdafg lines so it reads:
# Intel High Definition Audio
hdaudio* at pci? dev ? function ?
hdafg* at hdaudiobus?
You should also:
cd /dev
sh MAKEDEV audio
are now compiled in by default.
Note that MSR support in Xen depends on its version. rdmsr() should always
succeed, but wrmsr() to certain registers can end in a NOOP. In that case,
the error will be logged (see xm dmesg).
Setting CPU frequency (SpeedStep) requires Xen 3.3 with the option
cpufreq="dom0-kernel" passed down to hypervisor during boot.
Compiled and tested for SpeedStep under i386 for XEN3_DOM0 and XEN3PAE_DOM0
by jym@. amd64 was tested by Joel Carnat.
See also http://mail-index.netbsd.org/port-xen/2009/08/02/msg005213.html .
Commit requested by bouyer@.
%fs on i386, %gs on amd64 registers, before using them. Otherwise, it
might be invalid/garbage, eg. IPI can interrupt userspace.
- Explicitly initialize per-CPU emap generation number.
Thanks <drochner> for reporting and testing of patch.
activity of other threads will perform the TLB flush for the processes using
emap as a side effect. To track that, global and per-CPU generation numbers
are used. This idea was suggested by Andrew Doran; various improvements to
it by me. Notes:
- For now, zero-copy on pipe is not yet enabled.
- TCP socket code would likely need more work.
- Additional UVM loaning improvements are needed.
Proposed on <tech-kern>, silence there.
Quickly reviewed by <ad>.
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.
sometimes do not serve as memory barriers, allowing memory references to
bleed outside of critical sections. It's possible that this is the
reason for pkgbuild's longstanding crashiness.
This is not complete (atomic ops need some work too).
