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 plenty of legitima

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 this change? I've

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 enable/disa

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

Le 29/09/2017 à 05:17, Ryota Ozaki a écrit : Module Name:src Committed By: ozaki-r Date: Fri Sep 29 03:17:18 UTC 2017 Modified Files: src/sys/arch/x86/include: pmap.h Log Message: Fix build sys/arch/x86/x86/cpu.c:920:20: error: 'pmap_largepages' undeclared (first use i

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(&cpu_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(&cpu_lock) || !mp_online" failed: file "/disk4/home/k-nakahara/repos/netbsd-src/sys/arch/x86

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(&cpu_lock) || !mp_online" failed: file "/disk4/home/k-nakahara/repos/netbsd-src/sys/arch/x86/x86/idt.c", line 122 fatal breakpoint trap in su

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: Wed May 31 00:19

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 CPU can go. > > Thi

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

> #define VMXNET3_CORE_LOCK_ASSERT(_sc)mutex_owned((_sc)->vmx_mtx) > > #define VMXNET3_RXQ_LOCK_ASSERT(_rxq)\ > mutex_owned((_rxq)->vxrxq_mtx) > #define VMXNET3_TXQ_LOCK_ASSERT(_txq)\ > mutex_owned((_txq)->vxtxq_mtx) These should probably ass

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

I see Robert added hack meanwhile, I'll look at proper fix tomorrow. Jaromir 2016-10-16 0:23 GMT+02:00 Joerg Sonnenberger : > On Sat, Oct 15, 2016 at 04:46:15PM +, Jaromir Dolecek wrote: >> Module Name: src >> Committed By: jdolecek >> Date: Sat Oct 15 16:46:14 UTC 2016 >> >> Modifie

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

Date:Sun, 16 Oct 2016 02:14:27 +0200 From:Joerg Sonnenberger Message-ID: <20161016001427.ga7...@britannica.bec.de> | > I haven't compile tested it yet, but I think it needs: | See second sentence :) Obviously I had ... I just didn't originally interpret it as int

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

On Sun, Oct 16, 2016 at 06:59:53AM +0700, Robert Elz wrote: > Date:Sun, 16 Oct 2016 00:23:20 +0200 > From:Joerg Sonnenberger > Message-ID: <20161015222320.ga4...@britannica.bec.de> > > | On Sat, Oct 15, 2016 at 04:46:15PM +, Jaromir Dolecek wrote: > > | > Mod

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

Date:Sun, 16 Oct 2016 00:23:20 +0200 From:Joerg Sonnenberger Message-ID: <20161015222320.ga4...@britannica.bec.de> | On Sat, Oct 15, 2016 at 04:46:15PM +, Jaromir Dolecek wrote: | > Modified Files: | > src/sys/arch/x86/acpi: acpi_machdep.c | > Log Mess

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

On Sat, Oct 15, 2016 at 04:46:15PM +, Jaromir Dolecek wrote: > Module Name: src > Committed By: jdolecek > Date: Sat Oct 15 16:46:14 UTC 2016 > > Modified Files: > src/sys/arch/x86/acpi: acpi_machdep.c > src/sys/arch/x86/include: isa_machdep.h > src/sys/arch/x86/isa:

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 mailto:m...@netbsd.org>> 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

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 more meaningful co

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 strn

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 16

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 thi

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

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 n

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 kmem_al

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 ne

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

On 2015/08/13 13:52, SAITOH Masanobu wrote: Module Name:src Committed By: msaitoh Date: Thu Aug 13 04:52:40 UTC 2015 Modified Files: src/sys/arch/x86/pci: msipic.c Log Message: Add workaround for PCI prefetchable bit in msipic_construct_msix_pic(). Some chips (e.g. Int

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 src/

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

Date: Sat, 18 Oct 2014 17:43:10 +0900 From: Masao Uebayashi On Sat, Oct 18, 2014 at 5:55 AM, Masao Uebayashi wrote: > Fix another indirect circular dependency (agp_* -> (agpbus) -> pchb -> abp_*). > Fixes "no agp*" build. Reported & build-tested by Kurt Schreiner. Correction

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

On Sat, Oct 18, 2014 at 5:55 AM, Masao Uebayashi wrote: > Module Name:src > Committed By: uebayasi > Date: Fri Oct 17 20:55:21 UTC 2014 > > Modified Files: > src/sys/arch/x86/pci: files.pci > > Log Message: > Fix another indirect circular dependency (agp_* -> (agpbus) -> pc

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

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

In article <20140418072727.GA2474@marx.bitnet>, Jukka Ruohonen wrote: >On Thu, Apr 17, 2014 at 12:01:24PM -0400, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Thu Apr 17 16:01:24 UTC 2014 >> >> Modified Files: >> src/sys/arch/x86/acpi: a

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

On Thu, Apr 17, 2014 at 12:01:24PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Thu Apr 17 16:01:24 UTC 2014 > > Modified Files: > src/sys/arch/x86/acpi: acpi_cpu_md.c > > Log Message: > CID/1203191: Out of bounds read Oh, nasty. The code was p

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

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

Hello, On Mon, 27 Jan 2014 23:11:50 + "Jonathan A. Kollasch" wrote: > Module Name: src > Committed By: jakllsch > Date: Mon Jan 27 23:11:50 UTC 2014 > > Modified Files: > src/sys/arch/x86/pci: pci_machdep.c > > Log Message: > Stopgap to prevent genfb from stealing console.

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 (msai...

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: /cvsroot/src/sys/arch/x86/a

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 Log

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

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.

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

(2013/11/21 15:02), matthew green wrote: >> Module Name: src >> Committed By:msaitoh >> Date:Wed Nov 20 17:50:39 UTC 2013 >> >> Modified Files: >> src/sys/arch/x86/include: specialreg.h >> >> Log Message: >> - Add some AMD Fn8001 extended features %ecx bits definit

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

> Module Name: src > Committed By: msaitoh > Date: Wed Nov 20 17:50:39 UTC 2013 > > Modified Files: > src/sys/arch/x86/include: specialreg.h > > Log Message: > - Add some AMD Fn8001 extended features %ecx bits definitions from > the document (AMD64 Architecture ProgrammerVo

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

(2013/11/13 0:40), Christoph Egger wrote: > On 12.11.13 16:38, SAITOH Masanobu wrote: >> (2013/11/13 0:12), Christoph Egger wrote: >>> On 12.11.13 16:08, SAITOH Masanobu wrote: Module Name: src Committed By: msaitoh Date: Tue Nov 12 15:08:01 UTC 2013 >>

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

On 12.11.13 16:38, SAITOH Masanobu wrote: > (2013/11/13 0:12), Christoph Egger wrote: >> On 12.11.13 16:08, SAITOH Masanobu wrote: >>> Module Name:src >>> Committed By: msaitoh >>> Date: Tue Nov 12 15:08:01 UTC 2013 >>> >>> Modified Files: >>> src/sys/arch/x86/pci: a

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

(2013/11/13 0:12), Christoph Egger wrote: > On 12.11.13 16:08, SAITOH Masanobu wrote: >> Module Name: src >> Committed By:msaitoh >> Date:Tue Nov 12 15:08:01 UTC 2013 >> >> Modified Files: >> src/sys/arch/x86/pci: amdtemp.c >> >> Log Message: >> Calcurate the processor

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

On 12.11.13 16:08, SAITOH Masanobu wrote: > Module Name: src > Committed By: msaitoh > Date: Tue Nov 12 15:08:01 UTC 2013 > > Modified Files: > src/sys/arch/x86/pci: amdtemp.c > > Log Message: > Calcurate the processor family correctly. The extended family bits > should be added o

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, s

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_fea

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 retu

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

> Module Name: src > Committed By: jruoho > Date: Thu Dec 6 04:43:29 UTC 2012 > > Modified Files: > src/sys/arch/x86/acpi: acpi_cpu_md.c > > Log Message: > Disable C1E also on K8, if present. From Imre Vadasz > in PR install/47224. ah, that would explain why i still had to turn

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

On 05/16/12 14:00, Jean-Yves Migeon wrote: > Le 16/05/12 10:45, Christoph Egger a écrit : >> On 05/13/12 13:24, Martin Husemann wrote: >> >>> On Sun, May 13, 2012 at 01:04:15PM +0200, Jean-Yves Migeon wrote: Are you sure that moving to low priority xcalls is the way to go? You can end up

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

Le 16/05/12 10:45, Christoph Egger a écrit : On 05/13/12 13:24, Martin Husemann wrote: On Sun, May 13, 2012 at 01:04:15PM +0200, Jean-Yves Migeon wrote: Are you sure that moving to low priority xcalls is the way to go? You can end up with CPUs not being updated because they are offline. Curi

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

On 05/13/12 13:24, Martin Husemann wrote: > On Sun, May 13, 2012 at 01:04:15PM +0200, Jean-Yves Migeon wrote: >> Are you sure that moving to low priority xcalls is the way to go? You >> can end up with CPUs not being updated because they are offline. > > Curiously, while I could reproduce the cr

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

On Mon, May 14, 2012 at 08:09:18PM +0200, Joerg Sonnenberger wrote: > Why don't you just provide each CPU with a copy of the ucode and let it > free it once done? Even for 256 CPU with 16KB ucode, it would be only > 4MB of temporary memory. Or simply ref-count the memory. However (I have seen the

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

On Thu, May 10, 2012 at 12:35:53PM +, Christoph Egger wrote: > Module Name: src > Committed By: cegger > Date: Thu May 10 12:35:53 UTC 2012 > > Modified Files: > src/sys/arch/x86/x86: cpu_ucode_amd.c > > Log Message: > xc_wait() does not wait for all cpus to finish > their call

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

Le 13/05/12 13:24, Martin Husemann a écrit : On Sun, May 13, 2012 at 01:04:15PM +0200, Jean-Yves Migeon wrote: Are you sure that moving to low priority xcalls is the way to go? You can end up with CPUs not being updated because they are offline. Curiously, while I could reproduce the crash bef

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

On Sun, May 13, 2012 at 01:04:15PM +0200, Jean-Yves Migeon wrote: > Are you sure that moving to low priority xcalls is the way to go? You > can end up with CPUs not being updated because they are offline. Curiously, while I could reproduce the crash before this commit, I am unable to reproduce it

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

Le 10/05/12 14:35, Christoph Egger a écrit : + /* Check for race: +* When we booted with -x a cpu might already finished +* (why doesn't xc_wait() wait for *all* cpus?) +* and sc->sc_blob is already freed. +* In this ca

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

Le 05/05/12 17:08, Jean-Yves Migeon a écrit : Module Name:src Committed By: jym Date: Sat May 5 15:08:29 UTC 2012 Modified Files: src/sys/arch/x86/include: specialreg.h Log Message: Add latest CR4 bits: [snip] From Intel® 64 and IA-32 Architectures Software Developer

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

On 26 February 2012 01:33, Cherry G. Mathew 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. > xen_bcast_invlp

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

Hi Thomas, On 24 February 2012 14:21, Thomas Klausner 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

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

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

On 24 February 2012 13:41, Cherry G. Mathew wrote: > Module Name:    src > Committed By:   cherry > Date:           Fri Feb 24 08:11:14 UTC 2012 > > Modified Files: >        src/sys/arch/x86/x86: pmap.c > > Log Message: > kernel page attribute change should be reflected on all cpus, since > the pa

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 entri

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

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

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

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

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 and only > > autounloading the autoloaded one

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

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

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

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

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

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 rig

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

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? > > Th

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

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

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

On 18 October 2011 10:07, Jukka Ruohonen 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 >> >> D

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

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

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 autounload

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

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 autounload I wonder should autounloading be pr

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

On Mon, Aug 08, 2011 at 03:03:41PM +0300, Jukka Ruohonen wrote: > Note also that at least with Intel CPUs, > the TSC should be entirely safe with the current stock-NetBSD (i.e. no > automatic CPU power management), but now you've marked it unreliable for > many systems (cf. also [1]). Tell that to

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

On Mon, 8 Aug 2011, Jukka Ruohonen wrote: On Mon, Aug 08, 2011 at 08:16:43AM -0400, Jared McNeill wrote: Newer systems with invariant TSC shouldn't set the USE_PLATFORM_CLOCK flag. But the do, unfortunately. Again, I have several examples from the field. I'd be willing to let CPUID.8007

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

On Mon, 8 Aug 2011, Jukka Ruohonen wrote: Yes, but when possible, we should always prefer actual, reliable, CPU information instead of the BIOS. Note also that at least with Intel CPUs, the TSC should be entirely safe with the current stock-NetBSD (i.e. no automatic CPU power management), but now

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

On Mon, Aug 08, 2011 at 08:16:43AM -0400, Jared McNeill wrote: > Newer systems with invariant TSC shouldn't set the USE_PLATFORM_CLOCK > flag. But the do, unfortunately. Again, I have several examples from the field. - Jukka.

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

On Mon, Aug 08, 2011 at 02:29:36PM +0300, Jukka Ruohonen wrote: > We should not really trust ACPI/FADT here. See acpicpu(4) how this is > derived from the actual CPU information. Additionally, I suggested decreasing > the quality of tsc(9) based on this information a long time ago, but joerg@ > had

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

On Mon, Aug 08, 2011 at 07:49:42AM -0400, Jared McNeill wrote: > On Mon, 8 Aug 2011, Jukka Ruohonen wrote: > >>Why? > > > >Because we (the operating system) know this better than the BIOS writer. > >And because this flag is not reliable; numerous systems where tsc(9) is > >"broken" miss this flag i

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

On Mon, 8 Aug 2011, Jukka Ruohonen wrote: Why? Because we (the operating system) know this better than the BIOS writer. And because this flag is not reliable; numerous systems where tsc(9) is "broken" miss this flag in my ACPI table collection, and vice versa. This flag is new in ACPI v3.0. I

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

On Mon, Aug 08, 2011 at 07:40:45AM -0400, Jared McNeill wrote: > On Mon, 8 Aug 2011, Jukka Ruohonen wrote: > >We should not really trust ACPI/FADT here. See acpicpu(4) how this is > > Why? Because we (the operating system) know this better than the BIOS writer. And because this flag is not reliab

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

On Mon, 8 Aug 2011, Jukka Ruohonen wrote: We should not really trust ACPI/FADT here. See acpicpu(4) how this is Why? derived from the actual CPU information. Additionally, I suggested decreasing the quality of tsc(9) based on this information a long time ago, but joerg@ had concerns about thi

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

On Mon, Aug 08, 2011 at 11:18:35AM +, Jared D. McNeill wrote: > Module Name: src > Committed By: jmcneill > Date: Mon Aug 8 11:18:34 UTC 2011 > > Modified Files: > src/sys/arch/x86/x86: tsc.c > > Log Message: > If the USE_PLATFORM_CLOCK flag is set in the FADT, it indicates th

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

dyo...@pobox.com said: > Matthias Drochner wrote: > > add an experimental implementation of PCI MSIs (Message Signaled > > Interrupts) > Can you replace the magic numbers with symbols from pcireg.h ? You may > need to add the symbols, of course. There are already some symbols for MSIs, but incomp

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

On Mon, Aug 01, 2011 at 11:08:04AM +, Matthias Drochner wrote: > Module Name: src > Committed By: drochner > Date: Mon Aug 1 11:08:03 UTC 2011 > > Modified Files: > src/sys/arch/x86/include: pci_machdep_common.h > src/sys/arch/x86/pci: pci_intr_machdep.c > > Log Message:

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Mar 7, 2011, at 10:48 PM, Jared McNeill wrote: On Tue, 8 Mar 2011, Michael Lorenz wrote: Modified Files: src/sys/arch/x86/x86: x86_autoconf.c lol I was tempted to add something like "Yes Jared, hell did freeze over" ;) have

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

On Tue, 8 Mar 2011, Michael Lorenz wrote: Modified Files: src/sys/arch/x86/x86: x86_autoconf.c lol

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

> On Fri, Mar 04, 2011 at 04:04:53PM +1100, matthew green wrote: > > > Raise the return value of the match-function of est(4) and powernow(4). > > > The assigned priorities are now: 10 for acpicpu(4), 5 for est(4) and > > > powernow(4), and 1 for odcm(4). These are used to pick the preferred > >

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

On Fri, Mar 04, 2011 at 04:04:53PM +1100, matthew green wrote: > > Raise the return value of the match-function of est(4) and powernow(4). > > The assigned priorities are now: 10 for acpicpu(4), 5 for est(4) and > > powernow(4), and 1 for odcm(4). These are used to pick the preferred driver. > > t

<    2   3   4   5   6   7   8   >