CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Sat Jun 1 06:54:28 UTC 2019 Modified Files: src/sys/arch/x86/x86: spectre.c Log Message: Mmh, check the highest leaf before calling x86_cpuid(), otherwise on old CPUs we might be getting garbage. While here fix a typo. Likely

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: nonaka Date: Fri May 31 03:10:31 UTC 2019 Modified Files: src/sys/arch/x86/x86: consinit.c Log Message: Back out r1.30 change. > tuck in include inside ifdef, from Ryosuke Moro It was caused by the reporter's local change. To generate a

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: nonaka Date: Fri May 31 03:10:31 UTC 2019 Modified Files: src/sys/arch/x86/x86: consinit.c Log Message: Back out r1.30 change. > tuck in include inside ifdef, from Ryosuke Moro It was caused by the reporter's local change. To generate a

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: nonaka Date: Thu May 30 11:15:29 UTC 2019 Modified Files: src/sys/arch/x86/x86: hyperv.c Log Message: Avoid undefined reference to `hyperv_guid_video' without vmbus(4). To generate a diff of this commit: cvs rdiff -u -r1.2 -r1.3

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: nonaka Date: Thu May 30 11:15:29 UTC 2019 Modified Files: src/sys/arch/x86/x86: hyperv.c Log Message: Avoid undefined reference to `hyperv_guid_video' without vmbus(4). To generate a diff of this commit: cvs rdiff -u -r1.2 -r1.3

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: kamil Date: Tue May 28 16:43:24 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Avoid the 1<<31 construct Shift unsigned int rather than signed one. Detected with kUBSan when reading /proc/cpuinfo. To generate

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: kamil Date: Tue May 28 16:43:24 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Avoid the 1<<31 construct Shift unsigned int rather than signed one. Detected with kUBSan when reading /proc/cpuinfo. To generate

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: kamil Date: Tue May 28 13:20:23 UTC 2019 Modified Files: src/sys/arch/x86/x86: patch.c Log Message: Disable sanitizer instrumentation in x86_hotpatch() Local variables have empty (0-sized), unknown alignment to UBSan. This is hard to

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: kamil Date: Tue May 28 13:20:23 UTC 2019 Modified Files: src/sys/arch/x86/x86: patch.c Log Message: Disable sanitizer instrumentation in x86_hotpatch() Local variables have empty (0-sized), unknown alignment to UBSan. This is hard to

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Mon May 27 18:36:37 UTC 2019 Modified Files: src/sys/arch/x86/x86: cpu.c pmap.c svs.c Log Message: Change the effect of SVS on the TLB. Keep CR4_PGE set when SVS is enabled, but don't use PTE_G on the kernel PTEs in general. Add

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Mon May 27 18:36:37 UTC 2019 Modified Files: src/sys/arch/x86/x86: cpu.c pmap.c svs.c Log Message: Change the effect of SVS on the TLB. Keep CR4_PGE set when SVS is enabled, but don't use PTE_G on the kernel PTEs in general. Add

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: christos Date: Sun May 26 00:30:35 UTC 2019 Modified Files: src/sys/arch/x86/x86: consinit.c Log Message: tuck in include inside ifdef, from Ryosuke Moro To generate a diff of this commit: cvs rdiff -u -r1.29 -r1.30

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: christos Date: Sun May 26 00:30:35 UTC 2019 Modified Files: src/sys/arch/x86/x86: consinit.c Log Message: tuck in include inside ifdef, from Ryosuke Moro To generate a diff of this commit: cvs rdiff -u -r1.29 -r1.30

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Sat May 25 21:02:33 UTC 2019 Modified Files: src/sys/arch/x86/x86: fpu.c Log Message: Fix bug. We must fetch the whole FPU state, otherwise XSTATE_BV could be outdated, and we could be filling the AVX registers with garbage. To

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Sat May 25 21:02:33 UTC 2019 Modified Files: src/sys/arch/x86/x86: fpu.c Log Message: Fix bug. We must fetch the whole FPU state, otherwise XSTATE_BV could be outdated, and we could be filling the AVX registers with garbage. To

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: mlelstv Date: Sun May 19 07:43:17 UTC 2019 Modified Files: src/sys/arch/x86/x86: genfb_machdep.c Log Message: correct order of parameters, has no effect as anything set here is overwritten by the following reconfig. To generate a diff of

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: mlelstv Date: Sun May 19 07:43:17 UTC 2019 Modified Files: src/sys/arch/x86/x86: genfb_machdep.c Log Message: correct order of parameters, has no effect as anything set here is overwritten by the following reconfig. To generate a diff of

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Sat May 18 13:44:57 UTC 2019 Modified Files: src/sys/arch/x86/x86: identcpu.c Log Message: Enable EagerFPU by default. Sent on port-amd64@. To generate a diff of this commit: cvs rdiff -u -r1.89 -r1.90

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Sat May 18 08:54:38 UTC 2019 Modified Files: src/sys/arch/x86/x86: spectre.c Log Message: Use XC_HIGHPRI for SpectreV2 to reduce the CPU downtime. We already do this for MDS. To generate a diff of this commit: cvs rdiff -u -r1.27

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Sat May 18 08:54:38 UTC 2019 Modified Files: src/sys/arch/x86/x86: spectre.c Log Message: Use XC_HIGHPRI for SpectreV2 to reduce the CPU downtime. We already do this for MDS. To generate a diff of this commit: cvs rdiff -u -r1.27

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Sat May 18 07:49:31 UTC 2019 Modified Files: src/sys/arch/x86/x86: errata.c Log Message: Disable errata #1091. We are the only OS to apply it, and it seems to be causing trouble to VirtualBox (PR/54143). To generate a diff of

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: maxv Date: Sat May 18 07:49:31 UTC 2019 Modified Files: src/sys/arch/x86/x86: errata.c Log Message: Disable errata #1091. We are the only OS to apply it, and it seems to be causing trouble to VirtualBox (PR/54143). To generate a diff of

Re: CVS commit: src/sys/arch/x86/x86

On 2019/05/16 13:20, Jason Thorpe wrote: > > >> On May 15, 2019, at 9:19 PM, Maxime Villard wrote: >> >> Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : >>> Module Name:src >>> Committed By: msaitoh >>> Date: Thu May 16 02:36:30 UTC 2019 >>> Modified Files: >>>

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: msaitoh Date: Thu May 16 04:26:13 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Revert rev. 1.29. Use current cpuid 7 edx value to print. To generate a diff of this commit: cvs rdiff -u -r1.30 -r1.31

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: msaitoh Date: Thu May 16 04:26:13 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Revert rev. 1.29. Use current cpuid 7 edx value to print. To generate a diff of this commit: cvs rdiff -u -r1.30 -r1.31

Re: CVS commit: src/sys/arch/x86/x86

On 2019/05/16 13:19, Maxime Villard wrote: > Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : >> Module Name:    src >> Committed By:    msaitoh >> Date:    Thu May 16 02:36:30 UTC 2019 >> >> Modified Files: >> src/sys/arch/x86/x86: procfs_machdep.c >> >> Log Message: >>   Use

Re: CVS commit: src/sys/arch/x86/x86

> On May 15, 2019, at 9:19 PM, Maxime Villard wrote: > > Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : >> Module Name: src >> Committed By:msaitoh >> Date:Thu May 16 02:36:30 UTC 2019 >> Modified Files: >> src/sys/arch/x86/x86: procfs_machdep.c >> Log Message:

Re: CVS commit: src/sys/arch/x86/x86

Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : Module Name:src Committed By: msaitoh Date: Thu May 16 02:36:30 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Use ci_feat_val[7] instead of directly getting cpuid 7 edx. To generate a

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: msaitoh Date: Thu May 16 02:42:19 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Add md_clear. To generate a diff of this commit: cvs rdiff -u -r1.29 -r1.30 src/sys/arch/x86/x86/procfs_machdep.c Please note

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: msaitoh Date: Thu May 16 02:42:19 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Add md_clear. To generate a diff of this commit: cvs rdiff -u -r1.29 -r1.30 src/sys/arch/x86/x86/procfs_machdep.c Please note

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: msaitoh Date: Thu May 16 02:36:30 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Use ci_feat_val[7] instead of directly getting cpuid 7 edx. To generate a diff of this commit: cvs rdiff -u -r1.28 -r1.29

CVS commit: src/sys/arch/x86/x86

Module Name:src Committed By: msaitoh Date: Thu May 16 02:36:30 UTC 2019 Modified Files: src/sys/arch/x86/x86: procfs_machdep.c Log Message: Use ci_feat_val[7] instead of directly getting cpuid 7 edx. To generate a diff of this commit: cvs rdiff -u -r1.28 -r1.29

Re: CVS commit: src/sys/arch/x86/x86

Maxime Villard writes: > Can we do something about it now? It's been more than a week, and the issue is > still there. NVMM still doesn't modload, same for procfs, and GENERIC_KASLR > doesn't work either. > > This needs to be fixed now, and we should not start adding random hacks all > over the

Re: CVS commit: src/sys/arch/x86/x86

Can we do something about it now? It's been more than a week, and the issue is still there. NVMM still doesn't modload, same for procfs, and GENERIC_KASLR doesn't work either. This needs to be fixed now, and we should not start adding random hacks all over the place (like the one below). Le

re: CVS commit: src/sys/arch/x86/x86

Joerg Sonnenberger writes: > On Tue, Dec 04, 2018 at 07:27:22PM +, Cherry G. Mathew wrote: > > Module Name:src > > Committed By: cherry > > Date: Tue Dec 4 19:27:22 UTC 2018 > > > > Modified Files: > > src/sys/arch/x86/x86: cpu.c intr.c > > > > Log Message: >

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Dec 04, 2018 at 07:27:22PM +, Cherry G. Mathew wrote: > Module Name: src > Committed By: cherry > Date: Tue Dec 4 19:27:22 UTC 2018 > > Modified Files: > src/sys/arch/x86/x86: cpu.c intr.c > > Log Message: > Hypothetically speaking, if one were to want to compile a >

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 15:56, Christos Zoulas wrote: > In article <20180708092413.gb8...@mail.duskware.de>, > Martin Husemann wrote: >> On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: Module Name:src Committed By: kamil Date: Sat Jul 7 23:05:50 UTC 2018

Re: CVS commit: src/sys/arch/x86/x86

On 08.07.2018 10:49, Jaromír Doleček wrote: > Shouldn't this: > > memtop |= (uint16_t)mpbios_page[0x414] << 8; > > be actually << 16 to keep the same semantics? > No. This is a 2-byte (x86 word) variable. One byte has to be stored with the 8 bits shift. If it would be differently it would

Re: CVS commit: src/sys/arch/x86/x86

In article <20180708092413.gb8...@mail.duskware.de>, Martin Husemann wrote: >On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: >> > Module Name:src >> > Committed By: kamil >> > Date: Sat Jul 7 23:05:50 UTC 2018 >> > >> > Modified Files: >> >

Re: CVS commit: src/sys/arch/x86/x86

On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: > > Module Name:src > > Committed By: kamil > > Date: Sat Jul 7 23:05:50 UTC 2018 > > > > Modified Files: > > src/sys/arch/x86/x86: mpbios.c > > > > Log Message: > > Remove unaligned access to mpbios_page[] >

Re: CVS commit: src/sys/arch/x86/x86

Shouldn't this: memtop |= (uint16_t)mpbios_page[0x414] << 8; be actually << 16 to keep the same semantics? Jaromir Le dim. 8 juil. 2018 à 01:05, Kamil Rytarowski a écrit : > > Module Name:src > Committed By: kamil > Date: Sat Jul 7 23:05:50 UTC 2018 > > Modified Files: >

Re: CVS commit: src/sys/arch/x86/x86

transféré Sujet : Re: Fwd: CVS commit: src/sys/arch/x86/x86 Date : Thu, 21 Jun 2018 07:23:33 +0100 De : Nick Hudson Pour : Maxime Villard On 21/06/2018 07:21, Maxime Villard wrote: Le 21/06/2018 à 08:11, Nick Hudson a écrit : On 21/06/2018 06:42, Maxime Villard wrote: Le 21/06/20

re: CVS commit: src/sys/arch/x86/x86

"Maxime Villard" writes: > Module Name: src > Committed By: maxv > Date: Tue Jun 19 09:25:13 UTC 2018 > > Modified Files: > src/sys/arch/x86/x86: fpu.c > > Log Message: > When using EagerFPU, create the fpu state in execve at IPL_HIGH. why splhigh instead of kpreempt_disable()?

Re: CVS commit: src/sys/arch/x86/x86

> On Jun 7, 2018, at 7:59 AM, m...@netbsd.org wrote: > > You've changed a default and selectively fixed the one driver that > people noticed breaks from it. How do you know the rest aren't broken? As you know, there is very little certainty in this world. For example, how can I be certain

Re: CVS commit: src/sys/arch/x86/x86

You've changed a default and selectively fixed the one driver that people noticed breaks from it. How do you know the rest aren't broken? On Thu, Jun 07, 2018 at 01:35:31PM +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Thu Jun 7 13:35:31 UTC 2018 > >

Re: CVS commit: src/sys/arch/x86/x86

Le 07/02/2018 à 23:49, Maya Rashish a écrit : Module Name:src Committed By: maya Date: Wed Feb 7 22:49:32 UTC 2018 Modified Files: src/sys/arch/x86/x86: identcpu.c Log Message: stopgap fix: restrict XSAVEOPT to Intel CPUs The current code causes floating point

Re: CVS commit: src/sys/arch/x86/x86

On 2018/01/11 18:18, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Thu Jan 11 09:18:16 UTC 2018 Modified Files: src/sys/arch/x86/x86: cpu.c Log Message: Changing CR4 register may change cpuid values. For example, setting CR4_OSXSAVE sets

Re: CVS commit: src/sys/arch/x86/x86

This is really impressive and great work! On 21.10.2017 21:05, Alistair Crooks wrote: > Oh, nice! This is great :) > > Thank you for all your work on this, pkboot, kaslr and the pmap. > > Best, > Alistair > > On 21 October 2017 at 01:27, Maxime Villard wrote: >> Module Name:

Re: CVS commit: src/sys/arch/x86/x86

Oh, nice! This is great :) Thank you for all your work on this, pkboot, kaslr and the pmap. Best, Alistair On 21 October 2017 at 01:27, Maxime Villard wrote: > Module Name:src > Committed By: maxv > Date: Sat Oct 21 08:27:19 UTC 2017 > > Modified Files: >

Re: CVS commit: src/sys/arch/x86/x86

In article <20171017054709.b160cf...@cvs.netbsd.org>, Maya Rashish wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: maya >Date: Tue Oct 17 05:47:09 UTC 2017 > >Modified Files: > src/sys/arch/x86/x86: vmt.c > >Log Message: >Check that the host

Re: CVS commit: src/sys/arch/x86/x86

On Thu, Oct 05, 2017 at 02:52:55PM +0200, Kamil Rytarowski wrote: > An idea borrowed from the OpenBSD approach with wxneeded partition > (mount) property. I think that one pretty much completely misses the point. Joerg

Re: CVS commit: src/sys/arch/x86/x86

On 04.10.2017 08:35, Alexander Nasonov wrote: > Maxime Villard wrote: >> In the first mail, you said that it was better to have a all-or-nothing >> sysctl, which is *exactly* what I just committed. > > Yes, sysctl is better than giving rdtsc to root only. But "better" > alone isn't strong enough

Re: CVS commit: src/sys/arch/x86/x86

Maxime Villard wrote: > In the first mail, you said that it was better to have a all-or-nothing > sysctl, which is *exactly* what I just committed. Yes, sysctl is better than giving rdtsc to root only. But "better" alone isn't strong enough to count me as a supporter. > In the second one, as a

Re: CVS commit: src/sys/arch/x86/x86

Le 03/10/2017 à 22:47, Alexander Nasonov a écrit : Maxime Villard wrote: In case you didn't notice, this sysctl results directly from the answers I got, and is not my original plan (about which I changed my mind as a consequence of the conversation). So now tell me exactly which point I didn't

Re: CVS commit: src/sys/arch/x86/x86

Maxime Villard wrote: > In case you didn't notice, this sysctl results directly from the answers I > got, and is not my original plan (about which I changed my mind as a > consequence of the conversation). So now tell me exactly which point I didn't > consider and which reply I ignored. The thread

Re: CVS commit: src/sys/arch/x86/x86

If pax mprotect is an example then maxv should just go around rm -rf'ing any parts of the tree he doesn't like without even checking that the kernel builds afterwards, since that's the way we do things around here. It was months until I could run meld again, even disabling it for just python was

Re: CVS commit: src/sys/arch/x86/x86

Le 03/10/2017 à 21:14, Joerg Sonnenberger a écrit : I'm not responding to this nonsensical thread anymore, everything got told months ago. The option is here, people don't need to give a damn about it unless they explicitly want to - which is still legitimate in some cases, including for kaslr,

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Oct 03, 2017 at 06:54:52PM +0200, Maxime Villard wrote: > Just like disabling va0 or enabling PaX mprotect; if you feel like these are > no issues, then what's the fuss. You would be well served to read the "rdtsc > is still enabled by default" part of my email. Disabling va0 is low

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Oct 2, 2017 at 4:09 PM, Taylor R Campbell < campbell+netbsd-source-change...@mumble.net> wrote: > > Date: Mon, 2 Oct 2017 21:42:11 +0200 > > From: Joerg Sonnenberger > > > > On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote: > > > Add a machdep.tsc_user_enable

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Oct 2, 2017 at 4:43 PM, Joerg Sonnenberger wrote: > On Mon, Oct 02, 2017 at 04:25:34PM -0600, Warner Losh wrote: > > Even if you don't have the ability to change the defective hardware? > > The hardware is not defective. We are not talking about variable timing > for basic

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Oct 03, 2017 at 06:54:52PM +0200, Maxime Villard wrote: > I'm not responding to this nonsensical thread anymore, The problem is, you keep acting unilaterally without having gathered a consensus, then ignoring the resulting objections and demanding to have everything your way and only

Re: CVS commit: src/sys/arch/x86/x86

Le 03/10/2017 à 13:26, Joerg Sonnenberger a écrit : At the same time, it has interesting interactions with power management and the instruction queue. The queue is flushed by a serializing instruction executed right before, which is the recommended use case; the interaction with power

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Oct 03, 2017 at 08:17:27AM +0200, Maxime Villard wrote: > What is clear, however, is that the effort needed to perform accurate > measurements in software is much higher than that needed to invoke a hardware > instruction that will instantly give about the most accurate answer possible.

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Oct 02, 2017 at 04:25:34PM -0600, Warner Losh wrote: > Even if you don't have the ability to change the defective hardware? The hardware is not defective. We are not talking about variable timing for basic arithmetic operations based on the operand value. Outside maybe division, that

Re: CVS commit: src/sys/arch/x86/x86

> Date: Mon, 2 Oct 2017 16:25:34 -0600 > From: Warner Losh > > Why should I provide an attacker a stop watch? I want him/her to build > their own that has the potential to be accurate enough, but is necessarily > less accurate than the one I'm denying them access to. There are

Re: CVS commit: src/sys/arch/x86/x86

> Date: Mon, 2 Oct 2017 21:42:11 +0200 > From: Joerg Sonnenberger > > On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote: > > Add a machdep.tsc_user_enable sysctl, to enable/disable the rdtsc > > instruction in usermode. It defaults to enabled. > > Do we really need

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Mon Oct 2 19:23:16 UTC 2017 > > Modified Files: > src/sys/arch/x86/x86: tsc.c tsc.h x86_machdep.c > > Log Message: > Add a machdep.tsc_user_enable sysctl, to

Re: CVS commit: src/sys/arch/x86/x86

Hi maxv@n.o, On 2017/08/08 2:12, Maxime Villard wrote: > Le 07/08/2017 à 10:38, Kengo NAKAHARA a écrit : >> "intrctl affinity" in NetBSD-current causes panic. Here is the backtrace >> >> panic: kernel diagnostic assertion "mutex_owned(_lock) || !mp_online" >> failed: file

Re: CVS commit: src/sys/arch/x86/x86

Le 07/08/2017 à 10:38, Kengo NAKAHARA a écrit : Hi maxv@n.o, "intrctl affinity" in NetBSD-current causes panic. Here is the backtrace panic: kernel diagnostic assertion "mutex_owned(_lock) || !mp_online" failed: file

Re: CVS commit: src/sys/arch/x86/x86

Hi maxv@n.o, "intrctl affinity" in NetBSD-current causes panic. Here is the backtrace panic: kernel diagnostic assertion "mutex_owned(_lock) || !mp_online" failed: file "/disk4/home/k-nakahara/repos/netbsd-src/sys/arch/x86/x86/idt.c", line 122 fatal breakpoint trap in

Re: CVS commit: src/sys/arch/x86/x86

I've found this article: http://coypu.sdf.org/20170525-qemu-smp On 31.05.2017 08:51, Jaromír Doleček wrote: > You rock! Thank you. > > 2017-05-31 2:19 GMT+02:00 Maya Rashish >: > > Module Name:src > Committed By: maya > Date:

Re: CVS commit: src/sys/arch/x86/x86

You rock! Thank you. 2017-05-31 2:19 GMT+02:00 Maya Rashish : > Module Name:src > Committed By: maya > Date: Wed May 31 00:19:17 UTC 2017 > > Modified Files: > src/sys/arch/x86/x86: cpu.c > > Log Message: > Do not pause many times between testing if the

Re: CVS commit: src/sys/arch/x86/x86

Le 20/07/2016 à 07:07, Takashi YAMAMOTO a écrit : On Wed, Jul 20, 2016 at 3:54 AM, Maxime Villard > wrote: Module Name:src Committed By: maxv Date: Tue Jul 19 18:54:45 UTC 2016 Modified Files:

Re: CVS commit: src/sys/arch/x86/x86

On Wed, Jul 20, 2016 at 3:54 AM, Maxime Villard wrote: > Module Name:src > Committed By: maxv > Date: Tue Jul 19 18:54:45 UTC 2016 > > Modified Files: > src/sys/arch/x86/x86: pmap.c > > Log Message: > This loop makes no sense at all. > - can you provide

Re: CVS commit: src/sys/arch/x86/x86

Hi, On 2016/07/12 0:21, David Holland wrote: > On Mon, Jul 11, 2016 at 09:42:20AM +, Kengo NAKAHARA wrote: > > Log Message: > > strncpy should use destination buf length instead of source buf length. > > > > pointed out by nonaka@n.o. > > this should almost certainly be strlcpy, not

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Jul 11, 2016 at 09:42:20AM +, Kengo NAKAHARA wrote: > Log Message: > strncpy should use destination buf length instead of source buf length. > > pointed out by nonaka@n.o. this should almost certainly be strlcpy, not strncpy. -- David A. Holland dholl...@netbsd.org

Re: CVS commit: src/sys/arch/x86/x86

Le 01/07/2016 à 16:22, matthew green a écrit : We use only one L4 slot for the direct map, which means that we cannot map more than 512GB. Panic properly if this limit is reached. thanks for making the failure mode clear. it would be nice to remove this limitation, and support upto at least

Re: CVS commit: src/sys/arch/x86/x86

Le 01/07/2016 à 16:24, matthew green a écrit : Log Message: Surprisingly enough, the kernel expects the CPU to support large pages when creating the direct map on amd64. Therefore, the amd64 CPUs that do not support large pages basically don't work on NetBSD. It looks like it has always been

re: CVS commit: src/sys/arch/x86/x86

> Log Message: > Surprisingly enough, the kernel expects the CPU to support large pages > when creating the direct map on amd64. Therefore, the amd64 CPUs that do > not support large pages basically don't work on NetBSD. > > It looks like it has always been this way; add a KASSERT to panic >

re: CVS commit: src/sys/arch/x86/x86

> We use only one L4 slot for the direct map, which means that we cannot > map more than 512GB. Panic properly if this limit is reached. thanks for making the failure mode clear. it would be nice to remove this limitation, and support upto at least 16TB of ram. systems with well over 512GB are

Re: CVS commit: src/sys/arch/x86/x86

On Fri, Jul 01, 2016 at 11:44:05AM +, Maxime Villard wrote: > Log Message: > Use pmap_bootstrap_valloc and pmap_bootstrap_palloc under XEN at least > once, for these not to appear as unused functions (not tested, but I > guess). Maybe __used or ifndef XEN?

Re: CVS commit: src/sys/arch/x86/x86

Le 09/10/2015 06:49, Masanobu SAITOH a écrit : > On 2015/10/06 6:10, Jean-Yves Migeon wrote: >>> Log Message: >>> kmem_free() the address returned by kmem_alloc(). found by Brainy. >>> use the newly aligned location if we needed it. found by kre. >>> >>> >>> To generate a diff of this commit:

Re: CVS commit: src/sys/arch/x86/x86

On 2015/10/06 6:10, Jean-Yves Migeon wrote: Le 04/10/2015 19:52, matthew green a écrit : Module Name:src Committed By: mrg Date: Sun Oct 4 17:52:50 UTC 2015 Modified Files: src/sys/arch/x86/x86: cpu_ucode_intel.c Log Message: kmem_free() the address returned by

Re: CVS commit: src/sys/arch/x86/x86

Le 04/10/2015 19:52, matthew green a écrit : > Module Name: src > Committed By: mrg > Date: Sun Oct 4 17:52:50 UTC 2015 > > Modified Files: > src/sys/arch/x86/x86: cpu_ucode_intel.c > > Log Message: > kmem_free() the address returned by kmem_alloc(). found by Brainy. > use the

Re: CVS commit: src/sys/arch/x86/x86

On 2015/05/18 22:09, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Mon May 18 13:09:55 UTC 2015 Modified Files: src/sys/arch/x86/x86: cpu.c Log Message: PS. Revert previous. To generate a diff of this commit: cvs rdiff -u -r1.114 -r1.115

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Oct 14, 2014 at 03:16:56AM +, John Nemeth wrote: Module Name: src Committed By: jnemeth Date: Tue Oct 14 03:16:56 UTC 2014 Modified Files: src/sys/arch/x86/x86: identcpu.c Log Message: Force x86_xsave_features to 0 when running under XEN for AMD processors.

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Apr 01, 2014 at 07:16:18AM +, David Laight wrote: Module Name: src Committed By: dsl Date: Tue Apr 1 07:16:18 UTC 2014 Modified Files: src/sys/arch/x86/x86: x86_machdep.c Log Message: Revert most of the machdep sysctls to 32bit I think I remember why I set

Re: CVS commit: src/sys/arch/x86/x86

On Tue, Dec 10, 2013 at 02:02:41PM +0900, Masanobu SAITOH wrote: How about the following patch? Is it ok to commit? Looks good to me! - Jukka. Index: sys/arch/x86/acpi/acpi_cpu_md.c === RCS file:

Re: CVS commit: src/sys/arch/x86/x86

(2013/12/10 19:15), Jukka Ruohonen wrote: On Tue, Dec 10, 2013 at 02:02:41PM +0900, Masanobu SAITOH wrote: How about the following patch? Is it ok to commit? Looks good to me! Committed! Thanks. -- --- SAITOH Masanobu

Re: CVS commit: src/sys/arch/x86/x86

(2013/12/09 0:24), SAITOH Masanobu wrote: (2013/12/08 19:21), Jukka Ruohonen wrote: On Sun, Dec 08, 2013 at 04:07:38AM +, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Sun Dec 8 04:07:38 UTC 2013 Modified Files: src/sys/arch/x86/x86: tsc.c

Re: CVS commit: src/sys/arch/x86/x86

On Sun, Dec 08, 2013 at 04:07:38AM +, SAITOH Masanobu wrote: Module Name: src Committed By: msaitoh Date: Sun Dec 8 04:07:38 UTC 2013 Modified Files: src/sys/arch/x86/x86: tsc.c Log Message: Update invariant TSC detect code from both Intel and AMD documents. The

Re: CVS commit: src/sys/arch/x86/x86

(2013/12/08 19:21), Jukka Ruohonen wrote: On Sun, Dec 08, 2013 at 04:07:38AM +, SAITOH Masanobu wrote: Module Name: src Committed By:msaitoh Date:Sun Dec 8 04:07:38 UTC 2013 Modified Files: src/sys/arch/x86/x86: tsc.c Log Message: Update invariant TSC

Re: CVS commit: src/sys/arch/x86/x86

Hi, Christos. (2013/11/12 2:02), Christos Zoulas wrote: Module Name:src Committed By: christos Date: Mon Nov 11 17:02:53 UTC 2013 Modified Files: src/sys/arch/x86/x86: intel_busclock.c Log Message: CID 1128377: Comment out unreachable code; model is only 4 bits wide,

Re: CVS commit: src/sys/arch/x86/x86

On Wed, Jun 26, 2013 at 08:37:35PM -0400, Christos Zoulas wrote: Module Name: src Committed By: christos Date: Thu Jun 27 00:37:35 UTC 2013 Modified Files: src/sys/arch/x86/x86: tsc.c Log Message: detect a bad msr tsc and don't use it. + tsc_good = (cpu_feature[0]

re: CVS commit: src/sys/arch/x86/x86

Module Name: src Committed By: christos Date: Wed Jun 26 20:52:28 UTC 2013 Modified Files: src/sys/arch/x86/x86: identcpu.c Log Message: PR/47967: Jeff Rizzo: Add a probe for QEMU to disable it from claiming it has MSR_TSC. Fixes DTRACE crashing because it returned a

Re: CVS commit: src/sys/arch/x86/x86

On 26 February 2012 01:33, Cherry G. Mathew che...@netbsd.org wrote: Module Name:    src Committed By:   cherry Date:           Sat Feb 25 20:03:58 UTC 2012 Modified Files:        src/sys/arch/x86/x86: pmap.c Log Message: Revert previous since it does a redundant xpq queue flush.

Re: CVS commit: src/sys/arch/x86/x86

Hi Cherry! On Fri, Feb 24, 2012 at 08:44:45AM +, Cherry G. Mathew wrote: Module Name: src Committed By: cherry Date: Fri Feb 24 08:44:44 UTC 2012 Modified Files: src/sys/arch/x86/x86: pmap.c Log Message: kernel page attribute change should be reflected on all cpus,

Re: CVS commit: src/sys/arch/x86/x86

Hi Thomas, On 24 February 2012 14:21, Thomas Klausner w...@netbsd.org wrote: Hi Cherry! On Fri, Feb 24, 2012 at 08:44:45AM +, Cherry G. Mathew wrote: Module Name:  src Committed By: cherry Date:         Fri Feb 24 08:44:44 UTC 2012 Modified Files:       src/sys/arch/x86/x86: pmap.c

Re: CVS commit: src/sys/arch/x86/x86

On Fri, Dec 09, 2011 at 05:32:51PM +, Chuck Silvers wrote: Module Name: src Committed By: chs Date: Fri Dec 9 17:32:51 UTC 2011 Modified Files: src/sys/arch/x86/x86: pmap.c Log Message: only use PG_G on leaf PTEs. go back to tlbflush(), all the global entries that

Re: CVS commit: src/sys/arch/x86/x86

Am 18.10.11 06:27, schrieb Jukka Ruohonen: On Tue, Oct 18, 2011 at 12:07:45AM +, Jared D. McNeill wrote: Module Name: src Committed By:jmcneill Date:Tue Oct 18 00:07:45 UTC 2011 Modified Files: src/sys/arch/x86/x86: vmt.c Log Message: don't allow module

<    1   2   3   4   >