Re: HEADS UP: Capsicum overhaul.
On Fri, Mar 01, 2013 at 10:24:01PM -0500, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/13 21:05, Pawel Jakub Dawidek wrote: I just committed pretty large change that affects not only Capsicum, but also descriptor handling code in the kernel. If you will find some strange problems after r243611 (like panics, unexpected application errors, etc.) I may be at fault. I'll be looking at current@ mailing list closly, so report here if you find problems that look related to my change. Two things I noted with a kernel @ SVN r247608: On reboot .. newsyslog: can't mv /var/log/debug.log.zGwQSBb to /var/log/debug.log: Capabilities insufficient .. and X/intel/KMS fails to start reverting to SVN r247497 (my previous compilation) performs as expected, I've fixed the rename problem in r247616. Not sure if this will fix X. Could you give it a try? Thank you for the report! -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpNcW5DpTt_W.pgp Description: PGP signature
Re: HEADS UP: Capsicum overhaul.
On Fri, Mar 01, 2013 at 09:45:02PM -0600, Larry Rosenman wrote: On Sat, 2 Mar 2013, Pawel Jakub Dawidek wrote: I just committed pretty large change that affects not only Capsicum, but also descriptor handling code in the kernel. If you will find some strange problems after r243611 (like panics, unexpected application errors, etc.) I may be at fault. I'll be looking at current@ mailing list closly, so report here if you find problems that look related to my change. Similar to another post: vn up Updating '.': Udatabases/py-sqlite3/Makefile Udatabases/py-sqlite3/files/setup.py Udatabases/py-sqlite3/files/setup3.py svn: E93: Can't move '/usr/ports/.svn/tmp/svn-X6U5KQ' to '/usr/ports/databases/py-sqlite3/Makefile': Capabilities insufficient # svn up svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted # svn cleanup svn: E93: Can't move '/usr/ports/.svn/tmp/svn-Bb1iSM' to '/usr/ports/databases/py-sqlite3/Makefile': Capabilities insufficient This should be now fixed in r247616. Thank you for the report! -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpRi27mevghK.pgp Description: PGP signature
Re: Response of *.freebsd.org websites are very slow
Peter Wemm wrote: On Thu, Feb 28, 2013 at 3:44 AM, Fbsd8 fb...@a1poweruser.com wrote: [..] From cleveland ohio and www.freebsd.org is un-reachable again. It comes and gos. To me it's acting like someone high up is making dns changes. Some freebsd official better contact yahoo and put a stop to what ever there fooling around with. Nope. It isn't DNS, but there is a routing issue for ipv6 space between Level-3 and and Yahoo. I'm working on it. Peter Wemm; Just to keep you up to date, it's now March 02 and the same slowness / time out problem still exists. What ever your doing is causing it. Please don't leave your trial ipv6 fix in effect when your not actively working on the problem. Your trial fix is effecting all the freebsd sites. Leaving your nonworking trial fix in live production status is NOT the correct way of testing it. Restoring the environment to the known working condition in between cycles of testing your trial fix is the normal accepted method of testing such production level fixes to limit the un-desirable effects of said production level testing. ___ 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: HEADS UP: Capsicum overhaul.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/13 05:01, Pawel Jakub Dawidek wrote: I've fixed the rename problem in r247616. Not sure if this will fix X. Could you give it a try? That fixes X as well - thanks! imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (FreeBSD) iEYEARECAAYFAlEyEvAACgkQQv9rrgRC1JJM3wCfT2sg9yMRzrx/zU0DSz3ABhnT GW0AoMTwBTNoNuULkWIJIkXRhFWEuWtY =LTSA -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Import libyaml into base
hi, I want to import libyaml into base as libbsdyml so that no ports will use it like we do for expat. I need it for the pkg bootstrap, so it it can parse pkg.conf. I know that some of the bhyve people will also be glad to use it. libyaml is MIT licensed, it is stable: no abi/api revolution in it for a while. Does anyone have an objection? regards, Bapt pgpQ9FBc9CGlk.pgp Description: PGP signature
Re: Response of *.freebsd.org websites are very slow
On Sat, Mar 2, 2013 at 6:54 AM, Fbsd8 fb...@a1poweruser.com wrote: Peter Wemm wrote: On Thu, Feb 28, 2013 at 3:44 AM, Fbsd8 fb...@a1poweruser.com wrote: [..] From cleveland ohio and www.freebsd.org is un-reachable again. It comes and gos. To me it's acting like someone high up is making dns changes. Some freebsd official better contact yahoo and put a stop to what ever there fooling around with. Nope. It isn't DNS, but there is a routing issue for ipv6 space between Level-3 and and Yahoo. I'm working on it. Peter Wemm; Just to keep you up to date, it's now March 02 and the same slowness / time out problem still exists. What ever your doing is causing it. Please don't leave your trial ipv6 fix in effect when your not actively working on the problem. Your trial fix is effecting all the freebsd sites. Leaving your nonworking trial fix in live production status is NOT the correct way of testing it. Restoring the environment to the known working condition in between cycles of testing your trial fix is the normal accepted method of testing such production level fixes to limit the un-desirable effects of said production level testing. As of this time there is NO IPv6 address for www.freebsd.org. I assume that it was removed until the issues of routing between Y! and Level(3) are resolved. I'm not at all sure why you refer to the IPv6 support as a trial. As far as I know, the IPv6 was intended to be normal, production service and, for almost everyone, it worked fine, Unfortunately, the routing via Level(3) was not set up correctly and freebsd.org could not be reached via Level(3). It was NOT an IPv6 issue. The same thing has caused the same sort of problems with IPv4 and will continue to do so as it is simply two parties not understanding what the other expects in terms of routing. Also, please don't blame either side unless you know more details of the address assignment than are publicly available. I do find it disturbing that it is taking so long to fix, though. It really is not rocket science for people who understand BGP and routing policy. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ 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
access to hard drives is blocked by writes to a flash drive
When one of my flash drives is being heavily written to; typically by ``svn update'' on /usr/src, located on the flash drive; the following can be said about filesystem behavior: - ``svn update'' seems to be able to quickly update a bunch of files, but is then unable to continue for a period of time. This behavior is cyclical, and cycles several times, depending on the amount of updating work to be done for a particular run of ``svn update''. - Access to any filesystem, whether on the said flash drive or not, seems to be hindered a lot, typically during the said unable to continue time. Reading of a file on a hard drive was once delayed for more than 10 seconds. Seemingly as a consequence, the starting of top(1) is also typically delayed. SU is enabled on all UFS filesystems, including the ones on the hard drives and the flash drive. ___ 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: access to hard drives is blocked by writes to a flash drive
Wiadomość napisana przez deeptech71 w dniu 2 mar 2013, o godz. 18:29: When one of my flash drives is being heavily written to; typically by ``svn update'' on /usr/src, located on the flash drive; the following can be said about filesystem behavior: - ``svn update'' seems to be able to quickly update a bunch of files, but is then unable to continue for a period of time. This behavior is cyclical, and cycles several times, depending on the amount of updating work to be done for a particular run of ``svn update''. - Access to any filesystem, whether on the said flash drive or not, seems to be hindered a lot, typically during the said unable to continue time. Reading of a file on a hard drive was once delayed for more than 10 seconds. Seemingly as a consequence, the starting of top(1) is also typically delayed. When that happens, could you do ps axl and see the WCHAN column for the affected processes? Is it wdrain? -- If you cut off my head, what would I say? Me and my head, or me and my body? ___ 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: [PATCH] Fix sbin/fsdb/fsdbutil.c for r247212
Date: Sun, 24 Feb 2013 22:41:21 +0300 Subject: Re: [PATCH] Fix sbin/fsdb/fsdbutil.c for r247212 From: Sergey Kandaurov pluk...@freebsd.org To: David Wolfskill da...@catwhisker.org Cc: curr...@freebsd.org, Kirk McKusick mckus...@freebsd.org On 24 February 2013 19:25, David Wolfskill da...@catwhisker.org wrote: On Sun, Feb 24, 2013 at 07:05:34AM -0800, David Wolfskill wrote: ...hine was: Simple patch attached; world is still building, but at least it got through the make dependencies phase this time. ... That was incomplete, as it didn't (also) address the change to getdatablk(). The attached patch actually made it through buildworld. Note that it is entirely possible that I erred in specifying BT_UNKNOWN for the additional type argument. Hi David. Thank you for the proposed fix. I committed it with r247234. I'm not sure regarding BT_UNKNOWN value either. Well.. at least it should be not worse that it is now, and it should fix the build. I have not found any (regressive) changes in fsdb -d `blocks' output. -- wbr, pluknet Sorry, I am bad about keeping up with my mckus...@freebsd.org email. I do need to watch it right after making commits. I also had no idea that sbin/fsdb shared code with sbin/fsck_ffs. I really do need to get back in the habit of buildworlds before doing any commits. All that said, the changes that you have made are correct. The type is only used for collecting statistics. So, if you do not know the type, using DT_UNKNOWN is correct. If there is ever a desire to collect type-of-I/O statistics in fsdb then that choice will need to be revisited. But, I doubt that type-of-I/O statistics are ever likely to be interesting in fsdb. Kirk McKusick ___ 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 i386/i386
TB --- 2013-03-02 16:10:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-02 16:10: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-03-02 16:10:18 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-02 16:10:18 - cleaning the object tree TB --- 2013-03-02 16:10:18 - /usr/local/bin/svn stat /src TB --- 2013-03-02 16:10:22 - At svn revision 247633 TB --- 2013-03-02 16:10:23 - building world TB --- 2013-03-02 16:10:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 16:10:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 16:10:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 16:10:23 - SRCCONF=/dev/null TB --- 2013-03-02 16:10:23 - TARGET=i386 TB --- 2013-03-02 16:10:23 - TARGET_ARCH=i386 TB --- 2013-03-02 16:10:23 - TZ=UTC TB --- 2013-03-02 16:10:23 - __MAKE_CONF=/dev/null TB --- 2013-03-02 16:10:23 - cd /src TB --- 2013-03-02 16:10:23 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Sat Mar 2 16:10:28 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 Sat Mar 2 18:55:38 UTC 2013 TB --- 2013-03-02 18:55:38 - generating LINT kernel config TB --- 2013-03-02 18:55:38 - cd /src/sys/i386/conf TB --- 2013-03-02 18:55:38 - /usr/bin/make -B LINT TB --- 2013-03-02 18:55:38 - cd /src/sys/i386/conf TB --- 2013-03-02 18:55:38 - /usr/sbin/config -m LINT TB --- 2013-03-02 18:55:38 - building LINT kernel TB --- 2013-03-02 18:55:38 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 18:55:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 18:55:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 18:55:38 - SRCCONF=/dev/null TB --- 2013-03-02 18:55:38 - TARGET=i386 TB --- 2013-03-02 18:55:38 - TARGET_ARCH=i386 TB --- 2013-03-02 18:55:38 - TZ=UTC TB --- 2013-03-02 18:55:38 - __MAKE_CONF=/dev/null TB --- 2013-03-02 18:55:38 - cd /src TB --- 2013-03-02 18:55:38 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Mar 2 18:55:38 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 Kernel build for LINT completed on Sat Mar 2 19:26:40 UTC 2013 TB --- 2013-03-02 19:26:40 - cd /src/sys/i386/conf TB --- 2013-03-02 19:26:40 - /usr/sbin/config -m LINT-NOINET TB --- 2013-03-02 19:26:40 - building LINT-NOINET kernel TB --- 2013-03-02 19:26:40 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 19:26:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 19:26:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 19:26:40 - SRCCONF=/dev/null TB --- 2013-03-02 19:26:40 - TARGET=i386 TB --- 2013-03-02 19:26:40 - TARGET_ARCH=i386 TB --- 2013-03-02 19:26:40 - TZ=UTC TB --- 2013-03-02 19:26:40 - __MAKE_CONF=/dev/null TB --- 2013-03-02 19:26:40 - cd /src TB --- 2013-03-02 19:26:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Sat Mar 2 19:26:40 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 Kernel build for LINT-NOINET completed on Sat Mar 2 19:55:37 UTC 2013 TB --- 2013-03-02 19:55:37 - cd /src/sys/i386/conf TB --- 2013-03-02 19:55:37 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-03-02 19:55:37 - building LINT-NOINET6 kernel TB --- 2013-03-02 19:55:37 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 19:55:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-02 19:55:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-02 19:55:37 - SRCCONF=/dev/null TB --- 2013-03-02 19:55:37 - TARGET=i386 TB --- 2013-03-02 19:55:37 - TARGET_ARCH=i386 TB --- 2013-03-02 19:55:37 - TZ=UTC TB --- 2013-03-02 19:55:37 - __MAKE_CONF=/dev/null TB --- 2013-03-02 19:55:37 - cd /src TB --- 2013-03-02 19:55:37 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Sat Mar 2 19:55:38 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 Kernel build for LINT-NOINET6 completed on Sat Mar 2 20:24:56 UTC 2013 TB --- 2013-03-02 20:24:56 - cd /src/sys/i386/conf TB --- 2013-03-02 20:24:56 - /usr/sbin/config -m LINT-NOIP TB --- 2013-03-02 20:24:56 - building LINT-NOIP kernel TB --- 2013-03-02 20:24:56 - CROSS_BUILD_TESTING=YES TB --- 2013-03-02 20:24:56 - MAKEOBJDIRPREFIX=/obj
Re: access to hard drives is blocked by writes to a flash drive
On 03/02/2013 21:46, Edward Tomasz Napierała wrote: Wiadomość napisana przez deeptech71 w dniu 2 mar 2013, o godz. 18:29: When one of my flash drives is being heavily written to; typically by ``svn update'' on /usr/src, located on the flash drive; the following can be said about filesystem behavior: - ``svn update'' seems to be able to quickly update a bunch of files, but is then unable to continue for a period of time. This behavior is cyclical, and cycles several times, depending on the amount of updating work to be done for a particular run of ``svn update''. - Access to any filesystem, whether on the said flash drive or not, seems to be hindered a lot, typically during the said unable to continue time. Reading of a file on a hard drive was once delayed for more than 10 seconds. Seemingly as a consequence, the starting of top(1) is also typically delayed. When that happens, could you do ps axl and see the WCHAN column for the affected processes? Is it wdrain? What do you mean by the affected processes? The MWCHAN of an ``svn update'' contained long wdrain periods (but included getblk, drainvp, etc.). ``[bufdaemon]'' sometimes seemed to somewhat follow the wdrain state of ``svn update''. I've also found out that the inability for top(1) or ps(1) to start immediately has something to do with X -- in the virtual terminals, there was never a delay. ___ 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: access to hard drives is blocked by writes to a flash drive
On 2013-Mar-02 18:29:54 +0100, deeptech71 deeptec...@gmail.com wrote: When one of my flash drives is being heavily written to; typically by ``svn update'' on /usr/src, located on the flash drive; the following can be said about filesystem behavior: - ``svn update'' seems to be able to quickly update a bunch of files, but is then unable to continue for a period of time. This behavior is cyclical, and cycles several times, depending on the amount of updating work to be done for a particular run of ``svn update''. This sounds like normal flash behaviour: You can only write to erased blocks. The SSD firmware attempts to keep a free pool of erased blocks but if you write too fast, you empty the free pool and need to wait for the wear-levelling algorithm to move blocks around and erase them. Enabling TRIM (the '-t' flag on tunefs) will help if the drive supports TRIM (if it doesn't, it'll probably just lockup). Otherwise, you need to either put up with it or upgrade to a better SSD. I run into this regularly with the low-end SuperTalent drive in my Netbook but have never seen it with the OCZ Agility4 that I use for L2ARC in my fileserver. -- Peter Jeremy pgpPsz41Q1HhI.pgp Description: PGP signature
