Re: SVN r252892: videodev2.h update breaks gcc compilation
On Sun, 07 Jul 2013 06:59:59 -0400 Michael Butler i...@protected-networks.net wrote: The recent linux header update triggers the following error: In file included from /usr/src/sys/compat/linux/linux_ioctl.c:91: /usr/src/sys/contrib/v4l/videodev2.h:430: warning: declaration does not declare anything Does someone know what this is supposed to result in? I would assume as the unions are unnamed and no variable is declared inside the struct with it, that the size of the struct is the same as not having those unions inside the structs. If this is correct I would assume the correct fix would be to #if-0 them out. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: buildkernel is broken
On Sun, Jul 07, 2013 at 11:51:01PM +0200, Claude Buisson wrote: C On 07/07/2013 22:05, Gleb Smirnoff wrote: C On Fri, Jul 05, 2013 at 08:32:06AM -0700, Steve Kargl wrote: C S On Fri, Jul 05, 2013 at 05:03:38PM +0400, Gleb Smirnoff wrote: C S On Tue, Jul 02, 2013 at 08:45:16PM -0700, Steve Kargl wrote: C S S On Tue, Jul 02, 2013 at 10:51:57PM -0230, Jonathan Anderson wrote: C S S On Tuesday, 2 July 2013 at 22:16, Steve Kargl wrote: C S S It seems that C S S C S S # Enable FreeBSD7 compatibility syscalls C S S options COMPAT_FREEBSD7 C S S C S S is required in a kernel config file. If it is mandatory to C S S have this option on FreeBSD 10, it may be appropriate to C S S expand the comment to C S S C S S C S S # Enable FreeBSD7 compatibility syscalls C S S # This option is MANDATORY. Do not remove. C S S options COMPAT_FREEBSD7 C S S C S S So... a non-optional option? C S S C S S Yes, it appears to be that way. C S C S Not really. It is required only if you also got COMPAT_43, the C S pre-FreeBSD compat option. C S C S C S So, it's essentially non-optional as the comment above COMPAT_43 C S is C S C S # C S # Implement system calls compatible with 4.3BSD and older versions of C S # FreeBSD. You probably do NOT want to remove this as much current code C S # still relies on the 4.3 emulation. C S C S Is do NOT want to remove too strong of a statement? C C Where did you find this statement? I remember it, but haven't seen C it for long time. Can't find it in modern GENERIC. C C C Try and read sys/conf/NOTES I think, the statement is outdated today. -- Totus tuus, Glebius. ___ 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
Improved SYN Cookies: Looking for testers
We have a SYN cookie implementation for quite some time now but it has some limitations with current realities for window scaling and SACK encoding the in the few available bits. This patch updates and improves SYN cookies mainly by: a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN (initial sequence number) without the use of timestamp bits. b) switching to the very fast and cryptographically strong SipHash-2-4 hash MAC algorithm to protect the SYN cookie against forgery. The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). Please find it here for testing: http://people.freebsd.org/~andre/syncookie-20130708.diff Please enable TCP logdebug to see connection status reporting by the changes. Detailed discussion: The purpose of SYN cookies is to encode all necessary session state in the 32 bits of our initial sequence number to avoid storing any information locally in memory. This is especially important when under heavy spoofed SYN attacks where we would either run out of memory or the syncache would fill with bogus connection attempts swamping out legitimate connections. The 32 bits of the ISN are a very limited space because we also have to store a cryptographically strong enough hash MAC in it to prevent spoofing of valid SYN cookies. The result is that 24 bits have to be dedicated to the MAC hash and only 8 bits remain available for the session state. The common parameters used on TCP sessions have changed quite a bit since SYN cookies very invented some 17 years ago. Today we a lot more bandwidth making the use window scaling almost mandatory. Also SACK has become standard as it makes recovering from packet loss much more efficient. The original SYN cookies method only stored an indexed MSS values in the cookie. This obviously isn't sufficient anymore and breaks in the presence of WSCALE. WSCALE information is only exchanged during SYN and SYN-ACK. If we can't keep track of it then we severely under- estimate the available send or receive window compounded with the fact that with large window scaling the window size information on the TCP segment header would be even lower numerically. A number of years back I extended SYN cookies to store the additional state in the TCP timestamp fields, if available on a connection. It has been adapted by Linux as well. While timestamps are common among the BSD, Linux and other *nix systems Windows never enabled them by default and thus are not present for the vast majority of clients seen on the Internet. The new improvement in this patch moves all necessary information into the ISN again removing the need for timestamps. Both the MSS and send WSCALE are stored in 3 bit indexed form together with a single bit for SACK. While we can't represent all possible MSS and WSCALE values, both are 16 bit fields in the TCP header, in only 3 bits each this, it turns out, isn't actually necessary. The MSS depends on the MTU of the path and with the dominance of ethernet the main value seen is around 1460 bytes. Encapsulations for DSL lines and some other overheads reduce it by a few more bytes for many connections seen. Based on large traffic surveys I've selected the most common values that perfectly, or with only a small down rounding difference, represent essentially 99.99% of all connections seen in real life. Rounding down to the next lower value isn't a problem as we only would send slightly more packets for the same amount of data. The send WSCALE is bit more tricky as rounding down would let us under- estimate the available send space available towards the remote host. Again it turns out that a small number of values dominates all connections and is thus carefully selected again. The receive WSCALE isn't encoded at all but recalculated based on the local receive socket buffer size when a valid SYN cookie returns. The socket buffer size most likely didn't change in the mean time on a listen socket. If it did we'd have a discrepancy for those SYN cookies in flight at the time of the change. These improvements allow one to run with SYN cookies only on Internet facing servers. However while SYN cookies are calculated and sent all the time, they're only used when the syn cache overflows due to attacks or overload. In that cause though you can rest assured that no significant degradation in TCP connection setup happens anymore and that even Windows clients can make use of window scaling and SACK. In addition the hash MAC to protect the SYN cookies is changed from MD5 to SipHash-2-4, a much faster and cryptographically secure algorithm recently developed by Jean-Philippe Aumasson and Daniel J. Bernstein. Ministat makes the MAC hash calculation speed difference even more obvious: x md5 + siphash
Re: another -Wunsequenced topic
Well, this turned out to be a semi-false alarm. A week ago, for a short time, there was a bug in Clang. There is no undefined behavior in ptr = func(++ptr);, partially because a function call introduces a sequence point in C, but Clang did not respect this at that time. However, x = func1(++ptr) + func2(++ptr); is compiler-dependent. Additionally, if func() turns out to be a macro, rather than a native function, then undefined behavior (due to unsequencedness) occurs. According to the manpage for ntohl(): On machines which have a byte order which is the same as the network order, routines are defined as null macros.. This can bite libstand on big-endian systems So in the end, Clang has accidentally pointed me to an irrelated bug, and induced some unnecessary code changes. lolz ___ 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: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e)
Hello,
I applied the patch, trying to get brightness controls for my X121e.
But it looks like I need a different loader.conf setting.
hw.pci0.0.2.0.handle=_SB_.PCI0.PEG.VID
doesn't work. In my ASl there is only one device providing DOD / DOS:
Scope (_SB.PCI0)
{
Device (GFX0)
{
Name (_ADR, 0x0002) // _ADR: Address
Method (_DOS, 1, NotSerialized) // _DOS: Disable
Output Switching
{
Store (And (Arg0, 0x07), DSEN)
If (LEqual (And (Arg0, 0x03), Zero))
{
If (CondRefOf (HDOS))
{
HDOS ()
}
}
}
Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
{
If (CondRefOf (IDAB))
{
IDAB ()
}
Else
{
[truncated]
Unfortunately I'm far away from understanding the ASL, so I can only
guess this is the part where my graphics device is described. Also,
because I don't have a PEG device with DOD / DOS, I fear the described
patch for the X220 will not solve the problem for me?
My ASL is located here:
https://d2ux.org/owncloud/public.php?service=filest=7022f90cea5e48da7fa65806c0d66091
I would really appreciate if someone with more ACPI background could
take a look at it and
tell me what I should try next.
Thanks kind regards,
Matthias
___
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: ACPI Lenovo X121e (Model 3045-79G, i3, HD3000) Suspend and LCD Brightness
Hello Kevin, Zitat von Kevin Oberman rkober...@gmail.com: Can't help with suspend/resume, but I can point you to the brightness solution. This is probably the same issue that impacts most recent Lenovo laptops. If so, there is a fix in the thread titled Fixing X220 Video The Right Way on this (acpi@) mailing list with the patch by jhb on Feb. 28, but be usre to a followup message on using the fix posted on June 14. It' a tricky issue with getting a string with quoted characters parsed correctly. There have been a number of discussions on ThinkPad suspend/resume, but I have not seen a reliable fix. (I can't resume mine at this time, though it suspends fine :-) Thanks for your reply. I found the thread you recommended to me and followed up with it. Looks like I cannot apply the same procedure unchanged to the X121e. It would be interesting to know if the suspend / brightness issues are specific to the Thinkpads with integrated Intel HD graphics or if also the NVidia models are affected. Kind regards, Matthias ___ 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: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e)
Hello,
I applied the patch, trying to get brightness controls for my X121e.
But it looks like I need a different loader.conf setting.
hw.pci0.0.2.0.handle=_SB_.PCI0.PEG.VID
doesn't work. In my ASl there is only one device providing DOD / DOS:
Scope (_SB.PCI0)
{
Device (GFX0)
{
Name (_ADR, 0x0002) // _ADR: Address
Method (_DOS, 1, NotSerialized) // _DOS: Disable Output
Switching
{
Store (And (Arg0, 0x07), DSEN)
If (LEqual (And (Arg0, 0x03), Zero))
{
If (CondRefOf (HDOS))
{
HDOS ()
}
}
}
Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
{
If (CondRefOf (IDAB))
{
IDAB ()
}
Else
{
[truncated]
Unfortunately I'm far away from understanding the ASL, so I can only
guess this is the part where my graphics device is described. Also,
because I don't have a PEG device with DOD / DOS, I fear the described
patch for the X220 will not solve the problem for me?
My ASL is located here:
https://d2ux.org/owncloud/public.php?service=filest=7022f90cea5e48da7fa65806c0d66091
I would really appreciate if someone with more ACPI background could
take a look at it and
tell me what I should try next.
Thanks kind regards,
Matthias
___
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: ACPI Lenovo X121e (Model 3045-79G, i3, HD3000) Suspend and LCD Brightness
Hello Kevin, Zitat von Kevin Oberman rkober...@gmail.com: Can't help with suspend/resume, but I can point you to the brightness solution. This is probably the same issue that impacts most recent Lenovo laptops. If so, there is a fix in the thread titled Fixing X220 Video The Right Way on this (acpi@) mailing list with the patch by jhb on Feb. 28, but be usre to a followup message on using the fix posted on June 14. It' a tricky issue with getting a string with quoted characters parsed correctly. There have been a number of discussions on ThinkPad suspend/resume, but I have not seen a reliable fix. (I can't resume mine at this time, though it suspends fine :-) Thanks for your reply. I found the thread you recommended to me and followed up with it. Looks like I cannot apply the same procedure unchanged to the X121e. It would be interesting to know if the suspend / brightness issues are specific to the Thinkpads with integrated Intel HD graphics or if also the NVidia models are affected. Kind regards, Matthias ___ 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: Ipfilter pre-Vendor Import Issue
On 05.07.2013 20:38, Cy Schubert wrote: In message 20130705084649.gc67...@freebsd.org, Gleb Smirnoff writes: What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter Having ipfilter in one place instead of two (vendor and vendor-sys) makes a lot more sense. I suppose we could put ipfilter's kernel components in sys/netpfil but what about the userland sources? Also see my reply below regarding keeping it in contrib. In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? The reason to keep ipftilter in contrib is to maintain consistency with other contributed software such as bind, nvi, sendmail, pf, and a host of other notable software we don't maintain ourselves. Maintaining consistency with other contributed software should probably be maintained. I'm open to moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as long as consistency is maintained across the board. Do you think we should put the userland sources also in the same location or should we maintain a similar separation we do today? I'm open to both however I'd prefer keeping all vendor software (kernel and userland) in one location. I think the main distinction here is whether the adaptions to FreeBSD are kept local (resulting in almost a fork) or are fed upstream so that successive updates require less or no local changes. Having the kernel part in sys/netpfil certainly makes it easier for kernel people to adjust it to changed realities. IIRC ipfilter also has very messy ifdef's all over the place for every possible ancient version of FreeBSD. This probably should be cleaned up (and upstreamed) as well. -- Andre ___ 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: Ipfilter pre-Vendor Import Issue
Cy, On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote: C What I'd prefer to see is the following: C C - commit new ipfilter untouched to vendor-sys/ipfilter C - nuke sys/contrib/ipfilter C - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter C C Having ipfilter in one place instead of two (vendor and vendor-sys) makes a C lot more sense. C C I suppose we could put ipfilter's kernel components in sys/netpfil but what C about the userland sources? Also see my reply below regarding keeping it in C contrib. IMO, it is possible to keep a bulk checkout of ipfilter in vendor/ipfilter, but merge kernel files separately to sys/netpfil/ipfilter, and separately merge userland files to appropriate place. C In future imports do: C C - commit newer ipfilter to vendor-sys/ipfilter C - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter C C What's the reason to keep code in contrib? C C The reason to keep ipftilter in contrib is to maintain consistency with C other contributed software such as bind, nvi, sendmail, pf, and a host of C other notable software we don't maintain ourselves. Maintaining consistency C with other contributed software should probably be maintained. I'm open to C moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as C long as consistency is maintained across the board. C C Do you think we should put the userland sources also in the same location C or should we maintain a similar separation we do today? I'm open to both C however I'd prefer keeping all vendor software (kernel and userland) in one C location. The BSD license allows us to put the code into FreeBSD w/o any separation. So the question is: what is more handy to us? What do we actually gain having contrib/ipf, assuming we got vendor branch already? What we lose is: - more complex Makefiles - more complex hacking: edit files in one place, run make in other -- Totus tuus, Glebius. ___ 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 armv6/arm
TB --- 2013-07-08 11:50:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-08 11:50:18 - 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 --- 2013-07-08 11:50:18 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-08 11:50:18 - cleaning the object tree TB --- 2013-07-08 11:51:22 - /usr/local/bin/svn stat /src TB --- 2013-07-08 11:51:25 - At svn revision 253030 TB --- 2013-07-08 11:51:26 - building world TB --- 2013-07-08 11:51:26 - CROSS_BUILD_TESTING=YES TB --- 2013-07-08 11:51:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-08 11:51:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-08 11:51:26 - SRCCONF=/dev/null TB --- 2013-07-08 11:51:26 - TARGET=arm TB --- 2013-07-08 11:51:26 - TARGET_ARCH=armv6 TB --- 2013-07-08 11:51:26 - TZ=UTC TB --- 2013-07-08 11:51:26 - __MAKE_CONF=/dev/null TB --- 2013-07-08 11:51:26 - cd /src TB --- 2013-07-08 11:51:26 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Jul 8 11:51:33 UTC 2013 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 Mon Jul 8 14:53:29 UTC 2013 TB --- 2013-07-08 14:53:29 - generating LINT kernel config TB --- 2013-07-08 14:53:29 - cd /src/sys/arm/conf TB --- 2013-07-08 14:53:29 - /usr/bin/make -B LINT TB --- 2013-07-08 14:53:29 - cd /src/sys/arm/conf TB --- 2013-07-08 14:53:29 - /usr/sbin/config -m LINT TB --- 2013-07-08 14:53:29 - skipping LINT kernel TB --- 2013-07-08 14:53:29 - cd /src/sys/arm/conf TB --- 2013-07-08 14:53:29 - /usr/sbin/config -m AC100 TB --- 2013-07-08 14:53:29 - building AC100 kernel TB --- 2013-07-08 14:53:29 - CROSS_BUILD_TESTING=YES TB --- 2013-07-08 14:53:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-08 14:53:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-08 14:53:29 - SRCCONF=/dev/null TB --- 2013-07-08 14:53:29 - TARGET=arm TB --- 2013-07-08 14:53:29 - TARGET_ARCH=armv6 TB --- 2013-07-08 14:53:29 - TZ=UTC TB --- 2013-07-08 14:53:29 - __MAKE_CONF=/dev/null TB --- 2013-07-08 14:53:29 - cd /src TB --- 2013-07-08 14:53:29 - /usr/bin/make -B buildkernel KERNCONF=AC100 Kernel build for AC100 started on Mon Jul 8 14:53:29 UTC 2013 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 -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -ffreestanding -Werror /src/sys/arm/arm/pmap-v6.c /src/sys/arm/arm/pmap-v6.c:3339:28: error: more '%' conversions than data arguments [-Werror,-Wformat] va %x pte %x in %s, va, *ptep)); ~^ /src/sys/sys/systm.h:83:17: note: expanded from macro 'KASSERT' kassert_panic msg; \ ^ 1 error generated. *** Error code 1 Stop. make: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-08 14:56:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-08 14:56:07 - ERROR: failed to build AC100 kernel TB --- 2013-07-08 14:56:07 - 8905.29 user 1540.20 system 11149.19 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full ___ 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: [CFT] sysutils/bsdconfg (0.9.0) and sysutils/sysrc (5.2)
In light of Devin's CFT, I offer the following, related code...
Greetings -
I've been asked to look at inserting ZFS support into the guided setup
for FreeBSD.
I've got a mostly working set of patches, but they are still a bit
ugly -- hard wired to use ZFS now, rather than UFS, but I'm to the point
where some external input is needed.
On of the issues that I've run into is the partedit command knows
that pretty much a partition equates to a filesystem. While that
is true for UFS, it's not that way for ZFS. A partition is more likely
a zpool, and that zpool can have as many filesystems as the user
wants.
Also, the bsdinstall framework (nice piece of work!) would need to
be extended to query for zfs vs ufs and also have some hook for
setting up the different zfs filesystems. Right now, I just kludged
in a static list of filesystems to create in the mount script.
I suppose there should be filesystems script before mount that
lets a user muck about in terms of creating filesystems...
Anyway, attached should be a patch against a recent snapshot of
a -current source tree to add in this code. It's not ready for
primetime, buy I would like some feedback about the approach I've
taken so far.
Thanks.
-Kurt
diff --git a/usr.sbin/bsdinstall/partedit/Makefile
b/usr.sbin/bsdinstall/partedit/Makefile
--- a/usr.sbin/bsdinstall/partedit/Makefile
+++ b/usr.sbin/bsdinstall/partedit/Makefile
@@ -1,9 +1,11 @@
# $FreeBSD$
+STRIP=
+CFLAGS+=-g
BINDIR= /usr/libexec/bsdinstall
PROG= partedit
LINKS= ${BINDIR}/partedit ${BINDIR}/autopart \
${BINDIR}/partedit ${BINDIR}/scriptedpart
SYMLINKS= ${BINDIR}/partedit /usr/sbin/sade
DPADD= ${LIBGEOM} ${LIBNCURSESW} ${LIBUTIL} ${LIBDIALOG} ${LIBM}
LDADD= -lgeom -lncursesw -lutil -ldialog -lm
diff --git a/usr.sbin/bsdinstall/partedit/gpart_ops.c
b/usr.sbin/bsdinstall/partedit/gpart_ops.c
--- a/usr.sbin/bsdinstall/partedit/gpart_ops.c
+++ b/usr.sbin/bsdinstall/partedit/gpart_ops.c
@@ -114,16 +114,56 @@ newfs_command(const char *fstype, char *
strcat(command, -O1 );
else if (strcmp(items[i].name, SU) == 0)
strcat(command, -U );
else if (strcmp(items[i].name, SUJ) == 0)
strcat(command, -j );
else if (strcmp(items[i].name, TRIM) == 0)
strcat(command, -t );
}
+ } else if (strcmp(fstype, freebsd-zfs) == 0) {
+ int i;
+ DIALOG_LISTITEM items[] = {
+ {fletcher4, checksum algorithm: fletcher4,
+ Use fletcher4 for data integrity checking.
+ (default), 1 },
+ {fletcher2, checksum algorithm: fletcher2,
+ Use fletcher2 for data integrity checking.
+ (not recommended), 0 },
+ {sha256, checksum algorithm: sha256,
+ Use sha256 for data integrity checking.
+ (not recommended), 0 },
+ {atime, Update atimes for files,
+ Disable atime update, 0 },
+ };
+
+ if (!use_default) {
+ int choice;
+ choice = dlg_checklist(ZFS Options, , 0, 0, 0,
+ sizeof(items)/sizeof(items[0]), items, NULL,
+ FLAG_CHECK, i);
+ if (choice == 1) /* Cancel */
+ return;
+ }
+
+ strcpy(command, zpool create -o cachefile=/tmp/zpool.cache
+-O canmount=off -O mountpoint=none );
+ for (i = 0; i (int)(sizeof(items)/sizeof(items[0])); i++) {
+ if (items[i].state == 0)
+ continue;
+ if (strcmp(items[i].name, fletcher4) == 0)
+ strcat(command, -O checksum=fletcher4 );
+ else if (strcmp(items[i].name, fletcher2) == 0)
+ strcat(command, -O checksum=fletcher2 );
+ else if (strcmp(items[i].name, sha256) == 0)
+ strcat(command, -O checksum=sha256 );
+ else if (strcmp(items[i].name, atime) == 0)
+ strcat(command, -O atime=off );
+ }
+ strcat(command, zroot ); /* XXX */
} else if (strcmp(fstype, fat32) == 0 || strcmp(fstype, efi) == 0) {
int i;
DIALOG_LISTITEM items[] = {
{FAT32, FAT Type 32,
Create a FAT32 filesystem (default), 1 },
{FAT16, FAT Type 16,
Create a FAT16 filesystem, 0 },
{FAT12, FAT Type 12,
@@ -339,30 +379,34
Re: Ipfilter pre-Vendor Import Issue
In message 51da85cf.3000...@freebsd.org, Andre Oppermann writes: On 05.07.2013 20:38, Cy Schubert wrote: In message 20130705084649.gc67...@freebsd.org, Gleb Smirnoff writes: What I'd prefer to see is the following: - commit new ipfilter untouched to vendor-sys/ipfilter - nuke sys/contrib/ipfilter - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter Having ipfilter in one place instead of two (vendor and vendor-sys) makes a lot more sense. I suppose we could put ipfilter's kernel components in sys/netpfil but what about the userland sources? Also see my reply below regarding keeping it in contrib. In future imports do: - commit newer ipfilter to vendor-sys/ipfilter - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter What's the reason to keep code in contrib? The reason to keep ipftilter in contrib is to maintain consistency with other contributed software such as bind, nvi, sendmail, pf, and a host of other notable software we don't maintain ourselves. Maintaining consistency with other contributed software should probably be maintained. I'm open to moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as long as consistency is maintained across the board. Do you think we should put the userland sources also in the same location or should we maintain a similar separation we do today? I'm open to both however I'd prefer keeping all vendor software (kernel and userland) in one location. I think the main distinction here is whether the adaptions to FreeBSD are kept local (resulting in almost a fork) or are fed upstream so that successive updates require less or no local changes. I see no problem feeding update upstream. The email I just received from Darren (cc'd Gleb and yourself) is likely to lead to this kind of relationship. Having the kernel part in sys/netpfil certainly makes it easier for kernel people to adjust it to changed realities. True. I'm thinking we should do the same with the userland side of ipfilter, keeping everything consistent. Also, I think putting all of the vendor bits regardless of whether they're destined for kernel or userlan into vendor/ or vendor-sys/ should make it simpler as well. What are your thoughts? IIRC ipfilter also has very messy ifdef's all over the place for every possible ancient version of FreeBSD. This probably should be cleaned up (and upstreamed) as well. Yes. There's a lot of cruft in there for operating systems that are no longer relevant as well. At least we can push some of the FreeBSD cleanup upstream. Initially I'd like to import v5-1-2 into our vendor branch (either vendor/ or vendor-sys/ for the complete tarball) then svn merge into sys/netpfil/ (for kernel) and netpfil/ (for userland). Do you have any additional thoughts on any of this? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: Ipfilter pre-Vendor Import Issue
In message 20130708134400.gh67...@glebius.int.ru, Gleb Smirnoff writes: Cy, On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote: C What I'd prefer to see is the following: C C - commit new ipfilter untouched to vendor-sys/ipfilter C - nuke sys/contrib/ipfilter C - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter C C Having ipfilter in one place instead of two (vendor and vendor-sys) makes a C lot more sense. C C I suppose we could put ipfilter's kernel components in sys/netpfil but wha t C about the userland sources? Also see my reply below regarding keeping it i n C contrib. IMO, it is possible to keep a bulk checkout of ipfilter in vendor/ipfilter, but merge kernel files separately to sys/netpfil/ipfilter, and separately merge userland files to appropriate place. C In future imports do: C C - commit newer ipfilter to vendor-sys/ipfilter C - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter C C What's the reason to keep code in contrib? C C The reason to keep ipftilter in contrib is to maintain consistency with C other contributed software such as bind, nvi, sendmail, pf, and a host of C other notable software we don't maintain ourselves. Maintaining consistenc y C with other contributed software should probably be maintained. I'm open to C moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as C long as consistency is maintained across the board. C C Do you think we should put the userland sources also in the same location C or should we maintain a similar separation we do today? I'm open to both C however I'd prefer keeping all vendor software (kernel and userland) in on e C location. The BSD license allows us to put the code into FreeBSD w/o any separation. So the question is: what is more handy to us? What do we actually gain having contrib/ipf, assuming we got vendor branch already? What we lose is: - more complex Makefiles - more complex hacking: edit files in one place, run make in other How is this for a plan? Instead of importing the kernel bits into vendor-sys/ipfilter and the userland bits into vendor/ipfilter, the base tarball should be imported into vendor-sys/ipfilter (or vendor/ipfilter, doesn't matter which). We keep the complete tarball imported into one place in the tree. Merge ipfilter into sys/netpfil/ipfilter (for kernel bits) and netpfil/ipfilter (for userland bits). We should probably think of moving pf and ipfw into the new subdirectory as well, but that's for a future discussion. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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
new make vs security/vpnc
Using recent head and the latest ports as of now. $ cd /usr/ports/security/vpnc $ make === Building for vpnc-0.5.3_8 /usr/ports/security/vpnc/Makefile:37: *** missing separator. Stop. *** Error code 1 But fmake works just fine without any error. In my ports tree Makefile:37 is: .include bsd.port.options.mk Please advise. -- Andriy Gapon ___ 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: new make vs security/vpnc
on 09/07/2013 00:07 Andriy Gapon said the following: Using recent head and the latest ports as of now. $ cd /usr/ports/security/vpnc $ make === Building for vpnc-0.5.3_8 /usr/ports/security/vpnc/Makefile:37: *** missing separator. Stop. *** Error code 1 But fmake works just fine without any error. In my ports tree Makefile:37 is: .include bsd.port.options.mk Please advise. A quick followup. I ran make -dA and noticed the following in the output: *** Failed target: do-build *** Failed command: (cd /usr/obj/ports/usr/ports/security/vpnc/work/vpnc-0.5.3; if ! /usr/bin/env BINS=cisco-decrypt SHELL=/bin/sh NO_LINT=YES ADDR2LINE=/usr/local/bin/addr2line AR=/usr/local/bin/ar AS=/usr/local/bin/as CPPFILT=/usr/local/bin/c++filt GPROF=/usr/local/bin/gprof LD=/usr/local/bin/ld NM=/usr/local/bin/nm OBJCOPY=/usr/local/bin/objcopy OBJDUMP=/usr/local/bin/objdump RANLIB=/usr/local/bin/ranlib READELF=/usr/local/bin/readelf SIZE=/usr/local/bin/size STRINGS=/usr/local/bin/strings PREFIX=/usr/local LOCALBASE=/usr/local MOTIFLIB=-L/usr/local/lib -lXm -lXp LIBDIR=/usr/lib CC=gcc46 CFLAGS=-O2 -pipe -O2 -fno-strict-aliasing -pipe -march=amdfam10 -DOPENSSL_GPL_VIOLATION -DCISCO_PATCH_VERSION -march=amdfam10 -march=amdfam10 CPP=cpp46 CPPFLAGS= LDFLAGS= -lcrypto -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 CXX=g++46 CXXFLAGS=-O2 -pipe -O2 -fno-strict-aliasing -pipe -march=amdfam10 -DOPENSSL_GPL_VIOLATION -DCISCO_PATCH_VERSION -march=amdfam10 -march=amdfam10 -O2 -fno-strict-aliasing -pipe -march=amdfam10 -march=amdfam10 MANPREFIX=/usr/local BSD_INSTALL_PROGRAM=install -s -o root -g wheel -m 555 BSD_INSTALL_LIB=install -s -o root -g wheel -m 444 BSD_INSTALL_SCRIPT=install -o root -g wheel -m 555 BSD_INSTALL_DATA=install -o root -g wheel -m 444 BSD_INSTALL_MAN=install -o root -g wheel -m 444 gmake -f /usr/ports/security/vpnc/Makefile -j`/sbin/sysctl -n kern.smp.cpus` all; then if [ -n ] ; then echo === Compilation failed unexpectedly.; (echo ) | /usr/bin/fmt 75 79 ; fi; false; fi) This is quite a large snippet, so here is a smaller and more obvious one: gmake -f /usr/ports/security/vpnc/Makefile -j`/sbin/sysctl -n kern.smp.cpus` all And indeed: $ gmake Makefile:37: *** missing separator. Stop. The port has USES= ... gmake but that's supposed to affect what is used inside the working directory. It's certainly a bug that gmake is run with the port's make file. -- Andriy Gapon ___ 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: new make vs security/vpnc
Seems like the problem boils down to this: $ make -V MAKEFILE /usr/ports/security/vpnc/Makefile $ fmake -V MAKEFILE Makefile The only explicit assignments of MAKEFILE that I could find in ports infrastructure are these: /usr/ports/Mk/bsd.port.mk:MAKEFILE?=Makefile /usr/ports/Mk/bsd.gnustep.mk:MAKEFILE= GNUmakefile -- Andriy Gapon ___ 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 armv6/arm
TB --- 2013-07-08 23:00:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-08 23:00:18 - 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 --- 2013-07-08 23:00:18 - starting HEAD tinderbox run for armv6/arm TB --- 2013-07-08 23:00:18 - cleaning the object tree TB --- 2013-07-08 23:01:23 - /usr/local/bin/svn stat /src TB --- 2013-07-08 23:01:26 - At svn revision 253048 TB --- 2013-07-08 23:01:27 - building world TB --- 2013-07-08 23:01:27 - CROSS_BUILD_TESTING=YES TB --- 2013-07-08 23:01:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-08 23:01:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-08 23:01:27 - SRCCONF=/dev/null TB --- 2013-07-08 23:01:27 - TARGET=arm TB --- 2013-07-08 23:01:27 - TARGET_ARCH=armv6 TB --- 2013-07-08 23:01:27 - TZ=UTC TB --- 2013-07-08 23:01:27 - __MAKE_CONF=/dev/null TB --- 2013-07-08 23:01:27 - cd /src TB --- 2013-07-08 23:01:27 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Jul 8 23:01:34 UTC 2013 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 Tue Jul 9 02:03:30 UTC 2013 TB --- 2013-07-09 02:03:30 - generating LINT kernel config TB --- 2013-07-09 02:03:30 - cd /src/sys/arm/conf TB --- 2013-07-09 02:03:30 - /usr/bin/make -B LINT TB --- 2013-07-09 02:03:30 - cd /src/sys/arm/conf TB --- 2013-07-09 02:03:30 - /usr/sbin/config -m LINT TB --- 2013-07-09 02:03:30 - skipping LINT kernel TB --- 2013-07-09 02:03:30 - cd /src/sys/arm/conf TB --- 2013-07-09 02:03:30 - /usr/sbin/config -m AC100 TB --- 2013-07-09 02:03:31 - building AC100 kernel TB --- 2013-07-09 02:03:31 - CROSS_BUILD_TESTING=YES TB --- 2013-07-09 02:03:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-09 02:03:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-09 02:03:31 - SRCCONF=/dev/null TB --- 2013-07-09 02:03:31 - TARGET=arm TB --- 2013-07-09 02:03:31 - TARGET_ARCH=armv6 TB --- 2013-07-09 02:03:31 - TZ=UTC TB --- 2013-07-09 02:03:31 - __MAKE_CONF=/dev/null TB --- 2013-07-09 02:03:31 - cd /src TB --- 2013-07-09 02:03:31 - /usr/bin/make -B buildkernel KERNCONF=AC100 Kernel build for AC100 started on Tue Jul 9 02:03:31 UTC 2013 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 -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -ffreestanding -Werror /src/sys/arm/arm/pmap-v6.c /src/sys/arm/arm/pmap-v6.c:3339:28: error: more '%' conversions than data arguments [-Werror,-Wformat] va %x pte %x in %s, va, *ptep)); ~^ /src/sys/sys/systm.h:83:17: note: expanded from macro 'KASSERT' kassert_panic msg; \ ^ 1 error generated. *** Error code 1 Stop. make: stopped in /obj/arm.armv6/src/sys/AC100 *** Error code 1 Stop. make: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-09 02:06:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-09 02:06:09 - ERROR: failed to build AC100 kernel TB --- 2013-07-09 02:06:09 - 8909.68 user 1540.76 system 11150.78 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full ___ 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: another -Wunsequenced topic
On Jul 8, 2013, at 4:43 AM, d...@gmx.com wrote: Well, this turned out to be a semi-false alarm. A week ago, for a short time, there was a bug in Clang. There is no undefined behavior in ptr = func(++ptr);, No, there is not. However, this does have an implicit redundant store, so changing it to ptr = func(ptr + 1); is still a good idea, just not for the reason Clang was claiming. partially because a function call introduces a sequence point in C, but Clang did not respect this at that time. However, x = func1(++ptr) + func2(++ptr); is compiler-dependent. Code like this is badly broken. The order of evaluation here can even change across compiler versions (optimizers use a variety of criteria to reorganize code, which can easily change from version to version). Additionally, if func() turns out to be a macro, rather than a native function, then undefined behavior (due to unsequencedness) occurs. Replacing functions with macros is a common way to optimize code, which is yet another reason the idiom above should generally be avoided. So in the end, Clang has accidentally pointed me to an irrelated bug, and induced some unnecessary code changes. Not strictly necessary for correctness, but still good changes for the most part. 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
Kernel crash during heavy disk access
I experienced kernel crashes while make world or ports. For example: # cd /usr/port/lang/mono # make Will cause the crash, from /var/crash/core.txt: eb8460p dumped core - see /var/crash/vmcore.5 Mon Jul 8 21:22:58 PDT 2013 FreeBSD eb8460p 10.0-CURRENT FreeBSD 10.0-CURRENT #5 r253048: Mon Jul 8 19:07:18 PDT 2013 root@eb8460p:/u sr/obj/usr/src/sys/EB8460p amd64 panic: ffs_valloc: dup alloc GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: mode = 0100600, inum = 52969060, fs = / panic: ffs_valloc: dup alloc cpuid = 0 KDB: stack backtrace: #0 0x805fd6d0 at kdb_backtrace+0x60 #1 0x805c5b65 at panic+0x155 #2 0x807dda6a at ffs_valloc+0x88a #3 0x8081a34c at ufs_makeinode+0x7c #4 0x808d2872 at VOP_CREATE_APV+0x92 #5 0x80670c49 at vn_open_cred+0x2c9 #6 0x8066a22f at kern_openat+0x1ef #7 0x8085db47 at amd64_syscall+0x357 #8 0x808475db at Xfast_syscall+0xfb Uptime: 6m57s Dumping 599 out of 3972 MB:..3%..11%..22%..33%..41%..51%..62%..73%..81%..91% Reading symbols from /boot/modules/cuse4bsd.ko...done. Loaded symbols for /boot/modules/cuse4bsd.ko Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/ng_ubt.ko.symbols...done. Loaded symbols for /boot/kernel/ng_ubt.ko.symbols Reading symbols from /boot/kernel/netgraph.ko.symbols...done. Loaded symbols for /boot/kernel/netgraph.ko.symbols Reading symbols from /boot/kernel/ng_hci.ko.symbols...done. Loaded symbols for /boot/kernel/ng_hci.ko.symbols Reading symbols from /boot/kernel/ng_bluetooth.ko.symbols...done. Loaded symbols for /boot/kernel/ng_bluetooth.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/ng_l2cap.ko.symbols...done. Loaded symbols for /boot/kernel/ng_l2cap.ko.symbols Reading symbols from /boot/kernel/ng_btsocket.ko.symbols...done. Loaded symbols for /boot/kernel/ng_btsocket.ko.symbols Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. Loaded symbols for /boot/kernel/ng_socket.ko.symbols #0 doadump (textdump=value optimized out) at pcpu.h:236 236 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:236 #1 0x805c57e0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x805c5ba4 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x807dda6a in ffs_valloc (pvp=value optimized out, mode=value optimized out, cred=value optimized out, vpp=value optimized out) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1022 #4 0x8081a34c in ufs_makeinode (mode=value optimized out, dvp=0xfe011bf44ce8, vpp=0xff811ba058d8, cnp=0xff811ba05900) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2620 #5 0x808d2872 in VOP_CREATE_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:265 #6 0x80670c49 in vn_open_cred (ndp=0xff811ba05880, flagp=0xff811ba0595c, cmode=420, vn_open_flags=value optimized out, cred=0xfe0011fcee00, fp=0xfe00110925a0) at vnode_if.h:109 #7 0x8066a22f in kern_openat (td=0xfe011960f920, fd=value optimized out, path=0x801dbd580 Address 0x801dbd580 out of bounds, pathseg=UIO_USERSPACE, flags=1538, mode=value optimized out) at /usr/src/sys/kern/vfs_syscalls.c:1093 #8 0x8085db47 in amd64_syscall (td=0xfe011960f920, traced=0) at subr_syscall.c:134 #9 0x808475db in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #10 0x0008013a5f2a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) -- Eric Camachat signature.asc Description: This is a digitally signed message part
