On Sat, Feb 04, 2012 at 10:52:03AM +0100, Mario Fleischmann wrote:
Hi Konstantin,
I hope you don't mind me writing to you directly, but I'm having a hard
time finding information on Google.
You would get much higher chances of getting response if you post on the
public list Cc:ing
On Sat, Feb 04, 2012 at 02:10:25PM +0100, G??t Andr??s wrote:
Hi,
This is from a Linux machine:
processor : 15
vendor_id : AuthenticAMD
cpu family: 21
model : 1
model name: AMD Opteron(tm) Processor 4280
stepping : 2
microcode : 0x6000624
cpu MHz
On Sat, Feb 04, 2012 at 08:28:26AM -0800, Dennis Glatting wrote:
I am confused by the Bulldozer comment and what FreeeBSD 9.0 reports.
#1:
CPU: AMD FX(tm)-8150 Eight-Core Processor(4017.99-MHz
K8-class CPU)
Origin = AuthenticAMD Id = 0x600f12 Family = 15 Model = 1
On Sat, Feb 04, 2012 at 08:45:48AM -0800, Dennis Glatting wrote:
On Sat, 2012-02-04 at 08:38 -0800, Dennis Glatting wrote:
On Sat, 2012-02-04 at 18:33 +0200, Konstantin Belousov wrote:
On Sat, Feb 04, 2012 at 08:28:26AM -0800, Dennis Glatting wrote:
I am confused by the Bulldozer comment
On Thu, Mar 22, 2012 at 02:01:59PM -0400, Jeremiah Lott wrote:
We've been seeing some panics and deadlocks that appear to be related to
getting a page fault when accessing a page after it has been wired (on
amd64). All the ones we have seen are related to sysctl handlers that call
On Thu, Mar 22, 2012 at 05:09:15PM -0400, Jeremiah Lott wrote:
On Mar 22, 2012, at 2:34 PM, Konstantin Belousov wrote:
This should be the issue fixed in the r233291.
Agreed. I pulled back r233291 as well as r223886, r223888, and r223889 into
my 8.2-based branch and it seems to fix
On Wed, May 16, 2012 at 11:10:23PM -0700, mahdieh salamat wrote:
Hi all. Is there any way to hide or change the FreeBSD/adm64 message that
appear before login?
The greeting line for getty(1) is configured in /etc/gettytab, see
gettytab(5). You are interested in the im and lm properties.
On Mon, Jul 09, 2012 at 11:24:52AM -0400, John Baldwin wrote:
On Sunday, July 08, 2012 11:02:25 am Konstantin Belousov wrote:
Please find at
http://people.freebsd.org/~kib/misc/xsaveopt.1.patch
a patch to finally add suport for using XSAVEOPT for our amd64 context
switch code. See Intel
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.
diff --git a/sys/amd64/amd64/fpu.c b/sys/amd64/amd64/fpu.c
index a7812b7..34cf8d4 100644
---
On Wed, Jul 18, 2012 at 02:03:58AM +1000, Bruce Evans wrote:
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:
On Tue, Jul 17, 2012 at 08:09:15PM +0300, Konstantin Belousov wrote:
On Wed, Jul 18, 2012 at 02:03:58AM +1000, Bruce Evans wrote:
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
On Wed, Jul 18, 2012 at 10:32:23AM +1000, Bruce Evans wrote:
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,
On Wed, Jul 18, 2012 at 02:36:16PM +1000, Bruce Evans wrote:
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
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 machine/pcpu.h should avoid changing
On Sat, Jul 28, 2012 at 09:36:43AM -0700, Jim Harris wrote:
On Saturday, July 28, 2012, Konstantin Belousov wrote:
Hi,
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
On Sun, Jul 29, 2012 at 02:58:36PM +1000, Bruce Evans wrote:
On Sat, 28 Jul 2012, Konstantin Belousov wrote:
...
Handling of usermode will follow later.
I hesitate to mention that this doesn't pessimize all uses of rdtsc:
- x86/isa/clock.c uses raw rdtsc32() for DELAY()
There, fence
The following reply was made to PR amd64/170351; it has been noted by GNATS.
From: Konstantin Belousov kostik...@gmail.com
To: Ming Qiao mq...@juniper.net
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always get
unlimited rlimit
Date: Fri, 3
The following reply was made to PR amd64/170388; it has been noted by GNATS.
From: Konstantin Belousov kostik...@gmail.com
To: Jimmy Olgeni olg...@freebsd.org
Cc: freebsd-gnats-sub...@freebsd.org, j...@freebsd.org
Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot
The following reply was made to PR amd64/170351; it has been noted by GNATS.
From: Konstantin Belousov konstantin.belou...@zoral.com.ua
To: Ming Qiao mq...@juniper.net
Cc: Erin MacNeil emacn...@juniper.net, freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/170351: [patch] amd64: 64-bit process
The following reply was made to PR amd64/171250; it has been noted by GNATS.
From: Konstantin Belousov kostik...@gmail.com
To: David Naylor naylor.b.da...@gmail.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries
Date: Sun, 2 Sep 2012 18:57:55
The following reply was made to PR amd64/171250; it has been noted by GNATS.
From: Konstantin Belousov kostik...@gmail.com
To: David Naylor naylor.b.da...@gmail.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries
Date: Mon, 3 Sep 2012 15:26:50
On Sun, Sep 09, 2012 at 02:02:55PM +0300, Konstantin Belousov wrote:
On Sun, Sep 09, 2012 at 08:42:37AM +0200, Michael Fuckner wrote:
Hi all,
I changed your patch slightly to apply to specialreh.h on STABLE
root@c64:/root # diff smep.1.patch.bak smep.1.patch
80c80
diff --git
Please find below the patch to add the unwind annotations for the libc
and libthr assembler routines on amd64. The change shall have no impact
on the execution of the changed code, because no functions there ever
generate C++ exception or call a function that could generate exception.
The
On Sun, Sep 09, 2012 at 11:29:05PM +0300, Konstantin Belousov wrote:
On Sun, Sep 09, 2012 at 02:02:55PM +0300, Konstantin Belousov wrote:
On Sun, Sep 09, 2012 at 08:42:37AM +0200, Michael Fuckner wrote:
Hi all,
I changed your patch slightly to apply to specialreh.h on STABLE
On Sat, Feb 02, 2013 at 01:04:14PM +, Kaloyan Ganchev wrote:
When trying to boot FreeBSD 9.1 on kvm host with the following command:
kvm -cpu core2duo,+xsave -enable-kvm -drive file=freebsd-9.1-qcow2.img -boot
d -net nic -net user -nographic -vnc :0 -cdrom
The following reply was made to PR amd64/175780; it has been noted by GNATS.
From: Konstantin Belousov kostik...@gmail.com
To: Kaloyan Ganchev kaloqn.ganc...@gmail.com
Cc: freebsd-gnats-sub...@freebsd.org, am...@freebsd.org
Subject: Re: amd64/175780: Crash on KVM boot due to xsave instruction
The following reply was made to PR amd64/176835; it has been noted by GNATS.
From: Konstantin Belousov kostik...@gmail.com
To: Martin Bishop martin.bis...@gmail.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/176835: Fatal trap 12: page fault while in kernel mode
Date: Mon, 11 Mar
On Mon, Mar 18, 2013 at 05:40:01AM +, Martin Bishop wrote:
The following reply was made to PR amd64/176835; it has been noted by GNATS.
From: Martin Bishop martin.bis...@gmail.com
To: bug-follo...@freebsd.org, martin.bis...@gmail.com
Cc:
Subject: Re: amd64/176835: Fatal trap 12: page
The ddb use of hardware watchpoints on the x86 architectures is known to
be lacking. There are at least two known problems. One is the improper
interaction with the user-mode debuggers which use debug registers.
Another is that ddb only loads the debug registers for the watchpoint
into the CPU
For the several months, I worked (and continue the work now) on the
driver for the Intel VT-d for FreeBSD. The VT-d is sold as the I/O
Virtualization technology, but in essence it is a DMA addresses
remapping engine, i.e. it is advanced and improved I/O MMU, as also
found on other big-iron
On Mon, May 27, 2013 at 02:27:00PM +0200, Jeremie Le Hen wrote:
Hi kib,
On Mon, May 27, 2013 at 01:58:44PM +0300, Konstantin Belousov wrote:
For the several months, I worked (and continue the work now) on the
driver for the Intel VT-d for FreeBSD. The VT-d is sold as the I/O
Could you show the output of pciconf -lvc ?
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
On Tue, Jun 11, 2013 at 06:54:21PM +0200, Michal Sviba wrote:
xhci0@pci0:0:20:0: class=0x0c0330 card=0x3397103c chip=0x1e318086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Panther Point USB xHCI Host Controller'
class = serial bus
subclass
This is a public service announcement that for some time already,
the cc -m32 is functional on HEAD amd64.
I believe that all headers important for the usermode application
compilation from the base system, were converted to providing ILP32/LP64
correct definitions on x86. This was mostly done by
On Thu, Jun 13, 2013 at 10:18:30AM -0400, John Baldwin wrote:
On Tuesday, June 11, 2013 1:48:22 pm Konstantin Belousov wrote:
+ count = pci_msi_count(self);
+ if (count = 1) {
+ if (count 1)
+ count = 1;
You can just drop the if and always do
On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote:
Hi,
as a preliminary step in the implementation of adaptive spinning for
umtx, I'm switching the pthread/umtx code so that a thread that
acquires a pthread_mutex writes the address of struct pthread in the
owner field of the
On Wed, Aug 07, 2013 at 01:09:08PM +, FreeBSD Tinderbox wrote:
/src/sys/amd64/amd64/machdep.c: In function 'db_show_sysregs':
/src/sys/amd64/amd64/machdep.c:1226: error: 'MSR_IA32_FEATURE_CONTROL'
undeclared (first use in this function)
Should be fixed with the r254066, sorry for the
The following reply was made to PR amd64/187808; it has been noted by GNATS.
From: Konstantin Belousov kostik...@gmail.com
To: Peter Holm p...@freebsd.org
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/187808: Pointer validation gone missing for
__vdso_gettimeofday()
Date: Fri, 21 Mar
The following reply was made to PR amd64/188699; it has been noted by GNATS.
From: Konstantin Belousov kostik...@gmail.com
To: John Allman free...@hugme.org
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/188699: Dev tree
Date: Thu, 17 Apr 2014 21:44:52 +0300
On Wed, Apr 16, 2014 at 05
On Fri, May 23, 2014 at 04:28:34PM -0700, Peter Wemm wrote:
On 5/23/14, 4:22 PM, Peter Wemm wrote:
On 5/23/14, 3:53 PM, Peter Jeremy wrote:
I've been playing with Go (lang/go) and found that i386 Go binaries
segfault when run on amd64 (9.x, 10.x or HEAD). I've narrowed it down
to the LDT
On Sat, May 24, 2014 at 01:39:44PM +1000, Peter Jeremy wrote:
On 2014-May-24 02:34:44 +0300, Konstantin Belousov kostik...@gmail.com
wrote:
On Fri, May 23, 2014 at 04:28:34PM -0700, Peter Wemm wrote:
On 5/23/14, 4:22 PM, Peter Wemm wrote:
On 5/23/14, 3:53 PM, Peter Jeremy wrote:
I've
On Sat, Jul 19, 2014 at 10:58:18AM -0700, Marcel Moolenaar wrote:
On Jul 18, 2014, at 9:07 AM, Konstantin Belousov kostik...@gmail.com wrote:
It was mentioned somewhere recently, that typical BIOS today configures
NMI delivery on the hardware events as broadcast. When I developerd
On Mon, Nov 03, 2014 at 01:52:44PM -0500, John Baldwin wrote:
On Saturday 01 November 2014 18:55:53 Sourish Mazumder wrote:
Hi John,
I tried the pmap_mapdev() as suggested by you. Works perfectly. Thanks for
the information.
Sure.
What is required, If I want to add this nvram
Below is the patch to start using mwait instead of 'legacy' port read
to enter the higher Cx states when idle. This is the Intel' recommended
way of entering Cx, using hints provided by the vendor-specific
fixed function hardware GAS encoding. See the Intel(R) Processor
Vendor-Specific ACPI
Below is the patch which unifies some code from
sys/{amd64/amd64,i386/i386}/machdep.c into the new shared file
sys/x86/x86/cpu_machdep.c. Most of the code is related to handling
the idle CPU state, but there is some additional trivialities like
cpu_boot() etc.
The move is mostly a preparation
I implemented fast userspace gettimeofday(2) support for machines which
have to use HPET for timecounters. Details and measurements, as well as
the patch, are put at https://reviews.freebsd.org/D7473 .
I am interested in the testing by people using Core2 and older hardware.
Thanks.
On Mon, Aug 14, 2017 at 08:42:35PM +, Rang, Anton wrote:
> Hi,
>
> 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
On Wed, Jun 13, 2018 at 12:06:42PM +0100, Johannes Lundberg wrote:
>
> Konstantin Belousov writes:
>
> > Today I noted that AMD published the public errata document for Ryzens,
> > https://developer.amd.com/wp-content/resources/55449_1.12.pdf
> >
> > Some of th
On Sat, Jun 30, 2018 at 05:59:56PM -0400, Mark Johnston wrote:
> On Sat, Jun 30, 2018 at 10:38:21AM +0300, Mihai Carabas wrote:
> > On Sat, Jun 30, 2018 at 1:52 AM, Mark Johnston wrote:
> > > On Fri, Jun 29, 2018 at 11:58:31AM +0300, Elena Mihailescu wrote:
> > >> Is there anything I am doing
On Tue, Jul 31, 2018 at 06:46:31PM -0700, Mark Millard via freebsd-amd64 wrote:
> > Author: mmacy
> > Date: Mon Jul 2 19:48:38 2018
> > New Revision: 335873
> > URL:
> > https://svnweb.freebsd.org/changeset/base/335873
> >
> >
> > Log:
> > inline atomics and allow tied modules to inline
On Mon, Apr 09, 2018 at 08:22:13AM -0400, Yoshihiro Ota wrote:
> What is the current status of this?
>
> Based on SVN history, it doesn't look https://reviews.freebsd.org/D14633 has
> been merged/commited yet.
I fixed bugs reported by Bruce.
Right now the patch is waiting for some other testing
On Sun, Apr 01, 2018 at 01:05:57AM +0200, Dimitry Andric wrote:
> I haven't yet run any performance tests, I'll try building world and a
> few large ports tomorrow. General operation from the command line does
> not feel "sluggish" in any way, however.
I just updated the review with some changes
Hi,
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 tested by Peter Holm, and I am
satisfied with
On Wed, Mar 21, 2018 at 01:57:37PM +0200, Andriy Gapon wrote:
> On 21/03/2018 10:39, Stefan Esser wrote:
> > And you want to change occurances of /compat/linux in the kernel (and
> > possibly
> > some libraries and user programs), e.g. in /sys/amd64/linux/linux_sysvec.c
> > ...
> >
> > There is
On Fri, Nov 16, 2018 at 10:45:39AM +0530, Rajesh Kumar wrote:
> Hi,
>
> I did some study on this. During acpi_attach, if MCFG table is present,
> FreeBSD tries to use it (That is to map the PCI Base address to virtual
> address space). Setting hw.pci.mcfg=0, disables that mapping and lets the
>
Hello,
at https://reviews.freebsd.org/D18894 I put a review which main goal is
to allow i386 kernels to use NX bits on capable hardware. In essence,
single kernel now can operate using either PAE or non-PAE pagetables,
the selection is done at the cold (very early boot, before paging is
turned
On Thu, Apr 04, 2019 at 04:58:15PM -0700, Mark Millard via freebsd-amd64 wrote:
> On a:
>
> CPU: AMD Ryzen Threadripper 1950X 16-Core Processor (3393.70-MHz K8-class
> CPU)
> Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1
>
> Features=0x178bfbff
>
>
On Fri, Apr 05, 2019 at 11:47:58AM -0700, Mark Millard wrote:
>
>
> On 2019-Apr-5, at 04:46, Konstantin Belousov wrote:
>
> > On Thu, Apr 04, 2019 at 04:58:15PM -0700, Mark Millard via freebsd-amd64
> > wrote:
> >> On a:
> >>
> >> CPU: AMD R
58 matches
Mail list logo
