| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
check for addresses below the PROM range but also those above.
|
|
|
|
|
|
|
|
|
|
| |
table. This is required in order to set obp-control-relinquished
within the PROM, allowing to safely read the OFW translations node.
Without this, f.e. a `ofwdump -ap` triggers a fatal reset error or
worse things on machines based on USIII and beyond.
In theory this should allow to remove touching %tba in cpu_setregs(),
in practice we seem to currently face a chicken and egg problem when
doing so however.
|
| |
|
|
|
|
| |
cheetah_cache_enable()).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to 43 bits so update TD_PA_BITS accordingly. For the most part this
increase is transparent to the existing code except for when reading
the physical address from ASI_{D,I}TLB_DATA_ACCESS_REG, which we
only do in the loader and which was already adjusted in r182478, or
from the OFW translations node.
While at it, ensure we are only taking valid OFW mapping entries
into account.
|
|
|
|
|
| |
I think this is necessary in order to make sure the workarounds
in {d,i}tlb_get_data_sun4u() work correctly.
|
| |
|
|
|
|
|
|
|
|
|
| |
As reported by several users on the mailing lists, applications like
screen(1) fail to properly handle ^S and ^Q characters. This was because
MPSAFE TTY didn't implement packet mode (TIOCPKT) yet. Add basic packet
mode support to make these applications work again.
Obtained from: //depot/projects/mpsafetty/...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When I migrated tty_compat.c to MPSAFE TTY, I just hooked it up to the
build and fixed it until it compiled and somewhat worked. It turns out
this was not the smartest thing, because the old TTY layer also had a
field called t_flags, which contained a set of sgtty flags.
This means our current COMPAT_43TTY code overwrites the TTY flags,
causing all strange problems to occur. Fix this code to use a new struct
member called t_compatflags. This commit may cause kern/127054 to be
fixed, but this still has to be tested/confirmed by the originator. It
has to be fixed anyway.
PR: kern/127054
|
| |
|
|
|
|
| |
Pointy hat to: kevlo
|
|
|
|
| |
Obtained from: Semihalf
|
| |
|
|
|
|
| |
Submitted by: Dmitry S. Luhtionov <mitya@cabletv.dp.ua>
|
| |
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
information out of it. As reported by Giorgos Keramidas.
|
|
|
|
|
| |
receiving a PIL_TICK interrupt. This change was erroneously
omitted in r182730.
|
|
|
|
| |
Obtained from: //depot/projects/vimage-commit2/...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Fix nmount(2) local privilege escalation. [08:08]
- Fix IPv6 remote kernel panics. [08:09]
Fix for [08:07] is merge of r181823.
Submitted by: kib [08:07], csjp [08:08], bz [08:09]
Reviewed by: peter [08:07], jhb [08:07]
Reviewed by: jinmei [08:09], rwatson [08:09]
Approved by: re (SA blanket)
Approved by: so (simon)
Security: FreeBSD-SA-08:07.amd64
Security: FreeBSD-SA-08:08.nmount
Security: FreeBSD-SA-08:09.icmp6
|
|
|
|
|
| |
Obtained from: NetBSD
MFC after: 3 days
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This allows one to do flow modulation similar to dummynet
between arbitrary nodes.
|
| |
|
|
|
|
|
|
|
|
|
| |
- add new diag commands: devinfo, sysinfo for U-Boot-style details about the system
configuration
- better memory info summary
- style corrections
Obtained from: Semihalf
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
frequencies (and having different cache sizes) so use the STICK
(System TICK) timer, which was introduced due to this and is
driven by the same frequency across all CPUs, instead of the
TICK timer, whose frequency varies with the CPU clock, to drive
hardclock. We try to use the STICK counter with all CPUs that are
USIII or beyond, even when not necessary due to identical CPUs,
as we can can also avoid the workaround for the BlackBird erratum
#1 there. Unfortunately, using the STICK counter currently causes
a hang with USIIIi MP machines for reasons unknown, so we still
use the TICK timer there (which is okay as they can only consist
of identical CPUs).
- Given that we only (try to) synchronize the (S)TICK timers of APs
with the BSP during startup, we could end up spinning forever in
DELAY(9) if that function is migrated to another CPU while we're
spinning due to clock drift afterwards, so pin to the CPU in order
to avoid migration. Unfortunately, pinning doesn't work at the
point DELAY(9) is required by the low-level console drivers, yet,
so switch to a function pointer, which is updated accordingly, for
implementing DELAY(9). For USIII and beyond, this would also allow
to easily use the STICK counter instead of the TICK one here,
there's no benefit in doing so however.
While at it, use cpu_spinwait(9) for spinning in the delay-
functions. This currently is a NOP though.
- Don't set the TICK timer of the BSP to 0 during at startup as
there's no need to do so.
- Implement cpu_est_clockrate().
- Unfortunately, USIIIi-based machines don't provide a timecounter
device besides the STICK and TICK counters (well, in theory the
Tomatillo bridges have a performance counter that can be (ab)used
as timecounter by configuring it to count bus cycles, though unlike
the performance counter of Schizo bridges, the Tomatillo one is
broken and counts Sun knows what in this mode). This means that
we've to use a (S)TICK counter for timecounting, which has the old
problem of not being in sync across CPUs, so provide an additional
timecounter function which binds itself to the BSP but has an
adequate low priority.
|
|
|
|
|
|
| |
in 182691, as the sparc64 version is going to be rototilled and sun4v
currently can't be verified to still work with the new sparc64 one
due to its overall state.
|
|
|
|
|
|
|
|
|
|
|
|
| |
search hint.
Global data (pointed by R2 on PowerPC) in principle is not guaranteed to be in
proximity of U-Boot heap (where the API signature is placed) accross different
architectures and platforms. Instead, use U-Boot stack pointer as a hint for
the search instead of the global data; this method tends to be more uniform
accross different platforms.
Obtained from: Semihalf
|
| |
|
|
|
|
| |
This will [soon] be needed for ARM.
|
| |
|
|
|
|
|
| |
Noticed by: des
MFC after: 3 days
|
|
|
|
| |
Approved by: rwatson (mentor)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to an integer divide by zero panic in the kernel, if the kernel was
run with hz<1000.
Neither i386, pc98, amd64 or sparc64 are affected in the currently
supported branches and default configuration.
Submitted by: Miikka Saukko, Ossi Herrala and Jukka Taimisto from
the CROSS project at Codenomicon Ltd. via CERT-FI.
Reviewed by: bz, rwatson
Security: CVE-2008-2464
MFC after: 8 hours
|
| |
|
| |
|
|
|
|
|
|
| |
loop pointed out by cognet@ that occurs when calling strtod() with a
string representing a number between DBL_MAX and 2*DBL_MAX, when the
rounding mode is anything other than the default.
|
|
|
|
| |
if() statement.
|
|
|
|
|
| |
semi-logical segregation of 'b' and 'h' doesn't seem to make sense and
makes it harder to read.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
contexts as rtld's malloc is not thread safe and is only supposed to be
called with exclusive bind lock already held.
The originating PR submitted a patch on top of different pre-requisite
workaroud for unsafe dlopen calls, and the patch was midief slighlty to apply
to stock sources for the purpose of this commit. Running rtld malloc from
unlocked contexts is a bug on its own.
PR: 126950
Submited by: Oleg Dolgov
|
|
|
|
|
|
|
| |
at least pass muster with the loader on 3.0.3
Note that this doesn't actually make it work as Xen 3.0.3
appears to disallow recursive mappings on the page directory
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
Obtained from: Chelsio Inc.
|