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
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
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:
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 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
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
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
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
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
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
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 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...
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
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
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
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
On 11/02/2011 05:32, Andriy Gapon wrote:
[restored cc: to the original poster]
on 02/11/2011 08:10 Benjamin Kaduk said the following:
I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include
opt_global.h' to be passed on the command line. Is the issue just that the
opt_global.h
On 11/03/2011 08:24, Kostik Belousov wrote:
On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote:
On 11/02/2011 05:32, Andriy Gapon wrote:
[restored cc: to the original poster]
As Bruce Evans has pointed to me privately [I am not sure why privately],
there
is already an example in i386
On 11/04/2011 05:08, Kostik Belousov wrote:
On Thu, Nov 03, 2011 at 12:51:10PM -0500, Alan Cox wrote:
On 11/03/2011 08:24, Kostik Belousov wrote:
On Thu, Nov 03, 2011 at 12:40:08AM -0500, Alan Cox wrote:
On 11/02/2011 05:32, Andriy Gapon wrote:
[restored cc: to the original poster]
As Bruce
On 11/04/2011 10:30, Kostik Belousov wrote:
On Fri, Nov 04, 2011 at 10:09:09AM -0500, Alan Cox wrote:
On 11/04/2011 05:08, Kostik Belousov wrote:
On Thu, Nov 03, 2011 at 12:51:10PM -0500, Alan Cox wrote:
I would suggest introducing the vm_page_bits_t change first. If, at the
same time, you
On 11/05/2011 10:15, Kostik Belousov wrote:
On Sat, Nov 05, 2011 at 07:37:48AM -0700, m...@freebsd.org wrote:
On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousovkostik...@gmail.com wrote:
On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
Below is the KBI patch after vm_page_bits_t
On 11/06/2011 06:43, Kostik Belousov wrote:
On Sat, Nov 05, 2011 at 03:00:58PM -0500, Alan Cox wrote:
On 11/05/2011 10:15, Kostik Belousov wrote:
On Sat, Nov 05, 2011 at 07:37:48AM -0700, m...@freebsd.org wrote:
On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousovkostik...@gmail.com
wrote:
On Fri
On 11/14/2011 03:19, Andriy Gapon wrote:
Please disregard my report.
I've tracked the problem to one of the new modules being faulty. But memtest86*
tools still don't detect any issues with it. Apparently FreeBSD is a much more
thorough memory tester than the specialized tools :-)
Apologies
On 11/26/2011 06:44, Andriy Gapon wrote:
on 26/11/2011 14:19 Gustau Pérez said the following:
Starting Virtualbox in the console in headless mode allows to see what
happens
and get a dump of the panic.
The messages I got were not the cause problem. The panic I was able to get
shows
On 12/05/2011 07:56, Andriy Gapon wrote:
on 05/12/2011 15:15 Bernhard Froehlich said the following:
On 05.12.2011 14:06, Andriy Gapon wrote:
on 05/12/2011 14:57 Bernhard Froehlich said the following:
On 02.12.2011 12:55, Bernhard Froehlich wrote:
Patch has been send upstream:
On 12/5/2011 4:02 PM, Andriy Gapon wrote:
on 05/12/2011 19:58 Alan Cox said the following:
On 12/05/2011 07:56, Andriy Gapon wrote:
Pages should be marked busy only for some special occasions, wired pages are not
normally busy; the correct explanation is quite a bit longer than
On 12/5/2011 4:38 PM, Andriy Gapon wrote:
on 06/12/2011 00:22 Alan Cox said the following:
On 12/5/2011 4:02 PM, Andriy Gapon wrote:
on 05/12/2011 19:58 Alan Cox said the following:
On 12/05/2011 07:56, Andriy Gapon wrote:
Pages should be marked busy only for some special occasions, wired
On Sat, Jun 9, 2012 at 9:26 PM, Garrett Cooper yaneg...@gmail.com wrote:
I build out of my UFS-only VM in VMware Fusion from time to time,
and it looks like there's a large chunk of processes that are swapped out
when doing two parallel builds:
last pid: 27644; load averages: 2.43,
On 06/20/2012 08:25, Konstantin Belousov wrote:
On Wed, Jun 20, 2012 at 08:19:39AM -0400, John Baldwin wrote:
On Tuesday, June 19, 2012 9:30:59 pm Steve Wills wrote:
Hi,
I just got a panic out of my r237195 system. The panic looks like:
Sleeping thread (tid 173153, pid 42034) owns a
On Wed, Jul 4, 2012 at 4:57 PM, Steve Wills swi...@freebsd.org wrote:
Setting kern.ipc.shm_use_phys back to 0 (the default) fixed it. I had set
it to 1 for some reason that I can't recall.
That shouldn't cause a crash in pmap_enter(). What is line 3587 of pmap.c
in your sources? You
On 07/08/2012 11:59, Konstantin Belousov wrote:
On Sun, Jul 08, 2012 at 12:57:39PM -0400, Michael Butler wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/08/12 11:18, Michael Butler wrote:
On 07/08/12 10:31, Konstantin Belousov wrote:
Catch it next time ? This should be quite
On Sun, Jul 8, 2012 at 3:16 AM, Jean-Sébastien Pédron
dumbb...@freebsd.orgwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08.07.2012 05:14, Steve Wills wrote:
For what it's worth, I discovered that twm and xterm don't trigger
the issue, but konsole and other kde things do, which
On Sat, Jul 21, 2012 at 10:59 AM, Brandon Gooch jamesbrandongo...@gmail.com
wrote:
On Sat, Jul 21, 2012 at 10:11 AM, O. Hartmann
ohart...@zedat.fu-berlin.de wrote:
On 07/21/12 16:53, O. Hartmann wrote:
On FreeBSD 10.0-CURRENT #1 r238671: Sat Jul 21 16:21:32 CEST 2012
(/usr/src recently
On Sun, Aug 12, 2012 at 5:44 PM, Colin Percival cperc...@freebsd.orgwrote:
Hi all,
If I'm understanding things correctly, the maxswzone value -- set by the
kern.maxswzone loader tunable or to VM_SWZONE_SIZE_MAX by default -- should
be approximately 9 MiB per GiB of swap space.
The current
On Wed, Aug 22, 2012 at 7:01 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
I am trying to make netmap adapt the amount of memory it allocates
to what is available. At its core, it uses contigmalloc() with
small chunks (even down to 1 page) to fetch memory.
Problem is, i notice that before
On 08/23/2012 11:31, Luigi Rizzo wrote:
On Thu, Aug 23, 2012 at 10:48:27AM -0500, Alan Cox wrote:
On Wed, Aug 22, 2012 at 7:01 AM, Luigi Rizzori...@iet.unipi.it wrote:
I am trying to make netmap adapt the amount of memory it allocates
to what is available. At its core, it uses contigmalloc
On 08/23/2012 12:45, Luigi Rizzo wrote:
On Thu, Aug 23, 2012 at 12:08:40PM -0500, Alan Cox wrote:
...
yes i do see that.
Maybe less aggressive with M_NOWAIT but still kills processes.
Are you compiling world with MALLOC_PRODUCTION? The latest version of
whatever the default
On 08/24/2012 09:57, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 12:43:33AM -0500, Alan Cox wrote:
On 08/23/2012 12:45, Luigi Rizzo wrote:
On Thu, Aug 23, 2012 at 12:08:40PM -0500, Alan Cox wrote:
...
yes i do see that.
Maybe less aggressive with M_NOWAIT but still kills processes.
Are you
On 08/24/2012 11:54, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 11:12:51AM -0500, Alan Cox wrote:
On 08/24/2012 09:57, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 12:43:33AM -0500, Alan Cox wrote:
On 08/23/2012 12:45, Luigi Rizzo wrote:
On Thu, Aug 23, 2012 at 12:08:40PM -0500, Alan Cox wrote
On 08/26/2012 12:11, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 11:56:06AM -0500, Alan Cox wrote:
On 08/24/2012 11:54, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 11:12:51AM -0500, Alan Cox wrote:
On 08/24/2012 09:57, Luigi Rizzo wrote:
On Fri, Aug 24, 2012 at 12:43:33AM -0500, Alan Cox wrote
On 08/27/2012 06:39, Luigi Rizzo wrote:
On Mon, Aug 27, 2012 at 02:42:28AM -0500, Alan Cox wrote:
...
this is dmesg when I add kdb_backtrace() at the start of vm_pageout_oom()
The '... netmap_finalize_obj_allocator... are from my calls to
contigmalloc, each one doing one-page allocations
On 10/23/2012 08:14, Konstantin Belousov wrote:
On Tue, Oct 23, 2012 at 02:36:07PM +0200, Svatopluk Kraus wrote:
Hi,
I'm just syncing my ARM pmap code (base on i386 one) with current
i386 pmap code. It looks that sched_pin() is missing after successful
rw_try_wlock() in pmap_protect().
On 11/16/2012 20:54, Garrett Cooper wrote:
On Fri, Nov 16, 2012 at 6:24 PM, AN a...@neu.net wrote:
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r243165: Fri Nov 16
20:53:48 EST 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64
Vbox is broken for me after recent upgrade.
#
On 11/27/2012 09:06, Konstantin Belousov wrote:
On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc:/usr/obj/usr/src/head/sys/GENERIC amd64
#0 doadump (textdump=-2014022336) at
On 11/27/2012 12:08, Andre Oppermann wrote:
On 27.11.2012 17:42, Alan Cox wrote:
On 11/27/2012 09:06, Konstantin Belousov wrote:
On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
FreeBSD bbb.ccc 10.0-CURRENT FreeBSD 10.0-CURRENT #0:
Fri Nov 23 17:00:40 CET 2012
a...@bbb.ccc
On 11/27/2012 12:43, Andre Oppermann wrote:
On 27.11.2012 19:27, Alan Cox wrote:
On 11/27/2012 12:08, Andre Oppermann wrote:
On 27.11.2012 17:42, Alan Cox wrote:
On 11/27/2012 09:06, Konstantin Belousov wrote:
On Tue, Nov 27, 2012 at 12:26:44PM +0100, Andre Oppermann wrote:
FreeBSD bbb.ccc
On Wed, May 23, 2012 at 1:05 PM, Maksim Yevmenkin
maksim.yevmen...@gmail.com wrote:
hello,
would anyone object to the following patch?
No objection. There shouldn't be any controversy here. Your patch is
correct. The existing code in UMA is doing the wrong comparison.
Alan
===
I'll follow up with detailed answers to your questions over the weekend.
For now, I will, however, point out that you've misinterpreted the
tunables. In fact, they say that your kmem map can hold up to 16GB and the
current used space is about 58MB. Like other things, the kmem map is
auto-sized
On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore i...@freebsd.org wrote:
I ran into a panic while attempting to un-tar a large file on a
DreamPlug (arm-based system) running -current. The source and dest of
the un-tar is the root filesystem on sdcard, and I get this:
panic: kmem_malloc(4096):
On 01/28/2013 08:22, Ian Lepore wrote:
On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote:
On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore i...@freebsd.org wrote:
I ran into a panic while attempting to un-tar a large file on a
DreamPlug (arm-based system) running -current. The source and dest
On 02/01/2013 07:25, Andre Oppermann wrote:
As an outcome of the recent problems with auto-sizing and auto-tuning of
the various kernel subsystems and related memory structures I've taken a
closer look at the whole KVM inner working and initialization process.
I've found the VM and KVM
On 03/08/2013 06:58, Andre Oppermann wrote:
On 08.03.2013 10:16, Konstantin Belousov wrote:
On Thu, Mar 07, 2013 at 06:03:51PM +0100, Andre Oppermann wrote:
pager_map: is used for pager IO to a storage media (disk). Not
pageable. Calculation: MAXPHYS * min(max(nbuf/4, 16), 256).
It is
On Wed, Mar 20, 2013 at 12:24 PM, Maksim Yevmenkin e...@freebsd.org wrote:
hello,
would anyone object to the following small patch?
Yes, I don't think that we should entirely disable vm_lowmem events or
uma_reclaim() on pass == 0 calls to vm_pageout_scan(). However, I do
think it's
On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek chris.to...@gmail.com wrote:
In src/sys/amd64/include/vmparam.h is this handy map:
* 0x - 0x7fff user map
* 0x8000 - 0x7fff does not exist (hole)
* 0x8000 - 0x804020100fff
On Tue, Jul 16, 2013 at 7:08 AM, Kurt Lidl l...@pix.net wrote:
On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek chris.torek at gmail.com
wrote:
In src/sys/amd64/include/vmparam.**h is this handy map:
* 0x - 0x7fff user map
* 0x8000 -
On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote:
Hi Edward, Alan,
I plan to commit the following patch:
http://people.freebsd.org/~jlh/racct_munlock.diff
This solves the following panic:
panic: racct_sub: freeing 301989888 of resource 5, which is more than
allocated 73728 for
On Jul 21, 2013, at 2:50 PM, Jeremie Le Hen wrote:
On Sat, Jul 20, 2013 at 08:33:35PM -0700, Alan Cox wrote:
On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote:
Hi Edward, Alan,
I plan to commit the following patch:
http://people.freebsd.org/~jlh/racct_munlock.diff
This solves
On 01/19/2014 18:06, Manfred Antar wrote:
vm_reserv.c starting with revision 25 causes panic on sparc64 (netra T1
200)
version 259998 works
backtrace:
Starting apache22.
panic: Bad link elm 0xf8007d4728f8 prev-next != elm
cpuid = 0
KDB: enter: panic
[ thread pid 1965 tid 100058
On Wed, Aug 13, 2014 at 4:58 AM, David Chisnall thera...@freebsd.org
wrote:
On 12 Aug 2014, at 19:09, John Baldwin j...@freebsd.org wrote:
OTOH, I have actually seen junk profiling _improve_ performance in
certain
cases as it forces promotion of allocated pages to superpages since all
On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin j...@freebsd.org wrote:
On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
Hi!
On 16 July 2014 06:29, Konstantin Belousov kostik...@gmail.com wrote:
On Fri, Jun 27, 2014 at 03:56:13PM +0300, Konstantin Belousov wrote:
Hi,
I
On 08/14/2014 10:47, John Baldwin wrote:
On Wednesday, August 13, 2014 1:00:22 pm Alan Cox wrote:
On Tue, Aug 12, 2014 at 1:09 PM, John Baldwin j...@freebsd.org wrote:
On Wednesday, July 16, 2014 1:52:45 pm Adrian Chadd wrote:
Hi!
On 16 July 2014 06:29, Konstantin Belousov kostik
Andriy Gapon wrote:
So, here is the next version of the patch:
http://people.freebsd.org/~avg/amd64-minidump.4.diff
Changes since the last version:
1. libkvm - try to support both the new and the previous formats/versions of
amd64 minidump. I am not entirely sure about style in which I handled
Julian Elischer wrote:
On 11/9/10 9:04 AM, Bakul Shah wrote:
On Tue, 09 Nov 2010 08:45:14 PST Julian
Elischerjul...@freebsd.org wrote:
During the discussion at MeetBSD the question came up as to what the
real
limiting factors were with regard to how much RAM a system could have.
it was put
Andriy Gapon wrote:
on 09/11/2010 10:02 Alan Cox said the following:
The kernel portion of the patch looks correct. If I were to make one stylistic
suggestion, it would be to make the control flow of the outer and inner loops as
similar as possible, that is,
for (...
if ((pdp[i
Sean Bruno wrote:
http://people.freebsd.org/~sbruno/256G_SMAP.png
http://people.freebsd.org/~sbruno/256G_panic1.png
http://people.freebsd.org/~sbruno/256G_panic2.png
Trying to get the HP DL980 online today and I see the following panic on
startup from the installer CD that I created from
On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin j...@freebsd.org wrote:
On Sunday, November 21, 2010 8:05:26 pm Sean Bruno wrote:
Looks like these HP boxes have the capability to do 44 bit memory
addressing if configured to do so from the BIOS.
Is anyone interested in any data from that
On 11/22/2010 1:47 PM, John Baldwin wrote:
On Monday, November 22, 2010 1:37:45 pm Alan Cox wrote:
On Mon, Nov 22, 2010 at 6:59 AM, John Baldwinj...@freebsd.org wrote:
On Sunday, November 21, 2010 8:05:26 pm Sean Bruno wrote:
Looks like these HP boxes have the capability to do 44 bit memory
John Baldwin wrote:
On Monday, November 22, 2010 8:01:34 pm Alan Cox wrote:
On 11/22/2010 1:47 PM, John Baldwin wrote:
On Monday, November 22, 2010 1:37:45 pm Alan Cox wrote:
On Mon, Nov 22, 2010 at 6:59 AM, John Baldwinj...@freebsd.org wrote:
On Sunday, November 21
On Tue, Dec 28, 2010 at 1:33 PM, Bartosz Stec bartosz.s...@it4pro.plwrote:
Hi there.
Everything was fine with kernel dated 14.12, but now it's impossible to run
smartd without panic. Smartmontools rebuilded with this release still
produces panic. Everything else seems working fine.
core.txt
On Mon, May 9, 2011 at 8:45 AM, John Baldwin j...@freebsd.org wrote:
On Saturday, May 07, 2011 3:16:25 pm Kostik Belousov wrote:
On Fri, May 06, 2011 at 04:16:40PM -0400, John Baldwin wrote:
On Friday, May 06, 2011 10:04:28 am Kostik Belousov wrote:
On Fri, May 06, 2011 at 04:38:00PM
On 6/20/2011 12:10 PM, m...@freebsd.org wrote:
On Mon, Jun 20, 2011 at 11:40 AM, Garrett Cooperyaneg...@gmail.com wrote:
On Mon, Jun 20, 2011 at 11:37 AM, FreeBSD Tinderbox
tinder...@freebsd.org wrote:
TB --- 2011-06-20 17:09:28 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB ---
On 6/20/2011 11:40 AM, Garrett Cooper wrote:
On Mon, Jun 20, 2011 at 11:37 AM, FreeBSD Tinderbox
tinder...@freebsd.org wrote:
TB --- 2011-06-20 17:09:28 - tinderbox 2.7 running on freebsd-current.sentex.ca
TB --- 2011-06-20 17:09:28 - starting HEAD tinderbox run for ia64/ia64
TB --- 2011-06-20
...
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
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
Look at vm_map_find.
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
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
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
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
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 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
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 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 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
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
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 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
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
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
1 - 100 of 144 matches
Mail list logo
