Re: Updating from 9.1-release to svn head: what might be the problem?
I've been using 10.0 current for a few months now with no problem. What I do know about virtual machines is that they don't share kernel resources too well. If both virtual machines are trying to access the kernel, there will be a problem. On Wed, Jun 19, 2013 at 10:51 PM, Alexey Dokuchaev wrote: > On Tue, Jun 18, 2013 at 10:21:33PM +0700, Alexey Dokuchaev wrote: > > I've been trying to install fresh -CURRENT (in VirtualBox/i386), and > since > > recent snapshots did not work for me, had to do this by first installing > > from 9.1-release .iso. After "svn co .../head /usr/src" and standard > make > > world/kernel/mergemaster procedure (w/out any custom settings in > make.conf > > or src.conf), I apparently keep getting screwed up system [...] > > It's getting strange: colleague at $work convinced me to try VMware Player, > and I reluctantly agreed... Well, with that thing I managed to install > Marchish -CURRENT snapshot, successfully rebuild the world, and now > building > my ports... So I'm puzzled: is it my hands, broken 9.1 -> 10.0 upgrade, or > some VirtualBox vs. VMplayer issue?.. > > ./danfe > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On 19.06.2013 20:22, Andrey Fesenko wrote: > On Wed, Jun 19, 2013 at 10:15 PM, Zbyszek Bodek wrote: >> Hello, >> >> I've been trying to compile the kernel on my ARMv7 platform using the >> sources from the current FreeBSD HEAD. >> >> make buildkernel <.> -j5 >> >> 1/2 builds fails in the way described below: >> -- >> ing-include-dirs -fdiagnostics-show-option -nostdinc -I. >> -I/root/src/freebsd-arm-superpages/sys >> -I/root/src/freebsd-arm-superpages/sys/contrib/altq >> -I/root/src/freebsd-arm-superpages/sys/contrib/libfdt -D_KERNEL >> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror >> /root/src/freebsd-arm-superpages/sys/ufs/ffs/ffs_snapshot.c >> Cannot fork: Cannot allocate memory >> *** [ffs_snapshot.o] Error code 2 >> 1 error >> *** [buildkernel] Error code 2 >> 1 error >> *** [buildkernel] Error code 2 >> 1 error >> 5487.888u 481.569s 7:35.65 1310.0% 1443+167k 1741+5388io 221pf+0w >> -- >> > > -j5 tricky :) I think it is necessary to build one may be in two > streams, as well as make the swap > Hello Andrey, I'm not sure whether you see my point. Just for the record, I've checked make <...> -j1 and with a swap file. The results are the same. Nevertheless, I have 2GB of main memory on my ARM target and this is more than sufficient to build the kernel without a necessity of swap, etc. What more, I never use more than ~300-400MB of memory during build even when the error occurs. What I'm saying is that, starting from the earlier mentioned commit I'm suffering from the Cannot fork: Cannot allocate memory + vm_thread_new: kstack allocation failed errors, while using exactly the same setup, etc. Best regards Zbyszek Bodek ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic with RACCT on a jailed process
Wiadomość napisana przez Jeremie Le Hen w dniu 19 cze 2013, o godz. 00:08: > Hi, > > I've been bit by a panic three times over the last month. > > I'm currently running: >FreeBSD obiwan.piupiu.local 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r251519: > Sun Jun 9 22:37:09 CEST 2013 > root@obiwan.piupiu.local:/usr/obj/usr/src/sys/OBIWAN amd64 > > The panic message is: >panic: destroying non-empty racct: 1007616 allocated for resource 4 > > I quicky tried to track this down, but in half an hour I didn't get very > far. Resource 4 is RACCT_RSS. The faulty process seems to be 66555 > which looks like a 32-bits cron(8) running in a jail. I've seen a similar report in the past, but I was unable to figure out what could be causing this. Do you have a way to figure out exactly what cron job causes this? Also, could you try a workaround of adding any kind of rctl rule for that user (this will cause the uidinfo to be "held" by the rctl rule, so uifree() won't try to destroy its racct), e.g. "user:XXX:maxproc:log=10", and see if it panics in some other place? Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: https://svn0.us-east.freebsd.org/base/head is not on 1.8 yet?
On 06/20/13 10:32, Anton Shterenlikht wrote: svn --version svn, version 1.8.0 (r1490375) compiled Jun 20 2013, 09:21:02 on amd64-portbld-freebsd10.0 # svn up Updating '.': svn: E17: Unrecognized URL scheme for 'https://svn0.us-east.freebsd.org/base/head' Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" You need SERF option, since NEON is gone. Read /usr/ports/UPDATING - Nikolai Lifanov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
https://svn0.us-east.freebsd.org/base/head is not on 1.8 yet?
svn --version svn, version 1.8.0 (r1490375) compiled Jun 20 2013, 09:21:02 on amd64-portbld-freebsd10.0 # svn up Updating '.': svn: E17: Unrecognized URL scheme for 'https://svn0.us-east.freebsd.org/base/head' Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: https://svn0.us-east.freebsd.org/base/head is not on 1.8 yet?
On 06/20/13 10:32, Anton Shterenlikht wrote: > svn --version > svn, version 1.8.0 (r1490375) > compiled Jun 20 2013, 09:21:02 on amd64-portbld-freebsd10.0 > > # svn up > Updating '.': > svn: E17: Unrecognized URL scheme for 'https://svn0.us-east.freebsd.org/base/head' > > Anton > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > You need SERF option, since NEON is gone. Read /usr/ports/UPDATING Thanks Anton P.S. There is nothing in 20130619: about SERF. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On Wed, 19 Jun 2013, Zbyszek Bodek wrote:
Hello,
I've been trying to compile the kernel on my ARMv7 platform using the
sources from the current FreeBSD HEAD.
make buildkernel <.> -j5
1/2 builds fails in the way described below:
--
ing-include-dirs -fdiagnostics-show-option -nostdinc -I.
-I/root/src/freebsd-arm-superpages/sys
-I/root/src/freebsd-arm-superpages/sys/contrib/altq
-I/root/src/freebsd-arm-superpages/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror
/root/src/freebsd-arm-superpages/sys/ufs/ffs/ffs_snapshot.c
Cannot fork: Cannot allocate memory
*** [ffs_snapshot.o] Error code 2
1 error
*** [buildkernel] Error code 2
1 error
*** [buildkernel] Error code 2
1 error
5487.888u 481.569s 7:35.65 1310.0% 1443+167k 1741+5388io 221pf+0w
--
The warning from std err is:
--
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
--
I was trying to find out which commit is causing this (because I was
previously working on some older revision) and using bisect I got to:
--
Author: jeff
Date: Tue Jun 18 04:50:20 2013 +
Refine UMA bucket allocation to reduce space consumption and improve
performance.
- Always free to the alloc bucket if there is space. This gives LIFO
allocation order to improve hot-cache performance. This also allows
for zones with a single bucket per-cpu rather than a pair if the
entire
working set fits in one bucket.
- Enable per-cpu caches of buckets. To prevent recursive bucket
allocation one bucket zone still has per-cpu caches disabled.
- Pick the initial bucket size based on a table driven maximum size
per-bucket rather than the number of items per-page. This gives
more sane initial sizes.
- Only grow the bucket size when we face contention on the zone
lock, this
causes bucket sizes to grow more slowly.
- Adjust the number of items per-bucket to account for the header
space.
This packs the buckets more efficiently per-page while making them
not quite powers of two.
- Eliminate the per-zone free bucket list. Always return buckets back
to the bucket zone. This ensures that as zones grow into larger
bucket sizes they eventually discard the smaller sizes. It persists
fewer buckets in the system. The locking is slightly trickier.
- Only switch buckets in zalloc, not zfree, this eliminates
pathological
cases where we ping-pong between two buckets.
- Ensure that the thread that fills a new bucket gets to allocate from
it to give a better upper bound on allocation time.
Sponsored by:EMC / Isilon Storage Division
--
I checked this several times and this commits seems to be causing this.
Can you tell me how many cores and how much memory you have? And paste
the output of vmstat -z when you see this error.
You can try changing bucket_select() at line 339 in uma_core.c to read:
static int
bucket_select(int size)
{
return (MAX(PAGE_SIZE / size, 1));
}
This will approximate the old bucket sizing behavior.
Thanks,
Jeff
Does anyone observe similar behavior or have a solution?
Best regards
Zbyszek Bodek
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't compile lxpanel
On Fri, 07 Jun 2013 01:07:26 +0200, Dimitry Andric wrote: > On Jun 6, 2013, at 18:21, Walter Hurry wrote: >> On Thu, 06 Jun 2013 09:19:20 -0600, asomers wrote: >>> Looks like a bug upstream. If this port worked in FreeBSD-9, then the >>> difference might be the switch from gcc to clang. You could try >>> compiling the port with gcc. Just add these lines to /etc/make.conf >>> >>> CC=gcc CXX=g++ >>> CPP=gcpp >>> >>> Note: that will change the compiler used for ALL ports, as well as >>> kernel and world. To selectively change the compiler for just a few >>> ports, you can follow the examples here: >>> http://www.freebsd.org/doc/en/articles/custom-gcc/article.html >>> >> Thank you. Yes, switching to gcc (for that port only) worked. >> >> So should that go down as a defect in lxpanel, or in clang? > > It is a defect in lxpanel. The code is simply broken, as the error > messages clearly show. > Fixed now. Thanks go to the (new) maintainer. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [drm2][panic] Running XOrg with SNA enabled causes system panic after few hours on G33
On Wed, Jun 19, 2013 at 5:27 PM, Artyom Mirgorodskiy wrote: > Hm, yesterday I turn off SNA optimization and got hang when shutdown :( Check the logs for messages that can help to investigate the problem. If there is nothing helpful, I have no idea but to configure a serial console and see if there is something that helps to understand the problem. > On Wednesday 19 June 2013 00:25:55 Konstantin Belousov wrote: >> On Wed, Jun 19, 2013 at 01:11:19AM +0400, Oleg Sidorkin wrote: >> > On Sun, Jun 16, 2013 at 6:27 PM, Konstantin Belousov >> > >> > wrote: >> > > On Sun, Jun 16, 2013 at 06:04:39PM +0400, Oleg Sidorkin wrote: >> > >> Thanks for the patch. >> > >> I've adapted the proposed patch for stable/9 and it is running with >> > >> SNA enabled now. >> > > >> > > In other words, your problem seems to be gone with the patch applied ? >> > >> > Now 48h are passed without panics. Fix definitely works. Thanks. >> >> Thank you. >> >> I tested it locally (without SNA) and committed the change a hour ago. >> It is required anyway, since the race sounds possible. I was mostly >> concerned with a thinko in the logic. > -- > Artyom Mirgorodskiy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Atom N450 + C3 + HPET == bad timer behaviour
Hi, I'm having issues with HPET + C3 state on this Atom N450 based netbook. This is (shocking, I know!) running -HEAD (r251605.) If I use C2, HPET is fine. If I use RTC, i8254, LAPIC, C3 is also fine. But C3 + HPET results in multi-second pauses where it should be 1 second. I've disabled powerd and verified that dev.cpu.0.freq=1667; so it's not CPU frequency related. Doug found this: apparently SMI + timer fondling doesn't quite work out? http://lkml.indiana.edu/hypermail/linux/kernel/1102.3/00842.html Thanks! adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On Thu, 20 Jun 2013, Jeff Roberson wrote:
On Wed, 19 Jun 2013, Zbyszek Bodek wrote:
Hello,
I've been trying to compile the kernel on my ARMv7 platform using the
sources from the current FreeBSD HEAD.
make buildkernel <.> -j5
1/2 builds fails in the way described below:
--
ing-include-dirs -fdiagnostics-show-option -nostdinc -I.
-I/root/src/freebsd-arm-superpages/sys
-I/root/src/freebsd-arm-superpages/sys/contrib/altq
-I/root/src/freebsd-arm-superpages/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -mno-thumb-interwork -ffreestanding -Werror
/root/src/freebsd-arm-superpages/sys/ufs/ffs/ffs_snapshot.c
Cannot fork: Cannot allocate memory
*** [ffs_snapshot.o] Error code 2
1 error
*** [buildkernel] Error code 2
1 error
*** [buildkernel] Error code 2
1 error
5487.888u 481.569s 7:35.65 1310.0% 1443+167k 1741+5388io 221pf+0w
--
The warning from std err is:
--
vm_thread_new: kstack allocation failed
vm_thread_new: kstack allocation failed
--
I was trying to find out which commit is causing this (because I was
previously working on some older revision) and using bisect I got to:
--
Author: jeff
Date: Tue Jun 18 04:50:20 2013 +
Refine UMA bucket allocation to reduce space consumption and improve
performance.
- Always free to the alloc bucket if there is space. This gives LIFO
allocation order to improve hot-cache performance. This also allows
for zones with a single bucket per-cpu rather than a pair if the
entire
working set fits in one bucket.
- Enable per-cpu caches of buckets. To prevent recursive bucket
allocation one bucket zone still has per-cpu caches disabled.
- Pick the initial bucket size based on a table driven maximum size
per-bucket rather than the number of items per-page. This gives
more sane initial sizes.
- Only grow the bucket size when we face contention on the zone
lock, this
causes bucket sizes to grow more slowly.
- Adjust the number of items per-bucket to account for the header
space.
This packs the buckets more efficiently per-page while making them
not quite powers of two.
- Eliminate the per-zone free bucket list. Always return buckets back
to the bucket zone. This ensures that as zones grow into larger
bucket sizes they eventually discard the smaller sizes. It persists
fewer buckets in the system. The locking is slightly trickier.
- Only switch buckets in zalloc, not zfree, this eliminates
pathological
cases where we ping-pong between two buckets.
- Ensure that the thread that fills a new bucket gets to allocate from
it to give a better upper bound on allocation time.
Sponsored by:EMC / Isilon Storage Division
--
I checked this several times and this commits seems to be causing this.
Can you tell me how many cores and how much memory you have? And paste the
output of vmstat -z when you see this error.
You can try changing bucket_select() at line 339 in uma_core.c to read:
static int
bucket_select(int size)
{
return (MAX(PAGE_SIZE / size, 1));
}
This will approximate the old bucket sizing behavior.
Just to add some more information; On my machine with 16GB of ram the
handful of recent UMA commits save about 20MB of kmem on boot. There are
30% fewer buckets allocated. And all of the malloc zones have similar
amounts of cached space. Actually the page size malloc bucket is taking
up much less space.
I don't know if the problem is unique to arm but I have tested x86 limited
to 512MB of ram without trouble. I will need the stats I mentioned before
to understand what has happened.
Jeff
Thanks,
Jeff
Does anyone observe similar behavior or have a solution?
Best regards
Zbyszek Bodek
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On 20 June 2013 16:56, Jeff Roberson wrote: > Just to add some more information; On my machine with 16GB of ram the > handful of recent UMA commits save about 20MB of kmem on boot. There are > 30% fewer buckets allocated. And all of the malloc zones have similar > amounts of cached space. Actually the page size malloc bucket is taking up > much less space. > > I don't know if the problem is unique to arm but I have tested x86 limited > to 512MB of ram without trouble. I will need the stats I mentioned before > to understand what has happened. Have you tried lower than 512MB? Like, 128MB? I have a 128MB -HEAD VM on i386 and it's working fine but I haven't done much digging to see how _well_ its working. I'm about to try a 64MB and 96MB VM. I'd like to go all the way down to 32MB (obviously with a cut down kernel, as GENERIC is pretty damned big!) and ensure that i386 isn't behaving poorly. There are still plenty of ARM/MIPS embedded boards that ship with 32MB (and less) RAM. I'm going to try stable/9 on 128MB of RAM soon. I know that 9.1-REL i386 + 128MB RAM results in a crash. Hopefully this stuff is better on stable/9. Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Atom N450 + C3 + HPET == bad timer behaviour
On 20 June 2013 16:45, Adrian Chadd wrote: > Hi, > > I'm having issues with HPET + C3 state on this Atom N450 based > netbook. This is (shocking, I know!) running -HEAD (r251605.) > > If I use C2, HPET is fine. > > If I use RTC, i8254, LAPIC, C3 is also fine. > > But C3 + HPET results in multi-second pauses where it should be 1 second. > > I've disabled powerd and verified that dev.cpu.0.freq=1667; so it's > not CPU frequency related. > > Doug found this: apparently SMI + timer fondling doesn't quite work out? > > http://lkml.indiana.edu/hypermail/linux/kernel/1102.3/00842.html .. and the resolution: http://lkml.indiana.edu/hypermail/linux/kernel/1102.3/00957.html "clockevents: Prevent oneshot mode when broadcast device is periodic When the per cpu timer is marked CLOCK_EVT_FEAT_C3STOP, then we only can switch into oneshot mode, when the backup broadcast device supports oneshot mode as well. Otherwise we would try to switch the broadcast device into an unsupported mode unconditionally. This went unnoticed so far as the current available broadcast devices support oneshot mode. Seth unearthed this problem while debugging and working around an hpet related BIOS wreckage. Add the necessary check to tick_is_oneshot_available()." does that help? adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
