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,
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
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
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
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:
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
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
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
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
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
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
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
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:
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,
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.
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
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
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
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
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
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 that OSPM
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
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 reliable;
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. If
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 in my ACPI
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.
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
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
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 my
On Tue, 8 Mar 2011, Michael Lorenz wrote:
Modified Files:
src/sys/arch/x86/x86: x86_autoconf.c
lol
-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
Module Name: src
Committed By: jruoho
Date: Fri Mar 4 04:53:28 UTC 2011
Modified Files:
src/sys/arch/x86/x86: est.c powernow.c
Log Message:
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
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.
to the
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.
Module Name:src
Committed By: dyoung
Date: Wed Feb 24 21:22:01 UTC 2010
Modified Files:
src/sys/arch/x86/x86: intr.c
Log Message:
Rename to 'pc' all variables 'pci_chipset_tag'.
To generate a diff of this commit:
cvs rdiff -u -r1.66 -r1.67 src/sys/arch/x86/x86/intr.c
Module Name:src
Committed By: pgoyette
Date: Sun Feb 14 23:07:59 UTC 2010
Modified Files:
src/sys/arch/x86/x86: ipmi.c
Log Message:
Adapt to changes in sysmon's limit structure.
To generate a diff of this commit:
cvs rdiff -u -r1.42 -r1.43 src/sys/arch/x86/x86/ipmi.c
Module Name:src
Committed By: jym
Date: Tue Feb 9 23:47:10 UTC 2010
Modified Files:
src/sys/arch/x86/x86: cpu.c
Log Message:
Use roundup2() instead of hardcoding the operation.
To generate a diff of this commit:
cvs rdiff -u -r1.66 -r1.67 src/sys/arch/x86/x86/cpu.c
Module Name:src
Committed By: jym
Date: Tue Feb 9 23:52:14 UTC 2010
Modified Files:
src/sys/arch/x86/x86: cpu.c x86_machdep.c
Log Message:
Wrap a comment; add a space after a comma to another (align with next line)
To generate a diff of this commit:
cvs rdiff -u -r1.67
Module Name:src
Committed By: mlelstv
Date: Sun Jan 31 11:39:55 UTC 2010
Modified Files:
src/sys/arch/x86/x86: ipmi.c
Log Message:
Release buffer in case a receive failed.
To generate a diff of this commit:
cvs rdiff -u -r1.41 -r1.42 src/sys/arch/x86/x86/ipmi.c
Please
Module Name:src
Committed By: jym
Date: Sun Jan 10 12:10:23 UTC 2010
Modified Files:
src/sys/arch/x86/x86: pmap.c
Log Message:
Simplify pmap_init_tmp_pgtbl() a bit.
The first level of the temporary page mappings are also done in the first
iteration of the loop below, so
Module Name:src
Committed By: cegger
Date: Sat Jan 9 22:54:00 UTC 2010
Modified Files:
src/sys/arch/x86/x86: x86_machdep.c
Log Message:
TOPLIMIT for i386 PAE is 64GB.
To generate a diff of this commit:
cvs rdiff -u -r1.37 -r1.38 src/sys/arch/x86/x86/x86_machdep.c
Module Name:src
Committed By: jruoho
Date: Tue Jan 5 13:32:49 UTC 2010
Modified Files:
src/sys/arch/x86/x86: mpacpi.c
Log Message:
Fix several possible memory leaks in mpacpi_derive_bus().
ok pgoyette@, jmcneill@
To generate a diff of this commit:
cvs rdiff -u -r1.80
Module Name:src
Committed By: jruoho
Date: Tue Jan 5 17:23:18 UTC 2010
Modified Files:
src/sys/arch/x86/x86: mpacpi.c
Log Message:
Put back the evaluation of the return value from mpacpi_get_bbn().
Break reported by nj...@. Thanks!
To generate a diff of this commit:
Modified Files:
src/sys/arch/x86/x86: patch.c
Log Message:
Gracelessly bracket #include opt_spldebug.h with #ifdef i386.
Should fix the amd64 kernel-build failure that Andreas Wrede
reported.
perhaps __i386__
I think __i386__ or __x86_64__ for ${MACHINE_ARCH},
and i386 or amd64
In article 091104193344.m0225...@mirage.ceres.dti.ne.jp,
Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
Modified Files:
src/sys/arch/x86/x86: patch.c
Log Message:
Gracelessly bracket #include opt_spldebug.h with #ifdef i386.
Should fix the amd64 kernel-build failure that Andreas Wrede
note that the kernel is built with -D${MACHINE}, last i looked.
On Nov 5, 12:26pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/sys/arch/x86/x86
| note that the kernel is built with -D${MACHINE}, last i looked.
Should it, or should it rely just on the compiler defines?
the compiler does not and should
p...@whooppee.com said:
I guess maybe the minus signs shouldn't ever happen?
someone out here with a liquid nitrogen cooler?
best regards
Matthias
given that this issue is appearing on both ipmi and coretemp, and the
fact that coretemp doesn't even bother with hi/low limits, it's probably
something in envsys itself.
On Tue, 7 Jul 2009, Matthias Drochner wrote:
p...@whooppee.com said:
I guess maybe the minus signs shouldn't ever
301 - 349 of 349 matches
Mail list logo
