| Age | Commit message (Collapse) | Author |
|---|
|
code it was originally copied from.
ok kettenis@
|
|
impossible that there is a pending register window trap that we need to
fix up in this case.
|
|
From Alexander Frolkin.
|
|
|
|
|
|
cardbus_attach_args so we can switch to using proper pci config
space functions instead of callback based wrappers.
ok oga@ krw@ kettenis@
|
|
pointer to the pccbb softc, to distinguish it from a pci_chipset_tag_t
which can be passed to the normal pci functions.
Suggested by and ok kettenis@
|
|
cache line flushes
ok miod
|
|
Found by clang static analyser.
|
|
Found by Yao Zhao (dragonlinux at gmail dot com)
|
|
|
|
for a long time (if ever?), so send it to the Attic.
"with prejudice" miod@; GENERIC reminder from kettenis@
|
|
In uvm_pageout() we called pmap_page_protect(VM_PROT_NONE) with the
pageqlock held, when pageqlock was a mutex this caused recursion panics.
The problem was that freeing the pv_entries called uvm_km_free, which
needed the pageqlock itself. Fix this by changing the homegrown pool
allocator to just use the normal pool functions, then change the
cacheability as necessary.
That I know of, this leaves m68k still to be fixed, maybe arm bootstrap
(but I do not think so).
Tested by NicM@ on a 4m machine. ok miod@
|
|
ok kettenis@ miod@
|
|
|
|
|
|
|
|
Don't trunc_page when determining the highest address to alloc. it is
not what pglistalloc expects and pmemrange will fail that allocation.
For consistency, if we fail to alloc under 16meg then alloc high as
assume we'll bounce (same as i386 and amd64)
ok deraadt@
|
|
ok deraadt@
|
|
bus_dmamem_map can fail for a myriad of reasons already, so panicing if
pmap fails is just impolite. other archs will be forthcoming.
ok krw@, art@ before lock
|
|
note, only the pcidevs for those chipsets that have been tested are
enabled for now. Please contact me if you have a r600 or r700 that does
not attach radeondrm. Only the 2D/Xv bits are here. I'm ambivalent about
the implementation of the RADEON_CS ioctl for OpenGL since that was
originally kernel-modesetting only. When we update mesa I shall think
about (and test) it.
Tested by quite a number. Zero bad reports. Nagged perpetually by
robert@ (and probably others) for months now.
|
|
installed on a softraid volume. This is work in progress but can continue
in tree.
ok marco@
|
|
Also add a new optional metadata type for boot data. This is the first
step (of many) towards being able to boot from softraid volumes.
WARNING: This version of the softraid metadata is not compatible with
previous versions. As a result, any softraid volumes created with older
kernels will not assemble. Data on existing softraid volumes should be
backed up before upgrading. The volume should then be recreated and the
data restored.
ok marco@
|
|
|
|
- BCM5709S (id from FreeBSD, for fibre bnx)
- BCM5481/5482 (id from Linux, low-power PHY, for embedded boards etc)
|
|
|
|
|
|
Based on a comparison with the apm code.
ok deraadt@, kettenis@
|
|
1) when you have a wrapper function in a dmatag that just calls the
_bus_dmamem original, you don't need it, just put the original function
in the tag
2) don't trunc_page the avail_end/ISA_BOUNCE_THRESHOLD stuff (see icb
for a discussion of why this is wrong about 00:00 gmt). make i386 and
amd64 both do this the same (the amd64 way is cleaner and makes the
third diff actually possible without a lot of pain). just do
dmamem_alloc_range(0, threshold) and if that fails do a alloc_range(0,
-1) and assume we'll bounce to pick up the pieces. Also using avail_end
for alloc_range is not nice (miod has been trying to avoid these abuses
iirc), so just use (paddr_t)-1, which is equivalent since you want "any"
memory.
3) now this is the funny one. consider point 2. then considering why
using the same bloody function to allocate your bouncebuffer is just
f'ing wrong. instead allocate with alloc_range(0, threshold) to make
sure that our bouncebuffer is actually uner 16megs.
ok deraadt@, kettenis@. Tested by several people.
|
|
ncpufound before counting, because it defaults to 1 (for those
architectures which do not count)
ok kettenis
|
|
ok armani
|
|
|
|
phones.
ok armani
|
|
ok kettenis@
|
|
|
|
|
|
|
|
|
|
list walkers in sysctl that can block. As a reward, no more vslock.
With some feedback from art, guenther, phessler. ok guenther.
|
|
|
|
|
|
|
|
|
|
emulation to not return values either.
i think this is right, but cant test just yet.
found by deraadt@
|
|
ok kettenis@ beck@ (tentatively) and ariane@. deraadt asked for it to be
commited now.
original commit message:
extend uvm_page_physload to have the ability to add "device" pages to
the system.
This is needed in the case where you need managed pages so you can
handle faulting and pmap_page_protect() on said pages when you manage
memory in such regions (i'm looking at you, graphics cards).
these pages are flagged PG_DEV, and shall never be on the freelists,
assert this. behaviour remains unchanged in the non-device case,
specifically for all archs currently in the tree we panic if called
after bootstrap.
ok art@ kettenis@, beck@
|
|
|
|
|
|
Found out the hard way by Laurent ``bucky'' Lavaud and myself.
Input by claudio@, ok dlg@
|
|
supported by the processor and use it to calculate the mask used for
manipulating the MTRR registers. If CPUID leaf function 0x80000008 isn't
supported by the processor, default to the 36-bit mask we used before.
Fixes issues on machines that don't have a 36-bit physical address space
like Intel Atom and all 64-bit AMD CPUs.
ok weingart@, deraadt@
|
|
OK michele@
|
