for paddr_t values under i386 PAE. Use ctob() instead.
Although amd64 is not affected by this vaddr_t vs paddr_t issue (both
having the same size), for the sake of completeness, switch to
ctob() when manipulating paddr_t/psize_t entities in amd64 machdep.c.
Compile tested for i386 and amd64. No regression expected.
- NBPD_* macros are set to the types that better match their architecture
(UL for i386 and amd64, ULL for i386 PAE) - will revisit when paddr_t is
set to 64 bits for i386 non-PAE.
- type fixes in printf/printk messages (Use PRIxPADDR when printing paddr_t
values, instead of %lx - paddr_t/pd_entry_t being 64 bits with PAE)
- remove casts that are no more needed now that Xen2 support has been dropped
Some fixes are from jmorse@ patches for PAE.
Compile + tested for i386 GENERIC and XEN3 kernels. Only compile tested for
amd64.
Reviewed by bouyer@.
See also http://mail-index.netbsd.org/tech-kern/2010/02/22/msg007373.html
on the amount of physical memory and limited by NMBCLUSTERS if present.
Architectures without direct mapping also limit it based on the kmem_map
size, which is used as backing store. On i386 and ARM, the maximum KVA
used for mbuf clusters is limited to 64MB by default.
The old default limits and limits based on GATEWAY have been removed.
key_registered_sb_max is hard-wired to a value derived from 2048
clusters.
- Replace most remaining uses of l_addr with uvm_lwp_getuarea() or lwp_getpcb().
- Amend assembly in ports where it accesses PCB via struct user.
- Rename L_ADDR to L_PCB in few places. Reduce sys/user.h inclusions.
This allows use of subr_disk_mbr on all archs. Default to it for
the rump disk component. No functional change for regular kernels.
(The other option would've been to include dkbad in disklabels
everywhere, but arguably this approach has less possible side-effects,
especially given that wedges and related magic will take over the
world any second now).
for memory between 16M and 4G. On large memory machine, this avoids
the 32bit-accessible memory being eaten by various kernel early allocation,
causing 32bit bus_dma(9) memory allocation to fail at boot time.
Tested on a system with 48GB RAM; based on netbsd-5 patch proposed on
port-amd64 3 days ago.
- 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).
- Add interrupt shielding (direct hardware interrupts away from the
specified CPUs). Not documented just yet but will be soon.
- Redo /dev/cpu time_t compat so no kernel changes are needed.
x86:
- Make intr_establish, intr_disestablish safe to use when !cold.
- Distribute hardware interrupts among the CPUs, instead of directing
everything to the boot CPU.
- Add MD code for interrupt sheilding. This works in most cases but there is
a bug where delivery is not accepted by an LAPIC after redistribution. It
also needs re-balancing to make things fair after interrupts are turned
back on for a CPU.
mpacpi_scan_pci() and mpbios_scan_pci() are identical code, so replace
them with mp_pci_scan().
Introduce mp_pci_childdetached(), which helps us to detach root PCI
buses that were enumerated either by MP BIOS or by ACPI.
Let us detach and re-attach PCI buses from mainbus0 on i386. This is
necessarily a work-in-progress, because testing detach and re-attach
is very difficult: to detach and re-attach the entire PCI tree on most
x86 computers that I own is not possible because some essential device
attaches under the PCI subtree: the console, com0, NIC, or storage
controller always attaches in the PCI tree.
- Merge i386 and amd64 syscall.c into x86. No functional changes intended.
Proposed on (port-i386 & port-amd64). Unfortunately, I cannot merge these
lists into the single port-x86. :(
