On Tue, Jan 04, 2011 at 05:23:08 +, David Holland wrote:
On Tue, Jan 04, 2011 at 02:58:18AM +0100, Adam Hamsik wrote:
Are they really *lock* files?
It's lvm subsystem lock file. Does it need to be specific in any way ?
If it's really a lock file that may need to persist across
Matt Thomas modified UVM colour matching scheme;
Modified Files:
src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c
Log Message:
Add better color matching selecting free pages. KM pages will now allocated
so that VA and PA have the same color. On a page fault, choose a physical
On 1/4/11 2:26 AM, Matt Thomas wrote:
Module Name: src
Committed By: matt
Date: Tue Jan 4 08:26:33 UTC 2011
Modified Files:
src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c
Log Message:
...
When allocating kernel memory pages, allow the MD to specify a preferred
On Jan 4, 2011, at 2:19 AM, Michael Graff wrote:
On 1/4/11 2:26 AM, Matt Thomas wrote:
Module Name: src
Committed By:matt
Date:Tue Jan 4 08:26:33 UTC 2011
Modified Files:
src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c
Log Message:
...
When
On Mon Jan 03 2011 at 18:55:42 +, Arnaud Ysmal wrote:
Module Name: src
Committed By: stacktic
Date: Mon Jan 3 18:55:42 UTC 2011
Modified Files:
src/crypto/external/bsd/openssh/dist: sshconnect2.c
Log Message:
Fixed strvisx usage
Didn't you fix that already once
On Tue, 4 Jan 2011, Matt Thomas wrote:
Module Name:src
Committed By: matt
Date: Tue Jan 4 10:59:29 UTC 2011
Modified Files:
src/sys/compat/netbsd32: files.netbsd32 netbsd32_sa.c
Log Message:
Make the SA support as optional as is possible.
This commit appears to have
Jukka Ruohonen jruoho...@iki.fi wrote:
+/*
+ * sysmon_task_queue_cancel:
+ *
+ * Cancel a scheduled task.
+ */
+int
+sysmon_task_queue_cancel(void (*func)(void *))
+{
+ struct sysmon_task *st;
+
+ if (func == NULL)
+ return EINVAL;
+
+
On Tue, Jan 04, 2011 at 02:32:02AM -0800, Matt Thomas wrote:
Not really. A lot of device can only do 32bit DMA transfers so without some
type assistance (like the alpha has) you are restricted to DMA to the first
4GB of RAM. If you are doing DMA to an address = 4GB, the system will stage
The following patch seems to take care of things, at least on my amd64
machine. I'm not sure if this is the correct fix, so I will let someone
else handle the commit!
Index: netbsd32_sa.c
===
RCS file:
On Tue, Jan 04, 2011 at 12:52:57PM +, Mindaugas Rasiukevicius wrote:
1) There is a use-after-free. Hint: TAILQ_FOREACH_SAFE().
2) It is not safe; while lock is dropped, the 'next' entry may also
be removed and freed. Hint: have a local list and avoid relocking.
Hmm. 2) implies that the
On Tue, Jan 04, 2011 at 06:25:12PM +0900, Toru Nishimura wrote:
Matt Thomas modified UVM colour matching scheme;
Modified Files:
src/sys/uvm: uvm_extern.h uvm_fault.c uvm_km.c uvm_page.c
Log Message:
Add better color matching selecting free pages. KM pages will now allocated
so
On Jan 4, 2011, at 4:57 AM, Manuel Bouyer wrote:
On Tue, Jan 04, 2011 at 02:32:02AM -0800, Matt Thomas wrote:
Not really. A lot of device can only do 32bit DMA transfers so without some
type assistance (like the alpha has) you are restricted to DMA to the first
4GB of RAM. If you are
Masao Uebayashi uebay...@tombi.co.jp responds as;
The entire effect is to eliminate the necessity of VIPT fixup efforts in
port-specific pmap.c and ends up with improving the cache effeciency
in large degree. This is _the intent_ behind VIPT design. So far OS
virtual memory strategy paid
On Jan 4, 2011, at 8:33 AM, Manuel Bouyer wrote:
On Tue, Jan 04, 2011 at 08:03:33AM -0800, Matt Thomas wrote:
I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your
change
has reintroduced this problem ...
Since it's not turned on by default, I doubt it.
I guess if
On Tue, Jan 04, 2011 at 08:35:48AM -0800, Matt Thomas wrote:
On Jan 4, 2011, at 8:33 AM, Manuel Bouyer wrote:
On Tue, Jan 04, 2011 at 08:03:33AM -0800, Matt Thomas wrote:
I fixed this issue in arch/x86/x86/x86_machdep.c 1.37, I wonder if your
change
has reintroduced this problem ...
On Mon Jan 03 2011 at 18:55:42 +, Arnaud Ysmal wrote:
Module Name: src
Committed By: stacktic
Date: Mon Jan 3 18:55:42 UTC 2011
Modified Files:
src/crypto/external/bsd/openssh/dist: sshconnect2.c
Log Message:
Fixed strvisx usage
Didn't you fix that already
On Tue, Jan 04, 2011 at 11:46:34AM +0300, Valeriy E. Ushakov wrote:
2) /var/spool/lock/lvm
is the right place.
Ugh. What does it have to do with spooling?
What do any locks have to do with spooling? Historically, /var/spool
is for stuff. Since then lots of things traditionally
On Jan,Tuesday 4 2011, at 8:56 AM, Alan Barrett wrote:
On Tue, 04 Jan 2011, Adam Hamsik wrote:
I would like to have something persistent between reboots. I
have found that we already have /var/spool/lock. Therefore
/var/spool/lock/lvm/ seems to be might preferred place. Do you agree ?
I
On Tue, Jan 04, 2011 at 19:43:49 +, David Holland wrote:
On Tue, Jan 04, 2011 at 11:46:34AM +0300, Valeriy E. Ushakov wrote:
2) /var/spool/lock/lvm
is the right place.
Ugh. What does it have to do with spooling?
What do any locks have to do with spooling?
On Tue, Jan 04, 2011 at 23:41:00 +0100, Adam Hamsik wrote:
Subject: Re: /var/lock
From: Adam Hamsik haa...@gmail.com
Date: Tue, 4 Jan 2011 23:41:00 +0100
Cc: source-changes-d@NetBSD.org
To: Alan Barrett a...@cequrux.com
On Jan,Tuesday 4 2011, at 8:56 AM, Alan Barrett wrote:
On Tue,
On Wed, Jan 05, 2011 at 00:43:11 +0100, Adam Hamsik wrote:
On Jan,Wednesday 5 2011, at 12:13 AM, Valeriy E. Ushakov wrote:
On Tue, Jan 04, 2011 at 23:41:00 +0100, Adam Hamsik wrote:
Ok I will change it to /var/spool/lock/lvm tomorrow and I will update
hier to mention those
On Wed, 5 Jan 2011, Jeff Rizzo wrote:
Module Name:src
Committed By: riz
Date: Wed Jan 5 02:25:27 UTC 2011
Modified Files:
src/distrib/sets/lists/tests: mi
src/tests/sbin/resize_ffs: Makefile common.sh t_grow.sh t_shrink.sh
Added Files:
On 1/4/11 6:32 PM, Paul Goyette wrote:
On Wed, 5 Jan 2011, Jeff Rizzo wrote:
Log Message:
Update resize_ffs tests for byteswapped file system support, and
for UFS2 growth support. Also, reduce the number of tests run by
default
while still maintaining decent coverage of features and block
hi,
I take silence as no objection.
the silence in this case means was-busy-for-other-things-and-forgot.
sorry.
I have no real code for this big picture at this moment. Making
vm_physseg available as reference is the first step. This only
changes uvm_page_physload() to return a pointer:
24 matches
Mail list logo
