On 29-4-2010 6:17, Artem Belevich wrote:
Do you have vm.kmem_size set in /boot/loader.conf?
If not, do set it to about double of your physical RAM size. Defaults
are way too conservative for use with large amounts of memory and ZFS.
As per this suggestion I set this value to 2*8G:
vm.kmem_size
Hello,
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.
1) panic on gnome start via softdep_cancel_link().
2) Difficulty setting flags on /. This can only be done from a direct
boot into single user but there were
Thu, 29 Apr 2010 16:20:32 -0500 письмо от "James R. Van Artsdalen"
:
> Андрей Смагин wrote:
> > > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total
> > allocated
> > >
> > I open PR amd64/145654 with problem like it. Have you increasing Wired
> > memory at buildworld ?
> >
I won't be able to give all of the information because the machine in question
does not have a graphical environment.
Here is what I can give.
PowerMac G3
Motorola 750 400mHz revision 2.2
Open Firmware 3.0
FreeBSD 9.0 SNAPSHOT
lock order reversal:
1st 0xd47cc118 bufwait (bufwait) @ /usr/src/sy
On Thursday 29 April 2010 23:49:38 Michael Moll wrote:
> OK, that explains that with all the related commits backup out
> (207265-206664) the resulting config-binary still fails. I don't have
> time today to build the kernel with the different revisions to hunt the
> problem down to one commit...
In message: <2010043016.ga90...@darkthrone.kvedulv.de>
Michael Moll writes:
: On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote:
: > Do you have a small, reproducible sequence of events that will
: > recreate this problem? I've seen no problems at all in my testing.
:
On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote:
> Do you have a small, reproducible sequence of events that will
> recreate this problem? I've seen no problems at all in my testing.
> I assume this is in -current?
Yes, -CURRENT. Compile a kernel on sparc64 (didn't try this yet on
According to Tom Evans:
> Citation needed? I have a file server running amd64 8-STABLE with 4GB
> of RAM, 6 x 1.5 TB drives in raidz, and have never had any problems
> with memory usage. Are you saying that after my next update, adding
> another 6 x 1.5 TB drives, it will start being flaky and/or p
In message: <20100429224938.gi90...@darkthrone.kvedulv.de>
Michael Moll writes:
: Hi,
:
: On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote:
: > /boot/kernel/kernel". It looks like it thinks there's more data available
: > than there is.
: >
: > config/main.c gets the size
Hi,
On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote:
> /boot/kernel/kernel". It looks like it thinks there's more data available
> than there is.
>
> config/main.c gets the size of the configuration by running elfdump:
>
> > elfdump -c /boot/kernel/kernel | grep -A 5 kern_conf | tai
On Thursday 29 April 2010 22:46:29 Garrett Cooper wrote:
> Does a version prior to last week work, and could you please
> attach your kernel configuration file(s) for analysis?
I remember coming across the same error during buildkernel last week, but
can't remember how, or how I resolved it.
Scott Long wrote:
>
> I'm sorry, but I find it absolutely absurd that any filesystem has to wire
> down 2GB of RAM, and that the solution to panics is buy more
The only thing buying more RAM is likely to do is make the memory leak
behind this harder to reproduce. Likewise increasing kernel tunab
On Thu, Apr 29, 2010 at 2:41 PM, Bruce Cran wrote:
> On Thursday 29 April 2010 22:19:45 Andriy Gapon wrote:
>> on 30/04/2010 00:12 Michael Moll said the following:
>> > Hi,
>> >
>> > On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote:
>> >> on 29/04/2010 18:31 Michael Moll said the follo
On Thursday 29 April 2010 22:19:45 Andriy Gapon wrote:
> on 30/04/2010 00:12 Michael Moll said the following:
> > Hi,
> >
> > On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote:
> >> on 29/04/2010 18:31 Michael Moll said the following:
> >> You can use hd to see if you indeed have '\0' (
Hi,
On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote:
> on 29/04/2010 18:31 Michael Moll said the following:
> You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within
> your kernel config file.
Thanks, I checked this and there are no 0x00s in the config file itsel
Андрей Смагин wrote:
> > panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated
> >
> I open PR amd64/145654 with problem like it. Have you increasing Wired memory
> at buildworld ?
>
No. This
# while true
> do
> sysctl -A | grep wired
> make -j8 buildworld
> done
is g
on 30/04/2010 00:12 Michael Moll said the following:
> Hi,
>
> On Thu, Apr 29, 2010 at 11:33:30PM +0300, Andriy Gapon wrote:
>> on 29/04/2010 18:31 Michael Moll said the following:
>> You can use hd to see if you indeed have '\0' (0x00) symbol somewhere within
>> your kernel config file.
>
> Than
on 29/04/2010 18:31 Michael Moll said the following:
[snip]
> Assertion failed: (r != '\0' && ("Char present in the configuration " "string
> mustn't be equal to 0")), function kernconfdump, file
> /usr/src/usr.sbin/config/main.c, line 721.
[snip]
> Any ideas on this?
Yes, one idea - to verify wha
If I understand it correctly, the problem in this case is that even
when you do have more than enough RAM, kernel just does not provide
enough space in kmem_map to map that physical memory into.
Unless you want to have dedupe turned on large filesystem (and FreeBSD
does not have this feature yet)
Hi Mickael,
Thank you for the detailed response!
By "wait 8.1 to have all recent zfs enhancement for prod" are you
referring to the ZFS enhancements they've made over the past year in
that regard, or enhancements the FreeBSD committers are making to make
ZFS on FreeBSD work better?
I've got to s
On Apr 29, 2010, at 9:44 AM, Tom Evans wrote:
> On Thu, Apr 29, 2010 at 3:53 PM, Ollivier Robert
> wrote:
>> According to James R. Van Artsdalen:
>>> system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12
>>> GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB.
>>
i have two freebsd running MySQL 5.1 on ZFS:
- first: a 7-STABLE build (7.2, 2 month after zfs v13 import)
the machine crash recently after a 130 day uptime beceause i dont
limit arc size (so 4Gb by default) and i think they run oom.
even with vfs.zfs.cache_flush_disable=1, no data loose, innodb re
Hi Olivier,
We've actually been running MySQL on ZFS on Solaris for quite some
time. :) We're very comfortable with that setup.
My question is more specific to live experience with doing the same
thing on FreeBSD. We know where the sabots are on MySQL/ZFS/Solaris.
Would like to find out where the
On Thu, Apr 29, 2010 at 3:53 PM, Ollivier Robert
wrote:
> According to James R. Van Artsdalen:
>> system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12
>> GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB.
>
>> panic: kmem_malloc(131072): kmem_map too small: 38
Hi All,
after upgrading a FreeBSD/sparc64 machine from CURRENT sources of 3rd
March to ones of 28th April config(8) doesn't work correctly anymore:
server01# config -x /boot/kernel/kernel
options CONFIG_AUTOGENERATED
ident GENERIC
machine sparc64
cpu SUN4U
[...]
device fwe
device fwip
dev
* John Baldwin [100429 05:46] wrote:
> On Wednesday 28 April 2010 1:18:40 pm Alfred Perlstein wrote:
> > I was recently working on the enhanced coredumps
> > internal to Juniper and realized that there were
> > some defects in the code I pushed (mostly due to
> > mismerge), can someone please revi
According to James R. Van Artsdalen:
> system is a Core i7 975 (3.33 GHz x 4 cores 3x threads per core) with 12
> GB of RAM, a 2x2TB ZFS boot pool and a second (idle) pool of 16x2TB.
> panic: kmem_malloc(131072): kmem_map too small: 3832475648 total allocated
Apart from the fact that you must at
2010/4/29 Jason J. W. Williams :
> Hi Y'all,
>
> I've written before that we're considering moving to FreeBSD 8 from
> OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs
> ZFS implementation for a high reliability environment like a database?
> If so, what are your experiences?
>
Hi Y'all,
I've written before that we're considering moving to FreeBSD 8 from
OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs
ZFS implementation for a high reliability environment like a database?
If so, what are your experiences?
Basically, I'm curious how stable the impleme
On Wednesday 28 April 2010 7:59:58 pm Matthew Fleming wrote:
> It looks to me like taskqueue_drain(taskqueue_thread, foo) will not
> correctly detect whether or not a task is currently running. The check
> is against a field in the taskqueue struct, but for the taskqueue_thread
> queue with more t
On Wednesday 28 April 2010 1:18:40 pm Alfred Perlstein wrote:
> I was recently working on the enhanced coredumps
> internal to Juniper and realized that there were
> some defects in the code I pushed (mostly due to
> mismerge), can someone please review?
>
> 1) don't allocate hostname[] on the sta
On Thu, 29 Apr 2010 14:05:25 +0300, Dima Panov wrote:
Ruby is bad?
More like clang is bad, it's a known issue.
clangbsd errors in my blog:
http://dimapanov.wordpress.com/2010/04/29/clangbsd/
at this moment unbuildable some critical ports:
devel/binutils
devel/icu[4]
devel/pcre
lang/ruby1[
On Thursday 29 April 2010 02:40:24 Dima Panov wrote:
> On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote:
> > According to Dima Panov:
> > > while building lang/ruby18:
> > Which options to you use?
> >
> > _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1
> > WITHOUT_ONIGURUMA=true
> > WITH_RDOC
Hi Dmitry.
2010/4/29 Dmitry Krivenok :
> Hello Hackers!
>
> I have a problem with FreeBSD-CURRENT system:
> FreeBSD host 9.0-CURRENT FreeBSD 9.0-CURRENT #16 r207299: Wed Apr 28
> 04:15:07 UTC 2010 r...@host:/usr/obj/usr/src/sys/GENERIC amd64
>
> Perl aborts with the following error on exiting
Hello Hackers!
I have a problem with FreeBSD-CURRENT system:
FreeBSD host 9.0-CURRENT FreeBSD 9.0-CURRENT #16 r207299: Wed Apr 28
04:15:07 UTC 2010 r...@host:/usr/obj/usr/src/sys/GENERIC amd64
Perl aborts with the following error on exiting cpan shell:
cpan[2]> q
Lockfile removed.
perl: (ma
35 matches
Mail list logo
