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

hehehe - porn iterators - love it! On Fri, 15 Oct 2021, Jason Thorpe wrote: I demand this change be reverted. (/s) On Oct 15, 2021, at 11:12 AM, Jared D. McNeill wrote: Module Name:src Committed By: jmcneill Date: Fri Oct 15 18:12:48 UTC 2021 Modified Files:

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

I demand this change be reverted. (/s) > On Oct 15, 2021, at 11:12 AM, Jared D. McNeill wrote: > > Module Name: src > Committed By: jmcneill > Date: Fri Oct 15 18:12:48 UTC 2021 > > Modified Files: > src/sys/arch/x86/x86: tsc.c > > Log Message: > Fix typo in comment:

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

"Jaromir Dolecek" writes: > Module Name: src > Committed By: jdolecek > Date: Wed Jun 24 22:28:08 UTC 2020 > > Modified Files: > src/sys/arch/x86/x86: multiboot2.c > > Log Message: > don't try allocating 16KB of scratch space on stack > > it's too early for kmem_alloc(), so use

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

On Wed, Jun 24, 2020 at 10:28:08PM +, Jaromir Dolecek wrote: > Module Name: src > Committed By: jdolecek > Date: Wed Jun 24 22:28:08 UTC 2020 > > Modified Files: > src/sys/arch/x86/x86: multiboot2.c > > Log Message: > don't try allocating 16KB of scratch space on stack > >

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

In article <20200606135850.ge14...@pony.stderr.spb.ru>, Valery Ushakov wrote: >On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote: > >> On 06.06.2020 09:42, Simon Burge wrote: >> > "Kamil Rytarowski" wrote: >> > >> >> Module Name: src >> >> Committed By: kamil >> >> Date:

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

On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote: > On 06.06.2020 09:42, Simon Burge wrote: > > "Kamil Rytarowski" wrote: > > > >> Module Name: src > >> Committed By: kamil > >> Date: Fri Jun 5 21:48:04 UTC 2020 > >> > >> Modified Files: > >> > >>

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

On 06.06.2020 09:42, Simon Burge wrote: > "Kamil Rytarowski" wrote: > >> Module Name: src >> Committed By:kamil >> Date:Fri Jun 5 21:48:04 UTC 2020 >> >> Modified Files: >> >> src/sys/arch/x86/x86: cpu_rng.c >> >> Log Message: >> >> Change const unsigned to

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

"Kamil Rytarowski" wrote: > Module Name: src > Committed By: kamil > Date: Fri Jun 5 21:48:04 UTC 2020 > > Modified Files: > > src/sys/arch/x86/x86: cpu_rng.c > > Log Message: > > Change const unsigned to preprocessor define > > Fixes GCC -O0 build with the stack protector.

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

Hi, Hmm, but TSC drift is still observed on recent (high clock) CPUs. I will have researched and fix later. On 2020/04/03 12:05, Kengo NAKAHARA wrote: Module Name:src Committed By: knakahara Date: Fri Apr 3 03:05:39 UTC 2020 Modified Files: src/sys/arch/x86/x86: tsc.c

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

On Tue, Mar 17, 2020 at 10:38:14PM +, Andrew Doran wrote: > Log Message: > - Change some expensive checks DEBUG -> DIAGNOSTIC. That was meant to be the other way around, oops. Andrew

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

On Tue, Dec 03, 2019 at 01:14:14PM +0100, Kamil Rytarowski wrote: > On 03.12.2019 12:50, Juergen Hannken-Illjes wrote: > > Module Name:src > > Committed By: hannken > > Date: Tue Dec 3 11:50:45 UTC 2019 > > > > Modified Files: > > src/sys/arch/x86/x86:

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

On 03.12.2019 12:50, Juergen Hannken-Illjes wrote: > Module Name: src > Committed By: hannken > Date: Tue Dec 3 11:50:45 UTC 2019 > > Modified Files: > src/sys/arch/x86/x86: x86_machdep.c > > Log Message: > Make sure the assignment to "idepth" is done inside the loop to prevent >

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: >>>

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

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

Le 22/06/2018 à 03:40, matthew green a écrit : "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

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

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

On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote: 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:

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

On 18 October 2011 10:07, Jukka Ruohonen jruoho...@iki.fi wrote: On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote: 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

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

I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 08:43:46AM +0200, Marc Balmer wrote: Am 18.10.11

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

On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? That sounds right to me. As noted, generally I am not

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

On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? That

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

On Tue, Oct 18, 2011 at 12:44:52PM +0100, Iain Hibbert wrote: The real benefit of the modular system is that you don't need to load hundreds of modules on the off chance that they will be used. A cron entry could be used to flush unused modules if the sysop cares about that, why do we need a

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

On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? That sounds

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

Well I loaded vmt manually and it was auto unloaded on me a few minutes later, that's why I made this change in the first place. On 2011-10-18, at 7:57 AM, Paul Goyette wrote: On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would

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

On Tue, Oct 18, 2011 at 07:59:35AM -0400, Jared D. McNeill wrote: Well I loaded vmt manually and it was auto unloaded on me a few minutes later, that's why I made this change in the first place. On 2011-10-18, at 7:57 AM, Paul Goyette wrote: On Tue, 18 Oct 2011, Jukka Ruohonen wrote:

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

No wonder, in the thread if uvmexp.free uvmexp.freemin it skips the mod_autotime == 0 check. On 2011-10-18, at 8:06 AM, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 07:59:35AM -0400, Jared D. McNeill wrote: Well I loaded vmt manually and it was auto unloaded on me a few minutes later,

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

Fixed. On 2011-10-18, at 8:06 AM, Jukka Ruohonen wrote: True. But like Jared, I've also seen magic unloading of some of my driver modules. I guess there is a bug somewhere. - Jukka.

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

On Oct 18, 2011, at 4:39 AM, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? If I manually load a dozen drivers at boot because I have a dozen

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

On Oct 18, 2011, at 9:28 AM, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 08:49:39AM -0600, Warner Losh wrote: On Oct 18, 2011, at 4:39 AM, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded

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

Am 18.10.11 12:39, schrieb Jared McNeill: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only autounloading the autoloaded ones? I'd say that is a safe way. I am for it. On Tue, 18 Oct 2011, Jukka

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

Am 18.10.11 13:44, schrieb Iain Hibbert: On Tue, 18 Oct 2011, Jukka Ruohonen wrote: On Tue, Oct 18, 2011 at 06:39:49AM -0400, Jared McNeill wrote: I would argue that any manually loaded module shouldn't be autounloaded. What do you think about flagging modules as autoloaded and only

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

On Tue, 18 Oct 2011, Jukka Ruohonen wrote: 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   >