Try the attached patch. If this doesn't work, I'll back out
the last i386/isa/ipl_funcs.c change.
Alan
Index: i386/i386/swtch.s
===
RCS file: /home/ncvs/src/sys/i386/i386/swtch.s,v
retrieving revision 1.82
diff -c -r1.82 swtch.s
*
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 1999/07
On Sun, Jul 11, 1999 at 08:12:52AM +0100, Doug Rabson wrote:
>
> What a nightmare. This must be due to egcs compiling things differently
> from gcc 2.7.1. ...
Yes, at least for the one case in vm_pageout_flush. (I checked
the analogous code on a 3.x-STABLE system and it appears to be fine
for t
Actually, I should have said swap_pager_getpages and not
vm_pageout_flush.
Alan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 i
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
On Tue, Jul 13, 1999 at 11:29:03AM +0300, Ville-Pertti Keinonen wrote:
>
> Alan Cox <[EMAIL PROTECTED]> writes:
>
> > P.S. As an aside, just once, everyone should look at the /proc/"pid"/map
> > of a running cvsup. Each line you see is a vm_map_entry. (W
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: send
> ...
>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 st
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 yo
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 th
On Thu, Sep 30, 1999 at 01:40:22PM -0700, John Polstra wrote:
>
> Yep, I have fixed that in the PM3 release (which is the one that's
> actively maintained these days), but probably not in the SRC release
> on which our port is based. I have ports for PM3 in the wings,
> but I'm waiting for some
On Sun, Oct 03, 1999 at 09:42:45AM +1000, Bruce Evans wrote:
>
> I think the POSIX way is to use an auxiliary error code in siginfo_t to
> distinguish the causes of the signal. This only works for SA_SIGINFO
> handlers. We do something similar using the signal code of 3-arg signal
> handlers.
>
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 Fri, Oct 29, 1999 at 09:51:55PM +0200, Jesper Skriver wrote:
>
> Those "about six months" can you be more specific ?
>
Sorry for being imprecise. It was May 16th.
> $ uname -a
> FreeBSD pebbles.tele.dk 4.0-CURRENT FreeBSD 4.0-CURRENT #2: Thu Apr 22 11:52:50 CEST
>1999
> [EMAIL PROTECTED]:
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 millio
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, dillo
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
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 te
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 to
I'll remove (or change) the assertion later this evening
unless I hear protests to the contrary.
Alan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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 [59554/16/63] at ata0-master using UDMA66
I used the motherboard controller to support two of the drives. It was a
atapci0: port 0xffa0-0xffaf at device 31.1 o
Try a Promise ATA/66 controller. I have no problems
with either
ad0: 29311MB [59554/16/63] at ata0-master using UDMA66
or
ad3: 29188MB [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 controller. As of three or f
> 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
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. T
2010/3/20 Alexander Motin
> 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 with MAXPHY
On Sat, May 1, 2010 at 5:21 PM, Bruce Cran 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 "Sleeping t
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 maj
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 mail
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 g
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 p
On Tue, Aug 10, 2010 at 9:43 AM, Oliver Fromme wrote:
> Hi,
>
> This is i386 -current as of 2010-08-04.
> It was building the toolchain for amd64 when it happened.
> I'll keep the vmcore around, so I can dig more into it
> if someone tells me what to do.
>
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 200
2010/8/17 Dimitry Andric
> On 2010-08-16 10:55, Dag-Erling Smørgrav wrote:
> > Dimitry Andric writes:
> >> - Uses plain file descriptors instead of struct FILE, since the
> >> buffering is done manually anyway, and it makes it easier to support
> >> gzip and bzip2.
> > It might be worth a sh
On Tue, Aug 17, 2010 at 10:45 AM, Kostik Belousov wrote:
> [Cc: list sanitized]
>
> On Tue, Aug 17, 2010 at 05:28:08PM +0200, Dimitry Andric wrote:
> > On 2010-08-16 10:55, Dag-Erling Sm??rgrav wrote:
> > > Dimitry Andric writes:
> > >> - Uses plain file descriptors instead of struct FILE, since
On Tue, Aug 17, 2010 at 3:29 PM, Dimitry Andric wrote:
> On 2010-08-17 18:29, Alan Cox wrote:
> > Try it again on a memory resident file with the MAP_PREFAULT_READ option
> > that is provided by this patch:
> >
> > http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch<
Dimitry Andric wrote:
On 2010-08-17 23:24, Alan Cox wrote:
So normal mmap is ~3% slower, and prefault mmap does not seem to make
any measurable difference. I guess the added complexity is not really
worth it, for now.
Do you know what fraction of this time is being spent in the
Dag-Erling Smørgrav wrote:
Alan Cox writes:
Here is what actually puzzles me about these results. With
traditional I/O, even after the optimizations to bsdgrep, the system
time for gnugrep is still less than half that of the optimized
bsdgrep. I haven't looked at the changes, but I
m...@freebsd.org wrote:
[snip]
I will test this patch out; thanks for the help!
Two questions:
1) How does a thread get moved between CPUs when it's not running? I
see that we change the runqueue for non-running threads that are on a
runqueue. Does the code always check for THREAD_CAN_SCHED w
On 9/29/2010 3:41 PM, Andriy Gapon wrote:
on 27/09/2010 20:54 Andriy Gapon said the following:
It seems that minidump on amd64 is always dumping at least about 1GB of data
regardless of actual memory size and usage and thus can be even larger than
regular dump.
Specifically, I suspect the foll
On Thu, Sep 30, 2010 at 12:37 PM, Andre Oppermann wrote:
> On 30.09.2010 18:37, Andre Oppermann wrote:
>
>> Just for the kick of it I decided to take a closer look at the use of
>> splay trees (inherited from Mach if I read the history correctly) in
>> the FreeBSD VM system suspecting an interest
Andriy Gapon wrote:
on 01/10/2010 10:43 Andriy Gapon said the following:
The idea. We dump contiguously only pages with PDEs (which means both valid and
invalid PDEs), valid pages with PTEs are dumped the same way as data physical
pages (i.e. via dump_add_page, etc); no fake PTEs for 2MB pag
Please boot your i386 kernel and send me the output from "memcontrol list".
Alan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freeb
Andriy Gapon wrote:
on 03/11/2010 20:44 Alan Cox said the following:
[snip]
Thank you for the confirmation!
Andriy Gapon wrote:
P.S. is there a macro for extracting frame address from PDPE?
To a lower level page table page or to a 1GB physical page? For the latter, you
can
Paul B Mahol wrote:
On 11/6/10, Jia-Shiun Li wrote:
Hi,
I got a similar panic on amd64. Looking into the source it hit
KASSERT((base & (len - 1))) in pmap_demote_DMAP(). I replaced it with
a printf to see what triggered the assertion and here is the output.
Combined with memcontrol output '
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
Elischer 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 to us that the limi
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 -CURRE
On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin 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 setting?
>
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 Baldwin 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
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 Baldwin wrote:
On Sunday, November 21, 2010 8:05:26
On Tue, Dec 28, 2010 at 1:33 PM, Bartosz Stec wrote:
> 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 is here:
> http://
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
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 /usr/src/sys/i386/i
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
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 @
> /a/asami/portbuild/i386/src-client
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.
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 i
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
>
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 see
On Wed, May 5, 2010 at 11:19 AM, Yuri Pankov 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
> /home/yuri/src/FreeBSD/head/sys/vm/vm_page.c:1547
>
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 se
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 o
On 5/14/2010 1:44 AM, Benjamin Kaduk wrote:
On Fri, 14 May 2010, Kostik Belousov wrote:
On Fri, May 14, 2010 at 12:55:35AM -0400, Benjamin Kaduk wrote:
Hi all,
As was revealed in a recent thread here [1], several people have been
unable to use kgdb on coredumps for the past few months (but
p
Benjamin Kaduk wrote:
On Fri, 14 May 2010, Benjamin Kaduk wrote:
On Fri, 14 May 2010, Alan Cox wrote:
I suspect the following is needed:
Index: vm/vm_page.c
===
--- vm/vm_page.c(revision 207823)
+++ vm/vm_page.c
Garrett Cooper wrote:
Just reporting the fact that nvidia-driver 195.22 is horribly
broken between r206173 and r208486 (my machine consistency livelocks
at X11 startup); the latest driver is still broken as well with the
same symptoms. I realize that's a huge revision difference, and I'll
def
Kostik Belousov wrote:
On Wed, May 26, 2010 at 11:23:02AM -0500, Alan Cox wrote:
Garrett Cooper wrote:
Just reporting the fact that nvidia-driver 195.22 is horribly
broken between r206173 and r208486 (my machine consistency livelocks
at X11 startup); the latest driver is still
On 5/26/2010 2:56 PM, Ryan Stone wrote:
I'm by no means an expert in this area, but isn't removing the locking
on free a bad thing?
Looking at the code, it seems that vm_page_unwire() only requires the
page to be locked if it is managed. As it was acquired by
contigmalloc, the page should
On Thu, Jun 10, 2010 at 7:16 AM, John Baldwin wrote:
> On Wednesday 09 June 2010 5:27:47 pm Nathaniel W Filardo wrote:
> > Attempting to boot on (2-way SMP; SUN Fire V240) sparc64 a 9.0-CURRENT
> > kernel built on Jun 9 at 14:41, and fully csup'd before building (I don't
> > have the SVN revision
On Sun, Jun 13, 2010 at 8:38 PM, Doug Barton wrote:
> On 06/01/10 08:26, John Baldwin wrote:
>
>>
>> I've asked the driver author if the calls to vm_page_wire() and
>> vm_page_unwire() can simply be removed but have not heard back yet.
>>
>
> Is there any news on this? I have updated to the lates
On Wed, Jun 30, 2010 at 11:33 AM, Jeseem S wrote:
> hi,
> I am a newbie on freebsd kernel. Am currently trying to debug a scenario,
> where a custom driver I load uses a lot of static memory and hence lots of
> wired pages.
> The system still has a lot of free memory ( more than 200MB) and a fr
On 08/22/2018 10:29, Alan Cox wrote:
> On 08/22/2018 08:48, tech-lists wrote:
>> On 22/08/2018 05:29, Manfred Antar wrote:
>>>> On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev
>>>> wrote:
>>>>
>>>> On Tue, Aug 21, 2018 at 11:22:56PM +07
On Sun, Oct 19, 2014 at 10:30 AM, James R. Van Artsdalen <
james-freebsd-...@jrv.org> wrote:
> Removing kern.maxfiles from loader.conf still hangs in "kmem arena".
>
> I tried using a memstick image of -CURRENT made from the release/
> process and this also hangs in "kmem arena"
>
> An uninvolved
On Tue, Oct 21, 2014 at 5:03 PM, Alan Cox wrote:
> On Sun, Oct 19, 2014 at 10:30 AM, James R. Van Artsdalen <
> james-freebsd-...@jrv.org> wrote:
>
>> Removing kern.maxfiles from loader.conf still hangs in "kmem arena".
>>
>> I tried using a memst
Below is partial results from a profile of a parallel (-j7) "buildworld" on
a 6-core machine that I did after the introduction of pmap_advise, so this
is not a new profile. The results are sorted by total waiting time and
only the top 20 entries are listed.
max wait_max total wait_to
On 03/18/2015 12:58, Mateusz Guzik wrote:
> On Wed, Mar 18, 2015 at 10:17:22AM -0400, John Baldwin wrote:
>> On Friday, March 13, 2015 06:32:03 AM Mateusz Guzik wrote:
>>> On Thu, Mar 12, 2015 at 06:13:00PM -0500, Alan Cox wrote:
>>>> Below is partial results fro
On 04/05/2015 10:47, Gleb Smirnoff wrote:
> On Sun, Apr 05, 2015 at 06:37:58AM -0700, David Wolfskill wrote:
> D> It ocurred rather late in the transition to multi-user mode, but
> D> prior to starting xdm (on my laptop).
> D>
> D> Previous (working) head/i386 for this machine was r281074.
> D>
>
On 04/05/2015 14:34, Gleb Smirnoff wrote:
> On Sun, Apr 05, 2015 at 12:45:00PM -0500, Alan Cox wrote:
> A> On 04/05/2015 10:47, Gleb Smirnoff wrote:
> A> > On Sun, Apr 05, 2015 at 06:37:58AM -0700, David Wolfskill wrote:
> A> > D> It ocurred rather late in the tran
On 04/05/2015 15:17, Gleb Smirnoff wrote:
> On Sun, Apr 05, 2015 at 03:07:56PM -0500, Alan Cox wrote:
> A> On 04/05/2015 14:34, Gleb Smirnoff wrote:
> A> > On Sun, Apr 05, 2015 at 12:45:00PM -0500, Alan Cox wrote:
> A> > A> On 04/05/2015 10:47, Gleb Smirnoff wrote:
&g
On 04/05/2015 19:49, Rui Paulo wrote:
> On Apr 5, 2015, at 13:07, Alan Cox wrote:
>> On 04/05/2015 14:34, Gleb Smirnoff wrote:
>>> On Sun, Apr 05, 2015 at 12:45:00PM -0500, Alan Cox wrote:
>>> A> On 04/05/2015 10:47, Gleb Smirnoff wrote:
>>> A> > On
On 04/10/2015 04:11, Svatopluk Kraus wrote:
> Hi,
>
> my RPI-B has been stuck in vm_reserv_reclaim_contig() due to a bug
> within that function. I can reproduce that easily on my two-core
> pandaboard when I limit all memory in system to 128MiB and run "make
> -j16 kernel-toolchain". It happens in
This is fixed in r282706.
On Sun, May 10, 2015 at 10:19 AM, David Wolfskill
wrote:
> As noted yesterday, my laptop panicked trying to boot head/i386
> @r282676, but seemed OK withe head/amd64.
>
> That turns out to have been a bit optimistic: today, while performing a
> src update on the laptop
On Thu, Jul 30, 2015 at 6:34 AM, Zbigniew Bodek wrote:
> Hello,
>
> I'm writing to ensure what to do with that patch:
> https://reviews.freebsd.org/D1945
>
> It was created as a result of discussion related to this review:
> https://reviews.freebsd.org/D1833
> The patch (D1945) is still waiting t
On 12/19/2015 19:00, Michael Butler wrote:
> While the kernel modules will build, they won't load ..
>
> kernel: linker_load_file: Unsupported file type
> kernel: link_elf_obj: symbol vm_pageout_grow_cache undefined
> kernel: linker_load_file: Unsupported file type
> kernel: KLD vboxnetflt.ko: depe
that I said, "vm_page_reclaim_contig", not
"vm_pageout_reclaim_contig". The function in FreeBSD is different from
that in NextBSD.
>> On Dec 19, 2015, at 7:45 PM, Alan Cox wrote:
>>
>> On 12/19/2015 19:00, Michael Butler wrote:
>>> While the kernel modules will
On Sat, Jan 9, 2016 at 12:44 AM, Adrian Chadd
wrote:
> It shouldn't have changed though; you're just requesting memory to use
> for x86bios calls.
>
> +jhb - any ideas?
>
>
Yes, there is insufficient free (or reclaimable) physical memory below 1MB,
so contigmalloc() fails.
This is almost certai
On 01/09/2016 13:48, Adrian Chadd wrote:
> On 9 January 2016 at 11:30, John Baldwin wrote:
>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
>>> In message >> om>
>>> , Jeremie Le Hen writes:
On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd
wrote
:
> can you copy/p
On 01/09/2016 14:05, Alan Cox wrote:
> On 01/09/2016 13:48, Adrian Chadd wrote:
>> On 9 January 2016 at 11:30, John Baldwin wrote:
>>> On Thursday, January 07, 2016 01:47:32 AM Cy Schubert wrote:
>>>> In message
>>>> >>> om>
>>>&g
On Sun, Feb 14, 2016 at 8:09 AM, Andriy Gapon wrote:
> On 10/02/2016 23:28, Andriy Gapon wrote:
> >
> > Over a span of approximately 3 weeks I have got two slightly different
> panics of
> > the same kind. The affected system is a several months old amd64 head.
>
> I added a small assertion and
On Sat, Jul 1, 2017 at 2:46 PM, Guy Yur wrote:
> Hi,
>
> I tried to run armv6 /bin/sh in a chroot on an
> amd64 host using qemu-arm-static.
> It failed on invalid argument to mmap.
>
> # cp /usr/local/bin/qemu-arm-static /chroots/armv6/root/
> # chroot /chroots/armv6 /root/qemu-arm-static /bin/sh
1 - 100 of 153 matches
Mail list logo
