On Sun, 1 Apr 2018, Dimitry Andric wrote:
On 31 Mar 2018, at 17:57, Bruce Evans wrote:
On Sat, 31 Mar 2018, Konstantin Belousov wrote:
the change to provide full 4G of address space for both kernel and
user on i386 is ready to land. The motivation for the work was to both
mitigate
On Sat, 31 Mar 2018, Konstantin Belousov wrote:
the change to provide full 4G of address space for both kernel and
user on i386 is ready to land. The motivation for the work was to both
mitigate Meltdown on i386, and to give more breazing space for still
used 32bit architecture. The patch was
On Mon, 14 Aug 2017, Rang, Anton wrote:
While glancing at fpu_kern_enter, I noticed that fpusave() uses the XSAVE
instruction, but not XSAVEOPT. The instance in cpu_switch.S is patched if
XSAVEOPT is available, but should we also be able to use XSAVEOPT in fpusave as
well? I can't see any re
On Thu, 23 Mar 2017, Stefan Esser wrote:
Am 22.03.17 um 21:30 schrieb Don Lewis:
I put together a Ryzen 1700X machine over the weekend and installed the
12.0-CURRENT r315413 snapshot on it a couple of days ago. The RAM is
DDR4 2400.
First impression is that it's pretty zippy. Compared to my
On Fri, 3 Aug 2012, Konstantin Belousov wrote:
On Fri, Aug 03, 2012 at 03:35:20PM +, Ming Qiao wrote:
> >Description:
> On the amd64 platform, if a 32-bit process ever manually set its rlimit,
> none of its 64-bit child or offspring will be able to get the full 64-bit
> rlimit anymore, even
On Sat, 28 Jul 2012, Konstantin Belousov wrote:
This was discussed on somewhat unwieldly thread on svn-src@ as a followup
to the commit r238755 which uncovered the problem in the first place.
Below is the commit candidate. It changes the fix in r238755 to use CPUID
instead of rmb(), since rmb()
On Thu, 19 Jul 2012, Konstantin Belousov wrote:
On Thu, Jul 19, 2012 at 01:10:29PM +1000, Bruce Evans wrote:
On Wed, 18 Jul 2012, Konstantin Belousov wrote:
On Wed, Jul 18, 2012 at 04:59:38PM +1000, Bruce Evans wrote:
On Wed, 18 Jul 2012, Konstantin Belousov wrote:
Putting the definiton in
On Wed, 18 Jul 2012, Konstantin Belousov wrote:
On Wed, Jul 18, 2012 at 04:59:38PM +1000, Bruce Evans wrote:
On Wed, 18 Jul 2012, Konstantin Belousov wrote:
Putting the definiton in machine/pcpu.h should avoid changing the
prerequistes for machine/pcb.h.
#ifndef _KERNEL
/* stuff that *used
On Wed, 18 Jul 2012, Konstantin Belousov wrote:
On Wed, Jul 18, 2012 at 02:36:16PM +1000, Bruce Evans wrote:
On Wed, 18 Jul 2012, Konstantin Belousov wrote:
...
The curpcb access shall be spelled as PCPU_GET(curpcb). Please note that
compiler is not allowed to cache the accesses, since there
On Wed, 18 Jul 2012, Konstantin Belousov wrote:
On Wed, Jul 18, 2012 at 10:32:23AM +1000, Bruce Evans wrote:
OK. Also, you can tell instruction that faulted, provided there are
no spurious faults. I think spurious faults can only occur for IRQ13
exception handling which was never supported
On Tue, 17 Jul 2012, Mark Linimon wrote:
The following reply was made to PR amd64/169927; it has been noted by GNATS.
I'm replying to Mark's forwarding of this, but gnats isn't in the Cc list
so it will not be noted by gnats, again.
On Wed, Jul 18, 2012 at 02:03:58AM +10
On Wed, 18 Jul 2012, Bruce Evans wrote:
On Wed, 18 Jul 2012, Bruce Evans wrote:
..
So I still want a single kernel exception handle that merges the statuses.
Merge the independent statuses modified by their independent controls:
return (fpetable[(fpsw & ((~fpcw & 0x3f
On Wed, 18 Jul 2012, Bruce Evans wrote:
On Tue, 17 Jul 2012, Konstantin Belousov wrote:
...
+ status =3D mxcsr & 0x3f;
+ control =3D (mxcsr >> 16) & 0x3f;
+ return (fpetable[status & (~control | 0x40)]);
The 0x40 bit doesn't exist in the mxcsr stat
On Tue, 17 Jul 2012, Konstantin Belousov wrote:
It was on my TODO list for long time. Lets handle amd64 first, both for
native and compat32.
I think the following should be somewhat better variant. I do leave
the fnclex there for x87.
Too large for me. Although the exceptions are different,
The following reply was made to PR amd64/169927; it has been noted by GNATS.
From: Bruce Evans
To: Ed Alley
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-amd64@freebsd.org
Subject: Re: amd64/169927: siginfo, si_code for fpe errors when error occurs
using the SSE math processor
Date: Tue, 17
On Tue, 17 Jul 2012, Ed Alley wrote:
Description:
According to sigaction(2) by choosing SA_SIGINGO as one of the sa_flags
one can catch sigfpe signals. What is returned to the signal handler
for the sigfpe is a structure defined in siginfo(3). Within that
structure: the si_code entry gives
On Wed, 29 Feb 2012, Peter Wemm wrote:
On Wed, Feb 29, 2012 at 12:40 AM, Bruce Evans wrote:
On Wed, 29 Feb 2012, Thomas D. Dean wrote:
On 02/28/12 22:03, Bruce Evans wrote:
But why would you want it? It is essentially unusable on sparc64,
since it is several thousand times slower than 80
On Tue, 28 Feb 2012, Thomas D. Dean wrote:
On 02/17/12 13:03, Thomas D. Dean wrote:
I have been reading the Core-i7 developers manual and looking at libm. I have
been trying to shoe horn some calculations between the sizes of fpu
instructions and libgmp.
I think there is little support for 1
On Wed, 29 Feb 2012, Thomas D. Dean wrote:
On 02/28/12 22:03, Bruce Evans wrote:
But why would you want it? It is essentially unusable on sparc64,
since it is several thousand times slower than 80-bit floating point
on i386. At equal CPU clock speeds, it is only about 1000 times slower
On Tue, 28 Feb 2012, Thomas D. Dean wrote:
On 02/28/12 22:03, Bruce Evans wrote:
#include
#include
int main() {
char buf[128];
__float128 x = sqrtq(2.0Q);
quadmath_snprintf(buf, sizeof buf, "%.45Qf",x);
printf("sin(%s) = ",buf);
quadmath_snprintf(buf, sizeof buf, "
The following reply was made to PR amd64/156464; it has been noted by GNATS.
From: Bruce Evans
To: Michirou &
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-amd64@FreeBSD.org
Subject: Re: amd64/156464: fpsetprec does not work
Date: Tue, 19 Apr 2011 06:02:02 +1000 (EST)
On Mon, 18 Apr
On Mon, 18 Apr 2011, Michirou & wrote:
Description:
In default, fpgetprec() returns FP_PE, but results show FP_PD.
if fpsetprec(FP_PE) is called, results are never changed.
amd64 uses SSE except for long doubles, so fpsetprec() and no effect
on the results for long doubles. Since the precis
On Wed, 6 Apr 2011, Kostik Belousov wrote:
On Tue, Apr 05, 2011 at 03:10:37PM -0700, Xin LI wrote:
Is there a place to find ABI information for GCC on FreeBSD?
Specifically, I'm looking for which registers has to be preserved
across function call? (Or do we follow System V Application Binary
On Fri, 19 Nov 2010, KOIE Hidetaka wrote:
Description:
when CPU frequency is throttled down, time command reports too low CPU usage
like this:
4.849u 0.000s 0:09.13 53.0% 9+5026k 0+0io 0pf+0w
100% is expected, because the process is extreamly CPU-intensive.
wall clock is precise.
systat
The following reply was made to PR amd64/152405; it has been noted by GNATS.
From: Bruce Evans
To: KOIE Hidetaka
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-amd64@freebsd.org
Subject: Re: amd64/152405: wrong user time is reported when CPU frequency
throttled.
Date: Sat, 20 Nov 2010 18:08:37
On Wed, 1 Sep 2010, John Baldwin wrote:
On Wednesday, September 01, 2010 6:50:03 am Andriy Gapon wrote:
The following reply was made to PR amd64/150170; it has been noted by GNATS.
From: Andriy Gapon
To: Gerald Pfeifer
Cc: Gerald Pfeifer , freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/
On Wed, 28 Jul 2010, Tijl Coosemans wrote:
While working on cc -m32 support I added the following to all headers
in sys/amd64/include to make sure none of my changes have an effect on
building world+kernel:
#ifndef __x86_64__
#error bla
#endif
This exposed some problems in sys/boot. The Makefi
On Tue, 27 Jul 2010, John Baldwin wrote:
On Tuesday, July 27, 2010 3:06:50 pm Bruce Evans wrote:
hwpmc(4) is far too featureful for me, yet perfmon(4) still does things
for me that hwpmc cannot do:
- from userland, without using the library, try undocumented unnamed
counters. There are a
On Tue, 27 Jul 2010, John Baldwin wrote:
On Tuesday, July 27, 2010 8:43:00 am pluknet wrote:
Hi.
What is a status of "options PERFMON" on amd64?
...
Looking at cvs I see amd64/include/perfmon.h was never here.
PERFMON in general is obsoleted by hwpmc(4) which is far more useful and
featurefu
On Tue, 27 Jul 2010, pluknet wrote:
What is a status of "options PERFMON" on amd64?
It is just a bug in the options file.
AFAIK PERFMON opt. was inherited from i386 port and never worked.
Does it make sense to wipe out perfmon part on amd64?
The inheritance is 1 line in the options file.
30 matches
Mail list logo
