Re: Kernel dumps [was Re: possible changes from Panzura]
On 10 July 2013 19:07, Vincent Hoffman vi...@unsane.co.uk wrote: There was some work on something similar at one point, not sure what came of it. http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020164.html The code referenced there has been used in production since 2005 or so, and is based on an earlier implementation for FreeBSD 4.x that dates to 2000. Despite some shortcomings in the implementation it has proved quite reliable in practice. It hasn't made it into the tree yet for reasons raised in this thread. The primary issue is that it allocates mbufs in the packet sending path, and so relies on a number of kernel subsystems to be in a consistent state. It doesn't use the stack, routing table, or driver interrupt interfaces though. It could likely be made committable with a relatively small effort to switch to preallocating an mbuf+cluster or two at configuration time. More information is on the FreeBSD wiki, at https://wiki.freebsd.org/Netdump ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[PATCH] Install standalone debug files in /usr/lib/debug
Add a new knob WITH_DEBUG_FILES to control the building of standalone
debug files for userland programs and libraries. The -g debug flag
is automatically applied when WITH_DEBUG_FILES is set.
The debug files are now named ${prog}.debug and ${shlib}.debug for
consistency with other systems and documentation. In addition they are
installed under /usr/lib/debug, to simplify the process of installing
them if needed after a crash. Users of bsd.{prog,lib}.mk outside of the
base system place the standalone debug files in a .debug subdirectory.
GDB automatically searches both of these directories for standalone
debug files.
Thanks to everyone who contributed changes, review, and testing during
development.
---
Changes since previous version of the patch:
. some cleanup suggested by brooks@ and kib@
. separate debug tree into separate mtree file
. use new DEBUGMODE variable rather than BINMODE / LIBMODE, to avoid
suid or sgid debug files
Makefile.inc1 | 15
etc/Makefile| 6
etc/mtree/BSD.debug.dist| 48 +
etc/mtree/Makefile | 4 +++
gnu/usr.bin/gdb/Makefile.inc| 1 +
gnu/usr.bin/gdb/arch/amd64/config.h | 3 --
gnu/usr.bin/gdb/arch/arm/config.h | 3 --
gnu/usr.bin/gdb/arch/i386/config.h | 3 --
gnu/usr.bin/gdb/arch/ia64/config.h | 3 --
gnu/usr.bin/gdb/arch/mips/config.h | 3 --
gnu/usr.bin/gdb/arch/powerpc/config.h | 3 --
gnu/usr.bin/gdb/arch/powerpc64/config.h | 3 --
gnu/usr.bin/gdb/arch/sparc64/config.h | 3 --
gnu/usr.bin/gdb/gdb/Makefile| 1 +
share/mk/bsd.crunchgen.mk | 3 ++
share/mk/bsd.lib.mk | 37 +--
share/mk/bsd.own.mk | 10 ++
share/mk/bsd.prog.mk| 63 +
tools/build/options/WITH_DEBUG_FILES| 7
19 files changed, 178 insertions(+), 41 deletions(-)
create mode 100644 etc/mtree/BSD.debug.dist
create mode 100644 tools/build/options/WITH_DEBUG_FILES
diff --git a/Makefile.inc1 b/Makefile.inc1
index f09aa97..d65dd31 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -470,6 +470,13 @@ _worldtmp:
mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \
-p ${WORLDTMP}/usr/include /dev/null
ln -sf ${.CURDIR}/sys ${WORLDTMP}
+.if ${MK_DEBUG_FILES} != no
+ # We could instead disable debug files for these build stages
+ mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+ -p ${WORLDTMP}/legacy/usr/lib /dev/null
+ mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+ -p ${WORLDTMP}/usr/lib /dev/null
+.endif
.if ${MK_BIND_LIBS} != no
mtree -deU -f ${.CURDIR}/etc/mtree/BIND.include.dist \
-p ${WORLDTMP}/usr/include /dev/null
@@ -555,6 +562,10 @@ build32:
-p ${LIB32TMP}/usr /dev/null
mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \
-p ${LIB32TMP}/usr/include /dev/null
+.if ${MK_DEBUG_FILES} != no
+ mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+ -p ${LIB32TMP}/usr/lib /dev/null
+.endif
mkdir -p ${WORLDTMP}
ln -sf ${.CURDIR}/sys ${WORLDTMP}
.for _t in obj includes
@@ -779,6 +790,10 @@ distributeworld installworld: installcheck
installcheck_UGID
-p ${DESTDIR}/${DISTDIR}/${dist}/usr /dev/null
mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \
-p ${DESTDIR}/${DISTDIR}/${dist}/usr/include /dev/null
+.if ${MK_DEBUG_FILES} != no
+ mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+ -p ${DESTDIR}/${DISTDIR}/${dist}/usr/lib /dev/null
+.endif
.if defined(NO_ROOT)
${IMAKEENV} nmtree -C -f ${.CURDIR}/etc/mtree/BSD.root.dist | \
sed -e 's#^\./#./${dist}/#' ${METALOG}
diff --git a/etc/Makefile b/etc/Makefile
index c0806e8..f509a19 100644
--- a/etc/Makefile
+++ b/etc/Makefile
@@ -143,6 +143,9 @@ MTREE+= BIND.chroot.dist
MTREE+=BIND.include.dist
.endif
.endif
+.if ${MK_DEBUG_FILES} != no
+MTREE+=BSD.debug.dist
+.endif
PPPCNF=ppp.conf
@@ -312,6 +315,9 @@ MTREES= mtree/BSD.root.dist /
\
mtree/BSD.var.dist /var\
mtree/BSD.usr.dist /usr\
mtree/BSD.include.dist /usr/include
+.if ${MK_DEBUG_FILES} != no
+MTREES+= mtree/BSD.debug.dist/usr/lib
+.endif
.if ${MK_BIND_LIBS} != no
MTREES+= mtree/BIND.include.dist /usr/include
.endif
diff --git a/etc/mtree/BSD.debug.dist b/etc/mtree/BSD.debug.dist
new file mode 100644
index 000..ab75d0f
--- /dev/null
+++ b/etc/mtree/BSD.debug.dist
@@ -0,0 +1,48 @@
+# $FreeBSD$
+#
+# Please see the file src/etc/mtree/README before making changes to this file.
+#
+
+/set type=dir uname=root gname=wheel mode=0755
+.
+debug
+
Re: the Newcons Project
I would VERY much be able to have a console that looked like this in FreeBSD http://wiki.gentoo.org/images/7/7c/Bootsplash.png ... could someone with more understanding of this, be able to tell me if the Newcons project (when completed) is even going to do what i'm looking for? I'm not really sure what you're looking for, but I suspect newcons is orthogonal to it. Newcons won't change what is displayed, only how it is done; the primary user-facing advantages are Unicode support and better use of graphics modes. There are also some (very important) lower level infrastructural changes. -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files
On 22 December 2012 11:46, Ed Maste ema...@freebsd.org wrote: When this knob is set standalone debug files for shared objects are built and installed in /usr/lib/debug/so pathname.debug. GDB searches this path for debug data. I'm picking this up again - here is a new version of the patch, which should address the base/ports issue and other problems. Here's what it does: - Add WITH_DEBUG_FILES src.conf knob to control standalone debug file generation, instead of using standalone files whenever DEBUG_FLAGS is set. - Switch debug file extension from .symbols to .debug, for consistency with other users of this feature. - Store debug files under /usr/lib/debug for base system components, and in a .debug subdirectory for other share/mk consumers. - Switch gdb to use the default standalone debug directory of /usr/lib/debug. Also available at http://people.freebsd.org/~emaste/patches/shlib-debug-symbols.diff. Changes to bsd.prog.mk will come after. shlib-debug-symbols.diff Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NMI watchdog functionality on Freebsd
On 23 January 2013 11:57, Ian Lepore i...@freebsd.org wrote: But adding a real hardware watchdog that fires on a slightly longer timeout than the NMI watchdog gives you the best of everything: you get information if it's possible to produce it, and you get a real hardware reset shortly thereafter if producing the info fails. Yes, this is a great option if supported by hardware. Some Supermicro motherboards (like the X8STi) have two independent watchdogs, and one of them has a jumper to choose between NMI and reset upon expiry. In addition, the wbwd(4) driver has a sysctl to override the normal timeout to make the dual-stage watchdog possible: dev.wbwd.0.timeout_override This variable allows to program the timer to a value independent on the one provided by the watchdog(4) framework while still relying on the regular updates from e.g. watchdogd(8). This is particularly useful if your system provides multiple watchdogs and you want them to fire in a special sequence to trigger an NMI after a shorter period than the reset timeout for example. The value set must not be lower than the sleep time of watchdogd(8). A value of 0 disables this feature and the timeout value provided by watchdog(4) will be used. I hope this capability moves into the watchdog infrastructure rather than existing as a driver-specific kluge. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files
On 22 December 2012 23:13, Alfred Perlstein bri...@mu.org wrote: I have a patch for this. I am building world to see what happens, if you want to try it, or comment on it, please let me know. Changes are: base DEBUGDIR on LIBDIR for ports create intermediate directories for debug objs. Note that just moving ports debug data to /usr/local/lib/debug/... won't work since GDB won't search there. We could teach it to search a list of paths and include /usr/local/lib/debug and /usr/lib/debug, or perhaps a symlink under /usr/local/lib. We could also use a .debug subdirectory for ports and other users of bsd.lib.mk - so for example /usr/local/lib/libfoo.so would have debug info in /usr/local/lib/.debug/libfoo.so.debug. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files
When this knob is set standalone debug files for shared objects are built and installed in /usr/lib/debug/so pathname.debug. GDB searches this path for debug data. The -g flag is automatically added to CFLAGS if debug files are enabled (but the shared objects are still installed stripped, if DEBUG_FLAGS is not set). --- This is a refinement of my earlier change for shared object standalone debug. This patch also includes the following changes: - Change GDB's standalone debug file path to the default /usr/lib/debug. - Change debug file extension from 'symbols' to 'debug', in line with GDB's documentation. I initially followed the kernel build example in choosing .symbols, but .debug more accurately represents the use of these files. diff --git a/etc/mtree/BSD.usr.dist b/etc/mtree/BSD.usr.dist index 336d055..7b428d5 100644 --- a/etc/mtree/BSD.usr.dist +++ b/etc/mtree/BSD.usr.dist @@ -18,6 +18,22 @@ aout .. .. +debug +boot +.. +lib +geom +.. +.. +usr +lib +engines +.. +.. +lib32 +.. +.. +.. dtrace .. engines diff --git a/gnu/usr.bin/gdb/arch/amd64/config.h b/gnu/usr.bin/gdb/arch/amd64/config.h index ac81c54..ae3e104 100644 --- a/gnu/usr.bin/gdb/arch/amd64/config.h +++ b/gnu/usr.bin/gdb/arch/amd64/config.h @@ -440,7 +440,7 @@ #define PACKAGE gdb /* Global directory for separate debug files. */ -#define DEBUGDIR /usr/local/lib/debug +#define DEBUGDIR /usr/lib/debug /* Define to BFD's default architecture. */ #define DEFAULT_BFD_ARCH bfd_i386_arch diff --git a/gnu/usr.bin/gdb/arch/arm/config.h b/gnu/usr.bin/gdb/arch/arm/config.h index e1b128c..26b1891 100644 --- a/gnu/usr.bin/gdb/arch/arm/config.h +++ b/gnu/usr.bin/gdb/arch/arm/config.h @@ -452,7 +452,7 @@ #define PACKAGE gdb /* Global directory for separate debug files. */ -#define DEBUGDIR /usr/local/lib/debug +#define DEBUGDIR /usr/lib/debug /* Define to BFD's default architecture. */ #define DEFAULT_BFD_ARCH bfd_arm_arch diff --git a/gnu/usr.bin/gdb/arch/i386/config.h b/gnu/usr.bin/gdb/arch/i386/config.h index f21da4c..30e75c3 100644 --- a/gnu/usr.bin/gdb/arch/i386/config.h +++ b/gnu/usr.bin/gdb/arch/i386/config.h @@ -440,7 +440,7 @@ #define PACKAGE gdb /* Global directory for separate debug files. */ -#define DEBUGDIR /usr/local/lib/debug +#define DEBUGDIR /usr/lib/debug /* Define to BFD's default architecture. */ #define DEFAULT_BFD_ARCH bfd_i386_arch diff --git a/gnu/usr.bin/gdb/arch/ia64/config.h b/gnu/usr.bin/gdb/arch/ia64/config.h index 5faa96b..f8c84ab 100644 --- a/gnu/usr.bin/gdb/arch/ia64/config.h +++ b/gnu/usr.bin/gdb/arch/ia64/config.h @@ -440,7 +440,7 @@ #define PACKAGE gdb /* Global directory for separate debug files. */ -#define DEBUGDIR /usr/local/lib/debug +#define DEBUGDIR /usr/lib/debug /* Define to BFD's default architecture. */ #define DEFAULT_BFD_ARCH bfd_ia64_arch diff --git a/gnu/usr.bin/gdb/arch/mips/config.h b/gnu/usr.bin/gdb/arch/mips/config.h index 41a6731..01a7869 100644 --- a/gnu/usr.bin/gdb/arch/mips/config.h +++ b/gnu/usr.bin/gdb/arch/mips/config.h @@ -440,7 +440,7 @@ #define PACKAGE gdb /* Global directory for separate debug files. */ -#define DEBUGDIR /usr/local/lib/debug +#define DEBUGDIR /usr/lib/debug /* Define to BFD's default architecture. */ #define DEFAULT_BFD_ARCH bfd_mips_arch diff --git a/gnu/usr.bin/gdb/arch/powerpc/config.h b/gnu/usr.bin/gdb/arch/powerpc/config.h index f169fad..49472e7 100644 --- a/gnu/usr.bin/gdb/arch/powerpc/config.h +++ b/gnu/usr.bin/gdb/arch/powerpc/config.h @@ -440,7 +440,7 @@ #define PACKAGE gdb /* Global directory for separate debug files. */ -#define DEBUGDIR /usr/local/lib/debug +#define DEBUGDIR /usr/lib/debug /* Define to BFD's default architecture. */ #define DEFAULT_BFD_ARCH bfd_rs6000_arch diff --git a/gnu/usr.bin/gdb/arch/powerpc64/config.h b/gnu/usr.bin/gdb/arch/powerpc64/config.h index d8b9b6d..c904d1d 100644 --- a/gnu/usr.bin/gdb/arch/powerpc64/config.h +++ b/gnu/usr.bin/gdb/arch/powerpc64/config.h @@ -440,7 +440,7 @@ #define PACKAGE gdb /* Global directory for separate debug files. */ -#define DEBUGDIR /usr/local/lib/debug +#define DEBUGDIR /usr/lib/debug /* Define to BFD's default architecture. */ #define DEFAULT_BFD_ARCH bfd_rs6000_arch diff --git a/gnu/usr.bin/gdb/arch/sparc64/config.h b/gnu/usr.bin/gdb/arch/sparc64/config.h index 5527a79..ff87c28 100644 --- a/gnu/usr.bin/gdb/arch/sparc64/config.h +++ b/gnu/usr.bin/gdb/arch/sparc64/config.h @@ -440,7 +440,7 @@ #define PACKAGE gdb /* Global directory for separate debug files. */ -#define DEBUGDIR /usr/local/lib/debug +#define DEBUGDIR /usr/lib/debug /* Define to BFD's default architecture. */ #define DEFAULT_BFD_ARCH bfd_sparc_arch diff --git
Re: malloc+utrace, tracking memory leaks in a running program.
On 21 December 2012 22:37, Alfred Perlstein bri...@mu.org wrote: Is it time to start installing with some form of debug symbols? This would help us also with dtrace. I just posted a patch to add a knob to build and install standalone debug files. My intent is that we will build releases with this enabled, and add a base-dbg.txz distribution that contains the debug data for the base system, so that one can install it along with everything else, or add it later on when needed. We could perhaps teach dtrace to read its data from standalone .ctf files, or have it read DWARF directly and use the same debug files. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[PATCH] Shared library debug .symbols files
I've been working generating userland debugging symbols, with the goal
that we'll build them for each release. The user could install them
along with the system, or later on when needed for debugging. The
symbols files will also be useful for profiling and tools such as
Valgrind, without needing to build and install world first.
This patch enables .symbols files for shared libraries when DEBUG_FLAGS
is set. Future changes will be needed to address static libraries and
base system binaries, and the release build bits.
This is a different approach to the patches Mark Johnston posted to
-hackers about two years ago. I've followed the example of kmod.mk in
generating a .debug file which is split into the two components with
objcopy at build time. (Mark's patch overloaded strip to do it at
install time.)
Note that I used --strip-all and not --strip-debug, as the latter
results in duplication in the symtab and strtab between the shared lib
and its .symbols file.
diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk
index 2c96df1..6a1b476 100644
--- a/share/mk/bsd.lib.mk
+++ b/share/mk/bsd.lib.mk
@@ -34,14 +34,13 @@ NO_WERROR=
.endif
.if defined(DEBUG_FLAGS)
+OBJCOPY?= objcopy
CFLAGS+= ${DEBUG_FLAGS}
.if ${MK_CTF} != no ${DEBUG_FLAGS:M-g} !=
CTFFLAGS+= -g
.endif
-.endif
-
-.if !defined(DEBUG_FLAGS)
+.else
STRIP?=-s
.endif
@@ -173,14 +172,17 @@ SOLINKOPTS+= -Wl,--fatal-warnings
-Wl,--warn-shared-textrel
.endif
.if target(beforelinking)
-${SHLIB_NAME}: ${SOBJS} beforelinking
+${SHLIB_NAME}: beforelinking
+.endif
+.if defined(DEBUG_FLAGS)
+${SHLIB_NAME}.debug: ${SOBJS}
.else
${SHLIB_NAME}: ${SOBJS}
.endif
@${ECHO} building shared library ${SHLIB_NAME}
- @rm -f ${.TARGET} ${SHLIB_LINK}
+ @rm -f ${.SHLIB_NAME} ${SHLIB_LINK}
.if defined(SHLIB_LINK)
- @ln -fs ${.TARGET} ${SHLIB_LINK}
+ @ln -fs ${.SHLIB_NAME} ${SHLIB_LINK}
.endif
.if !defined(NM)
@${CC} ${LDFLAGS} ${SSP_CFLAGS} ${SOLINKOPTS} \
@@ -194,6 +196,15 @@ ${SHLIB_NAME}: ${SOBJS}
.if ${MK_CTF} != no
${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${SOBJS}
.endif
+
+.if defined(DEBUG_FLAGS)
+${SHLIB_NAME}: ${SHLIB_NAME}.debug ${SHLIB_NAME}.symbols
+ ${OBJCOPY} --strip-all --add-gnu-debuglink=${SHLIB_NAME}.symbols\
+ ${SHLIB_NAME}.debug ${.TARGET}
+
+${SHLIB_NAME}.symbols:
+ ${OBJCOPY} --only-keep-debug ${SHLIB_NAME}.debug ${.TARGET}
+.endif
.endif
.if defined(INSTALL_PIC_ARCHIVE) defined(LIB) !empty(LIB)
${MK_TOOLCHAIN} != no
@@ -270,6 +281,11 @@ _libinstall:
${INSTALL} ${STRIP} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
${_INSTALLFLAGS} ${_SHLINSTALLFLAGS} \
${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}
+.if defined(DEBUG_FLAGS)
+ ${INSTALL} -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
+ ${_INSTALLFLAGS} ${_SHLINSTALLFLAGS} \
+ ${SHLIB_NAME}.symbols ${DESTDIR}${SHLIBDIR}
+.endif
.if defined(SHLIB_LINK)
# ${_SHLIBDIRPREFIX} and ${_LDSCRIPTROOT} are both needed when cross-building
# and when building 32 bits library shims. ${_SHLIBDIRPREFIX} is the directory
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Shared library debug .symbols files
On 13 December 2012 13:54, Konstantin Belousov kostik...@gmail.com wrote: On Thu, Dec 13, 2012 at 04:08:47PM +, Ed Maste wrote: ... This patch enables .symbols files for shared libraries when DEBUG_FLAGS is set. Future changes will be needed to address static libraries and base system binaries, and the release build bits. You cannot strip static libraries, at least if you want the result to be useful for the consequent use. Right, presumably I can use --strip-debug on static libraries and not --strip-all (assuming that objcopy still leaves the required parts). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Running kgdb in batch mode.
On 26 November 2012 01:21, Sushanth Rai sushanth_...@yahoo.com wrote: Basically I would like to get kernel backtrace of a bunch of threads from the live kernel under some conditions. When the condition is seen I would like to run kgdb, collect kernel backtrace of specific threads and exit. Is there a way run kgdb in batch mode ? Or any other way to get the stack trace. Have a look at /usr/sbin/crashinfo for an example of how to do so - basically just run kgdb $KERNEL $VMCORE commands_file. -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
tftpd: avoid logging error for pxeboot option negotiation?
After upgrading a diskless boot server from FreeBSD 6 to 8 I see an error message logged each time a diskless client boots: Feb 20 00:56:38 TPC-D4-35 tftpd[55229]: Got ERROR packet: TFTP Aborted It turns out that the pxeboot client (from Intel) first performs a TFTP read request with the tsize option to which it receives an acknowledgement containing the size of the file to be transferred. Then it sends back an error response to abort the transfer, and sends the read request again (without the tsize option). The sequence of packets is: 1. C-S TFTP Read Request, File: pxeboot, Transfer type: octet, tsize=0 2. S-C TFTP Option Acknowledgement, tsize=239616 3. C-S TFTP Error Code, Code: Not defined, Message: TFTP Aborted 4. C-S TFTP Read Request, File: pxeboot, Transfer type: octet, blksize=1456 5. S-C TFTP Option Acknowledgement, blksize=1456 6. C-S TFTP Acknowledgement, Block: 0 7. S-C TFTP Data Packet, Block: 1 ... I'd like to avoid logging the error here, for the sake of this pxeboot client and any other tftp clients that might check options without actually starting a transfer. Anyone opposed to removing it? (A proposed patch is at http://people.freebsd.org/~emaste/tftpd.diff). -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: tftpd: avoid logging error for pxeboot option negotiation?
On Mon, Feb 20, 2012 at 03:39:59PM -0500, Alexander Kabaev wrote:
IIRC, PXE sends an error packet with zero error code. Could you supress
the error message in that case and avoid propagation of the 'ignore
error' flag?
PXE client is not alone doing that - custom TFTP
implementation in pxeloader does that as well now, so suppressing errors
in this case is a good idea.
Thanks for the suggestion, that makes a much simpler patch:
Index: tftp-io.c
===
--- tftp-io.c (revision 231851)
+++ tftp-io.c (working copy)
@@ -463,7 +463,8 @@
}
if (pkt-th_opcode == ERROR) {
- tftp_log(LOG_ERR, Got ERROR packet: %s, pkt-th_msg);
+ tftp_log(pkt-th_code == EUNDEF ? LOG_DEBUG : LOG_ERR,
+ Got ERROR packet: %s, pkt-th_msg);
return (RP_ERROR);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Parallels v4 regression (aka ada(4) oddity) in RELENG_9
On Mon, Jan 23, 2012 at 10:32:59AM -0800, Garrett Cooper wrote: It's better to be methodical and delete all of the partitions and create the table from scratch. I've run into reproducible cases in the past where just doing gpart destroy -F for instance [on 9.0-BETA1+ media] didn't work because geom retasted the partition tables and slices. Do you have the reproduction steps documented somewhere (and if not, can you write them up)? In order to have working automated installs we need to be able to unconditionally reinit a drive w/o having behavoiur depend on what happens to be left behind. -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] __FreeBSD_kernel__
On Tue, Jul 05, 2011 at 02:05:27PM -0400, Alexander Kabaev wrote: I agree with all of the above reasons, but none of them change the fact that __linux__ is used left and right to identify both kernel and userland environments just as __FreeBSD__ is. You choose to disable __FreeBSD__ in GNU/kFreeBSD presumably because it makes your life porting software easier and are asking FreeBSD project to cope with the decision. This breaks compiles of new software with older compilers than do not define the macro, takes __FreeBSD__ out of symmetry with __linux__ and other similarly defined platform macros and forces a race to update every other compiler out there to follow the suit. I fail to see the benefits out-weighting the drawbacks in this scenario. There are two separate issues here - the macro itself, and where it's defined. On the topic of the macro itself, __FreeBSD__ implies something about the kernel and the libc, and it used to be the same case for __linux__. This became broken for __linux__ once people started combining a Linux kernel with other than glibc, and it would break if those combining the FreeBSD kernel with another libc defined __FreeBSD__. (A note on terminology - some may dislike the GNU/ name for various reasons, but either way their project is properly called Debian GNU/kFreeBSD. I'll refer to it as kFreeBSD here for brevity though, since the kFreeBSD part is the unique aspect of this project vs other Debian ports, and the full name is rather awkward to type.) kFreeBSD can't define __FreeBSD__, since it will break any existing software that uses that to infer something about the libc in use. So, that project had a choice; they could have created a new macro __Debian_GNU_kFreeBSD__, say, that indicates the kernel and libc in use. However, defining __FreeBSD_kernel__ (and __glibc__ presumably) makes more sense, and actually reduces the porting effort for both them and the FreeBSD porters. Any effort on porting software to the FreeBSD kernel done by either project is then applicable to the other. If kFreeBSD project members make a change to get some piece of software working on a FreeBSD kernel and then gets that change commited upstream we can take advantage of that work without any additional effort on our part. On the topic of where such a macro should be defined I originally had no strong opinion. However, valid points have been raised about compiling software for FreeBSD using compilers that are not the one in the base system (from ports or otherwise, and GCC or otherwise). This I think is a very valid point and one that would make me lean towards defining the macro in sys/param.h. How workable is it to #include sys/param.h to pick up the macro where needed? -Ed Maste ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] __FreeBSD_kernel__
On Sun, Jul 03, 2011 at 12:45:12PM -0700, Julian Elischer wrote: On 7/3/11 7:35 AM, Alexander Kabaev wrote: __linux__ is exactly what __FreeBSD__ is and dies not identify kernel but rather Linux as whole OS, whatever that might be these days. There does not appear to be an universal macro that identifies environment as using Linux kernel regardless of the rest of components used (say, to identify Android and Ubuntu or something embedded with ucLibc as running Linux kernel with different userland implementations). I thought it was (__linux__ __KERNEL__) I corresponded with Julian off-list, but for the sake of the archives I'll summarize here. This is not correct because __KERNEL__ is used for code or header files to detect that they are targetting the kernel (e.g., a device driver) while what we're looking for here is a macro for userland code to detect that it is being compiled to run _on_ a given kernel (Linux or FreeBSD). -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] __FreeBSD_kernel__
On Sat, Jul 02, 2011 at 07:37:24PM -0400, Alexander Kabaev wrote: On Sat, 2 Jul 2011 17:41:03 +0200 Robert Millan r...@debian.org wrote: My request is that FreeBSD also defines __FreeBSD_kernel__. If this happens, life would be made a bit easier on both sides, as it'd be more natural for porters of either system to support both using a single macro [1]. I think this is a good idea, especially if it means that a single change can make it into upstream projects to support both FreeBSD and Debian kFreeBSD. I do not think this belongs in GCC at all. You should already have a defined symbol to identify your OS and that should be used in cases where it matters. I suspect the proposed patch put it in GCC based on the fact that we already have __FreeBSD__ in contrib/gcc/config/freebsd-spec.h: builtin_define_with_int_value (__FreeBSD__, FBSD_MAJOR); \ Alternatively, you should provide the symbol in similar way in which we provide __FreeBSD_version, through well-known header like sys/param.h and not pollute GCC. I suspect this is probably a reasonable alternative, but may mean software will have to pick up an additional #include. Out of curiosity, what is the canonical way for software to identify a Linux kernel -- __linux__ or some variant? Where is it defined? Regards, Ed Maste ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Keeping /etc/localtime up-to-date
On Sun, Mar 27, 2011 at 03:27:32PM -0700, David Wolfskill wrote: There are other ways to do it, of course -- e.g., the first time the utility is run, it could actually ask, but then cache the information in some place so it could look there first (and if it finds a cached answer, avoid asking again unless it's told to ignore the cache -- as might be reasonable if the machine is moved to a different time zone. That's what tzsetup does in HEAD - the name of the selected timezone file is stored in /var/db/zoneinfo, and tzsetup -r can be used to copy in an updated file: -r Reinstall the zoneinfo file installed last time. The name is obtained from /var/db/zoneinfo. It looks like this hasn't been MFC'd, although I'm not sure why. The change came in from svn rev 198267 by edwin (CC'd). -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Userland debug symbols directory
On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: I like the idea a lot, but why not to leave symbol files in /usr/obj, The application where this is most useful (and why we implemented it originally) is the case where /usr/obj isn't available - for instance, a binary installation other than where the source tree was built. If you're going to keep /usr/obj around anyway then you can get most of the benefit by just keeping the unstripped binaries / libs in there, no? -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Userland debug symbols directory
On Sat, Nov 06, 2010 at 07:56:03PM +0200, Kostik Belousov wrote: On Sat, Nov 06, 2010 at 01:36:20PM -0400, Ed Maste wrote: On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: I like the idea a lot, but why not to leave symbol files in /usr/obj, The application where this is most useful (and why we implemented it originally) is the case where /usr/obj isn't available - for instance, a binary installation other than where the source tree was built. If you're going to keep /usr/obj around anyway then you can get most of the benefit by just keeping the unstripped binaries / libs in there, no? Not that easy, since you have to arrange to use libraries from obj/, by LD_LIBRARY_PATH etc. I fully support the work to install symbol files, and it should go into /usr, might be /usr/lib/debug. Possibly, some change to gdb (config) is required. Yeah, I just mean that using LD_LIBRARY_PATH or whatever is still a lot easier than realizing you don't have the debug info at all, and trying to rebuild an identical binary or library with debug. I definitely want the changes to build and install the symbol files in the FreeBSD tree. I don't have a huge concern over the exact path we pick. -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Generating userland debugging symbols
On Fri, Oct 29, 2010 at 09:58:26PM -0400, Mark Johnston wrote: On Sat, Oct 30, 2010 at 02:39:00AM +0300, Kostik Belousov wrote: I do think that something like this would be useful. But, shouldn't the DEBUG_FLAGS be also involved in the patch ? The goal would be to have debug symbols for userland staff. esp. the libraries, handled in a similar manner to kernel symbols. But I do like the intent of keeping the symbols in the separate directory. Yes, you're right. What I would probably do is have make(1) set DEBUG_FLAGS=-g automatically if WITH_DEBUG_SYMBOLS is defined in /etc/src.conf. I've been using the source tree at my work, which has another Makefile and some other scripts on top of the FreeBSD build system, so they're probably doing some things I don't know about. Based on what I've seen however, it shouldn't be too much work to port the necessary changes over. Ahh yes, the way it was being done (before the change to build .symbols files) is that the buildworld was done using a make.conf with DEBUG_FLAGS=-g while the installworld omitted it; the /usr/obj tree then had the debug information but the installed binaries and libraries did not. It looks like the .symbols change built on top of this. -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Cygwin termcap entry
I'd like to replace our termcap entry for cygwin with either one taken from /etc/termcap on a Cygwin system, as in the patch below, or maybe with the one from http://catb.org/esr/terminfo/termtypes.tc.gz. Any comments? -Ed Patch for Cygwin-provided entry: Index: share/termcap/termcap.src === --- share/termcap/termcap.src (revision 213890) +++ share/termcap/termcap.src (working copy) @@ -4580,8 +4580,26 @@ linux-m|Linux Console no color:\ :pa@:Co@:AF@:AB@:op@:\ :tc=linux: -cygwin:\ - :xn@:op=\E[39;49m:Km=\E[M:tc=linux: +cygwin|ansi emulation for Cygwin:\ + :am:hs:mi:ms:xo:\ + :Co#8:it#8:pa#64:\ + :7=^Z:@7=\E[4~:AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:\ + :DL=\E[%dM:DO=\E[%dB:F1=\E[23~:F2=\E[24~:F3=\E[25~:\ + :F4=\E[26~:F5=\E[28~:F6=\E[29~:F7=\E[31~:F8=\E[32~:\ + :F9=\E[33~:FA=\E[34~:IC=\E[%d@:K2=\E[G:LE=\E[%dD:\ + :RI=\E[%dC:S2=\E[11m:S3=\E[10m:UP=\E[%dA:al=\E[L:bl=^G:\ + :cb=\E[1K:cd=\E[J:ce=\E[K:ch=\E[%i%dG:cl=\E[H\E[J:\ + :cm=\E[%i%d;%dH:cr=^M:cv=\E[%i%dd:dc=\E[P:dl=\E[M:do=\E[B:\ + :ec=\E[%dX:ei=\E[4l:fs=^G:ho=\E[H:ic=\E[@:im=\E[4h:\ + :k1=\E[[A:k2=\E[[B:k3=\E[[C:k4=\E[[D:k5=\E[[E:k6=\E[17~:\ + :k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:kD=\E[3~:\ + :kI=\E[2~:kN=\E[6~:kP=\E[5~:kb=\177:kd=\E[B:kh=\E[1~:\ + :kl=\E[D:kr=\E[C:ku=\E[A:le=^H:md=\E[1m:me=\E[0m:mk=\E[8m:\ + :mr=\E[7m:nd=\E[C:nw=^M^J:op=\E[39;49m:r1=\Ec\E]R:rc=\E8:\ + :sc=\E7:se=\E[27m:sf=^J:so=\E[7m:sr=\EM:ta=^I:\ + :te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ts=\E];:\ + :u6=\E[%i%d;%dR:u7=\E[6n:u8=\E[?6c:u9=\E[c:ue=\E[24m:\ + :up=\E[A:us=\E[4m: # Multilingual Sysinstall (kon2 console) # HOSOKAWA, Tatsumi (hosok...@freebsd.org) kons25x|kons25-euc:\ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Cygwin termcap entry
On Fri, Oct 15, 2010 at 03:09:11PM -0430, Andres Perera wrote: On Fri, Oct 15, 2010 at 1:15 PM, Ed Maste ema...@freebsd.org wrote: I'd like to replace our termcap entry for cygwin with either one taken from /etc/termcap on a Cygwin system, as in the patch below, or maybe with the one from http://catb.org/esr/terminfo/termtypes.tc.gz. Any comments? The problem is that it _does_ share capabilities with linux, so don't get rid of tc=linux. The one from catb.org has tc=ansi.sys instead; just because there are a common subset of capabilities doesn't necessarily imply that it should use tc=, in my opinion. Does it share capabilities with Linux because it is based on some code in Linux? -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why is TUNABLE_INT discouraged?
On Sun, Aug 08, 2010 at 01:30:19AM +0200, Ivan Voras wrote: 2010/8/8 Dag-Erling Sm??rgrav d...@des.no: Garrett Cooper gcoo...@freebsd.org writes: Dag-Erling Sm??rgrav d...@des.no writes: Perhaps. ??I don't remember all the details; I can't find a discussion in the list archives (other than me announcing the change in response to a bug report), but there must have been one, either on IRC or in Karlsruhe. In any case, I never removed TUNABLE_INT(), so... It does matter for integers on 64-bit vs 32-bit architectures though, right Not sure what you mean. ??The original issue was that someone had used TUNABLE_INT() for something that was actually a memory address. ??I changed it to TUNABLE_ULONG(). ??Of course, if your tunable is a boolean value or something like maxprocs, an int is fine - but so is a long. Semantically valid but using TUNABLE_INT to hold pointers is a developer bug, not the fault of the API, and there's nothing wrong with int as a data type in this context. I agree with Ivan here. If we can't find an actual reason to universally prefer long I'd like to remove this comment. As a counterpoint to the preference for long I can offer a reason to prefer int: the same variable is often exposed by both a tunable and a sysctls, and a sysctl using long can have 32-bit compat issues. (That is, a 32-bit app using sysctlbyname will try to use 4 bytes for a long.) -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: svn commit: r210561 - projects/sv/sys/net
On Wed, Jul 28, 2010 at 03:10:31PM +, Attilio Rao wrote: Log: Initial import of the netdump files. They still need a lot of polishing and cleanup so they might not be considered definitive at all. This code is a port to recent FreeBSD of Darrell Anderson's network crashdump support, which was done in the 4.x days. I can't find a current website with the original versions but archive.org has a cache of course: http://web.archive.org/web/20041204223729/http://www.cs.duke.edu/~anderson/freebsd/netdump/ Quoting from the old readme: Netdump provides FreeBSD kernel crash dumping over the network. Netdump is a FreeBSD kernel module client and user-level server. A normal kernel crash writes a raw dump of memory to a dedicated partition (usually the swap partition) using a low-level disk routine, and then copies that raw dump into a file (via savecore) during the following boot process. Netdump replaces the standard dump routine. During a crash, a netdump client broadcasts to locate a netdump server, then sends the dump as UDP/IP packets (with retransmission after loss). The netdump server creates a dump file suitable for gdb. If netdump fails (for example, no netdump server is located), a normal disk dump is performed. There is cleanup work to be done still, but we plan to have this in shape for 9.0. -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [problem] aac0 does not respond
2009/3/24 Vladimir Ermakov samflan...@gmail.com: Hello, All Describe my problem: have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 2 HHD of 6 have errors in smart data (damaged) i am try read file /var/db/mysql/ibdata1 from this volume system does not respond ( lost access to ssh ) after read 6GB data from this file and print debug messages on ttyv0 If the messages you see are the same as in the message to which you provided a link (COMMAND xxx TIMED OUT AFTER xxx SECONDS) it typically means that the RAID controller has crashed. My initial suggestion is to check the firmware version installed on your card, and update to the latest from Adaptec's website if you're not running that one already. Attilio also has some driver updates (ported from Adaptec's latest vendor driver) that you can try. The plan is to commit them sometime soon, but he can forward those on for testing before that happens. -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Acquiring a mtx after an sx lock
On Mon, Aug 18, 2008 at 11:38:40AM -0700, Julian Elischer wrote: Ed Maste wrote: Ahh, it seems ups' commit of rmlocks changed the You have: sx_lock, You want: Slp_mtx case from no to ok (in r173444). Ignore me.. I was reading the table backwards.. of course if you have an sx you can still take out a mutex, but not visa versa. Yep, and ups' r173444 change didn't affect this at all, it just corrected the table. If I don't hear otherwise I'll merge the changes to the table to 7 sometime soon: You have: You want: Spin_mtx Slp_mtx sx_lock rw_lock sleep - SPIN mutex ok no no no no-3 + SPIN mutex ok-1 no no no no-3 Sleep mutex ok ok-1no ok no-3 - sx_lock ok no ok-2no ok-4 + sx_lock ok ok ok-2ok ok-4 rw_lock ok ok no ok-2no-3 Have SPIN / want SPIN adds the Recursion is defined per lock footnote. Have sx / want Slp have sx / want rw change from no to ok. - Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acquiring a mtx after an sx lock
On Mon, Aug 18, 2008 at 12:02:56PM -0400, Ryan Stone wrote: On Mon, Aug 18, 2008 at 11:54 AM, Max Laier [EMAIL PROTECTED] wrote: On Monday 18 August 2008 17:14:01 Ryan Stone wrote: Are there any problems acquiring a sleep mutex after acquiring an sx lock? man 9 locking says that you can't, but doesn't provide any reasons. [...] Where does it say so? The interaction table clearly shows: [...] Ahh, it seems ups' commit of rmlocks changed the You have: sx_lock, You want: Slp_mtx case from no to ok (in r173444). -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kgdb info threads and proc / thread names
I noticed kgdb's info threads is a little less useful after kernel
threads have been changed to share a proc:
8 Thread 17 (PID=12: intr) fork_trampoline
7 Thread 16 (PID=12: intr) sched_switch
6 Thread 15 (PID=12: intr) sched_switch
The attached patch outputs both the proc's p_comm and the thread's
td_name, like so:
8 Thread 17 (PID=12: intr/swi3: vm)
7 Thread 16 (PID=12: intr/swi4: clock sio)
6 Thread 15 (PID=12: intr/swi1: net)
Any comments on the format (p_comm/td_name) or the patch?
I'd like to do something similar with top, as right now for threaded
apps you just get {initial thread} in the COMMAND column. I'd like
to display something like artsd/initial thread instead.
-Ed
Index: kthr.c
===
RCS file: /usr/cvs/src/gnu/usr.bin/gdb/kgdb/kthr.c,v
retrieving revision 1.8
diff -p -u -r1.8 kthr.c
--- kthr.c 16 Nov 2007 22:17:37 - 1.8
+++ kthr.c 17 Jan 2008 21:24:48 -
@@ -36,6 +36,7 @@ __FBSDID($FreeBSD$);
#include kvm.h
#include stdio.h
#include stdlib.h
+#include string.h
#include defs.h
#include frame-unwind.h
@@ -206,15 +207,25 @@ kgdb_thr_extra_thread_info(int tid)
{
struct kthr *kt;
struct proc *p;
- static char comm[MAXCOMLEN + 1];
+ struct thread *t;
+ char comm[MAXCOMLEN + 1];
+ char td_name[MAXCOMLEN + 1];
+ static char info[MAXCOMLEN + 1 + MAXCOMLEN + 1];
kt = kgdb_thr_lookup_tid(tid);
if (kt == NULL)
return (NULL);
p = (struct proc *)kt-paddr;
+ t = (struct thread *)kt-kaddr;
if (kvm_read(kvm, (uintptr_t)p-p_comm[0], comm, sizeof(comm)) !=
sizeof(comm))
return (NULL);
-
- return (comm);
+ if (kvm_read(kvm, (uintptr_t)t-td_name[0], td_name,
+sizeof(td_name)) != sizeof(td_name))
+ td_name[0] = '\0';
+ if (td_name[0] != '\0' strcmp(comm, td_name) != 0)
+ snprintf(info, sizeof(info), %s/%s, comm, td_name);
+ else
+ strlcpy(info, comm, sizeof(info));
+ return (info);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: config(8) patch for review for src dir handling
On Sun, Dec 23, 2007 at 10:40:39AM +0100, Dag-Erling Sm??rgrav wrote: Ed Maste [EMAIL PROTECTED] writes: Right now config(8) calls realpath(../.., ... to find the src path to write into the kernel Makefile. I want to change this to use $PWD with the last two path components removed, assuming it's the same dir as ../.. . I'm worried that your patch assumes that $PWD is present and correct, for which there is no guarantee. What happens if you use getcwd() instead of getenv(PWD)? The patch assumes neither; it checks for $PWD and verifies that the dir obtained by removing the last two components is the same as that provided by realpath(../.. . If $PWD is not set, or the path based on it is not correct, it falls back to the current behaviour -- the path returned by realpath(../.. . Getcwd doesn't give the desired behaviour since, like realpath, it returns the physical directory. -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
config(8) patch for review for src dir handling
I've attached a patch I'd like to commit to config(8) for the way it
handles get_srcdir. I'm asking for review since it partially reverts
some changes made in revision 1.42 of usr.sbin/config/main.c and I'd
like to make sure there are no issues there.
Right now config(8) calls realpath(../.., ... to find the src path
to write into the kernel Makefile. I want to change this to use $PWD
with the last two path components removed, assuming it's the same dir
as ../.. .
I want to put this in because I often build from an amd(8)-mounted src
tree, and realpath produces a path using amd's special temporary mount
directory /.amd_mnt/... instead of the intended /host_mounts/... type of
path and it times out when accessed that way. Using the logical cwd
means that the generated Makefile references /host_mounts/... and amd
knows the mount is still in use when building.
Comments?
-Ed
Index: main.c
===
RCS file: /usr/cvs/src/usr.sbin/config/main.c,v
retrieving revision 1.76
diff -p -u -r1.76 main.c
--- main.c 17 May 2007 04:53:52 - 1.76
+++ main.c 18 Dec 2007 21:02:32 -
@@ -249,9 +249,30 @@ main(int argc, char **argv)
static void
get_srcdir(void)
{
+char *pwd;
if (realpath(../.., srcdir) == NULL)
errx(2, Unable to find root of source tree);
+
+ if ((pwd = getenv(PWD)) != NULL *pwd == '/'
+ (pwd = strdup(pwd))) {
+ struct stat lg, phy;
+ int i;
+ char *p;
+
+ /* remove last two path components */
+ for (i = 0; i 2; i++) {
+ if ((p = strrchr(pwd, '/')) == NULL) {
+ free(pwd);
+ return;
+ }
+ *p = '\0';
+ }
+ if (stat(pwd, lg) != -1 stat(srcdir, phy) != -1
+lg.st_dev == phy.st_dev lg.st_ino == phy.st_ino)
+ strlcpy(srcdir, pwd, MAXPATHLEN);
+ free(pwd);
+ }
}
static void
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hung kernel from sysv semaphore semu_list corruption
On Thu, Mar 08, 2007 at 10:55:22AM +0100, Divacky Roman wrote:
this is wrong.. you cannot remove element from a *LIST when its iterated
using *LIST_FOREACH.
Use *LIST_FOREACH_SAFE instead...
We're not freeing the item in the loop so it would work unless
QUEUE_MACRO_DEBUG is turned on to intentionally trash the link
pointer on _REMOVE. You're right though it's not the correct approach.
There's an efficiency issue with the previous patch anyhow in that
SLIST_REMOVE walks the list again to find the element to remove.
How about the patch below instead:
Index: sysv_sem.c
===
RCS file: /usr/cvs/src/sys/kern/sysv_sem.c,v
retrieving revision 1.85
diff -u -r1.85 sysv_sem.c
--- sysv_sem.c 22 Oct 2006 11:52:13 - 1.85
+++ sysv_sem.c 8 Mar 2007 14:22:43 -
@@ -1301,8 +1301,10 @@
*/
SEMUNDO_LOCK();
SLIST_FOREACH_PREVPTR(suptr, supptr, semu_list, un_next) {
- if (suptr-un_proc == p)
+ if (suptr-un_proc == p) {
+ *supptr = SLIST_NEXT(suptr, un_next);
break;
+ }
}
SEMUNDO_UNLOCK();
@@ -1362,8 +1364,9 @@
* Deallocate the undo vector.
*/
DPRINTF((removing vector\n));
+ SEMUNDO_LOCK();
suptr-un_proc = NULL;
- *supptr = SLIST_NEXT(suptr, un_next);
+ SEMUNDO_UNLOCK();
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Hung kernel from sysv semaphore semu_list corruption
Nightly tests on our 6.1-based installation using pgsql have resulted in
a number of kernel hangs, due to a corrupt semu_list (the list ended up
with a loop).
It seems there are a few holes in the locking in the semaphore code. The
issue we've encountered comes from semexit_myhook. It obtains a pointer
to a list element after acquiring SEMUNDO_LOCK, and after dropping the
lock manipulates the next pointer to remove the element from the list.
The fix below solves our current problem. Any comments?
--- RELENG_6/src/sys/kern/sysv_sem.cTue Jun 7 01:03:27 2005
+++ swbuild_plt_boson/src/sys/kern/sysv_sem.c Tue Mar 6 16:13:45 2007
@@ -1259,16 +1259,17 @@
struct proc *p;
{
struct sem_undo *suptr;
- struct sem_undo **supptr;
/*
* Go through the chain of undo vectors looking for one
* associated with this process.
*/
SEMUNDO_LOCK();
- SLIST_FOREACH_PREVPTR(suptr, supptr, semu_list, un_next) {
- if (suptr-un_proc == p)
+ SLIST_FOREACH(suptr, semu_list, un_next) {
+ if (suptr-un_proc == p) {
+ SLIST_REMOVE(semu_list, suptr, sem_undo, un_next);
break;
+ }
}
SEMUNDO_UNLOCK();
@@ -1328,8 +1329,9 @@
* Deallocate the undo vector.
*/
DPRINTF((removing vector\n));
+ SEMUNDO_LOCK();
suptr-un_proc = NULL;
- *supptr = SLIST_NEXT(suptr, un_next);
+ SEMUNDO_UNLOCK();
}
static int
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A New FreeBSD Server
On Mon, Jun 26, 2006 at 10:10:28AM -0400, Mike Meyer wrote: In [EMAIL PROTECTED], Dmitry Morozovsky [EMAIL PROTECTED] typed: On Sat, 24 Jun 2006, Mike Meyer wrote: MM The other constraint on swap is that if you want the system to save a MM core dump if it panics, you need a device to dump on that's 64Kb MM bigger than ram. That's one device, not all of swap. This is not quite true, as there always are some unused memory regions, hence you need not add 64k to RAM size. At least, I had no trouble using swap == RAM for last 5 years or so... Or memory areas that aren't needed when doing the post mortem. The question is, how do you guarantee that those are what's not going to make it out to the dump device? The core dump routine won't even attempt to write if the swap space is too small, so there's no ambiguity as to what makes it into the core file. FreeBSD 5.x and previous try to write all of memory out so the extra 64Kb or so is necessary. Also, -CURRENT uses minidumps on i386 and amd64, so only memory regions of use are written out and you can get by with swap smaller than RAM. -ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [RFC][patch] dhclient Classless Static Routes support
On Mon, Jun 19, 2006 at 09:26:12PM -0700, Brooks Davis wrote: On Sun, Jun 18, 2006 at 01:12:22PM +0400, Andrey V. Elsukov wrote: Hi! I have implemented RFC3442 support for the FreeBSD dhclient. Patch can be fetched from http://butcher.heavennet.ru/patches/other/dhclient/ I have a small bit of testing with isc-dhcpd and dnsmasqd. And i think it works fine. I have tested with: 1) Normal classless routes: 10.0.0.0/21 router, 10.1.0.0/19 router 2) default route 3) link routes: 192.168.0.0/24 0.0.0.0, 192.168.1.0/24 0.0.0.0 I don't know what i should make with incorrect data received from DHCP server.. At a glance I don't see any major issues. I won't have time to do anything more with it for at least a couple weeks. I'd suggest filing a PR with it to ensure it isn't lost. Ed, if you're interested in it, feel free to commit. Hi Brooks. I'll be testing this out shortly and plan to commit it soon. One question I had for you was how we want to handle dhclient with respect to OpenBSD -- I seem to recall that we've decided to own our dhclient after the import. So it would be advantageous if OpenBSD decides to take the patch, but not necessary. -ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Polling for devices other than NICs [patch]
On Sat, Jan 07, 2006 at 11:17:00PM +, Nate Nielsen wrote: Nate Nielsen wrote: The polling functionality in FreeBSD is currently a bit NIC centric. With a few changes other types devices can use the polling subsystem. Attached is my first whack at this. This is some of my first hacking on the FreeBSD kernel. It'd be great if there was someone who could take a look and help me get it right. Attached is a patch against HEAD. This looks like a good start to expanding polling beyond network interfaces, but it doesn't address the fact that the polling code currently has a single feedback parameter, shared by all devices, to control the amount of work done in each handler. Passing the count parameter to devices other than network interfaces implies that their drivers should do roughly as much work as a network interface would to process that number of packets. If the other devices take too long per count then polling-enabled network interfaces will end up without enough CPU time to do their required work. In addition, the current polling algorithm breaks down when you get to very high CPU utilization by the stack (e.g. if acting as a high bandwidth router). This happens because it adds one count per tick if the polling did not run longer than one hardclock interval, but brings it down to 7/8ths if it did. This ends up producing a sawtooth effect in the amount of work done by the polling handlers. Andre Oppermann is performing some high-perf stack testing, and he ran into this effect; in polling mode the maximum packet rate was achieved while there was still idle CPU time. I have a proof of concept patch that modifies the polling feedback algorithm to measure the amount of time spent in the polling handlers, and then attempt to schedule an appropriate amount of work to fill out the time slot. Andre is going to be testing it out shortly. Don't get me wrong, I think your patch is a step in the right direction, but we do have more work to do in order to completely generalize the polling code. (By the way, it seems some of your driver diffs move the *_poll functions around, making it harder to see what you actually changed. It would be better to leave the functions where they already are, I think.) -Ed Maste ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: memory mapped packet capturing - bpf replacement ?
Sergey Lyubka wrote: Discussion on -current, read vs mmap, explained this. If userland process does pre-fault allocated memory, ng_mmq appears to be considerably faster than pcap: Excellent! If I connect it directly to ng_ether, the network stack stops working. The question is - how to make it `transparent', so event the lower hook is connected, mbufs are still passed to upper network stack layers ? Is it possible without additional copies like ng_tee/ng_hub do ? Perhaps you could have two hooks, one connected to each of the lower and upper ng_ether hooks. Then just copy the data into your ringbuffer and pass the mbuf back out the other hook? -ed ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: memory mapped packet capturing - bpf replacement ?
A bit offtopic - what traffic generator you use ? It's an in-house project somewhat similar to Emulab www.emulab.net. The traffic itself is generated by a small number of FreeBSD boxes. In my testing I found the call to microtime() to be quite expensive. (It will vary depending on which timecounter is being used.) I haven't added the timestamp to the header yet, so what would you recommed to use ? The problem is that microtime queries the timecounter on each use, and in my case of SMP the timecounter used is the 8254. Accessing it takes a (relatively) long time. If you need accurate timestamps on received packets you're pretty much stuck with the overhead. There's another call, getmicrotime, which can return a less precise, but faster to obtain, time. I added a BPF ioctl (to our local tree) to turn off timestamps completely if they're not needed. Is this in a SMP or uniprocesor environment? I think your gain from a ringbuffer interface will be more significant in the SMP case. I gonna test it much more on both SMP and UP machines All of my testing was done on SMP, where I think the benefit from removing the read call will be greater than UP. This way, you intercept all Ethernet traffic trough ng_hub. Then, ng_bpf does BPF filtering, if any. If no filtering is needed, then ng_bpf node may be omitted. And, at last, ng_mmq does queuing. Would connecting ng_mmq directly to the ng_ether lower hook provide a useful datapoint? Are you using the same snap length (or copying the entire packet) in each case? Hmm not sure what are you mean here. I am copying whole mbuf chain the same way BPF does. mbuf chain comes from the hook, and it can arrive to the hook from whatever source. If you just run e.g. tcpdump, by default only the first bit of the packet is actually copied. But as BMS pointed out you've set the snaplen to 32K so that won't be an issue here. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: memory mapped packet capturing - bpf replacement ?
Matthew Dillon wrote: There's no reason why the time has to be in microseconds or even that it must be adjusted to realtime. You also do not have to support low power modes during testing which means that just time-stamping the packets with the TSC plus a simple base offset to correct for variences between cpus and machines on the network ought to be sufficient. Fair enough. In my case I didn't need the timestamp anyway so just disabling it was the least-effort way to remove the overhead. I pointed out the timestamp issue only because it will penalize BPF against a new method (that doesn't have them) more than one might expect. -ed ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: memory mapped packet capturing - bpf replacement ?
The module is a netgraph node, called ng_mmq. mmq stands for memory-mapped queue. The node has one hook, called input. When this hook is connected, o memory buffer is allocated. size is controlled by the debug.mmq_size sysctl. o a device /dev/mmqX is created, where X is a node ID o /dev/mmqX is mmap-able by the user, mmap() returns an allocated buffer o when packet arrives on hook, it is copied to the buffer, which is actually a ringbuffer. The ringbuffer's head is advanced. o user spins until tail != head, which means new data arrived. Then it reads from ringbuffer, and advances the tail. o no mutexes are used The code is at So this is the basic idea. I connected ng_mmq node to my rl0: ethernet node via the ng_hub, and benchmarked it against the pcap, using the same pcap callback function. Packet processing was simulated by the delay() function that just takes some CPU cycles. What I have found is: 1. bpf seems to be faster, i.e. it drops less packets than mmq 2. mmq seems to capture more packets. This is sample output from the benchmark utility: # ./benchmark rl0 /dev/mmq5 1000 pcap: rcvd: 15061, dropped: 14047, seen: 1000 mmq: rcvd: 23172, dropped: 21789, seen: 1000 Now, the questions: 1. is my interpretation of benchmark results correct? 2. if they are correct, why bpf is faster? 3. is it OK to have no mutexes for ringbuffer operations ? Hello Sergey. I haven't looked at your code, but I'll provide some comments, having implemented a mmaped ringbuffer BPF replacement myself. First off, you should be able to do significantly better than vanilla BPF. Gigabit line rate is doable for reasonable sized packets and good hardware. Watch how much time you spend in your simulated packet processing. I also needed to add a delay to my benchmarking, because without it I'd run into the hardware limit (i.e. 1gbps), hiding the effects of further tweaking. However, if it's too great it will overwhelm the bpf/ringbuffer overhead, making your results less useful. I did my benchmark by increasing the packet rate until I found the point at which packets started to be dropped. In my testing I found the call to microtime() to be quite expensive. (It will vary depending on which timecounter is being used.) Is this in a SMP or uniprocesor environment? I think your gain from a ringbuffer interface will be more significant in the SMP case. Does the ng_hub cause the packet to be copied? If so you've still got the same number of copies as vanilla BPF. Are you using the same snap length (or copying the entire packet) in each case? As for question 3, be careful that you're atomically modifying the head and tail indices/pointers. But yes, you can do it without a mutex. -ed ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sio issue
I can reliably cause a panic in the sio driver by trying to enter the kernel
debugger (with cr ~ ^b) while large numbers of kernel messages are being
output to the console. I've included a stack trace excerpt showing what
happens. In all of my cases siointr1 was called by comstart, and then is
entered again from Xfastintr4 and it gives me the panic about the com lock
shown.
John Baldwin has a patch
(http://www.geocrawler.com/mail/msg.php3?msg_id=8616108list=163) for IRQ
sharing, which doesn't set INTR_FAST for the shared case. I also tried
switching sio to use normal interrupts since it seems safer, and I am unable
to reproduce the panic. Does sio specify INTR_FAST only for performance
reasons? We don't care about modems etc. dropping characters so I'd be
happy eliminating the INTR_FAST if it's there only for improved performance.
-ed
#12 0xc01bd801 in panic (
fmt=0xc02d592e rslock: cpu: %d, addr: 0x%08x, lock: 0x%08x)
at /usr/src/sys/kern/kern_shutdown.c:607
#13 0xc02d592e in bsl1 ()
#14 0xc02c2960 in Xfastintr4 ()
#15 0xc02eb79c in siocnopen (sp=0xe166ab5c, iobase=1016, speed=115200)
at /usr/src/sys/isa/sio.c:3099
#16 0xc02ebc9d in siocnputc (dev=0xc0363b04, c=116)
at /usr/src/sys/isa/sio.c:3418
#17 0xc01da2fc in cnputc (c=116) at /usr/src/sys/kern/tty_cons.c:476
#18 0xc014628a in db_putchar (c=116, arg=0x0)
at /usr/src/sys/ddb/db_output.c:108
#19 0xc01cb8d8 in kvprintf (fmt=0xc02f812e opped at\t,
func=0xc0146270 db_putchar, arg=0x0, radix=16, ap=0xe166ac5c )
at /usr/src/sys/kern/subr_prf.c:532
#20 0xc014636e in db_printf (fmt=0xc02f812c Stopped at\t)
at /usr/src/sys/ddb/db_output.c:164
#21 0xc01470ea in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:76
#22 0xc02c1188 in kdb_trap (type=3, code=0, regs=0xe166accc)
at /usr/src/sys/i386/i386/db_interface.c:158
#23 0xc02d701c in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi =
1,
tf_esi = -1019379712, tf_ebp = -513364692, tf_isp = -513364744,
tf_ebx = -1019379712, tf_edx = 1016, tf_ecx = 50331649, tf_eax = 0,
tf_trapno = 3, tf_err = 0, tf_eip = -1070685984, tf_cs = 8,
tf_eflags = 70, tf_esp = -1019379712, tf_ss = -1018515456})
at /usr/src/sys/i386/i386/trap.c:592
#24 0xc02ea0e0 in siointr1 (com=0xc33d8000) at machine/cpufunc.h:67
#25 0xc02eb171 in comstart (tp=0xc34ab000) at /usr/src/sys/isa/sio.c:2782
#26 0xc01d7883 in ttstart (tp=0xc34ab000) at /usr/src/sys/kern/tty.c:1401
#27 0xc01d8506 in ttwrite (tp=0xc34ab000, uio=0xe166aedc, flag=8323073)
at /usr/src/sys/kern/tty.c:1969
#28 0xc02e9bff in siowrite (dev=0xc0363b04, uio=0xe166aedc, flag=8323073)
at /usr/src/sys/isa/sio.c:1769
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
