Re: Panic on boot after svn update
On Sat, Jul 28, 2012 at 10:15 PM, Greg 'groggy' Lehey g...@freebsd.org wrote: On Sunday, 29 July 2012 at 0:53:55 -0400, David J. Weller-Fahy wrote: So, I recently updated and encountered a panic on boot which is reproducible, and wanted to see if anyone's encountered this before I file a PR. I found a problem in (I think) recent changes to the e1000 driver. I'm running FreeBSD 10-CURRENT as a VirtualBox guest. #v+ FreeBSD fork-pooh 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r238764: Sat Jul 28 17:21:47 EDT 2012 root@fork-pooh:/usr/obj/usr/src/sys/GENERIC amd64 #v- I have the Adapter Type set to, Intel PRO/1000 MT Desktop (82540EM), and the following card is detected by pciconf. ... Updating motd:. Starting ntpd. panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881 aolMe too/aol The panic message is identical, and I'm also running in VirtualBox. My version string (from strings on the kernel) is: FreeBSD 10.0-CURRENT #4: Sat Jul 28 09:45:10 EST 2012 r...@swamp.lemis.com:/usr/obj/src/FreeBSD/svn/head/sys/GENERIC Note that this is a different EST (UTC+10). I have a dump, but I can't get much sense out of it: kgdb: kvm_read: invalid address (0x354540a) #0 0x in ?? () I'm currently rebuilding the system, but it looks as if that won't help much. One interesting point is that the first panic happened after installing the new image (from yesterday's sources) while I was trying to reboot with the old kernel, dating back to FreeBSD swamp.lemis.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3: Sun May 13 14:34:43 EST 2012 r...@swamp.lemis.com:/usr/obj/src/FreeBSD/svn/head/sys/GENERIC i386 See this thread: http://lists.freebsd.org/pipermail/freebsd-current/2012-July/035593.html . -Garrett ___ 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: r238860: bsdtar: eating up 100% CPU, hanging
I am also looking into it: 1. It happens only with libarchive 3.0.4 (3.0.3 works fine) 2. It happens only if archiving files located on ZFS (UFS works fine) 3. Backtrace: #0 setup_acl_posix1e (a=0x801c45100, entry=0x801d69100, acl=0x801d8a000, archive_entry_acl_type=256) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:474 #1 0x000800879036 in archive_read_disk_entry_from_file (_a=0x801c45100, entry=0x801d69100, fd=6, st=Variable st is not available. ) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:434 #2 0x00080087831e in _archive_read_next_header2 (_a=0x801c45100, entry=0x801d69100) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_posix.c:1070 #3 0x004078d5 in write_hierarchy (bsdtar=0x7fffd940, a=0x801c17140, path=Variable path is not available. ) at /base/head/usr.bin/tar/../../contrib/libarchive/tar/write.c:825 #4 0x00407d51 in write_archive (a=0x801c17140, bsdtar=0x7fffd940) at /base/head/usr.bin/tar/../../contrib/libarchive/tar/write.c:471 #5 0x00404fbd in main (argc=4, argv=Variable argv is not available. ) at /base/head/usr.bin/tar/../../contrib/libarchive/tar/bsdtar.c:668 This infinite loop has been fixed in libarchive master: https://github.com/libarchive/libarchive/commit/d8b9dbd d8b9dbd6dac0125957b997c2fe8d246237ec9f94 I suggest you backport to release also the following: f67370d5c33b336b103c43fe35984defe7e0e473 https://github.com/libarchive/libarchive/commit/f67370d c6d3cd33aecdc579966c3fbe7b9424cea83c7555 https://github.com/libarchive/libarchive/commit/c6d3cd3 Dňa 29. 7. 2012 3:18 Tim Kientzle wrote / napísal(a): On Jul 28, 2012, at 10:21 AM, O. Hartmann wrote: When updating ports (like databases/sqlite3 or graphics/png via portmaster graphics/png), the installation process comes to a point where a backup of the old port is created with bsdtar. The process hangs then … My operating system is FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 That's newer than my -CURRENT system here; I'm updating now. Martin imported a few changes from upstream just recently, so this is likely a new problem. What to do? Can you get the full command line for the command that's hanging? $ ps auxww | grep tar Knowing the exact options that were used will help narrow it down. Thanks for reporting it, Tim ___ 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: Unable to load i915kms
Hi,
On Sun, Jul 29, 2012 at 12:12:01PM +0700, Erich Dollansky wrote:
On Sat, 28 Jul 2012 21:49:18 -0700
Kevin Oberman kob6...@gmail.com wrote:
You are working too hard from old information. Do not attempt to load
i915kms.ko. Do not attempt to load drm2.ko. For the past months the
drivers have been fixed to automatically load all needed drivers and
kernel modules when Xorg is started. My Sandybridge behaves just like
How do the wrong modules get loaded?
Thanks for all the help guys. The problem was the result of my own
stupidity.
I went through some code trying to find out why the wrong modules were
loaded, and I discovered that I previously commented out this line in
x11-drivers/xf86-video-intel/Makefile:
EXTRA_PATCHES+= ${PATCHDIR}/extra-i915kms
This patch is for -CURRENT since the name of the module changed when
kib@ imported the code to -CURRENT:
- intel-drmSubFD = drmOpen(i915, busid);
+ intel-drmSubFD = drmOpen(i915kms, busid);
Since I built -CURRENT from around 3 months ago and an up-to-date ports
tree, I had to remove this patch to make it work. So it fell apart when
I tried to upgrade to the lastest -CURRENT...
Apparently portsnap doesn't overwrite local modifications to the ports
tree unless there are updates (unlike csup), so the patch wasn't
included until I discovered my mistake.
Next time I'll keep a list of local changes for my ports tree, so I
don't shoot myself in the foot again. Sorry for the noise.
--
Denny Lin
___
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: Unable to load i915kms
Hi,
On Sun, 29 Jul 2012 15:21:36 +0800
Denny Lin dennyli...@hs.ntnu.edu.tw wrote:
How do the wrong modules get loaded?
Thanks for all the help guys. The problem was the result of my own
stupidity.
I went through some code trying to find out why the wrong modules were
loaded, and I discovered that I previously commented out this line in
x11-drivers/xf86-video-intel/Makefile:
EXTRA_PATCHES+= ${PATCHDIR}/extra-i915kms
so, wrong name -- wrong modules. This simple.
Erich
___
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: r238860: bsdtar: eating up 100% CPU, hanging
On 07/29/12 08:30, Martin Matuska wrote: I am also looking into it: 1. It happens only with libarchive 3.0.4 (3.0.3 works fine) 2. It happens only if archiving files located on ZFS (UFS works fine) It happens in my case also on UFS2 filesystem (SU+J). My ports are residing on an UFS partition - but ZFS is also available on the system ... 3. Backtrace: #0 setup_acl_posix1e (a=0x801c45100, entry=0x801d69100, acl=0x801d8a000, archive_entry_acl_type=256) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:474 #1 0x000800879036 in archive_read_disk_entry_from_file (_a=0x801c45100, entry=0x801d69100, fd=6, st=Variable st is not available. ) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:434 #2 0x00080087831e in _archive_read_next_header2 (_a=0x801c45100, entry=0x801d69100) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_posix.c:1070 #3 0x004078d5 in write_hierarchy (bsdtar=0x7fffd940, a=0x801c17140, path=Variable path is not available. ) at /base/head/usr.bin/tar/../../contrib/libarchive/tar/write.c:825 #4 0x00407d51 in write_archive (a=0x801c17140, bsdtar=0x7fffd940) at /base/head/usr.bin/tar/../../contrib/libarchive/tar/write.c:471 #5 0x00404fbd in main (argc=4, argv=Variable argv is not available. ) at /base/head/usr.bin/tar/../../contrib/libarchive/tar/bsdtar.c:668 This infinite loop has been fixed in libarchive master: https://github.com/libarchive/libarchive/commit/d8b9dbd d8b9dbd6dac0125957b997c2fe8d246237ec9f94 I suggest you backport to release also the following: f67370d5c33b336b103c43fe35984defe7e0e473 https://github.com/libarchive/libarchive/commit/f67370d c6d3cd33aecdc579966c3fbe7b9424cea83c7555 https://github.com/libarchive/libarchive/commit/c6d3cd3 Dňa 29. 7. 2012 3:18 Tim Kientzle wrote / napísal(a): On Jul 28, 2012, at 10:21 AM, O. Hartmann wrote: When updating ports (like databases/sqlite3 or graphics/png via portmaster graphics/png), the installation process comes to a point where a backup of the old port is created with bsdtar. The process hangs then … My operating system is FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 That's newer than my -CURRENT system here; I'm updating now. Martin imported a few changes from upstream just recently, so this is likely a new problem. What to do? Can you get the full command line for the command that's hanging? $ ps auxww | grep tar Knowing the exact options that were used will help narrow it down. Thanks for reporting it, Tim ___ 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: RFC: libkern version of inet_ntoa_r
On Sat, Jul 28, 2012 at 10:14:10PM +, Bjoern A. Zeeb wrote: On Wed, 25 Jul 2012, Luigi Rizzo wrote: During some ipfw/dummynet cleanup i noticed that the libkern version of inet_ntoa_r() is missing the buffer size argument that is present in the libc counterpart. Any objection if i fix it ? And why exactly would you need it? What does libc do with it? Render partial IPv4 addresses? Thanks for raising the issue because things are actually simpler than i thought. In general, having a function with same name and different arguments/behaviour in the kernel and userspace is annoying and should be avoided/fixed if possible. We have to live with malloc/free as they are too widely used to suggest a change, but this inet_ntoa_r() is very seldom used. In fact, the libc version is never used in HEAD, stable/9 and stable/8 and only the libkern version has a small number of clients (see below). Given that libkern has inet_ntop, with the same arguments of the userspace version, we'd be much better off with the following course of action: 1. replace calls to inet_ntoa_r() with inet_ntop() This needs to be done only in the kernel, because the libc version is never used at least in the source tree (maybe some port does). 2. nuke inet_ntoa_r() from libkern 3. nuke inet_ntoa_r() from libc The discussion on the cost of the extra argument is not very relevant here, because the function is intrinsically slow and called on slow paths (involves an snprintf, and likely some device I/O downstream). cheers luigi # grep -r net_ntoa_r . | grep -Ev pristine ./include/arpa/inet.h:#define inet_ntoa_r __inet_ntoa_r ./include/arpa/inet.h:char *inet_ntoa_r(struct in_addr, char *buf, socklen_t size); ./lib/libc/inet/Symbol.map: __inet_ntoa_r; ./lib/libc/inet/Symbol.map: inet_ntoa_r; ./lib/libc/inet/inet_ntoa.c:inet_ntoa_r(struct in_addr in, char *buf, socklen_t size) ./lib/libc/inet/inet_ntoa.c:__weak_reference(__inet_ntoa_r, inet_ntoa_r); ./lib/libc/net/Makefile.inc:inet.3 inet_network.3 inet.3 inet_ntoa.3 inet.3 inet_ntoa_r.3\ ./lib/libc/net/inet.3:.Nm inet_ntoa_r , ./lib/libc/net/inet.3:.Fo inet_ntoa_r ./lib/libc/net/inet.3:.Fn inet_ntoa_r ./sys/libkern/inet_ntoa.c:inet_ntoa_r(struct in_addr ina, char *buf) ./sys/net/flowtable.c: inet_ntoa_r(ssin-sin_addr, saddr); ./sys/net/flowtable.c: inet_ntoa_r(dsin-sin_addr, daddr); ./sys/net/flowtable.c: inet_ntoa_r(*(struct in_addr *) dsin-sin_addr, daddr); ./sys/net/flowtable.c: inet_ntoa_r(*(struct in_addr *) hashkey[2], daddr); ./sys/net/flowtable.c: inet_ntoa_r(*(struct in_addr *) hashkey[1], saddr); ./sys/net/if_llatbl.c: inet_ntoa_r(sin-sin_addr, l3s); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, src); ./sys/netinet/ipfw/ip_fw_dynamic.c: inet_ntoa_r(da, dst); ./sys/netinet/ipfw/ip_fw_log.c: inet_ntoa_r(ip-ip_src, src); ./sys/netinet/ipfw/ip_fw_log.c: inet_ntoa_r(ip-ip_dst, dst); ./sys/netinet/in.h:char *inet_ntoa_r(struct in_addr ina, char *buf); /* in libkern */ ./sys/netinet/in_pcb.c: inet_ntoa_r(inc-inc_laddr, laddr_str); ./sys/netinet/in_pcb.c: inet_ntoa_r(inc-inc_faddr, faddr_str); ./sys/netinet/tcp_subr.c: inet_ntoa_r(inc-inc_faddr, sp); ./sys/netinet/tcp_subr.c: inet_ntoa_r(inc-inc_laddr, sp); ./sys/netinet/tcp_subr.c: inet_ntoa_r(ip-ip_src, sp); ./sys/netinet/tcp_subr.c: inet_ntoa_r(ip-ip_dst, sp); ` I need it because i would like to compile parts of the kernel in userspace, and having a kernel function with the same name and different arguments from of a libc function is annoying. I can accept that -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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
[head tinderbox] failure on sparc64/sparc64
TB --- 2012-07-29 10:08:15 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-29 10:08:15 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-07-29 10:08:15 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-07-29 10:08:15 - cleaning the object tree TB --- 2012-07-29 10:10:14 - cvsupping the source tree TB --- 2012-07-29 10:10:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2012-07-29 10:11:09 - building world TB --- 2012-07-29 10:11:09 - CROSS_BUILD_TESTING=YES TB --- 2012-07-29 10:11:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-29 10:11:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-29 10:11:09 - SRCCONF=/dev/null TB --- 2012-07-29 10:11:09 - TARGET=sparc64 TB --- 2012-07-29 10:11:09 - TARGET_ARCH=sparc64 TB --- 2012-07-29 10:11:09 - TZ=UTC TB --- 2012-07-29 10:11:09 - __MAKE_CONF=/dev/null TB --- 2012-07-29 10:11:09 - cd /src TB --- 2012-07-29 10:11:09 - /usr/bin/make -B buildworld World build started on Sun Jul 29 10:11:10 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Sun Jul 29 11:12:28 UTC 2012 TB --- 2012-07-29 11:12:28 - generating LINT kernel config TB --- 2012-07-29 11:12:28 - cd /src/sys/sparc64/conf TB --- 2012-07-29 11:12:28 - /usr/bin/make -B LINT TB --- 2012-07-29 11:12:28 - cd /src/sys/sparc64/conf TB --- 2012-07-29 11:12:28 - /usr/sbin/config -m LINT TB --- 2012-07-29 11:12:28 - building LINT kernel TB --- 2012-07-29 11:12:28 - CROSS_BUILD_TESTING=YES TB --- 2012-07-29 11:12:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-29 11:12:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-29 11:12:28 - SRCCONF=/dev/null TB --- 2012-07-29 11:12:28 - TARGET=sparc64 TB --- 2012-07-29 11:12:28 - TARGET_ARCH=sparc64 TB --- 2012-07-29 11:12:28 - TZ=UTC TB --- 2012-07-29 11:12:28 - __MAKE_CONF=/dev/null TB --- 2012-07-29 11:12:28 - cd /src TB --- 2012-07-29 11:12:28 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Jul 29 11:12:28 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/iscsi/initiator/isc_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/isp/isp_freebsd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany
Re: RFC: libkern version of inet_ntoa_r
On Sun, 29 Jul 2012, Luigi Rizzo wrote: On Sat, Jul 28, 2012 at 10:14:10PM +, Bjoern A. Zeeb wrote: On Wed, 25 Jul 2012, Luigi Rizzo wrote: .. Given that libkern has inet_ntop, with the same arguments of the userspace version, we'd be much better off with the following course of action: 1. replace calls to inet_ntoa_r() with inet_ntop() This needs to be done only in the kernel, because the libc version is never used at least in the source tree (maybe some port does). 2. nuke inet_ntoa_r() from libkern I am Ok with that I think (without looking at source implications) but I guess you'll post a patch. 3. nuke inet_ntoa_r() from libc I am not sure we can easily do that (despite not being used in base). I fear some broader research into ports is needed, or as a shortcut, does linux have an inet_ntoa_r()? -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: RFC: libkern version of inet_ntoa_r
On 29 Jul 2012, at 10:58, Luigi Rizzo wrote: 3. nuke inet_ntoa_r() from libc inet_ntoa_r is a public symbol and therefore part of our ABI contract with userspace applications. Even if no one that we are aware of is using it, we should officially deprecate it for one major release before removing it. ABI churn for purely aesthetic reasons does not make users happy people. I need it because i would like to compile parts of the kernel in userspace, and having a kernel function with the same name and different arguments from of a libc function is annoying. Presumably this usage can be trivially fixed with a trivial macro in a prefix header? David___ 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: r238860: bsdtar: eating up 100% CPU, hanging
Do you know what the value of acl_tag is at this point? On Jul 28, 2012, at 11:30 PM, Martin Matuska wrote: I am also looking into it: 1. It happens only with libarchive 3.0.4 (3.0.3 works fine) 2. It happens only if archiving files located on ZFS (UFS works fine) 3. Backtrace: #0 setup_acl_posix1e (a=0x801c45100, entry=0x801d69100, acl=0x801d8a000, archive_entry_acl_type=256) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:474 #1 0x000800879036 in archive_read_disk_entry_from_file (_a=0x801c45100, entry=0x801d69100, fd=6, st=Variable st is not available. ) at /base/head/lib/libarchive/../../contrib/libarchive/libarchive/archive_read_disk_entry_from_file.c:434 This infinite loop has been fixed in libarchive master: https://github.com/libarchive/libarchive/commit/d8b9dbd d8b9dbd6dac0125957b997c2fe8d246237ec9f94 I suggest you backport to release also the following: f67370d5c33b336b103c43fe35984defe7e0e473 https://github.com/libarchive/libarchive/commit/f67370d c6d3cd33aecdc579966c3fbe7b9424cea83c7555 https://github.com/libarchive/libarchive/commit/c6d3cd3 Dňa 29. 7. 2012 3:18 Tim Kientzle wrote / napísal(a): On Jul 28, 2012, at 10:21 AM, O. Hartmann wrote: When updating ports (like databases/sqlite3 or graphics/png via portmaster graphics/png), the installation process comes to a point where a backup of the old port is created with bsdtar. The process hangs then … My operating system is FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 That's newer than my -CURRENT system here; I'm updating now. Martin imported a few changes from upstream just recently, so this is likely a new problem. What to do? Can you get the full command line for the command that's hanging? $ ps auxww | grep tar Knowing the exact options that were used will help narrow it down. Thanks for reporting it, Tim ___ 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: r238860: bsdtar: eating up 100% CPU, hanging
Do you still have this problem after r238882? Dňa 28. 7. 2012 19:21 O. Hartmann wrote / napísal(a): When updating ports (like databases/sqlite3 or graphics/png via portmaster graphics/png), the installation process comes to a point where a backup of the old port is created with bsdtar. The process hangs then: === Starting build for graphics/png === === All dependencies are up to date === Creating a backup package for old version png-1.5.12 load: 1.38 cmd: bsdtar 99286 [running] 1301.04r 1296.34u 0.00s 100% 5656k And a look on top: last pid: 3365; load averages: 1.49, 1.44, 1.41 up 0+04:39:08 19:17:44 65 processes: 2 running, 63 sleeping CPU: 50.4% user, 0.0% nice, 1.0% system, 0.0% interrupt, 48.6% idle Mem: 521M Active, 3599M Inact, 3424M Wired, 32M Cache, 826M Buf, 323M Free ARC: 1970M Total, 672M MRU, 1224M MFU, 48K Anon, 46M Header, 28M Other Swap: 32G Total, 32G Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 99286 root 1 1030 71724K 5672K CPU11 24:10 100.00% bsdtar 1339 root 1 210 3221M 38008K select 1 3:02 1.71% Xorg 3364 ohartmann 28 200 634M 301M uwait 1 0:06 0.63% thunderbird 737 root 1 200 16520K 1492K select 0 0:42 0.00% moused 3286 ohartmann 22 200 681M 368M uwait 1 0:14 0.00% firefox 1469 ohartmann1 200 72364K 10612K select 1 0:05 0.00% xterm I can circumvent by doing a make reinstall in the port's directory, but this doesn't work for ports which copy files around using tar - like www/firefox and mail/thunderbird (which also get stuck when bsdtar is involved). My operating system is FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 buildworld and kernel from today's sources, ports seem to be up to date, I updated everything successfully before installing the new world which seems to be faulty. I also recompiled usr.bin/tar separately and installed it, but without success. What to do? regards, Oliver ___ 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
post SVN r238886 no boot?
Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( imb signature.asc Description: OpenPGP digital signature
Re: post SVN r238886 no boot?
On 29.07.2012 19:40 (UTC+2), Michael Butler wrote: Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( imb Yes, it's the same here. I had to revert to old kernel. Rainer ___ 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: post SVN r238886 no boot?
On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler i...@protected-networks.net wrote: Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( What was the previous version you booted and what's your configuration? Thanks, -Garrett ___ 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: post SVN r238886 no boot?
On 7/29/2012 10:40 AM, Michael Butler wrote: Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( imb me2 If I stop at single user and then continue, then all seems okay. I'm guessing (just a SWAG) that it might be related to the disk resize CAM stuff just added. ___ 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: post SVN r238886 no boot?
On 07/29/12 14:24, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler i...@protected-networks.net wrote: Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( What was the previous version you booted and what's your configuration? Thanks, -Garrett I'm on an x86 core duo laptop with a single SATA disk split between Windoze-7 and FreeBSD. Nothing really special in the kernel config (as attached). The kernel from r238864 (yesterday) is working just fine, imb # TOSHI include GENERIC ident TOSHI-SMP nomakeoptionDEBUG #makeoptionsWITH_CTF=no nocpu I486_CPU nocpu I586_CPU #nooptions SCHED_ULE # ULE scheduler #optionsSCHED_4BSD # 4BSD scheduler nooptions MD_ROOT # MD is a potential root device nooptions NFSSERVER # Network Filesystem Server nooptions NFS_ROOT# NFS usable as /, requires NFSCLIENT nooptions NFSD# Experimental Network Filesystem Server #options NFSCL nooptions COMPAT_FREEBSD4 # Compatible with FreeBSD4 nooptions COMPAT_FREEBSD5 # Compatible with FreeBSD5 nooptions COMPAT_FREEBSD6 # Compatible with FreeBSD6 nooptions COMPAT_FREEBSD7 # Compatible with FreeBSD7 #nooptions SCSI_DELAY # Debugging for use in -current nooptions KDB # Enable kernel debugger support. nooptions DDB # Support DDB. nooptions GDB # Support remote GDB. nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity checking nooptions INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect deadlocks and cycles nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed #optionsKDB_TRACE # print a stack trace on panic #optionsDEBUG_MEMGUARD # detect reads or writes from allocated memory after free #optionsDIAGNOSTIC # enable additional, more expensive diagnostic tests along # the lines of options INVARIANTS. nodeviceeisa nodevicefdc #device ata nodeviceataraid # ATA RAID drives nodeviceatapifd # ATAPI floppy drives nodeviceatapist # ATAPI tape drives nodeviceatadisk # ATA disk drives nodeviceatapicd # ATAPI CDROM drives #device atausb # ATA-USB bridge #device atapicam# emulate ATAPI devices as SCSI ditto via CAM # needs CAM to be present (scbus pass) #device atacore # Core ATA functionality #device atapci # PCI bus support; only generic chipset support #device ataahci # AHCI SATA #device ataintel# Intel #device ahci #device ada nodevicemvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA nodevicesiis# SiliconImage SiI3124/SiI3132/SiI3531 SATA # SCSI Controllers nodeviceahb # EISA AHA1742 family nodeviceahc # AHA2940 and onboard AIC7xxx devices nooptions AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. nodeviceahd # AHA39320/29320 and onboard AIC79xx devices nooptions AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. nodeviceamd # AMD 53C974 (Tekram DC-390(T)) nodeviceesp # AMD Am53C974 (Tekram DC-390(T)) nodevicehptiop # Highpoint RocketRaid 3xxx series nodeviceisp # Qlogic family nodevicempt # LSI-Logic MPT-Fusion nodevicesym # NCR/Symbios Logic (newer chipsets + those of `ncr') nodevicetrm # Tekram DC395U/UW/F DC315U adapters nodeviceadv # Advansys SCSI adapters nodeviceadw # Advansys wide SCSI adapters nodeviceaha # Adaptec 154x SCSI adapters nodeviceaic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. nodevicebt # Buslogic/Mylex MultiMaster SCSI adapters nodevicencv # NCR 53C500 nodevicensp # Workbit Ninja SCSI-3 nodevicestg # TMC 18C30/18C50 nodeviceisci# Intel C600 SAS controller nodevicech
Re: post SVN r238886 no boot?
On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler i...@protected-networks.net wrote: On 07/29/12 14:24, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler i...@protected-networks.net wrote: Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( What was the previous version you booted and what's your configuration? Thanks, -Garrett I'm on an x86 core duo laptop with a single SATA disk split between Windoze-7 and FreeBSD. Nothing really special in the kernel config (as attached). The kernel from r238864 (yesterday) is working just fine, And if you go back to r238885...? Thanks! -Garrett ___ 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: post SVN r238886 no boot?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/12 14:39, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler i...@protected-networks.net wrote: On 07/29/12 14:24, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler i...@protected-networks.net wrote: Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( What was the previous version you booted and what's your configuration? Thanks, -Garrett I'm on an x86 core duo laptop with a single SATA disk split between Windoze-7 and FreeBSD. Nothing really special in the kernel config (as attached). The kernel from r238864 (yesterday) is working just fine, And if you go back to r238885...? Building that now, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAVg+EACgkQQv9rrgRC1JKpZgCfbvRx7bliF7yZs0ekBneTsXif AKYAnjP4bgD3H0bZPl5HZdMDCkXtiMxm =7OJA -END PGP SIGNATURE- ___ 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: post SVN r238886 no boot?
On Sun, Jul 29, 2012 at 11:39:14AM -0700, Garrett Cooper wrote: ... What was the previous version you booted and what's your configuration? Thanks, -Garrett I'm on an x86 core duo laptop with a single SATA disk split between Windoze-7 and FreeBSD. Nothing really special in the kernel config (as attached). The kernel from r238864 (yesterday) is working just fine, And if you go back to r238885...? Thanks! FWIW, I built booted r238885 on both my laptop my home build machine (without icident), and I'm in the process of building r238886 on my desktop at work as I type. (I haven't a serial console attached to the latter, and I'm remote from it, so this may be ... interesting for me :-}) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpozD2wfW5yE.pgp Description: PGP signature
Re: RFC: libkern version of inet_ntoa_r
On Sun, Jul 29, 2012 at 05:55:19PM +0100, David Chisnall wrote:
On 29 Jul 2012, at 10:58, Luigi Rizzo wrote:
3. nuke inet_ntoa_r() from libc
inet_ntoa_r is a public symbol and therefore part of our ABI contract with
userspace applications. Even if no one that we are aware of is using it, we
should officially deprecate it for one major release before removing it. ABI
churn for purely aesthetic reasons does not make users happy people.
sure, interpret nuke as a long term thing
(starting with deprecation, manpage notes, etc.)
I need it because i would like to compile parts of the kernel in userspace,
and having a kernel function with the same name and different arguments
from of a libc function is annoying.
Presumably this usage can be trivially fixed with a trivial macro in a prefix
header?
Remapping f(a) into f(a, b) requires both a macro
and a wrapping function, something like this
T __f(T1 a, T2 b) { return f(a, b); }
#define f(a) __f(a, b)
Surely can be done (in fact, i have done it already, see
http://info.iet.unipi.it/~luigi/netmap/20120725-ipfw-user.tgz
but i am not so interested in participating to the IOCCC :)
http://www.ioccc.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: post SVN r238886 no boot?
On 07/29/12 14:39, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler i...@protected-networks.net wrote: On 07/29/12 14:24, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler i...@protected-networks.net wrote: Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( What was the previous version you booted and what's your configuration? Thanks, -Garrett I'm on an x86 core duo laptop with a single SATA disk split between Windoze-7 and FreeBSD. Nothing really special in the kernel config (as attached). The kernel from r238864 (yesterday) is working just fine, And if you go back to r238885...? Thanks! Boots just fine .. imb@toshi:/home/imb uname -a FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r238885: Sun Jul 29 14:44:58 EDT 2012 i...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 signature.asc Description: OpenPGP digital signature
Re: post SVN r238886 no boot?
On Sun, Jul 29, 2012 at 12:02 PM, Michael Butler i...@protected-networks.net wrote: On 07/29/12 14:39, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler i...@protected-networks.net wrote: On 07/29/12 14:24, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler i...@protected-networks.net wrote: Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( What was the previous version you booted and what's your configuration? Thanks, -Garrett I'm on an x86 core duo laptop with a single SATA disk split between Windoze-7 and FreeBSD. Nothing really special in the kernel config (as attached). The kernel from r238864 (yesterday) is working just fine, And if you go back to r238885...? Thanks! Boots just fine .. imb@toshi:/home/imb uname -a FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r238885: Sun Jul 29 14:44:58 EDT 2012 i...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 CCed mav@ because it appears to be fallout from r238886. Thanks! -Garrett ___ 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: post SVN r238886 no boot?
On 29.07.2012 22:04, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 12:02 PM, Michael Butler i...@protected-networks.net wrote: On 07/29/12 14:39, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 11:36 AM, Michael Butler i...@protected-networks.net wrote: On 07/29/12 14:24, Garrett Cooper wrote: On Sun, Jul 29, 2012 at 10:40 AM, Michael Butler i...@protected-networks.net wrote: Is anyone else having troubles getting -current after SVN r238886 to boot? In my case, I have an unstoppable stream of pager_something console messages :-( What was the previous version you booted and what's your configuration? Thanks, -Garrett I'm on an x86 core duo laptop with a single SATA disk split between Windoze-7 and FreeBSD. Nothing really special in the kernel config (as attached). The kernel from r238864 (yesterday) is working just fine, And if you go back to r238885...? Thanks! Boots just fine .. imb@toshi:/home/imb uname -a FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r238885: Sun Jul 29 14:44:58 EDT 2012 i...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 CCed mav@ because it appears to be fallout from r238886. Do you have any devices other then SATA disk? CD or some USB drive? Can you make at least any screenshot or tell something diagnostic about the problem? If there is chance to grab some output, could you set via the loader prompt variable kern.cam.dflags=0x41 and grab output after that? -- Alexander Motin ___ 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: RFC: libkern version of inet_ntoa_r
Hi,
On Sun, Jul 29, 2012 at 3:19 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
Remapping f(a) into f(a, b) requires both a macro
and a wrapping function, something like this
T __f(T1 a, T2 b) { return f(a, b); }
#define f(a) __f(a, b)
This can be done way more easily:
void fn(int a, int b)
{
printf(%d %d\n, a, b);
}
#define fn(x) ({ fn(x, 42); })
int main(int argc, char **argv)
{
fn(0);
return 0;
}
works just fine.
but i am not so interested in participating to the IOCCC :)
maybe you should ;-)
- Arnaud
ps: this construct is used all over the Linux kernel compatibility libraries.
___
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: post SVN r238886 no boot?
Hello, Alexander. You wrote 29 июля 2012 г., 23:15:06: AM Do you have any devices other then SATA disk? CD or some USB drive? ``Me too'' I have same problem on my net5501. IT is i386 (AMD GEODE) with CF card attached as IDE (not SATA) disk. I have no swap configured. AM Can you make at least any screenshot or tell something diagnostic about AM the problem? If there is chance to grab some output, could you set via AM the loader prompt variable kern.cam.dflags=0x41 and grab output after that? Attached log of booting without kern.cam.dflags=0x41 and with kern.cam.dflags=0x41 (two files), as I have serial console. To be honest, I can not spot the difference. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org bad-boot-no-cam-debug.txt.bz2 Description: Binary data bad-boot-with-cam-debug.txt.bz2 Description: Binary data ___ 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: post SVN r238886 no boot?
On 29.07.2012 22:52, Lev Serebryakov wrote: Hello, Alexander. You wrote 29 июля 2012 г., 23:15:06: AM Do you have any devices other then SATA disk? CD or some USB drive? ``Me too'' I have same problem on my net5501. IT is i386 (AMD GEODE) with CF card attached as IDE (not SATA) disk. I have no swap configured. I was able to diagnose problem and it is not related to CAM as I've thought initially. It is related to GEOM spoiling mechanism. During boot process fsck opens checked disks for writing, while root at that time mounted as read-only. Disks close by fsck causes spoiling of the root partition's GEOM VFS, that with r238886 change made it inaccessible. I've reverted that GEOM VFS change at r238892, that should fix the problem until better solution will be found. I'm sorry. -- Alexander Motin ___ 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: RFC: libkern version of inet_ntoa_r
On Sun, Jul 29, 2012 at 03:38:59PM -0400, Arnaud Lacombe wrote:
Hi,
On Sun, Jul 29, 2012 at 3:19 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
Remapping f(a) into f(a, b) requires both a macro
and a wrapping function, something like this
T __f(T1 a, T2 b) { return f(a, b); }
#define f(a) __f(a, b)
This can be done way more easily:
void fn(int a, int b)
{
printf(%d %d\n, a, b);
}
#define fn(x) ({ fn(x, 42); })
nice trick, one always learns something on these lists...
now i wonder how it works with MSVC (windows being one of the
other platforms where i need to build the ipfw+dummynet code...)
cheers
luigi
___
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: RFC: libkern version of inet_ntoa_r
Hello, Luigi.
You wrote 30 июля 2012 г., 0:47:21:
#define fn(x) ({ fn(x, 42); })
LR nice trick, one always learns something on these lists...
LR now i wonder how it works with MSVC (windows being one of the
LR other platforms where i need to build the ipfw+dummynet code...)
It looks very gcc-ish.
--
// Black Lion AKA Lev Serebryakov l...@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: post SVN r238886 no boot?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/12 16:13, Alexander Motin wrote: I was able to diagnose problem and it is not related to CAM as I've thought initially. It is related to GEOM spoiling mechanism. During boot process fsck opens checked disks for writing, while root at that time mounted as read-only. Disks close by fsck causes spoiling of the root partition's GEOM VFS, that with r238886 change made it inaccessible. I've reverted that GEOM VFS change at r238892, that should fix the problem until better solution will be found. I can confirm that this change avoids/fixes the issue - thanks :-) I'm sorry. No apology required - if I'm running -current, I should and do expect the occasional breakage. It's better found now than when it hits a wider release, i.e. I don't put -current on a production box .. imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAVqPAACgkQQv9rrgRC1JLfagCgzA7Rxtq7Sy4ps6CR0AaqDIvT Nh0AoKX+xn3KjEUjQy3SHWyA8vhvCSwe =65il -END PGP SIGNATURE- ___ 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: r238860: bsdtar: eating up 100% CPU, hanging
Am 07/29/12 19:19, schrieb Martin Matuska: Do you still have this problem after r238882? Dňa 28. 7. 2012 19:21 O. Hartmann wrote / napísal(a): When updating ports (like databases/sqlite3 or graphics/png via portmaster graphics/png), the installation process comes to a point where a backup of the old port is created with bsdtar. The process hangs then: === Starting build for graphics/png === === All dependencies are up to date === Creating a backup package for old version png-1.5.12 load: 1.38 cmd: bsdtar 99286 [running] 1301.04r 1296.34u 0.00s 100% 5656k And a look on top: last pid: 3365; load averages: 1.49, 1.44, 1.41 up 0+04:39:08 19:17:44 65 processes: 2 running, 63 sleeping CPU: 50.4% user, 0.0% nice, 1.0% system, 0.0% interrupt, 48.6% idle Mem: 521M Active, 3599M Inact, 3424M Wired, 32M Cache, 826M Buf, 323M Free ARC: 1970M Total, 672M MRU, 1224M MFU, 48K Anon, 46M Header, 28M Other Swap: 32G Total, 32G Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 99286 root 1 1030 71724K 5672K CPU11 24:10 100.00% bsdtar 1339 root 1 210 3221M 38008K select 1 3:02 1.71% Xorg 3364 ohartmann 28 200 634M 301M uwait 1 0:06 0.63% thunderbird 737 root 1 200 16520K 1492K select 0 0:42 0.00% moused 3286 ohartmann 22 200 681M 368M uwait 1 0:14 0.00% firefox 1469 ohartmann1 200 72364K 10612K select 1 0:05 0.00% xterm I can circumvent by doing a make reinstall in the port's directory, but this doesn't work for ports which copy files around using tar - like www/firefox and mail/thunderbird (which also get stuck when bsdtar is involved). My operating system is FreeBSD 10.0-CURRENT #0 r238860: Sat Jul 28 11:28:38 CEST 2012 buildworld and kernel from today's sources, ports seem to be up to date, I updated everything successfully before installing the new world which seems to be faulty. I also recompiled usr.bin/tar separately and installed it, but without success. What to do? regards, Oliver The specific problem has gone - bsdtar now performs well. But another issue occurs now: Ports like mail/thunderbird or www/firefox which seems to install using bsdtar, install files with weird access bits set: --xr-xr-x I need to adjust the access bits manually. I do not know whether this is also libarchive related. I did not investigate further due to time constraints. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: RFC: libkern version of inet_ntoa_r
Hi,
On Sun, Jul 29, 2012 at 4:30 PM, Lev Serebryakov l...@freebsd.org wrote:
Hello, Luigi.
You wrote 30 июля 2012 г., 0:47:21:
#define fn(x) ({ fn(x, 42); })
LR nice trick, one always learns something on these lists...
LR now i wonder how it works with MSVC (windows being one of the
LR other platforms where i need to build the ipfw+dummynet code...)
It looks very gcc-ish.
could you back your point with a technical argument, please ? This
sounds rather FUD'ish so far.
The ({ ... }) is nothing more than a primary-expression enclosing a
compound-statement; this part is not specifically necessary. As for
the expansion, I would assume the following part of iso9899:1999
applies:
6.10.3 Macro replacement
10
A preprocessing directive of the form
# define identifier lparen identifier-listopt ) replacement-list new-line
# define identifier lparen ... ) replacement-list new-line
# define identifier lparen identifier-list , ... ) replacement-list new-line
defines a function-like macro with arguments, similar syntactically to
a function call. [...] Each subsequent instance of the function-like
macro name followed by a ( as the next preprocessing token introduces
the sequence of preprocessing tokens that is replaced by the
replacement list in the definition (an invocation of the macro). The
replaced sequence of preprocessing tokens is terminated by the
matching ) preprocessing token, [...]
Note that the standard say Each subsequent, no All, so
fn(1, 2);
#define fn(a) fn(a, 2)
fn(1);
would produces:
fn(1, 2);
fn(1, 2);
I do not see any gcc'ism here.
Now, I might be wrong, and would enjoy being proven so.
Thanks,
- Arnaud
___
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 on boot after svn update
* Garrett Cooper yaneg...@gmail.com [2012-07-29 02:34 -0400]: See this thread: http://lists.freebsd.org/pipermail/freebsd-current/2012-July/035593.html Huh - apparently my SA was not at its highest yesterday... Thanks for the heads up! -- dave [ please don't CC me ] pgp9V1FHEuPMz.pgp Description: PGP signature
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
* Garrett Cooper yaneg...@gmail.com [2012-07-28 18:43 -0400]: On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe lacom...@gmail.com wrote: Close, but you missed a spot. The attached patch (based on your's) works, i.e. no longer panics at boot on my vbox instance. Thanks! FYI - The patch works for me as well, thank you! -- dave [ please don't CC me ] pgpj5dArvxxnE.pgp Description: PGP signature
