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 fpusa
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
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 t
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
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
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 the issues listed there looks quite relevant to the potential
hangs that some people still experience with the machines. I wrote
a script which should appl
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 wron
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 locks
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
> s
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)
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
>
> Features2=0x7ed8
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
On Sun, Jul 12, 2020 at 12:32:08AM +0300, Lytochkin Boris wrote:
> Hi.
>
> I am trying to make a patch that gives loader ability to bring whole
> partitions as preload md(4) items. While this could sound a bit crazy, it
> allows making an easy to get "diskless" routers: root partition is 2Gb
> sto
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 correspond
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
> c
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 Mod
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:
> >
On Sat, Feb 04, 2012 at 09:41:54AM -0800, Dennis Glatting wrote:
> On Sat, 2012-02-04 at 09:10 -0800, Dennis Glatting wrote:
> > > What is written into dmesg after the load ?
> > > Try to restart sshd and log into the system over ssh after aesni(4)
> > and
> > > cryptodev(4) modules are loaded.
> >
On Sat, Feb 04, 2012 at 10:14:18AM -0800, Dennis Glatting wrote:
> On Sat, 2012-02-04 at 20:04 +0200, Konstantin Belousov wrote:
> > On Sat, Feb 04, 2012 at 09:41:54AM -0800, Dennis Glatting wrote:
> > > On Sat, 2012-02-04 at 09:10 -0800, Dennis Glatting wrote:
> > > >
On Sat, Feb 11, 2012 at 04:30:16AM +, Russell Cattelan wrote:
> The following reply was made to PR amd64/163710; it has been noted by GNATS.
>
> From: Russell Cattelan
> To: bug-follo...@freebsd.org, catte...@thebarn.com
> Cc:
> Subject: Re: amd64/163710: setjump in userboot.so causes stac
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
> sysct
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-base
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.
Def
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 SDM for description of the XSAVEOPT instruction.
Summary is that the instruction allows to not write parts of the FPU
state which was no
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 co
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
--- a/sys/amd64/amd64
The following reply was made to PR amd64/169927; it has been noted by GNATS.
From: Konstantin Belousov
To: Bruce Evans
Cc: Ed Alley , 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
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 independ
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
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
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 spur
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* to be inclu
On Wed, Jul 18, 2012 at 11:10:03AM +0300, 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
> > prerequis
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 machin
On Sat, Jul 21, 2012 at 07:55:23PM +0200, Arvydas Sidorenko wrote:
> This is the output I get when building 10-CURRENT from HEAD:
> /usr/src/sys/amd64/amd64/cpu_switch.S: Assembler messages:
> /usr/src/sys/amd64/amd64/cpu_switch.S:128: Error: no such instruction:
> `xsave (%r8)'
> /usr/src/sys/amd6
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 candidate. It changes the fix in r238755 to use CPUID
instead of rmb(), since rmb() translates to locked operation on i386,
and e
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
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 rdtsc
The following reply was made to PR amd64/170351; it has been noted by GNATS.
From: Konstantin Belousov
To: Ming Qiao
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always get
unlimited rlimit
Date: Fri, 3 Aug 2012 20:39:23
The following reply was made to PR amd64/170388; it has been noted by GNATS.
From: Konstantin Belousov
To: Jimmy Olgeni
Cc: freebsd-gnats-sub...@freebsd.org, j...@freebsd.org
Subject: Re: amd64/170388: 8-STABLE amd64 past r233799 is unable to boot in
certain KVM environments
Date: Sun, 5 Aug
The following reply was made to PR amd64/170351; it has been noted by GNATS.
From: Konstantin Belousov
To: Ming Qiao
Cc: Erin MacNeil , freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/170351: [patch] amd64: 64-bit process can't always get
unlimited rlimit
Date: Thu, 9 Aug 2012 01:
The following reply was made to PR amd64/171250; it has been noted by GNATS.
From: Konstantin Belousov
To: David Naylor
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries
Date: Sun, 2 Sep 2012 18:57:55 +0300
--7HqTdBsuSOA5h1B/
Content-Type
The following reply was made to PR amd64/171250; it has been noted by GNATS.
From: Konstantin Belousov
To: David Naylor
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries
Date: Mon, 3 Sep 2012 15:26:50 +0300
--7FDnRloC5L6+fPHS
Content-Type
Please find at
http://people.freebsd.org/~kib/misc/smep.1.patch
the patch which should enable the FSGSBASE and SMEP features
supposedly present in the IvyBridge CPUs.
FSGSBASE are four new instructions available in the 64bit mode only.
They allow to access bases for %fs and %gs without touching MS
md64/include/specialreg.h
>
> I got a new kernel, but it is stuck immediately (kerneltrap 9 with
> interrupts disabled), system doesn't boot on E3-1230 V2 on Supermicro
> X9SCM-IIF
>
> Anything else I could check?
I need the backtrace and the whole kernel messages.
>
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
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 addition
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
On Fri, Nov 02, 2012 at 09:21:56AM +0100, Michael Fuckner wrote:
>
> > is at http://people.freebsd.org/~kib/misc/smep.3.patch .
> >
> > Please test.
>
> looks good (after changing the location of specialreg.h (on STABLE)
>
> do you need any output or something like that?
No, thank you, I do not
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
> ./isos/FreeBSD-9.1-RELE
The following reply was made to PR amd64/175780; it has been noted by GNATS.
From: Konstantin Belousov
To: Kaloyan Ganchev
Cc: freebsd-gnats-sub...@freebsd.org, am...@freebsd.org
Subject: Re: amd64/175780: Crash on KVM boot due to xsave instruction issue
Date: Sat, 2 Feb 2013 17:02:42 +0200
The following reply was made to PR amd64/176835; it has been noted by GNATS.
From: Konstantin Belousov
To: Martin Bishop
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/176835: Fatal trap 12: page fault while in kernel mode
Date: Mon, 11 Mar 2013 14:01:52 +0200
--YyN8ymQDUlI+Fj6t
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
> To: bug-follo...@freebsd.org, martin.bis...@gmail.com
> Cc:
> Subject: Re: amd64/176835: Fatal trap 12: page fault while in ker
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 whic
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 machine
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
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
> subc
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;
>
&
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 br
The following reply was made to PR amd64/187808; it has been noted by GNATS.
From: Konstantin Belousov
To: Peter Holm
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/187808: Pointer validation gone missing for
__vdso_gettimeofday()
Date: Fri, 21 Mar 2014 14:30:44 +0200
The following reply was made to PR amd64/188699; it has been noted by GNATS.
From: Konstantin Belousov
To: John Allman
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:32:45PM +, John Allman wrote
On Mon, Apr 21, 2014 at 02:31:12PM -0400, John Baldwin wrote:
> On Thursday, April 17, 2014 2:50:01 pm Konstantin Belousov wrote:
> > The following reply was made to PR amd64/188699; it has been noted by GNATS.
> >
> > From: Konstantin Belousov
> > To: John Allman
On Mon, Apr 21, 2014 at 11:52:59PM +0200, Emanuel Haupt wrote:
> On 21/04/14 21:51, Konstantin Belousov wrote:
> > On Mon, Apr 21, 2014 at 02:31:12PM -0400, John Baldwin wrote:
> >> On Thursday, April 17, 2014 2:50:01 pm Konstantin Belousov wrote:
> >>> The follow
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
> >>
On Sat, May 24, 2014 at 01:39:44PM +1000, Peter Jeremy wrote:
> On 2014-May-24 02:34:44 +0300, Konstantin Belousov
> 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, Pete
On Mon, May 26, 2014 at 09:36:22PM +1000, Peter Jeremy wrote:
> On 2014-May-24 10:41:01 +0300, Konstantin Belousov
> wrote:
> >> >Provide the minimal test case.
> >>
> >> The following go program, compiled on i386 and run on amd64 will die
> >&g
On Thu, May 29, 2014 at 08:55:42AM +1000, Peter Jeremy wrote:
> As I wrote in my initial mail, I am not certain whether this is a problem
> with Go or FreeBSD. And having done some poking at corefiles with gdb
> (you need gdb7.6 from ports to grok the Go debug information), I have
> found that all
On Thu, May 29, 2014 at 02:19:06PM -0700, Neel Natu wrote:
> Hi,
>
> On Thu, May 29, 2014 at 3:44 AM, Peter Jeremy wrote:
> > On 2014-May-29 04:38:18 +0300, Konstantin Belousov
> > wrote:
> >>Hm, I think I know what is going on. Try this, please.
> >>A
It was mentioned somewhere recently, that typical BIOS today configures
NMI delivery on the hardware events as broadcast. When I developerd
the dmar(4) busdma backend, I indeed met the problem, and wrote a
prototype which avoided startup of ddb on all cores. Instead, the patch
implements custom s
On Sat, Jul 19, 2014 at 10:58:18AM -0700, Marcel Moolenaar wrote:
>
> On Jul 18, 2014, at 9:07 AM, Konstantin Belousov wrote:
>
> > It was mentioned somewhere recently, that typical BIOS today configures
> > NMI delivery on the hardware events as broadcast. When I deve
On Sat, Jul 19, 2014 at 12:57:24PM -0700, Marcel Moolenaar wrote:
>
> On Jul 19, 2014, at 11:29 AM, Konstantin Belousov wrote:
> >>
> >> One may call kdb_enter on different CPUs at the same time and it's
> >> also possible to call panic on multiple CPUs a
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 th
below.
>
> On Tue, Nov 4, 2014 at 2:16 PM, Konstantin Belousov
> wrote:
>
> > 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,
> > > >
> > >
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 for
On Tue, Apr 21, 2015 at 12:25:29AM +0300, Sergey Kandaurov wrote:
> On 20 April 2015 at 19:21, Konstantin Belousov wrote:
> [..]
> > +struct {
> > + void*id_fn;
> > + char*id_name;
> > +} idle_tbl[] = {
> > + { cpu_idle_spin, &q
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 Interf
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.
_
81 matches
Mail list logo
