| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
in the same order as it's set in ate_set_mac.
I remember a discussion about this on -arm, but apparently nothing was done.
Warner, is this wrong ?
X-MFC After: proper review
|
|
|
|
|
|
| |
at the beginning of the RAM).
MFC After: 1 week
|
| |
|
| |
|
|
|
|
|
|
| |
yet connected to the build, but reduces diffs to p4 repo.
Obtained from: NetBSD
|
|
|
|
| |
got them from NetBSD).
|
| |
|
|
|
|
|
|
| |
_ARM_ARCH_5E instead.
MFC After: 3 days
|
|
|
|
| |
MFC After: 3 days
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support machines having multiple independently numbered PCI domains
and don't support reenumeration without ambiguity amongst the
devices as seen by the OS and represented by PCI location strings.
This includes introducing a function pci_find_dbsf(9) which works
like pci_find_bsf(9) but additionally takes a domain number argument
and limiting pci_find_bsf(9) to only search devices in domain 0 (the
only domain in single-domain systems). Bge(4) and ofw_pcibus(4) are
changed to use pci_find_dbsf(9) instead of pci_find_bsf(9) in order
to no longer report false positives when searching for siblings and
dupe devices in the same domain respectively.
Along with this change the sole host-PCI bridge driver converted to
actually make use of PCI domain support is uninorth(4), the others
continue to use domain 0 only for now and need to be converted as
appropriate later on.
Note that this means that the format of the location strings as used
by pciconf(8) has been changed and that consumers of <sys/pciio.h>
potentially need to be recompiled.
Suggested by: jhb
Reviewed by: grehan, jhb, marcel
Approved by: re (kensmith), jhb (PCI maintainer hat)
|
|
|
|
|
|
|
|
|
|
| |
After discussion with Sam, switch back to use firmware(9) instead of
having the firmware in hex format.
Put the binary firmware uuencoded into sys/contrib/dev/npe, and slap a
LICENSE file, as found on the Intel website.
Approved by: re (blanket), mux (mentor)
MFC After: 1 week
|
|
|
|
|
|
|
| |
hexed into our tree, instead of requiring the user to download it.
Approved by: re (blanket)
MFC after: 1 week
|
|
|
|
|
| |
Spotted out by: Marius Nuennerich <marius.nuennerich AT gmx D0T de>
Approved by: re (blanket)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ways:
(1) Cached pages are no longer kept in the object's resident page
splay tree and memq. Instead, they are kept in a separate per-object
splay tree of cached pages. However, access to this new per-object
splay tree is synchronized by the _free_ page queues lock, not to be
confused with the heavily contended page queues lock. Consequently, a
cached page can be reclaimed by vm_page_alloc(9) without acquiring the
object's lock or the page queues lock.
This solves a problem independently reported by tegge@ and Isilon.
Specifically, they observed the page daemon consuming a great deal of
CPU time because of pages bouncing back and forth between the cache
queue (PQ_CACHE) and the inactive queue (PQ_INACTIVE). The source of
this problem turned out to be a deadlock avoidance strategy employed
when selecting a cached page to reclaim in vm_page_select_cache().
However, the root cause was really that reclaiming a cached page
required the acquisition of an object lock while the page queues lock
was already held. Thus, this change addresses the problem at its
root, by eliminating the need to acquire the object's lock.
Moreover, keeping cached pages in the object's primary splay tree and
memq was, in effect, optimizing for the uncommon case. Cached pages
are reclaimed far, far more often than they are reactivated. Instead,
this change makes reclamation cheaper, especially in terms of
synchronization overhead, and reactivation more expensive, because
reactivated pages will have to be reentered into the object's primary
splay tree and memq.
(2) Cached pages are now stored alongside free pages in the physical
memory allocator's buddy queues, increasing the likelihood that large
allocations of contiguous physical memory (i.e., superpages) will
succeed.
Finally, as a result of this change long-standing restrictions on when
and where a cached page can be reclaimed and returned by
vm_page_alloc(9) are eliminated. Specifically, calls to
vm_page_alloc(9) specifying VM_ALLOC_INTERRUPT can now reclaim and
return a formerly cached page. Consequently, a call to malloc(9)
specifying M_NOWAIT is less likely to fail.
Discussed with: many over the course of the summer, including jeff@,
Justin Husted @ Isilon, peter@, tegge@
Tested by: an earlier version by kris@
Approved by: re (kensmith)
|
|
|
|
|
|
| |
least the minimum asked by the driver.
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
|
|
| |
IQ31244 version.
Approved by: re (blanket)
|
|
|
|
|
| |
MFC After: 1 week
Approved by: re (blanket)
|
|
|
|
|
| |
Approved by: re (blanket)
Beer from: jadawin
|
|
|
|
| |
Approved by: re@ (blanket)
|
|
|
|
| |
Approved by: re@ (blanket)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of pages don't sum to anywhere near the total number of pages on amd64.
This is for the most part because uma_small_alloc() pages have never been
counted as wired pages, like their kmem_malloc() brethren. They should
be. This changes fixes that.
It is no longer necessary for the page queues lock to be held to free
pages allocated by uma_small_alloc(). I removed the acquisition and
release of the page queues lock from uma_small_free() on amd64 and ia64
weeks ago. This patch updates the other architectures that have
uma_small_alloc() and uma_small_free().
Approved by: re (kensmith)
|
|
|
|
|
|
|
|
|
|
| |
Fix a few while (!uart_getreg() & SR1_TNF) when
while (!(uart_getreg() & SR18TNF)) was really meant.
This driver should die anyway, it's awful, and uart_ns8250 should be fine
for the StrongArm 1110. I'll kill it later.
Submitted by: Mikhael Skvorts
Approved by: re (blanket)
|
|
|
|
|
|
|
| |
optimizing, gcc4 doesn't always do so.
Reported by: Nathan Whitehorn
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
|
|
|
| |
In PREREAD, just invalidate the cache lines, and do not write back them, if
the buffer is properly aligned.
Approved by: re (blanket)
|
|
|
|
|
| |
Approved by: re (blanket)
Pointy hat to: cognet
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
|
|
| |
required for ULE.
Approved by: re (blanket)
|
|
|
|
|
|
|
| |
only USB 1.1 speeds available, but this shouldn't hurt. Now that we have
working usb support for this board, this is a natural followup.
Approved by: re (kensmith)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
7 months. You must have JP6 in the 1-2 position to supply power to the
USB devices, but I've used uftdi, uplcom and umass successfully. If you
have it in 2-3, then nothing will show up. Also, if you have the FQPA
packaging for the AT91RM9200 (like the KN9202 boards have), you will get
the following message
uhub0: device problem (IOERROR), disabling port 2
due to a hardware erratum. It is safe to ignore as it is about pins that
aren't brought out on the FQPA package and aren't proeprly terminated either.
Alas, there's no register to read to tell the FQPA from the BGA versions.
Submitted by: Daan Vreeken
Approved by: re (kensmith)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
revision 1.66
date: 2007/07/31 06:23:26; author: marcel; state: Exp; lines: +2 -2
Fix backward compatibility of the "old" (i.e. FreeBSD6) lseek
syscall. It was broken when a new lseek syscall was introduced.
The problem is that we need to swap the 32-bit td_retval values
for the __syscall indirect syscall when the actual syscall has
a 32-bit return value. Hence, we need to exclude lseek(2). And
this means the "old" lseek(2) as well -- which we didn't.
Based on a patch from: grehan@
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
|
|
| |
except it uses different registers.
Approved by: re (blanket)
|
|
|
|
|
|
| |
Thanks to Intel for providing sample hardware.
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
|
|
| |
when available.
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
|
|
| |
Make sure we cache entries in the L2 cache.
Approved by: re (blanket)
|
|
|
|
|
|
|
|
|
|
| |
a proper solution.
- Add a dummy entry point which just calls the C entry points, and try to make
sure it's the first code in the binary.
- Copy a bit more than func_end to try to copy the whole load_kernel()
function. gcc4 puts code behind the func_end symbol.
Approved by: re (blanket)
|
|
|
|
|
|
| |
CPU except Xscale core 3.
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
| |
Approved by: re (blanket)
|