| Age | Commit message (Collapse) | Author |
|---|
|
- introduce an interface for widget drivers to ask the xbow to map arbitrary
views of their address space, in addition to the low 16MB. This operation
may fail or map a subset range of what the caller asked for, depending on
the platform we're running on.
- use this in xbridge to set up views on the direct memory and i/o spaces,
to map devices resources when they don't fit in one of the devio small
ranges (limited to 2MB anyway). These views are only allocated when
devio can't do the job, so as not to consume too many resources on
Origin family systems where such views are scarce resources (and
shared accross the whole crossbow).
This makes pci devices with large resource needs configure correctly.
While there, fix programming of 64 bit memory BAR; this makes bge(4)
work.
Tested on Octane (with Bridge revision < 4 and >= 4), Origin 200 (Bridge >= 4)
and Fuel (XBridge).
ok deraadt@
|
|
to store the bootblocks.
ok deraadt@
|
|
ATI Radeon 7000 chip on them). While there, make gfxp(4) depend on rasops32
just in case somebody removes other framebuffers that pull this in from their
kernel config.
ok deraadt@, miod@
|
|
whenever possible for devices with both i/o and memory resources; still
doesn't allow more than 2MB of mappings per device in each space, though.
|
|
Octane support. The Octane being a single-node system, address space is
ludicrous enough to allow the whole address space of every widget to be
directly accessible in whole, using the address bits reserved to nasid.
However, on IP27 and IP35, things do not work this way - while we still have
the low 16MB address space of each widget available (the so-called
``short window''), access to other parts of the wiget address space is done
through translation slots (IOTTE) at the Hub I/O space level, on a per-node
basis.
Given the imminent release lock, give up completely on ``large'' mappings
of widgets, and restrict ourselves to short window operation, all the time
(thus reinforcing the use of devio registers to map pci resources on xbridge).
A proper interface to request mappings of specific widget areas, either
directly on Octane, or through IOTTE if available on Origin, will appear
post-release.
No functional change (except from silently repairing Octane support which the
previous xbridge commit silently broke).
|
|
|
|
the GENERIC kernel growth; verified to not conflict with old prom on sun4.
ok deraadt@
|
|
|
|
I/O resources, via devio.
Unfortunately it works as badly as when using the large window, so the bugs
I am hunting must come from elsewhere.
|
|
|
|
needs palette support.
|
|
matching on pci id, and if no match is found, on pci subsystem id, match
on openfirmware device names (which amounts to a pci id AND subsystem id
exact match).
This makes XVR-500 cards (``bobcat'') run without acceleration. Which is
better than trying to use ``jfb'' acceleration and fail.
ok kettenis@
|
|
As long as I can't figure out what endianness knobs I need to frob to make
I/O and memory accesses through the large window work as intended, we are
stuck to devio I/O mappings only...
|
|
the loop. No functional change.
|
|
it if it does not fit in our extent, and force a suitable address. Prevents
extent sanity check panics with some cards.
|
|
be disabled with some UKC tinkering.
|
|
The change was unrelated to v7 support, it was a cleanup item. For some reason
this breaks ksyms on zaurus. however zaurus uses the old loadfile that
is not fully synced with libsa
|
|
p->p_stats earlier, and loss of information there can cause spurious
SIGPROF or SIGVTALRM to be delivered. ok kettenis@
|
|
|
|
|
|
partitions; since all of them are DPME partitions, they might not be
contiguous but that's the best we can do at the moment.
|
|
|
|
|
|
test built and booted by me
ok marco@, deraadt@
|
|
case it is not OK to DPRINTF, so delete that code. Found by dhill
ok marco dhill
|
|
firmwares into the smaller (and larger) media
ok krw
|
|
Everything that worked before should still work so in it goes. Newer
boards (2300, 2400) may now work but are still a work in progress.
Thanks to many testers but especially kettenis@ for finding a show
stopper bug and stomping it.
ok deraadt@
|
|
Tested by nick@
|
|
process waiting on getblk when all ATE are exhausted, despite the exhaustion
being transient; I fear the only way to skirt this is to use bounce buffers.
|
|
is still unhappy due to ``interferences'' between the L1 console and the
brick's serial ports, unfortunately.
|
|
|
|
"sure" miod@
|
|
|
|
|
|
makes the sigreturn regress test pass, as well as todd@'s ``run
sh -c "trap exit 2 3;while :; do sleep 120; done", then press ^C'' test pass.
Since userland setjmp uses sigcontext, the kernel will still support the
old layout for a while (until libc is fixed and a reasonable grace period
is over).
|
|
|
|
|
|
watchdog timer.
Copied over from MI hme(4).
Tested by nick@. From Brad.
|
|
|
|
ok miod@ drahn@
|
|
|
|
|
|
1 and above, so report them as such.
|
|
a diff by kettenis but he is gone for a day or so
|
|
|
|
allocator).
"i can't see any obvious problems" oga
|
|
separately).
a change at or just before the hackathon has either exposed or added a
very very nasty memory corruption bug that is giving us hell right now.
So in the interest of kernel stability these diffs are being backed out
until such a time as that corruption bug has been found and squashed,
then the ones that are proven good may slowly return.
a quick hitlist of the main commits this backs out:
mine:
uvm_objwire
the lock change in uvm_swap.c
using trees for uvm objects instead of the hash
removing the pgo_releasepg callback.
art@'s:
putting pmap_page_protect(VM_PROT_NONE) in uvm_pagedeactivate() since
all callers called that just prior anyway.
ok beck@, ariane@.
prompted by deraadt@.
|
|
three
commits:
1) The sysctl allowing bufcachepercent to be changed at boot time.
2) The change moving the buffer cache hash chains to a red-black tree
3) The dynamic buffer cache (Which depended on the earlier too).
ok on the backout from marco and todd
|
|
ok deraadt@ kettenis@
|
|
> extend uvm_page_physload to have the ability to add "device" pages to the
> system.
since it was overlayed over a system that we warned would go "in to be
tested, but may be pulled out". oga, you just made me spend 20 minutes
of time I should not have had to spend doing this.
|
