| Age | Commit message (Collapse) | Author |
|---|
|
hardware, like SUN4M is for sun4m hardware.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
recently on other architectures.
|
|
(which I will leave for Dale since it needs special handling).
From NetBSD (and same as sparc64). espie@ OK
|
|
|
|
|
|
|
|
|
|
Add intvec counting.
Adapt to openbsd WOPEN handling.
All untested but does compile...
|
|
sigsegv deliveries; vm_ssize is in pages, apparently
|
|
with gcc3.2, and add a ';' for a case statement as it requests.
|
|
|
|
regs before rfir
|
|
which straddled the last register first stack parameter.
|
|
(with pending fxp BE diffs)
|
|
simpler, indeed; after art's suggestion and by looking into his diffs oneyed
|
|
|
|
|
|
FreeBSD commit messages say:
Some BIOSs are using MTRR values that are only documented under NDA
to control the mapping of things like the ACPI and APM into memory.
The problem is that starting X changes these values, so if something
was using the bits of BIOS mapped into memory (say ACPI or APM),
then next time they access this memory the machine would hang.
This patch refuse to change MTRR values it doesn't understand,
unless a new "force" option is given. This means X doesn't change
them by accident but someone can override that if they really want
to.
PR: 28418
Tested by: Christopher Masto <chris at netmonger dot net>,
David Bushong <david at bushong dot net>,
Santos <casd at myrealbox dot com>
Make the MTRR code a bit more defensive - this should help people
trying to run X on some Athlon systems where the BIOS does odd things
(mines an ASUS A7A266, but it seems to also help on other systems).
Here's a description of the problem and my fix:
The problem with the old MTRR code is that it only expects
to find documented values in the bytes of MTRR registers.
To convert the MTRR byte into a FreeBSD "Memory Range Type"
(mrt) it uses the byte value and looks it up in an array.
If the value is not in range then the mrt value ends up
containing random junk.
This isn't an immediate problem. The mrt value is only used
later when rewriting the MTRR registers. When we finally
go to write a value back again, the function i686_mtrrtype()
searches for the junk value and returns -1 when it fails
to find it. This is converted to a byte (0xff) and written
back to the register, causing a GPF as 0xff is an illegal
value for a MTRR byte.
To work around this problem I've added a new mrt flag
MDF_UNKNOWN. We set this when we read a MTRR byte which
we do not understand. If we try to convert a MDF_UNKNOWN
back into a MTRR value, then the new function, i686_mrt2mtrr,
just returns the old value of the MTRR byte. This leaves
the memory range type unchanged.
I have seen one side effect of the fix, which is that ACPI calls
after X has been run seem to hang my machine. As running X would
previously panic the machine, this is still an improvement ;-)
PR: 28418, 25958
Tested by: jkh, Christopher Masto <chris at netmonger dot net>
|
|
<miod> well, my comments are "looks sane, works for me, ok to commit"
|
|
|
|
|
|
|
|
|
|
Last bits of diff generated by Chris Kuethe.
|
|
Diff generated by Chris Kuethe.
|
|
|
|
|
|
pages into the queue already containing allocated pages.
breaks i386:setup_buffers() because of this.
|
|
|
|
|
|
|
|
are signaled through the exception trap w/ invalid opcode marked
instruction in the exception registers, not through the emulation
trap (as long as the fpu is enabled, of course).
parse emulation from the exception trap as well as the emulation
trap and fix the dispatcher into usable condition.
parse invalid op exception on trap and signal the user appropriately.
reset the exception on exec and for child on fork.
the later is appropriate since exceptions are delayed until next
fpu instruction, which was in the parent indeed, let him get it.
save parent's fpu context on fork before cipying it, if the
parent owned the fpu.
|
|
be put in the cardbus register which really work instead of crashing the
machine. if_dc @cardbus now works, xl@cardbus will configure, but does
not work properly (endian?) wdc should work fine, but has not been tested
recently.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to update the colormap, as it causes _some_ machines to freeze solid;
could not be reproduced here, thanks to Thomas Koellmann (koellmann
at gmx dot net) for reporting this problem and testing this change.
ok deraadt@
|
|
to bring it in a prom-friendly mode upon halting the system, like the
other > 8 bit framebuffers do.
|
|
|
|
Testing by Brandon Creighton and Jim Uhl.
|
