kernel build fails due to incorrect call to ktls_disable_ifnet
I don't remember seeing this reported. Recent HEAD kernel build results in this error: make[1]: "/usr/src/Makefile.inc1" line 337: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 342: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker. -- >>> Kernel build for ernst_new started on Wed Jul 7 12:53:52 CEST 2021 -- ===> ernst_new -- >>> stage 1: configuring the kernel -- Kernel build directory is /home/garyj/obj/usr/src/amd64.amd64/sys/ernst_new Don't forget to do ``make cleandepend && make depend'' -- >>> stage 2.3: build tools -- -- >>> stage 3.1: building everything -- linking kernel.full ld: error: undefined symbol: ktls_disable_ifnet >>> referenced by tcp_var.h:1161 (/usr/src/sys/netinet/tcp_var.h:1161) >>> tcp_output.o:(tcp_account_for_send) --- kernel.full --- *** [kernel.full] Error code 1 This is caused because ktls_disable_ifnet() is present in /sys/kern/uipc_ktls.c, which is included in the kernel build only when options kern_ktls is present in the config file. I do not have this option set. So, it's wrong to blindly call this function in tcp_var.h. Commenting out the relevant code results in a successful build. -- Gary Jennejohn
Re: kernel build fails
___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
kernel build fails
Hello: On a system running: FreeBSD 13.0-CURRENT #0 r365372: Sun Sep 6 10:51:26 EDT 2020 amd64 with sources updated to last night, "buildworld" succeeds. "buildkernel", with the appended config file, fails with: /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct device' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:152:9: error: implicit declaration of function 'dev_get_drvdata' is invalid in C99 [-Werror,-Wimplicit-function-declaration] return dev_get_drvdata(_dev->dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:212:1: error: static declaration of 'dev_get_drvdata' follows non-static declaration dev_get_drvdata(const struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:242:9: note: previous implicit declaration is here return dev_get_drvdata(>dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:219:1: error: static declaration of 'dev_set_drvdata' follows non-static declaration dev_set_drvdata(struct device *dev, void *data) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:248:2: note: previous implicit declaration is here dev_set_drvdata(>dev, data); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:438:1: error: static declaration of 'device_unregister' follows non-static declaration device_unregister(struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:236:2: note: previous implicit declaration is here device_unregister(>dev); ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:277:27: error: initializing 'struct backlight_device *' with an expression of incompatible type 'void' struct backlight_device *bd = to_backlight_device(dev); ^ 12 errors generated. *** Error code 1 (Full build log available on request.) Don't see anything applicable in UPDATING. This is way above my pay grade. Help, please. Respectfully, Robert Huff # # JERUSALEM -- kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (https://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: head/sys/amd64/conf/GENERIC 343949 2019-02-10 07:54:46Z cem $ cpu HAMMER ident JERUSALEM makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options NUMA# Non-Uniform Memory Architecture support options PREEMPTION # Enable kernel thread preemption options VIMAGE # Subsystem virtualization, e.g. VNET options INET# InterNETworking options INET6 # IPv6 communications protocols options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 options ROUTE_MPATH # Multipath routing support options TCP_OFFLOAD # TCP offload options TCP_BLACKBOX# Enhanced TCP event logging options TCP_HHOOK
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On 25.06.2013 05:23, Jeff Roberson wrote: On Sun, 23 Jun 2013, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:50:40PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 08:44:25PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:16:17PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db This is completely broken. It seems that witness triggered the panic, and ddb is unable to obtain a backtrace from the normal panic(9) call. Show the output of the 'show alllocks'. No such command Do you have witness in the kernel config ? If not, add it to the config and retry. Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db show alllocks Process 1 (kernel) thread 0xc55fc620 (11) exclusive sleep mutex pmap (pmap) r = 0 (0xc5600590) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:729 exclusive rw pmap pv global (pmap pv global) r = 0 (0xc1479dd0) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:728 shared rw vm object (vm object) r = 0 (0xc1551d4c) locked @ /usr/home/br/dev/head/sys/vm/vm_map.c:1809 exclusive sx vm map (user) (vm map (user)) r = 0 (0xc5600528) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:445 exclusive lockmgr ufs (ufs) r = 0 (0xc56f7914) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:821 exclusive sleep mutex Giant (Giant) r = 0 (0xc147c778) locked @ /usr/home/br/dev/head/sys/kern/vfs_mount.c:1093 db Would any of the arm users be interested in testing a larger patch that changes the way the kernel allocations KVA? It also has some UMA code that lessens kernel memory utilization. http://people.freebsd.org/~jeff/vmem.diff Any reports would be helpful. Is there any ETA on getting stack tracing fixed? I suspect the pmap recursion encountered with Kostik's patch exist in the current kernel. The other changes in this patch my fix that as well. Thanks, Jeff Hello Jeff, I apologize for a long time with no respond. The problems that I reported at the origin of this tread are no longer relevant. I've made some really extensive tests on the current HEAD and there is no track of kstack allocation failure on my ARM target now. Thanks a lot for your help! 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 Mon, Jun 24, 2013 at 8:23 PM, Jeff Roberson jrober...@jroberson.net wrote: skip Would any of the arm users be interested in testing a larger patch that changes the way the kernel allocations KVA? It also has some UMA code that lessens kernel memory utilization. http://people.freebsd.org/~jeff/vmem.diff Any reports would be helpful. Is there any ETA on getting stack tracing fixed? I suspect the pmap recursion encountered with Kostik's patch exist in the current kernel. The other changes in this patch my fix that as well. I know mine is not a failed case but I still went ahead and gave your diffs a whirl. I have pretty much working beaglebone black running 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r252049M: Applied your patch and rebuilt the kernel. Everything seem sane right now. For reference: root@beaglebone:~ # cc -v FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Target: armv6-unknown-freebsd10.0 Thread model: posix root@beaglebone:~ # df -k Filesystem 1024-blocksUsed Avail Capacity Mounted on /dev/mmcsd0s2a13129204 6459024 561984453%/ devfs1 1 0 100%/dev /dev/mmcsd0s1 2020 660135933%/boot/msdos /dev/md0 29340 24 26972 0%/tmp /dev/md1 14492 64 13272 0%/var/log /dev/md2 4508 84140 0%/var/tmp root@beaglebone:~ # root@beaglebone:~ # sysctl hw.physmem hw.physmem: 536870912 root@beaglebone:~ # dmesg | less KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0: Wed Jun 26 09:51:05 UTC 2013 root@beaglebone:/usr/obj/usr/src/sys/BEAGLEBONE arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 536870912 (512 MB) avail memory = 511758336 (488 MB) Texas Instruments AM3358 Processor, Revision ES1.1 Anything in particular you want me to test other than, it seems to be working fine for me? Thanks, Hiren Thanks, Jeff ___ 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 Sun, 23 Jun 2013, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:50:40PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 08:44:25PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:16:17PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db This is completely broken. It seems that witness triggered the panic, and ddb is unable to obtain a backtrace from the normal panic(9) call. Show the output of the 'show alllocks'. No such command Do you have witness in the kernel config ? If not, add it to the config and retry. Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db show alllocks Process 1 (kernel) thread 0xc55fc620 (11) exclusive sleep mutex pmap (pmap) r = 0 (0xc5600590) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:729 exclusive rw pmap pv global (pmap pv global) r = 0 (0xc1479dd0) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:728 shared rw vm object (vm object) r = 0 (0xc1551d4c) locked @ /usr/home/br/dev/head/sys/vm/vm_map.c:1809 exclusive sx vm map (user) (vm map (user)) r = 0 (0xc5600528) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:445 exclusive lockmgr ufs (ufs) r = 0 (0xc56f7914) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:821 exclusive sleep mutex Giant (Giant) r = 0 (0xc147c778) locked @ /usr/home/br/dev/head/sys/kern/vfs_mount.c:1093 db Would any of the arm users be interested in testing a larger patch that changes the way the kernel allocations KVA? It also has some UMA code that lessens kernel memory utilization. http://people.freebsd.org/~jeff/vmem.diff Any reports would be helpful. Is there any ETA on getting stack tracing fixed? I suspect the pmap recursion encountered with Kostik's patch exist in the current kernel. The other changes in this patch my fix that as well. Thanks, Jeff ___ 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 Sat, Jun 22, 2013 at 04:37:24PM -1000, Jeff Roberson wrote:
On Fri, 21 Jun 2013, Zbyszek Bodek wrote:
On 21.06.2013 01:56, Jeff Roberson wrote:
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 j...@freebsd.org
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.
Hello Jeff,
Thank you for your interest in my problem.
My system is a quad-core ARMv7 with 2048 MB of RAM on board.
Please see attachment for the output from vmstat -z when the error occurs.
Changing bucket_select() to
static int
bucket_select(int size)
{
return (MAX(PAGE_SIZE / size, 1));
}
as you suggested helps for the problem. I've performed numerous attempts
to build the
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On Sun, Jun 23, 2013 at 09:57:06AM +0300, Konstantin Belousov wrote: I don't really see a lot of wasted memory in the zones. There is certainly some. Can you give me sysctl vm from both a working and non-working kernel after the build is done or fails? Try this: http://people.freebsd.org/~kib/misc/arm_bcache.1.patch Please _do_ notify me whether it compiled and helped with your problem. Btw, there is a problem while allocating 2GB RAM on armv7 boards while unmapped_buf_allowed == 1 (default): - ## Starting application at 0x40F0 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #5 r252090M: Sun Jun 23 12:18:31 MSK 2013 r...@intel.bsdpad.com:/usr/obj/arm.armv6/usr/home/br/dev/head/sys/ARNDALE arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Cortex A15 rev 4 (Cortex-A core) Supported features: ARM_ISA THUMB2 THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:2 Cache level 1: 32KB/64B 2-way data cache WB Read-Alloc Write-Alloc 32KB/64B 2-way instruction cache Read-Alloc Cache level 2: 1024KB/64B 16-way unified cache WB Read-Alloc Write-Alloc real memory = 2147483648 (2048 MB) panic: kmem_suballoc: bad status return of 3 - arm_bcache.1.patch resolves the issue above, but forced another one: - Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 - and there are no problems at all if unmapped_buf_allowed == 0 -Ruslan ___ 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 Sun, Jun 23, 2013 at 12:32:20PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 09:57:06AM +0300, Konstantin Belousov wrote: I don't really see a lot of wasted memory in the zones. There is certainly some. Can you give me sysctl vm from both a working and non-working kernel after the build is done or fails? Try this: http://people.freebsd.org/~kib/misc/arm_bcache.1.patch Please _do_ notify me whether it compiled and helped with your problem. Btw, there is a problem while allocating 2GB RAM on armv7 boards while unmapped_buf_allowed == 1 (default): - ## Starting application at 0x40F0 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #5 r252090M: Sun Jun 23 12:18:31 MSK 2013 r...@intel.bsdpad.com:/usr/obj/arm.armv6/usr/home/br/dev/head/sys/ARNDALE arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Cortex A15 rev 4 (Cortex-A core) Supported features: ARM_ISA THUMB2 THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:2 Cache level 1: 32KB/64B 2-way data cache WB Read-Alloc Write-Alloc 32KB/64B 2-way instruction cache Read-Alloc Cache level 2: 1024KB/64B 16-way unified cache WB Read-Alloc Write-Alloc real memory = 2147483648 (2048 MB) panic: kmem_suballoc: bad status return of 3 - arm_bcache.1.patch resolves the issue above, but forced another one: I have no idea why do you think that the patch 'forced' this issue. - Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 - This is useless without a backtrace. and there are no problems at all if unmapped_buf_allowed == 0 -Ruslan pgp3TZXZ2IVMl.pgp Description: PGP signature
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 05:32:48PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 12:32:20PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 09:57:06AM +0300, Konstantin Belousov wrote: I don't really see a lot of wasted memory in the zones. There is certainly some. Can you give me sysctl vm from both a working and non-working kernel after the build is done or fails? Try this: http://people.freebsd.org/~kib/misc/arm_bcache.1.patch Please _do_ notify me whether it compiled and helped with your problem. Btw, there is a problem while allocating 2GB RAM on armv7 boards while unmapped_buf_allowed == 1 (default): - ## Starting application at 0x40F0 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #5 r252090M: Sun Jun 23 12:18:31 MSK 2013 r...@intel.bsdpad.com:/usr/obj/arm.armv6/usr/home/br/dev/head/sys/ARNDALE arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Cortex A15 rev 4 (Cortex-A core) Supported features: ARM_ISA THUMB2 THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:2 Cache level 1: 32KB/64B 2-way data cache WB Read-Alloc Write-Alloc 32KB/64B 2-way instruction cache Read-Alloc Cache level 2: 1024KB/64B 16-way unified cache WB Read-Alloc Write-Alloc real memory = 2147483648 (2048 MB) panic: kmem_suballoc: bad status return of 3 - arm_bcache.1.patch resolves the issue above, but forced another one: I have no idea why do you think that the patch 'forced' this issue. - Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 - This is useless without a backtrace. Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db This is completely broken. It seems that witness triggered the panic, and ddb is unable to obtain a backtrace from the normal panic(9) call. Show the output of the 'show alllocks'. and there are no problems at all if unmapped_buf_allowed == 0 -Ruslan pgphG7dmySOg8.pgp Description: PGP signature
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On Sun, Jun 23, 2013 at 05:32:48PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 12:32:20PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 09:57:06AM +0300, Konstantin Belousov wrote: I don't really see a lot of wasted memory in the zones. There is certainly some. Can you give me sysctl vm from both a working and non-working kernel after the build is done or fails? Try this: http://people.freebsd.org/~kib/misc/arm_bcache.1.patch Please _do_ notify me whether it compiled and helped with your problem. Btw, there is a problem while allocating 2GB RAM on armv7 boards while unmapped_buf_allowed == 1 (default): - ## Starting application at 0x40F0 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #5 r252090M: Sun Jun 23 12:18:31 MSK 2013 r...@intel.bsdpad.com:/usr/obj/arm.armv6/usr/home/br/dev/head/sys/ARNDALE arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Cortex A15 rev 4 (Cortex-A core) Supported features: ARM_ISA THUMB2 THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:2 Cache level 1: 32KB/64B 2-way data cache WB Read-Alloc Write-Alloc 32KB/64B 2-way instruction cache Read-Alloc Cache level 2: 1024KB/64B 16-way unified cache WB Read-Alloc Write-Alloc real memory = 2147483648 (2048 MB) panic: kmem_suballoc: bad status return of 3 - arm_bcache.1.patch resolves the issue above, but forced another one: I have no idea why do you think that the patch 'forced' this issue. - Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 - This is useless without a backtrace. Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db and there are no problems at all if unmapped_buf_allowed == 0 -Ruslan ___ 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 Sun, Jun 23, 2013 at 08:44:25PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:16:17PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db This is completely broken. It seems that witness triggered the panic, and ddb is unable to obtain a backtrace from the normal panic(9) call. Show the output of the 'show alllocks'. No such command Do you have witness in the kernel config ? If not, add it to the config and retry. db show all chains ifnets lltablespcpuprocs rman trace ttys db pgpyJ_FbBxlIn.pgp Description: PGP signature
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On Sun, Jun 23, 2013 at 07:16:17PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db This is completely broken. It seems that witness triggered the panic, and ddb is unable to obtain a backtrace from the normal panic(9) call. Show the output of the 'show alllocks'. No such command db show all chains ifnets lltablespcpuprocs rman trace ttys db ___ 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 Sun, Jun 23, 2013 at 07:50:40PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 08:44:25PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 07:16:17PM +0300, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db This is completely broken. It seems that witness triggered the panic, and ddb is unable to obtain a backtrace from the normal panic(9) call. Show the output of the 'show alllocks'. No such command Do you have witness in the kernel config ? If not, add it to the config and retry. Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db show alllocks Process 1 (kernel) thread 0xc55fc620 (11) exclusive sleep mutex pmap (pmap) r = 0 (0xc5600590) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:729 exclusive rw pmap pv global (pmap pv global) r = 0 (0xc1479dd0) locked @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:728 shared rw vm object (vm object) r = 0 (0xc1551d4c) locked @ /usr/home/br/dev/head/sys/vm/vm_map.c:1809 exclusive sx vm map (user) (vm map (user)) r = 0 (0xc5600528) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:445 exclusive lockmgr ufs (ufs) r = 0 (0xc56f7914) locked @ /usr/home/br/dev/head/sys/kern/imgact_elf.c:821 exclusive sleep mutex Giant (Giant) r = 0 (0xc147c778) locked @ /usr/home/br/dev/head/sys/kern/vfs_mount.c:1093 db ___ 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 Jun 23, 2013, at 9:16 AM, Konstantin Belousov wrote: On Sun, Jun 23, 2013 at 06:43:46PM +0400, Ruslan Bukin wrote: On Sun, Jun 23, 2013 at 05:32:48PM +0300, Konstantin Belousov wrote: This is useless without a backtrace. Trying to mount root from ufs:/dev/da0 []... WARNING: / was not properly dismounted warning: no time-of-day clock registered, system time will not be set accurately panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv global @ /usr/home/br/dev/head/sys/arm/arm/pmap-v6.c:1289 KDB: enter: panic [ thread pid 1 tid 11 ] Stopped at kdb_enter+0x48: ldrbr15, [r15, r15, ror r15]! db bt Tracing pid 1 tid 11 td 0xc547f620 _end() at 0xde9d0530 scp=0xde9d0530 rlv=0xc1211458 (db_trace_thread+0x34) rsp=0xde9d0514 rfp=0xc12d1b60 Bad frame pointer: 0xc12d1b60 db This is completely broken. It seems that witness triggered the panic, and ddb is unable to obtain a backtrace from the normal panic(9) call. Kernel backtraces are currently broken on ARM EABI kernels. Tim signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On Fri, 21 Jun 2013, Zbyszek Bodek wrote:
On 21.06.2013 01:56, Jeff Roberson wrote:
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 j...@freebsd.org
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.
Hello Jeff,
Thank you for your interest in my problem.
My system is a quad-core ARMv7 with 2048 MB of RAM on board.
Please see attachment for the output from vmstat -z when the error occurs.
Changing bucket_select() to
static int
bucket_select(int size)
{
return (MAX(PAGE_SIZE / size, 1));
}
as you suggested helps for the problem. I've performed numerous attempts
to build the kernel and none of them failed.
I don't really see a lot of wasted memory in the zones. There is
certainly some. Can you give me sysctl vm from both a working and
non-working kernel after the build is done or fails?
Thanks,
Jeff
Best regards
Zbyszek Bodek
Re: Kernel build fails on ARM: Cannot fork: Cannot allocate memory
On 21.06.2013 01:56, Jeff Roberson wrote:
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 j...@freebsd.org
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.
Hello Jeff,
Thank you for your interest in my problem.
My system is a quad-core ARMv7 with 2048 MB of RAM on board.
Please see attachment for the output from vmstat -z when the error occurs.
Changing bucket_select() to
static int
bucket_select(int size)
{
return (MAX(PAGE_SIZE / size, 1));
}
as you suggested helps for the problem. I've performed numerous attempts
to build the kernel and none of them failed.
Best regards
Zbyszek Bodek
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
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 z...@semihalf.com 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: 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 j...@freebsd.org
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: 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 j...@freebsd.org
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 jrober...@jroberson.net 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
Kernel build fails on ARM: Cannot fork: Cannot allocate memory
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 j...@freebsd.org 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. 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 Wed, Jun 19, 2013 at 10:15 PM, Zbyszek Bodek z...@semihalf.com 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 ___ 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
make kernel build fails
uname -a FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Fri Apr 20 11:58:36 UTC 2012 root@:/usr/obj/usr/src/sys/GENERIC amd64 when trying a make kernel it errors out with jemalloc: /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:650: Failed assertion: ((uintptr_t)ptr - ((uintptr_t)run + (uintptr_t)bin_info-reg0_offset)) % bin_info-reg_interval == 0 *** [kernel.debug] Signal 6 or uest.o scif_sas_task_request_state_handlers.o scif_sas_task_request_states.o scif_sas_timer.o syscons_isa.o vga_isa.o kern_clocksource.o link_elf_obj.o ia32_reg.o ia32_signal.o ia32_sigtramp.o ia32_syscall.o ia32_misc.o freebsd32_ioctl.o freebsd32_misc.o freebsd32_syscalls.o freebsd32_sysent.o ia32_sysvec.o imgact_elf32.o memmove.o memset.o x86bios.o x86emu.o OsdEnvironment.o acpi_apm.o madt.o srat.o powernow.o est.o hwpstate.o p4tcc.o atrtc.o clock.o isa.o isa_dma.o nmi.o orm.o pci_bus.o qpi.o busdma_machdep.o dump_machdep.o intr_machdep.o io_apic.o legacy.o local_apic.o mca.o msi.o nexus.o tsc.o config.o env.o hints.o vnode_if.o hack.So vers.o *** [kernel.debug] Signal 10 Stop in /usr/obj/usr/src/sys/GENERIC. *** [buildkernel] Error code 1 Stop in /usr/src. *** [buildkernel] Error code 1 Stop in /usr/src. ___ 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
kernel: build fails in most recent sources in ath
Hello,
I receive this error since I reeled in the most recent sources for FBSD
10.0-CURRENT/amd64. I build the system with CLANG.
clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3
-fno-strict-aliasing -march=native -D_KERNEL -DKLD_MODULE -nostdinc -I.
-I/usr/src/sys/modules/ath/../../dev/ath
-I/usr/src/sys/modules/ath/../../dev/ath/ath_hal
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq
-fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR
-mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -c
/usr/src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c
clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3
-fno-strict-aliasing -march=native -D_KERNEL -DKLD_MODULE -nostdinc -I.
-I/usr/src/sys/modules/ath/../../dev/ath
-I/usr/src/sys/modules/ath/../../dev/ath/ath_hal
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq
-fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR
-mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -c
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136:17: error: no
member named 'ts_flags' in 'struct ath_tx_status'
hasba = !! (ts.ts_flags HAL_TX_BA);
~~ ^
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139:13: error: no
member named 'ts_ba_low' in 'struct ath_tx_status'
ba[0] = ts.ts_ba_low;
~~ ^
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140:13: error: no
member named 'ts_ba_high' in 'struct ath_tx_status'
ba[1] = ts.ts_ba_high;
~~ ^
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156:16: error: no
member named 'ts_tid' in 'struct ath_tx_status'
if (tid != ts.ts_tid) {
~~ ^
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158:25: error: no
member named 'ts_tid' in 'struct ath_tx_status'
__func__, tid, ts.ts_tid);
~~ ^
5 errors generated.
signature.asc
Description: OpenPGP digital signature
Re: kernel: build fails in most recent sources in ath
Hi,
You need to build the system with:
options AH_SUPPORT_AR5416
.. even if you're not building _with_ the ath device. This is a
byproduct of how the modules are currently built.
I'm sorry for introducing this breakage. I'm going to try and fix the
driver soon but it's going to require a little more extensive code
shuffling and changes to make it neat to do.
Adrian
On 6 January 2012 14:56, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
Hello,
I receive this error since I reeled in the most recent sources for FBSD
10.0-CURRENT/amd64. I build the system with CLANG.
clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3
-fno-strict-aliasing -march=native -D_KERNEL -DKLD_MODULE -nostdinc -I.
-I/usr/src/sys/modules/ath/../../dev/ath
-I/usr/src/sys/modules/ath/../../dev/ath/ath_hal
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq
-fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR
-mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -c
/usr/src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c
clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -pipe -O3
-fno-strict-aliasing -march=native -D_KERNEL -DKLD_MODULE -nostdinc -I.
-I/usr/src/sys/modules/ath/../../dev/ath
-I/usr/src/sys/modules/ath/../../dev/ath/ath_hal
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/THOR/opt_global.h -I. -I@ -I@/contrib/altq
-fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/THOR
-mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -c
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3136:17: error: no
member named 'ts_flags' in 'struct ath_tx_status'
hasba = !! (ts.ts_flags HAL_TX_BA);
~~ ^
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3139:13: error: no
member named 'ts_ba_low' in 'struct ath_tx_status'
ba[0] = ts.ts_ba_low;
~~ ^
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3140:13: error: no
member named 'ts_ba_high' in 'struct ath_tx_status'
ba[1] = ts.ts_ba_high;
~~ ^
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3156:16: error: no
member named 'ts_tid' in 'struct ath_tx_status'
if (tid != ts.ts_tid) {
~~ ^
/usr/src/sys/modules/ath/../../dev/ath/if_ath_tx.c:3158:25: error: no
member named 'ts_tid' in 'struct ath_tx_status'
__func__, tid, ts.ts_tid);
~~ ^
5 errors generated.
___
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
kernel build fails in agp_nvidia.c
Hello, cvsupped half an hour ago, the following error occurs when trying to build a kernel (mine, which worked fine with yesterdays source) @ - /usr/src/sys machine - /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/pci/agp_if.m -c awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/pci/agp_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h touch opt_bdg.h touch opt_bus.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include -I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/agp/../../pci/agp.c agp_if.c /usr/src/sys/modules/agp/../../pci/agp_i810.c /usr/src/sys/modules/agp/../../pci/agp_intel.c /usr/src/sys/modules/agp/../../pci/agp_via.c /usr/src/sys/modules/agp/../../pci/agp_sis.c /usr/src/sys/modules/agp/../../pci/agp_ali.c /usr/src/sys/modules/agp/../../pci/agp_amd.c /usr/src/sys/modules/agp/../../pci/agp_nvidia.c /usr/src/sys/pci/agp_nvidia.c:53:24: pci/pcivar.h: No such file or directory /usr/src/sys/pci/agp_nvidia.c:54:24: pci/pcireg.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/agp. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/CALE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. pgp0.pgp Description: signature
Re: kernel build fails in agp_nvidia.c
On Sat, 23 Aug 2003, Harald Schmalzbauer wrote: cvsupped half an hour ago, the following error occurs when trying to build a kernel (mine, which worked fine with yesterdays source) This one is mine, sorry. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel build fails in agp_nvidia.c
On Saturday 23 August 2003 21:31, Matthew N. Dodd wrote: On Sat, 23 Aug 2003, Harald Schmalzbauer wrote: cvsupped half an hour ago, the following error occurs when trying to build a kernel (mine, which worked fine with yesterdays source) This one is mine, sorry. No problem, but if you want to punish yourself for that horrible mistake you could explain me what this is good for ;-) (I have a brand new GF4mx440 with dual head config and everything is working fine with the downloaded nvidia drivers) I don't really understand things going on with this driver but I know that there can be two different agp drivers used (the FreeBSD one, which I haven't in the kernel or the nvidia builtin (which I use) Is this module the extracted agp driver from the nvidia driver? Thanks, -Harry pgp0.pgp Description: signature
Kernel Build Fails - Syscons errors...
While compiling a new kernel based on today's sources, I get the following errors from the syscons history code: [freya] [/sys/i386/compile/freya5] # make cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/syscons/schistory.c ../../../dev/syscons/schistory.c: In function `sc_alloc_history_buffer': ../../../dev/syscons/schistory.c:127: void value not ignored as it ought to be ../../../dev/syscons/schistory.c:127: syntax error before ')' token ../../../dev/syscons/schistory.c: In function `sc_hist_ioctl': ../../../dev/syscons/schistory.c:306: void value not ignored as it ought to be ../../../dev/syscons/schistory.c:306: syntax error before ')' token *** Error code 1 Stop in /usr/src/sys/i386/compile/freya5. TIA for assistance... /robert/ -- --- END --- At a dinner party one should eat wisely but not too well, and talk well but not too wisely. -- W. Somerset Maugham (1874-1965) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel Build Fails In -Current
when trying to build a kernel this morning I get: cc1: wanings being treated as errors /usr/sys/src/dev/aic7xxx/aicxxx7.c In function ahc_calc_residual': /usr/sys/src/dev/aic7xxx/aicxxx7:5757 warning 'resid' might be an uninitialized function *** Error code 1 does anyone know if this has been fixed yet ?? Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
On Wed, 23 Jan 2002, Bruce Evans wrote: On Sun, 20 Jan 2002, k Macy wrote: Should I file a PR to track this or is that overkill? Yes, it would be overkill. Remind me if it's not fixed in a week or two. I tested and committed the fix. Please report any other profiling bugs for SMP. I'm mainly interested in things that work for !SMP but not even as well as possible for SMP (no attempt is made to separate stats for each CPU so all we can hope for now is proper merging of the stats). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel build fails in latest -CURRENT
With the latest -CURRENT, the kernel fails building with the SVR4 option but is fine without the SVR4 options as follows: touch hack.c cc -elf -shared -nostdlib hack.c -o hack.So rm -f hack.c sh /usr/src/sys/conf/newvers.sh PELE cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -elf -mpreferred-stack-boundary=2 vers.c linking kernel.debug svr4_filio.o: In function `svr4_fil_ioctl': /usr/src/sys/compat/svr4/svr4_filio.c(.text+0xbd): undefined reference to `mtx_lock' /usr/src/sys/compat/svr4/svr4_filio.c(.text+0x118): undefined reference to `mtx_unlock' /usr/src/sys/compat/svr4/svr4_filio.c(.text+0x130): undefined reference to `mtx_unlock' /usr/src/sys/compat/svr4/svr4_filio.c(.text+0x141): undefined reference to `mtx_unlock' /usr/src/sys/compat/svr4/svr4_filio.c(.text+0x1ed): undefined reference to `mtx_unlock' *** Error code 1 Stop in /usr/obj/usr/src/sys/PELE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. root@pele [9:08pm][/usr/src] Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
On Sun, 20 Jan 2002, k Macy wrote: Should I file a PR to track this or is that overkill? Yes, it would be overkill. Remind me if it's not fixed in a week or two. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
Should I file a PR to track this or is that overkill?
-Kip
--- Bruce Evans [EMAIL PROTECTED] wrote:
On Sat, 19 Jan 2002, k Macy wrote:
Thanks for working on this. I was going to try
running
a profiled kernel on -CURRENT and -STABLE to see
what
the difference was in time distribution. On
-STABLE
it built without a hitch. However, on -CURRENT I
got
the following even after doing a make clean:
../../../libkern/mcount.c: In function `mcount':
../../../libkern/mcount.c:91: `mcount_lock'
undeclared
(first use in this function)
The mcount_lock stuff apparently never even
compiled. It is only used
for the !GUPROF SMP case, but it cannot work in
that case since
mcount_lock is not declared. Unfortunately, LINT
only tests the GUPROF
case, which compiles but is even more broken at
runtime in the SMP
case. GUPROF worse fine in the !SMP case and should
be non-optional
(it gives about 10 times as much resolution as
PROF on current
machines, instead of only 1000 times as much as on
486's when it was
written).
This fix has not been tested. It has some chance of
working, because
RELENG_4 uses similar code. However, it is
certainly broken if the
atomic functions that it calls are not inlined (then
the functions will
call MCOUNT_ENTER() on entry). I think this only
happens if mcount.c
is compiled with -O0. This bug is missing in
RELENG_4 too.
%%%
Index: profile.h
===
RCS file:
/home/ncvs/src/sys/i386/include/profile.h,v
retrieving revision 1.25
diff -u -2 -r1.25 profile.h
--- profile.h 30 Oct 2001 15:04:57 - 1.25
+++ profile.h 20 Jan 2002 06:05:24 -
@@ -65,4 +65,5 @@
#define MCOUNT_DECL(s) u_long s;
#ifdef SMP
+extern int mcount_lock;
#define MCOUNT_ENTER(s) { s = read_eflags();
disable_intr(); \
while (!atomic_cmpset_acq_int(mcount_lock,
0, 1)) \
%%%
Bruce
__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
profiled kernel build fails was Re: -CURRENT AIO bug
Thanks for working on this. I was going to try running a profiled kernel on -CURRENT and -STABLE to see what the difference was in time distribution. On -STABLE it built without a hitch. However, on -CURRENT I got the following even after doing a make clean: ../../../libkern/mcount.c: In function `mcount': ../../../libkern/mcount.c:91: `mcount_lock' undeclared (first use in this function) ../../../libkern/mcount.c:91: (Each undeclared identifier is reported only once ../../../libkern/mcount.c:91: for each function it appears in.) machine/atomic.h:141: warning: inlining failed in call to `atomic_cmpset_int' ../../../libkern/mcount.c:91: warning: called from here machine/atomic.h:234: warning: inlining failed in call to `atomic_store_rel_int' ../../../libkern/mcount.c:242: warning: called from here ../../../libkern/mcount.c: In function `mcount': ../../../libkern/mcount.c:91: `mcount_lock' undeclared (first use in this function) ../../../libkern/mcount.c:91: (Each undeclared identifier is reported only once ../../../libkern/mcount.c:91: for each function it appears in.) machine/atomic.h:141: warning: inlining failed in call to `atomic_cmpset_int' ../../../libkern/mcount.c:91: warning: called from here machine/atomic.h:234: warning: inlining failed in call to `atomic_store_rel_int' ../../../libkern/mcount.c:242: warning: called from here --- Alan L. Cox [EMAIL PROTECTED] wrote: k Macy wrote: It turns that this problem is specific to AIO in -CURRENT. I wrote a simple program that uses the three different completion mechanisms (polling with aio_error, polling with kevent, and using SIGIO) to fill up a file by writing 8kb at a time to the file and then reading 8kb at a time from the file. I believe that I've fixed this problem. Please update to revision 1.112 of kern/vfs_aio.c and retry your tests. Best regards, Alan __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
On Sat, 19 Jan 2002, k Macy wrote:
Thanks for working on this. I was going to try running
a profiled kernel on -CURRENT and -STABLE to see what
the difference was in time distribution. On -STABLE
it built without a hitch. However, on -CURRENT I got
the following even after doing a make clean:
../../../libkern/mcount.c: In function `mcount':
../../../libkern/mcount.c:91: `mcount_lock' undeclared
(first use in this function)
The mcount_lock stuff apparently never even compiled. It is only used
for the !GUPROF SMP case, but it cannot work in that case since
mcount_lock is not declared. Unfortunately, LINT only tests the GUPROF
case, which compiles but is even more broken at runtime in the SMP
case. GUPROF worse fine in the !SMP case and should be non-optional
(it gives about 10 times as much resolution as PROF on current
machines, instead of only 1000 times as much as on 486's when it was
written).
This fix has not been tested. It has some chance of working, because
RELENG_4 uses similar code. However, it is certainly broken if the
atomic functions that it calls are not inlined (then the functions will
call MCOUNT_ENTER() on entry). I think this only happens if mcount.c
is compiled with -O0. This bug is missing in RELENG_4 too.
%%%
Index: profile.h
===
RCS file: /home/ncvs/src/sys/i386/include/profile.h,v
retrieving revision 1.25
diff -u -2 -r1.25 profile.h
--- profile.h 30 Oct 2001 15:04:57 - 1.25
+++ profile.h 20 Jan 2002 06:05:24 -
@@ -65,4 +65,5 @@
#defineMCOUNT_DECL(s) u_long s;
#ifdef SMP
+extern int mcount_lock;
#defineMCOUNT_ENTER(s) { s = read_eflags(); disable_intr(); \
while (!atomic_cmpset_acq_int(mcount_lock, 0, 1)) \
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel build fails
On Sat, 5 Jan 2002, Sheldon Hearn wrote: Yeah, that script was committed untested. :-( Try the untested patch included below. Why are there C-style comments in a Perl script? * This file is produced automatically. * Do not modify anything in here by hand. * - * Created from $FreeBSD: src/sys/kern/vnode_if.pl,v 1.28 2002/01/04 05:27:47 silby Exp $ + * Created from \$FreeBSD: src/sys/kern/vnode_if.pl,v 1.28 2002/01/04 05:27:47 silby Exp $ */ Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel build fails
On Sun, 2002-01-06 at 19:38, Doug White wrote: Why are there C-style comments in a Perl script? At a guess, it's a here document. -- brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineeringKF8NH carnegie mellon university [better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel build fails
I got the following trying to build -current today: make _kernel-depend cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/i386/i386/genassym.c NM=nm OBJFORMAT=elf sh /usr/src/sys/kern/genassym.sh genassym.o assym.s perl5 /usr/src/sys/kern/vnode_if.pl -h /usr/src/sys/kern/vnode_if.src Global symbol $FreeBSD requires explicit package name at /usr/src/sys/kern/vnode_if.pl line 82. Use of $* is deprecated at /usr/src/sys/kern/vnode_if.pl line 82. Global symbol $FreeBSD requires explicit package name at /usr/src/sys/kern/vnode_if.pl line 98. Execution of /usr/src/sys/kern/vnode_if.pl aborted due to compilation errors. *** Error code 255 Stop in /usr/obj/usr/src/sys/GALAXY. *** Error code 1 Anyone else see this? Beech --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel build fails in atomic.c
I got the following eariler, and thinking I was out of sync, I cvsupped everything from scratch, and still got it. --- cc -c -g -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -f format-extensions -ansi -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../ ../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 -fomit-frame-pointer ../../../i386/i386/atomic.c In file included from ../../../i386/i386/atomic.c:48: machine/atomic.h: In function `atomic_set_char': machine/atomic.h:214: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_char': machine/atomic.h:215: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_char': machine/atomic.h:216: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_char': machine/atomic.h:217: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_short': machine/atomic.h:219: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_short': machine/atomic.h:220: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_short': machine/atomic.h:221: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_short': machine/atomic.h:222: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_int': machine/atomic.h:224: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_int': machine/atomic.h:225: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_int': machine/atomic.h:226: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_int': machine/atomic.h:227: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_long': machine/atomic.h:229: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_long': machine/atomic.h:230: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_long': machine/atomic.h:231: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_long': machine/atomic.h:232: inconsistent operand constraints in an `asm' *** Error code 1 Stop in /usr/src/sys/i386/compile/WAHOO. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - Religious fundamentalism is the biggest threat to international security that exists today. United Nations Secretary General B.B.Ghali, 1995 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current kernel build fails with src/sys/kern/sys_socket.c v 1.342001/07/25 20:14:59 fenner
It seems with the src/sys/kern/sys_socket.c v 1.34 2001/07/25 20:14:59 fenner committed today, kernel build fails in -current as follows: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/kern/sys_socket.c /usr/src/sys/kern/sys_socket.c: In function `soo_ioctl': /usr/src/sys/kern/sys_socket.c:145: too few arguments to function `rtioctl' *** Error code 1 Stop in /usr/obj/usr/src/sys/PELE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. root@pele [10:47am][/usr/src] Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current kernel build fails with src/sys/kern/sys_socket.c v 1.34 2001/07/25 20:14:59 fenner
You must have updated in the middle of the commit. Make sure you have rev 1.38 of src/sys/net/route.h . Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
