Doug Barton wrote:
On 05/05/10 11:56, Alan Cox wrote:
I'm afraid that I would advise waiting a few days. This round of changes
are not yet complete.
Is the coast clear yet? :) I have been holding off on updating -current
due to the SUJ stuff, but that seems to have mostly settled
Doug Barton wrote:
On 05/08/10 13:36, Alan Cox wrote:
Doug Barton wrote:
On 05/05/10 11:56, Alan Cox wrote:
I'm afraid that I would advise waiting a few days. This round of
changes
are not yet complete.
Is the coast clear yet? :) I have been holding off
On Wed, May 5, 2010 at 11:19 AM, Yuri Pankov yuri.pan...@gmail.com wrote:
Hi,
After recent changes to sys/vm/ by alc@, I'm getting panics as soon as I
start xorg-server with nvidia-driver (both 195.22 and 195.36.15):
panic: mutex page lock not owned at
On Sat, May 1, 2010 at 5:21 PM, Bruce Cran bru...@cran.org.uk wrote:
On Thu, Apr 29, 2010 at 06:37:00PM -1000, Jeff Roberson wrote:
I fixed a few SUJ bugs. If those of you who reported one of the
following bugs could re-test I would greatly appreciate it.
I've started seeing a panic
2010/3/20 Alexander Motin m...@freebsd.org
Hi.
With set of changes done to ATA, CAM and GEOM subsystems last time we
may now get use for increased MAXPHYS (maximum physical I/O size) kernel
constant from 128K to some bigger value.
[snip]
All above I have successfully tested last months
On Mon, Oct 06, 2003 at 02:30:30AM -0700, Kris Kennaway wrote:
I got this upon attempting to burn a CD with cdrecord on my
freshly-updated current machine:
panic: mutex vm object not owned at ../../../vm/vm_page.c:762
This should now be fixed.
Alan
syncing disks, buffers remaining...
This should resolve the problem starting X.
- Forwarded message from Alan Cox [EMAIL PROTECTED] -
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
From: Alan Cox [EMAIL PROTECTED]
Date: Sun, 5 Oct 2003 15:23:44 -0700 (PDT)
To: [EMAIL
On Sat, Oct 04, 2003 at 11:31:33PM -0700, Kris Kennaway wrote:
I don't think I've seen this one before (i386, kernel built Sep 17).
Is it already fixed?
No, not yet.
Regards,
Alan
recursed on non-recursive lock (sleep mutex) vm page queue mutex @
On Thu, Sep 25, 2003 at 11:15:57AM -0400, Robert Watson wrote:
...
#6 0xc049f355 in vm_fault (map=0xc6fc1700, vaddr=0, fault_type=1 '\001',
fault_flags=0) at /usr/src/sys/vm/vm_fault.c:219
#7 0xc04eddd9 in trap_pfault (frame=0xdd699b18, usermode=0, eva=0)
at
At the start of the weekend, I made a typo in a commit that changed
vmapbuf() to use a new pmap function. The result was that raw disk
access sometimes failed. I recognized and fixed the problem last
night. Simply update your vfs_bio.c to the latest version and
you should be fine.
Sorry for
The Mach code we originally inherited was supposed to already by
multiprocessor safe. Did we manage to eliminate that capability?
Yes and no. The vm_map layer still has the necessary locking calls,
but the vm_object and pmap layers don't. The pmap is still similar
enough that the original
Hi.
Isn't the page coloring algoritm in _vm_page_list_find totally bogus?
No, it's not. The comment is, however, misplaced. It describes
the behavior of an inline function in vm_page.h, and not the function
it precedes.
It skips queue pq[index PQ_L2_MASK].
That's correct. The
Does anyone know if it's by design or by accident that kthread_create
specifies RFFDG to fork1? It seems odd to ask for the file descriptor
table to be copied and not shared.
Alan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Try a Promise ATA/66 controller. I have no problems
with either
ad0: 29311MB Maxtor 53073U6 [59554/16/63] at ata0-master using UDMA66
or
ad3: 29188MB ST330630A [59303/16/63] at ata3-master using UDMA66
on a very heavy disk load using either a Promise ATA/66 or
the Intel 810(E)'s ATA/66
About two days ago, I tested a machine with four IDE drives
each on its own cable as the master. All four drives were:
ad0: 29311MB Maxtor 53073U6 [59554/16/63] at ata0-master using UDMA66
I used the motherboard controller to support two of the drives. It was a
atapci0: Intel ICH ATA66
This patch introduces a new bug. While it does guarantee that
the assertion in vm_object_shadow isn't tripped over, it doesn't
clear the OBJ_ONEMAPPING flag on the newly created shadow object.
(New objects are created with OBJ_ONEMAPPING set.) Consequently,
we'll have two overlapping mappings
On Sat, Apr 15, 2000 at 11:23:11AM -0700, Matthew Dillon wrote:
:Well, first the question must be answered, in an absolute yes or no:
:is it wrong in the first place to have OBJ_ONEMAPPING set with a ref_count
:of more than 1? I'd accept an authoritative answer about this from
:alc, dillon,
On Sat, Apr 15, 2000 at 06:12:22PM -0400, Brian Fundakowski Feldman wrote:
On Sat, 15 Apr 2000, Matthew Dillon wrote:
Note that the ref_count == 1 test in the vm_object_shadow optimization
should be left intact. This optimization requires a much stricter set
of tests because
On Sat, Apr 15, 2000 at 06:09:56PM -0400, Brian Fundakowski Feldman wrote:
I'm still trying to understand this: if you know that the object may
have pages mapped elsewhere, the backing objects recursively inherit
the assumption that it may have parts mapped elsewhere?
Umm, just to be
On Sat, Apr 15, 2000 at 08:13:20PM -0700, Matthew Dillon wrote:
:Here's what I worry about: We only clear OBJ_ONEMAPPING on the top-level
:object, and none of its backing objects. Nothing guarantees that these
:backing objects have OBJ_ONEMAPPING cleared. The page that we're "double"
On Sat, Apr 15, 2000 at 08:18:01PM -0700, Matthew Dillon wrote:
:Is there a good reason for not having the vm_object_clear_flag() in
:vm_object_reference()?
Well, yes... vm_object's are referenced for all sorts of things
temporarily. Everything from a process looking one up
Arun Sharma wrote:
I just did some investigation into seeing if this (balanced binary trees)
is a useful optimization. It doesn't look like one.
I instrumented the kernel and collected some stats. On booting the kernel
into KDE and running xemacs and netscape, I got:
The applications you
...
Resource limits are still an issue. It turns out that the
MAP_STACK code does not deal with the stack resource limit
well at all -- sometimes it catches it, sometimes it doesn't.
In what sense? My recollection is that resource limits are
enforced on the "regular" process stack
I would appreciate it if people running -current would run a "vmstat -s"
and tell me if they see a NON-ZERO value for copy-on-write optimized
faults. About six months ago, I implemented a simpler and more general
optimization at an earlier "fork in the road". (In effect, I avoid
the creation of
On Sat, Oct 30, 1999 at 12:47:40AM +0200, Bernd Walter wrote:
307625181 copy-on-write faults
26 copy-on-write optimized faults
Thanks to Bernd and everyone else who has responded. Unless someone
reports a case where the old "optimization" gets applied more often
than 1 in ten million
Actually, the last time I looked the Modula-3 run-time system determined
the faulting address from the undocumented (except on SunOS 4) 4th argument
that most BSD-derived systems passed to the signal handler. There was
a time in fact when sc_err wasn't included in the sigcontext on FreeBSD
and
I don't think this is a new problem. I recall a similar error being
mentioned on the -stable mailing list last week.
If you can repeat the error, please write down the program counter
value. Knowing the instruction at which the fault occurs would
be most valuable.
Alan
To Unsubscribe:
On Mon, Jul 12, 1999 at 10:53:49PM +0400, Dmitrij Tejblum wrote:
I don't see how MAP_ANON is better than MAP_STACK.
It consumes fewer resources. Each time you grow the stack, it adds
another vm_map_entry to the vm_map and (eventually) allocates another
vm_object. Using MAP_ANON, there is
Before this thread on "cache coherence" and "memory consistency" goes
any further, I'd like to suggest a time-out to read something like
http://www-ece.rice.edu/~sarita/Publications/models_tutorial.ps.
A lot of what I'm reading has a grain of truth but isn't quite
right. This paper appeared as a
Please try the attached patch.
Alan
Index: vm/vm_object.c
===
RCS file: /home/ncvs/src/sys/vm/vm_object.c,v
retrieving revision 1.158
diff -c -r1.158 vm_object.c
*** vm_object.c 1999/07/01 19:53:42 1.158
--- vm_object.c
I bought two of the cards in order to decide whether or not I wanted
to use them in my research group's PII cluster. Right now, they're
plugged into a 233MHz Pentium Pro and a 400Mhz K6-2 (using an
Aladdin V-based board). I did a bunch of NFS testing over the
gigabit link last week and didn't
I've just committed Matt's VFS/BIO/NFS patch.
Alan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
On Wed, Apr 28, 1999 at 11:19:17AM -0700, Matthew Dillon wrote:
I know this is a little late ... but I don't suppose there might be a
way to lock a TLB entry in place? That would solve the problem too.
Baring that, %fs is the way to go.
Unfortunately, on the x86, the answer is
On Wed, Apr 28, 1999 at 02:48:56PM -0700, Matthew Dillon wrote:
...
There might be less confusion with %fs if we simply use it as a
'cpu number' index and then make all the cpu-dependant variables
standard arrays. i.e. instead if 'struct proc *curproc' we would
have
I've committed the basic infrastructure to improve TLB management
on SMPs. Translation: this will lead to the elimination of a LOT
of interprocessor interrupts to invalidate TLB entries. I'll be
turning on the new mechanisms slowly so we can carefully debug
each step and (hopefully) avoid any
On Thu, Mar 04, 1999 at 01:46:49PM -0500, John Capo wrote:
Is this valid for 3.1 or just -current?
Yes. The same bug exists in 3.1.
Alan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
On Thu, Mar 04, 1999 at 02:40:14AM +0900, Daniel C. Sobral wrote:
And the question is how he managed to. :-)
I graduated from CMU in 1986. While there, I worked part-time
on the Mach project. Later, I used the Mach VM code as infrastructure
for my Ph.D. thesis on automatic data placement
There is an SMP-specific bug in pmap_remove_all. Specifically, it may
fail to perform a TLB invalidation on the other processor(s) when one is
in fact necessary.
I don't have an SMP to test this, so would some of you with SMPs
please do a sanity test on this patch? In effect, the patch disables
On Tue, Mar 02, 1999 at 10:41:46PM +1100, Bruce Evans wrote:
Doesn't it modify the map indirectly vi subyte()? I think it wants
to prevent modifications, but this is impossible.
Bear with me, I'll have to split some hairs...
We're only interested in whether mincore directly changes the
On Tue, Mar 02, 1999 at 06:16:50PM -0500, Brian Feldman wrote:
Where exactly does thrd_sleep come in, since that's where the program locks
up now? Can't be killed, of course...
The lock manager isn't bright enough to detect that the process
already holds a read lock when it attempts to get
Until you modify the map, an exclusive lock on the map is overkill. Try
using read locks. (See vm_map_lookup.)
In the meantime, I can't see any reason why mincore acquires an
exclusive lock either. (It never modifies the map.) I'm going
to remedy that.
Alan
To Unsubscribe: send
Your bug fix is in my queue.
Alan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
On Tue, 16 Feb 1999, John S. Dyson wrote:
If we can get ALC to agree, I prefer him to be the first line (but I am
willing to fill-in and support DG and ALC when needed.) ...
I am willing. In the meantime, let's try to cool things down a bit.
Alan
To Unsubscribe: send mail to
Look at vm_map_find.
Alan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
101 - 144 of 144 matches
Mail list logo
