svn commit: r343548 - in head/sbin: newfs tunefs
Author: marck (doc committer)
Date: Tue Jan 29 10:21:41 2019
New Revision: 343548
URL: https://svnweb.freebsd.org/changeset/base/343548
Log:
Allow dashes as a valid character in UFS labels.
Reviewed by: mckusick, imp, 0mp
MFC after:2 weeks
Differential Revision:D18991
Modified:
head/sbin/newfs/newfs.8
head/sbin/newfs/newfs.c
head/sbin/tunefs/tunefs.8
head/sbin/tunefs/tunefs.c
Modified: head/sbin/newfs/newfs.8
==
--- head/sbin/newfs/newfs.8 Tue Jan 29 09:22:20 2019(r343547)
+++ head/sbin/newfs/newfs.8 Tue Jan 29 10:21:41 2019(r343548)
@@ -28,7 +28,7 @@
.\" @(#)newfs.88.6 (Berkeley) 5/3/95
.\" $FreeBSD$
.\"
-.Dd July 7, 2017
+.Dd January 29, 2019
.Dt NEWFS 8
.Os
.Sh NAME
@@ -89,7 +89,7 @@ See
for details.
.It Fl L Ar volname
Add a volume label to the new file system.
-Legal characters are alphanumerics and underscores.
+Legal characters are alphanumerics, dashes, and underscores.
.It Fl N
Cause the file system parameters to be printed out
without really creating the file system.
Modified: head/sbin/newfs/newfs.c
==
--- head/sbin/newfs/newfs.c Tue Jan 29 09:22:20 2019(r343547)
+++ head/sbin/newfs/newfs.c Tue Jan 29 10:21:41 2019(r343548)
@@ -153,10 +153,10 @@ main(int argc, char *argv[])
volumelabel = optarg;
i = -1;
while (isalnum(volumelabel[++i]) ||
- volumelabel[i] == '_');
+ volumelabel[i] == '_' || volumelabel[i] == '-');
if (volumelabel[i] != '\0') {
errx(1, "bad volume label. Valid characters "
- "are alphanumerics and underscores.");
+ "are alphanumerics, dashes, and
underscores.");
}
if (strlen(volumelabel) >= MAXVOLLEN) {
errx(1, "bad volume label. Length is longer
than %d.",
Modified: head/sbin/tunefs/tunefs.8
==
--- head/sbin/tunefs/tunefs.8 Tue Jan 29 09:22:20 2019(r343547)
+++ head/sbin/tunefs/tunefs.8 Tue Jan 29 10:21:41 2019(r343548)
@@ -28,7 +28,7 @@
.\" @(#)tunefs.8 8.2 (Berkeley) 12/11/93
.\" $FreeBSD$
.\"
-.Dd April 19, 2016
+.Dd January 29, 2019
.Dt TUNEFS 8
.Os
.Sh NAME
@@ -112,7 +112,7 @@ By default
sets it to half of the space reserved to minfree.
.It Fl L Ar volname
Add/modify an optional file system volume label.
-Legal characters are alphanumerics and underscores.
+Legal characters are alphanumerics, dashes, and underscores.
.It Fl l Cm enable | disable
Turn on/off MAC multilabel flag.
.It Fl m Ar minfree
Modified: head/sbin/tunefs/tunefs.c
==
--- head/sbin/tunefs/tunefs.c Tue Jan 29 09:22:20 2019(r343547)
+++ head/sbin/tunefs/tunefs.c Tue Jan 29 10:21:41 2019(r343548)
@@ -189,10 +189,13 @@ main(int argc, char *argv[])
name = "volume label";
Lvalue = optarg;
i = -1;
- while (isalnum(Lvalue[++i]) || Lvalue[i] == '_');
+ while (isalnum(Lvalue[++i]) || Lvalue[i] == '_' ||
+ Lvalue[i] == '-')
+ ;
if (Lvalue[i] != '\0') {
errx(10, "bad %s. Valid characters are "
- "alphanumerics and underscores.", name);
+ "alphanumerics, dashes, and underscores.",
+ name);
}
if (strlen(Lvalue) >= MAXVOLLEN) {
errx(10, "bad %s. Length is longer than %d.",
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343483 - in head/sbin: newfs tunefs
Kirk,
On Sat, 26 Jan 2019, Kirk McKusick wrote:
> Author: mckusick
> Date: Sat Jan 26 22:27:12 2019
> New Revision: 343483
> URL: https://svnweb.freebsd.org/changeset/base/343483
>
> Log:
> Update tunefs and newfs error messages for the -L (volume label) option
> to note that underscores are valid.
while you're here -- most of FSes also allow dash as a valid symbol in FS name.
I stepped on it several times, and even did some local patch, but was too lazy
to sumbit it.
could you please look into it?
thanks!
>
> PR: 235182
> Reported by: Rodney W. Grimes (rgrimes@)
> Sponsored by: Netflix
>
> Modified:
> head/sbin/newfs/newfs.c
> head/sbin/tunefs/tunefs.c
>
> Modified: head/sbin/newfs/newfs.c
> ==
> --- head/sbin/newfs/newfs.c Sat Jan 26 22:24:15 2019(r343482)
> +++ head/sbin/newfs/newfs.c Sat Jan 26 22:27:12 2019(r343483)
> @@ -155,7 +155,8 @@ main(int argc, char *argv[])
> while (isalnum(volumelabel[++i]) ||
> volumelabel[i] == '_');
> if (volumelabel[i] != '\0') {
> - errx(1, "bad volume label. Valid characters are
> alphanumerics.");
> + errx(1, "bad volume label. Valid characters "
> + "are alphanumerics and underscores.");
> }
> if (strlen(volumelabel) >= MAXVOLLEN) {
> errx(1, "bad volume label. Length is longer
> than %d.",
>
> Modified: head/sbin/tunefs/tunefs.c
> ==
> --- head/sbin/tunefs/tunefs.c Sat Jan 26 22:24:15 2019(r343482)
> +++ head/sbin/tunefs/tunefs.c Sat Jan 26 22:27:12 2019(r343483)
> @@ -191,9 +191,8 @@ main(int argc, char *argv[])
> i = -1;
> while (isalnum(Lvalue[++i]) || Lvalue[i] == '_');
> if (Lvalue[i] != '\0') {
> - errx(10,
> - "bad %s. Valid characters are alphanumerics.",
> - name);
> + errx(10, "bad %s. Valid characters are "
> + "alphanumerics and underscores.", name);
> }
> if (strlen(Lvalue) >= MAXVOLLEN) {
> errx(10, "bad %s. Length is longer than %d.",
> ___
> svn-src-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
--
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: ma...@freebsd.org ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r343164 - head/usr.sbin/jail
Author: marck (doc committer)
Date: Fri Jan 18 23:00:52 2019
New Revision: 343164
URL: https://svnweb.freebsd.org/changeset/base/343164
Log:
Clarify error messages a bit.
X-Found-With: r343112
MFC after:1 month
Modified:
head/usr.sbin/jail/command.c
Modified: head/usr.sbin/jail/command.c
==
--- head/usr.sbin/jail/command.cFri Jan 18 22:20:29 2019
(r343163)
+++ head/usr.sbin/jail/command.cFri Jan 18 23:00:52 2019
(r343164)
@@ -497,7 +497,7 @@ run_command(struct cfjail *j)
argv = alloca(7 * sizeof(char *));
path = string_param(j->intparams[KP_PATH]);
if (path == NULL) {
- jail_warnx(j, "mount.devfs: no path");
+ jail_warnx(j, "mount.devfs: no jail root path defined");
return -1;
}
devpath = alloca(strlen(path) + 5);
@@ -528,7 +528,7 @@ run_command(struct cfjail *j)
argv = alloca(7 * sizeof(char *));
path = string_param(j->intparams[KP_PATH]);
if (path == NULL) {
- jail_warnx(j, "mount.fdescfs: no path");
+ jail_warnx(j, "mount.fdescfs: no jail root path
defined");
return -1;
}
devpath = alloca(strlen(path) + 8);
@@ -554,7 +554,7 @@ run_command(struct cfjail *j)
argv = alloca(7 * sizeof(char *));
path = string_param(j->intparams[KP_PATH]);
if (path == NULL) {
- jail_warnx(j, "mount.procfs: no path");
+ jail_warnx(j, "mount.procfs: no jail root path
defined");
return -1;
}
devpath = alloca(strlen(path) + 6);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339413 - in head: libexec libexec/rc libexec/rc/rc.d sbin/init sbin/init/rc.d
On Wed, 17 Oct 2018, Nathan Whitehorn wrote: > Is there some high-level overview of the plan for pkgbase somewhere? > Which things will be in which packages, how the tools will work, etc.? > I'm still a little confused by how things are intended to work and it's > a bit hard to follow from commits with lots of small reorganizations. possibly https://wiki.freebsd.org/PkgBase but it's pretty vague [snip] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r337497 - in head: . contrib/mdocml contrib/tnftp/src etc/root share/skel tools/tools/nanobsd/pcengines/Files/root tools/tools/nanobsd/rescue/Files/root usr.bin/mail usr.bin/man usr.bi
On Fri, 24 Aug 2018, Kyle Evans wrote: [snip] > >> Any chance you'd consider `less -E` for mergemaster, instead of > >> unsalted less? After going through a second round of updates since > >> this, that one feels super repetitive as you end up with two > >> keystrokes at the end per file that differs as opposed to the previous > >> one. This is pretty nit-picky, so I won't be upset if you say no. =) > >> > >> Thanks, > >> > >> Kyle Evans > > > > > > Hmm, "-E" would make sense for mergemaster, even though I hate that > > behavior for man. But if mergemaster's pager is going to use different > > options than other applications, then it also should get its own variable; > > mergemaster should use MERGEMASTERPAGER the way that man uses MANPAGER. > > Agree? > > I'm inclined to agree on both counts. While I don't like a > proliferation of things to set to override defaults like this in the > general case, it seems to make sense for mergemaster. The application > of pager here is a different use case than most. What about freebsd-update then? Usually one should type 'q' twice on two empty lists there. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r313675 - in head/sys: netinet netinet6
On Sun, 12 Feb 2017, Glen Barber wrote: [snip previous] > > I didn't read this when I hit send on my email. Hopefully nobody takes > > offense. I was upset and still am. > > > > I still think that the revision numbers of any backout should have been > > documented in the commit log. > > > > I absolutely agree, and was the key meaning behind my "what exactly does > this mean?" reply. The commit log, as-is, provides nothing useful to > the reader. > > > Something we could do, as is expected by re@ for commits during a freeze, > > is metees also let their mentors know of what the contents of commit log > > messages will be. I think commit log messages discussing the what, why and > > rationale are as important as the code itself. > > > > I thought this was standard practice. But if not, I would agree that > both code changes and the commit log should be both approved by the > mentor. Shouldn't we then emphacise this in the Committer's Guide? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r313330 - in head: contrib/netcat lib/libipsec sbin/ifconfig sbin/setkey share/man/man4 sys/conf sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/net sys/netinet sys/netinet/tc
On Mon, 6 Feb 2017, Andrey V. Elsukov wrote: > Author: ae > Date: Mon Feb 6 08:49:57 2017 > New Revision: 313330 > URL: https://svnweb.freebsd.org/changeset/base/313330 > > Log: > Merge projects/ipsec into head/. [snip] Great, thanks! Have you any plans to merge this into stable/11 to reduce diffs in network stack code? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r298011 - head/sys/cam/ata
On Fri, 15 Apr 2016, Warner Losh wrote:
> A shorter timeout dramatically cuts the length of time that the
> queue has to be frozen for error recovery. This allows one,
> in theory, to recover the system more quickly after a drive
> goes off into the weeds.
May be make some more generic changes? Could we detect SSD vs spinning disk vs
unknown and set timeouts accordigly to the nature of the underlying device?
>
> Warner
>
>
> > On Apr 15, 2016, at 9:23 AM, Ronald Klop <ronald-li...@klop.ws> wrote:
> >
> > Hello,
> >
> > Out of curiosity, what are these big problems? Broken device or other
> > things (timeouts/triggers/full queues) going on in the kernel?
> >
> > Regards,
> > Ronald.
> >
> >
> > On Fri, 15 Apr 2016 00:13:46 +0200, Warner Losh <i...@freebsd.org> wrote:
> >
> >> Author: imp
> >> Date: Thu Apr 14 22:13:46 2016
> >> New Revision: 298011
> >> URL: https://svnweb.freebsd.org/changeset/base/298011
> >> erLog:
> >> Add a comment about why the timeout for flush was lowered to 5s.
> >>
> >> Modified:
> >> head/sys/cam/ata/ata_da.c
> >>
> >> Modified: head/sys/cam/ata/ata_da.c
> >> ==
> >> --- head/sys/cam/ata/ata_da.c Thu Apr 14 22:13:44 2016
> >> (r298010)
> >> +++ head/sys/cam/ata/ata_da.c Thu Apr 14 22:13:46 2016
> >> (r298011)
> >> @@ -912,6 +912,11 @@ adadump(void *arg, void *virtual, vm_off
> >>if (softc->flags & ADA_FLAG_CAN_FLUSHCACHE) {
> >>xpt_setup_ccb(_h, periph->path, CAM_PRIORITY_NORMAL);
> >> + /*
> >> + * Tell the drive to flush its intenral cache. if we
> >> + * can't flush in 5s we have big problems. No need to
> >> + * wait the default 60s to detect problems.
> >> + */
> >>ccb.ccb_h.ccb_state = ADA_CCB_DUMP;
> >>cam_fill_ataio(,
> >>0,
> >> ___
> >> svn-src-...@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> >> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
>
>
--
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: ma...@freebsd.org ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r298002 - in head/sys: cam cam/ata cam/scsi conf dev/ahci
Warner, On Thu, 14 Apr 2016, Warner Losh wrote: > You add CAM_NETFLIX_IOSCHED to your kernel config to enable it. Hmmm, > looking at the diff, perhaps I should add that to LINT. > > In production, we use it for three things. First, our scheduler keeps a lot > more statistics than the default one. These statistics are useful for us > knowing when a system is saturated and needs to shed load. Second, we favor > reads over writes because our workload, as you might imagine, is a read > mostly work load. Finally, in some systems, we throttle the write throughput > to the SSDs. The SSDs we buy can do 300MB/s write while serving 400MB/s read, > but only for short periods of time (long enough to do 10-20GB of traffic). > After that, write performance drops, and read performance goes out the > window. Experiments have shown that if we limit the write speed to no more > than 30MB/s or so, then the garbage collection the drive is doing won't > adversely affect the read latency / performance. > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf Thank you again for clarifications! I'd reacted because we're @work possibly can see similar (while not nearly as comparable loads, of course!) patterns. > > This code has run in production at Netflix for over a year now. > > > > Looking at this: could it be possibly targeted for MFCing? > > While this has been running in 10.x stable for the past year on our servers, > I have no plans to MFC it at this time. Great, at least it could be played with then! ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r298002 - in head/sys: cam cam/ata cam/scsi conf dev/ahci
Warner, On Thu, 14 Apr 2016, Warner Losh wrote: > Author: imp > Date: Thu Apr 14 21:47:58 2016 > New Revision: 298002 > URL: https://svnweb.freebsd.org/changeset/base/298002 > > Log: > New CAM I/O scheduler for FreeBSD. The default I/O scheduler is the same [snip] First, thanks so much for this quite a non-trivial work! What are the ways to enable this instead of deafult, and what ar the benefits and drawbacks? > This code has run in production at Netflix for over a year now. Looking at this: could it be possibly targeted for MFCing? [snip all the diff] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] -------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r289109 - head/sys/dev/drm2/i915
On Sat, 10 Oct 2015, Jean-S?bastien P?dron wrote: > That said, I'm not sure a kernel from HEAD will work nicely with > userland from 10.2. That's worth a try. well, it should -- otherwise stable/10 jails would not work under -current. Not the other way os course. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] ---- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r286570 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys
Alexander, On Mon, 10 Aug 2015, Alexander Motin wrote: Author: mav Date: Mon Aug 10 10:34:23 2015 New Revision: 286570 URL: https://svnweb.freebsd.org/changeset/base/286570 Log: MFV r277426: 5408 managing ZFS cache devices requires lots of RAM illumos/illumos-gate@89c86e32293a30cdd7af530c38b2073fee01411c [snip] For an average blocksize of 8KB, this means that for the L2ARC, the ratio of metadata to data has gone down from about 2.92% to 1.56%. For a 'storage optimized' EC2 instance with 1600GB of SSD and 60GB of RAM, this means that we expect a completely full L2ARC to use (1600 GB * 0.0156) / 60GB = 41% of the available memory, down from 78%. Thanks! Any MFC planned please? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r285387 - in head: lib/libc/sys share/man/man4 sys/conf sys/kern sys/sys sys/vm usr.bin usr.bin/numactl
Adrian, On Sat, 11 Jul 2015, Adrian Chadd wrote: Author: adrian Date: Sat Jul 11 15:21:37 2015 New Revision: 285387 URL: https://svnweb.freebsd.org/changeset/base/285387 Log: Add an initial NUMA affinity/policy configuration for threads and processes. This is totally awesome. Thank you and all related people/companies a lot. [snip all the rest] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r284683 - head/etc/etc.arm
On Sun, 21 Jun 2015, John-Mark Gurney wrote: Glen Barber wrote this message on Sun, Jun 21, 2015 at 19:50 +: Author: gjb Date: Sun Jun 21 19:50:02 2015 New Revision: 284683 URL: https://svnweb.freebsd.org/changeset/base/284683 Log: Enable ttyu1, ttyu2, ttyu3 for arm installations. This should make all consoles available, whether it is VGA, HDMI, serial, or JTAG, but more importantly enables all consoles when ttyu0 is not predictable. For example, the Pandaboard ES apparently has three consoles available, but the DB9/RS232 serial port is ttyu2, so not available by default after the system boots. I was about to do the same for at least ttyu1 for amd64/i386 as the RCC-VE 4860 from Netgate has the console on com2 (2f8) instead of com1(3f8)... I couldn't use the live cd part of the memstick because of this... also, many, if not all, IPMI default configs have SOL console on either com3 or com2 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r283383 - in head/sys: amd64/linux32 compat/linux i386/linux
On Sun, 24 May 2015, Dmitry Chagin wrote: Author: dchagin Date: Sun May 24 14:53:16 2015 New Revision: 283383 URL: https://svnweb.freebsd.org/changeset/base/283383 Log: Switch linuxulator to use the native 1:1 threads. Wow. Quite a bit of work! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r281451 - head/sys/vm
On Sat, 25 Apr 2015, Scott Long via svn-src-all wrote: True, it's not actually odd, it's just surprising the first time one comes across it. Also, I goofed in the text: With the flexible array, (sizeof(struct uma_cache)) is going to be 32 bytes smaller than without it. It's `struct uma_zone` that shrinks by (potentially) more than one would expect. (The uma_cache struct is itself 32 bytes and is not changed, so the args.size value should be the same -- implying that some OTHER sizeof(struct uma_zone) is where things are going wrong.) vm_mem_init() called before uma init. unfortunately, we have not seen a proper info about panic from scottl Too early in boot to get a crashdump. ... and even console not set up enough to have a backtrace/some debugging printfs displayed? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r281373 - in head: contrib/nvi contrib/nvi/catalog contrib/nvi/cl contrib/nvi/common contrib/nvi/docs contrib/nvi/docs/USD.doc contrib/nvi/docs/internals contrib/nvi/docs/interp contri
On Fri, 10 Apr 2015, Baptiste Daroussin wrote: Update nvi to 2.1.3 which fixes the data corruption when locale conversion failed Thank you very much for this import. Any MFC Planned please? Not before I find how to readd the lost documentations Fair enough; thanks again for your attention! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r281026 - in head/sys: cddl/contrib/opensolaris/uts/common/fs/zfs kern sys
Alexander, On Fri, 3 Apr 2015, Alexander Motin wrote: Author: mav Date: Fri Apr 3 14:45:48 2015 New Revision: 281026 URL: https://svnweb.freebsd.org/changeset/base/281026 Log: Make ZFS ARC track both KVA usage and fragmentation. Even on Illumos, with its much larger KVA, ZFS ARC steps back if KVA usage reaches certain threshold (3/4 on i386 or 16/17 otherwise). FreeBSD has even less KVA, but had no such limit on archs with direct map as amd64. As result, on machines with a lot of RAM, during load with very small user- space memory pressure, such as `zfs send`, it was possible to reach state, when there is enough both physical RAM and KVA (I've seen up to 25-30%), but no continuous KVA range to allocate even single 128KB I/O request. Address this situation from two sides: - restore KVA usage limitations in a way the most close to Illumos; - introduce new requirement for KVA fragmentation, specifying that we should have at least one sequential KVA range of zfs_max_recordsize bytes. Experiments show that first limitation done alone is not sufficient. On machine with 64GB of RAM it is sometimes needed to drop up to half of ARC size to get at leats one 1MB KVA chunk. Statically limiting ARC to half of KVA/RAM is too strict, so second limitation makes it to work in cycles: accumulate trash up to certain critical mass, do massive spring-cleaning, and then start littering again. :) MFC after: 1 month Wow. Excellent dig, thank you. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r280323 - head/sys/kern
On Sat, 21 Mar 2015, Konstantin Belousov wrote: Somewhat modernize the SysV shm code: Is my understanding correct that postgres still uses shm? If so, has someone benchmarked the speedup? Yes, some versions of Postgres still use SysV shm. To be clarified: IIUC, *all* contemporary versions of PostgreSQL do use SHM for shatrd buffers (as PgSQL use process-per-connection model) No. Recent versions use mmaped shared region for buffers. Yes, starting from 9.3 main buffers are memory-mapped. SysV SHM and Semaphores *are* still in use though. (mainly for search engines) Thanks for the clarification. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r280323 - head/sys/kern
On Sat, 21 Mar 2015, Konstantin Belousov wrote: Somewhat modernize the SysV shm code: Interesting. Is my understanding correct that postgres still uses shm? If so, has someone benchmarked the speedup? Yes, some versions of Postgres still use SysV shm. To be clarified: IIUC, *all* contemporary versions of PostgreSQL do use SHM for shatrd buffers (as PgSQL use process-per-connection model) But note that the code changed only works during shared segment creation and teardown. Page faults are handled by the same VM code as it was before. In other words, I expect that nothing changes WRT benchmarks. On the other hand, I also do not see anything that could change benchmarks significally -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r279783 - head/usr.bin/ctlstat
Author: marck (doc committer) Date: Sun Mar 8 17:34:06 2015 New Revision: 279783 URL: https://svnweb.freebsd.org/changeset/base/279783 Log: Correct wordings a bit. MFC after:1 week Modified: head/usr.bin/ctlstat/ctlstat.8 Modified: head/usr.bin/ctlstat/ctlstat.8 == --- head/usr.bin/ctlstat/ctlstat.8 Sun Mar 8 16:50:45 2015 (r279782) +++ head/usr.bin/ctlstat/ctlstat.8 Sun Mar 8 17:34:06 2015 (r279783) @@ -34,7 +34,7 @@ .\ $Id: //depot/users/kenm/FreeBSD-test2/usr.bin/ctlstat/ctlstat.8#2 $ .\ $FreeBSD$ .\ -.Dd March 6, 2013 +.Dd March 8, 2015 .Dt CTLSTAT 8 .Os .Sh NAME @@ -69,7 +69,7 @@ and a combined total column that also in .It Fl c Ar count Display statistics this many times. .It Fl C -Disable display of CPU statistics. +Disable CPU statistics. .It Fl d Display DMA operation time (latency) instead of overall I/O time (latency). .It Fl D ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r279361 - in head: sys/kern sys/sys usr.sbin/jail
On Mon, 2 Mar 2015, Ian Lepore wrote: Log: Allow the kern.osrelease and kern.osreldate sysctl values to be set in a jail's creation parameters. This allows the kernel version to be reliably spoofed within the jail whether examined directly with sysctl or indirectly with the uname -r and -K options. [..] There is no sanity or range checking, other than disallowing an empty release string or a zero release date, by design. The system administrator is trusted to set sane values. Setting values that are newer than the actual running kernel will likely cause compatibility problems. I would think that you could at set time ensure that only older releases were allowed.. I'm not sure what the rule would be with sub-sub-jails.. older than parent, or older than base system..? I am a really really strong believer in giving administrators complete control of their systems. If they want to do something stupid because it works for them, I'm not going to stop them. Well, what about giving them a hinting warning in such case? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r279361 - in head: sys/kern sys/sys usr.sbin/jail
Ian, On Fri, 27 Feb 2015, Ian Lepore wrote: Author: ian Date: Fri Feb 27 16:28:55 2015 New Revision: 279361 URL: https://svnweb.freebsd.org/changeset/base/279361 Log: Allow the kern.osrelease and kern.osreldate sysctl values to be set in a jail's creation parameters. This allows the kernel version to be reliably spoofed within the jail whether examined directly with sysctl or indirectly with the uname -r and -K options. The values can only be set at jail creation time, to eliminate the need for any locking when accessing the values via sysctl. The overridden values are inherited by nested jails (unless the config for the nested jails also overrides the values). There is no sanity or range checking, other than disallowing an empty release string or a zero release date, by design. The system administrator is trusted to set sane values. Setting values that are newer than the actual running kernel will likely cause compatibility problems. Differential Revision: https://reviews.freebsd.org/D1948 Relnotes: yes Thanks, very useful feature. Just one question: no MFC planned? [diff snipped] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r279361 - in head: sys/kern sys/sys usr.sbin/jail
On Sat, 28 Feb 2015, Ian Lepore wrote: Thanks, very useful feature. Just one question: no MFC planned? [diff snipped] I will definitely mfc (we need this on 10-stable at $work), but I hate being spammed and/or nagged by robots so I don't use MFC: tags. X-MFC-in: $period would suffice both your and others needs I suppose then... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r279030 - in head/sys: net netinet netinet6
On Thu, 19 Feb 2015, Gleb Smirnoff wrote: Author: glebius Date: Thu Feb 19 23:16:10 2015 New Revision: 279030 URL: https://svnweb.freebsd.org/changeset/base/279030 Log: Now that all users of _WANT_IFADDR are fixed, remove this crutch and hide ifaddr, in_ifaddr and in6_ifaddr under _KERNEL. Wow, finally! ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r278433 - in head: . contrib/xz contrib/xz/src/common contrib/xz/src/liblzma contrib/xz/src/liblzma/api contrib/xz/src/liblzma/api/lzma contrib/xz/src/liblzma/check contrib/xz/src/libl
Rui, On Mon, 9 Feb 2015, Rui Paulo wrote: No, I didn't, but now it should be easy for you to try! :-) Unfortunately, the most powerful machine @myhands is 2*8core root@briareus:~# sysctl hw.model hw.model: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz root@briareus:~# sysctl hw.ncpu hw.ncpu: 16 and even this one is mostly loaded with $JOB ;) I'll try comparing with my home fileserver, which is on marck@hamster:~ sysctl hw.model hw.model: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz marck@hamster:~ sysctl hw.ncpu hw.ncpu: 4 and load is rather moderate, especially if I stop smbd ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r278433 - in head: . contrib/xz contrib/xz/src/common contrib/xz/src/liblzma contrib/xz/src/liblzma/api contrib/xz/src/liblzma/api/lzma contrib/xz/src/liblzma/check contrib/xz/src/libl
Glen, On Mon, 9 Feb 2015, Glen Barber wrote: Log: Merge xz 5.2.0. This brings support for multi-threaded compression. This brings close N times faster compression where N is the number of CPU cores. Because of this, liblzma now depends on libthr. This is fantastic, thank you for doing this update. FWIW, compressing VM images (some sparse files, some not) would take upwards of 45 minutes, which after this update, just takes a few minutes. root@releng2:/R2/vmimages # time xz -T 0 -k FreeBSD-11.0-CURRENT-amd64.qcow2 \ time xz -T 0 -k FreeBSD-11.0-CURRENT-amd64.raw; \ time xz -T 0 -k FreeBSD-11.0-CURRENT-amd64.vhd; \ time xz -T 0 -k FreeBSD-11.0-CURRENT-amd64.vmdk 1027.602u 40.376s 1:09.57 1535.1% 81+192k 0+19774io 0pf+0w 1032.978u 38.823s 1:08.17 1572.2% 81+192k 0+19696io 0pf+0w 1033.908u 38.593s 1:11.70 1495.8% 81+192k 0+19729io 0pf+0w 1091.749u 42.371s 1:04.27 1764.6% 81+192k 0+19751io 0pf+0w I meant to include that this is on a 48-core machine. Hm, I can't beleive you didn't use pxz ;) Anyway, having this in base, and not depending on external tool, is amazingly great. BTW, Rui, did you some comparative tests with pxz? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r276083 - head/etc
Author: marck (doc committer) Date: Mon Dec 22 21:26:49 2014 New Revision: 276083 URL: https://svnweb.freebsd.org/changeset/base/276083 Log: Add VAMI (VMware Appliance Management Interface) port. Reviewed by: eadler MFC after:2 weeks Modified: head/etc/services Modified: head/etc/services == --- head/etc/services Mon Dec 22 21:06:26 2014(r276082) +++ head/etc/services Mon Dec 22 21:26:49 2014(r276083) @@ -2345,6 +2345,8 @@ mdns 5353/tcp #Multicast DNS mdns 5353/udp #Multicast DNS postgresql 5432/tcp #PostgreSQL Database postgresql 5432/udp #PostgreSQL Database +vami 5480/tcp #VMware Appliance Management Interface, HTTPS-like +vami 5480/udp #VMware Appliance Management Interface, HTTPS-like rplay /udp amqp 5672/sctp #AMQP amqp 5672/tcp #AMQP ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r275385 - head/contrib/subversion/subversion/svn
On Tue, 2 Dec 2014, Baptiste Daroussin wrote: Author: bapt Date: Tue Dec 2 00:23:26 2014 New Revision: 275385 URL: https://svnweb.freebsd.org/changeset/base/275385 Log: Sync the svn template with the one from ports Possibly dumb question: I we patch this file anyway, could we possibly extract template to external file? and, finally, convince this to upstream? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r274095 - head/release
On Tue, 4 Nov 2014, Glen Barber wrote: Author: gjb Date: Tue Nov 4 17:24:13 2014 New Revision: 274095 URL: https://svnweb.freebsd.org/changeset/base/274095 Log: Fix VOLUME_LABEL when BRANCH contains non-alpha characters, in particular '-' and '.'. [snip] By the way, what are original reasons to not allow '-' and '_' in volume names? It looks a bit inconsistent with other file systems volume labels... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r274095 - head/release
On Tue, 4 Nov 2014, Jung-uk Kim wrote: Log: Fix VOLUME_LABEL when BRANCH contains non-alpha characters, in particular '-' and '.'. [snip] By the way, what are original reasons to not allow '-' and '_' in volume names? It looks a bit inconsistent with other file systems volume labels... AFAIK, it is an ISO9660 limitation, i.e., it must be d-characters. http://wiki.osdev.org/ISO_9660#String_format http://wiki.osdev.org/ISO_9660#The_Primary_Volume_Descriptor In fact, makefs(8) enforces this rule. Ah, so iso9660 has stricter rules than, say, xFAT/NTFS and even UFS... Maybe then we could distinguish file system type given to makefs(8) and apply different check/sed rules depending on it? I mean: it looks a bit unexpected (if not uncomfortable) to have label set up by outer OS accepted by geom_label (and thus created in /dev tree) but unable to duplicate it via makefs(8) and similar mechanisms... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r274095 - head/release
On Tue, 4 Nov 2014, Dag-Erling Sm?rgrav wrote: Maybe then we could distinguish file system type given to makefs(8) and apply different check/sed rules depending on it? More work, more complexity, more opportunity for error, for - let's be honest here - absolutely no gain. I do see your point, Dag-Erling, and honestly have no real counter-arguments ;) Well, so be it. (another sidenote: it's quite an example of be permissive on input, and restrictive on output principle) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r272384 - head/usr.bin/mkimg
On Fri, 3 Oct 2014, Ed Maste wrote: On 2 October 2014 10:43, Ed Maste ema...@freebsd.org wrote: I've been using brooks' NO_ROOT support along with makefs / mkimg to build and test changes by creating an image to boot in QEMU. This change provides a noticeable improvement in the cycle time. I've had a couple of inquiries about the workflow I've been using, so I've added a brief set of steps to my Wiki page at https://wiki.freebsd.org/EdMaste/BuildVM . With -DNO_ROOT for the install targets an mtree file named METALOG file is created at the top of DESTDIR. Files are installed owned by the user, without special flags. Makefs reads the METALOG file and applies the desired ownership, permissions and flags in the generated file system. Then mkimg creates an image with a GPT partition table, the UFS filesystem created by makefs, and the various boot loader bits for legacy and UEFI boot. Wouldn't it be useful for automating backing up config directories? I'd think about copying, say, /etc and /usr/local/etc to sometemporary place, changing owner to non-privileged user, and then commit changes (removals should be treated specially, of course) to some kind of SCM? Or, does such project exist already? I failed to find it, but maybe my goole-fu is lacking necessary components ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
Steve, On Thu, 28 Aug 2014, Steven Hartland wrote: Author: smh Date: Thu Aug 28 19:50:08 2014 New Revision: 270759 URL: http://svnweb.freebsd.org/changeset/base/270759 Log: Refactor ZFS ARC reclaim logic to be more VM cooperative [snip] Credit to Karl Denninger for the original patch on which this update was based. Tested by: dteske MFC after: 1 week Relnotes: yes Sponsored by: Multiplay Thank you, and also Karl and Devin for this work! Is this change applicable to stable/9? I suppose, pretty large base of users could benefit from this. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm
On Thu, 28 Aug 2014, Steven Hartland wrote: Thank you, and also Karl and Devin for this work! Is this change applicable to stable/9? I suppose, pretty large base of users could benefit from this. Its very likely applicable to stable/9 although I've never used 9 myself, we jumped from 9 direct to 10. My target for this is to make the cutoff for 10.1 freeze. I'll MFC to 9 and possibly 8 as well at that time if relavent. No rush for other stable branches, surely; also, we're at the EoL (EoS at least) for stable/8 -- but if the changeset is not too harsh I see no reason not to merge it down there. As I @work have some loaded machines with ZFS base on at least 9 (while not really memory-loaded, not more than 32G -- but sometimes rather heavy loaded with userbase apps), I would be glad to test changesets if it's feasible. Thanks again! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r269882 - head/share/misc
Author: marck (doc committer) Date: Tue Aug 12 16:51:37 2014 New Revision: 269882 URL: http://svnweb.freebsd.org/changeset/base/269882 Log: (belatedly) Document FreeBSD 9.3-R MFC after:1 week Mmisc/bsd-family-tree Modified: head/share/misc/bsd-family-tree Modified: head/share/misc/bsd-family-tree == --- head/share/misc/bsd-family-tree Tue Aug 12 16:08:13 2014 (r269881) +++ head/share/misc/bsd-family-tree Tue Aug 12 16:51:37 2014 (r269882) @@ -291,21 +291,21 @@ FreeBSD 5.2 | | | | | | | | | | FreeBSD | |NetBSD 6.1.2 | | |9.2 Mac OS X | | | | - | 10.9| |OpenBSD 5.4 | - || | | | DragonFly 3.6.0 - || | | | | - *--FreeBSD | |NetBSD 6.1.3 | | - | 10.0 | | | | | - || | | | DragonFly 3.6.1 - || | | | | - || | | | | - || | | | DragonFly 3.6.2 - || |NetBSD 6.1.4 | | - || | | | - || |OpenBSD 5.5 | - || | | DragonFly 3.8.0 - || | | | - || | | | + | | 10.9| |OpenBSD 5.4 | + | `-.| | | | DragonFly 3.6.0 + |\ | | | | | + *--FreeBSD| | |NetBSD 6.1.3 | | + | 10.0 | | | | | | + | | | | | | DragonFly 3.6.1 + | | | | | | | + | | | | | | | + | | | | | | DragonFly 3.6.2 + | | | |NetBSD 6.1.4 | | + | | | | | | + | | | |OpenBSD 5.5 | + | | | | | DragonFly 3.8.0 + | FreeBSD | | | | + |9.3 | | | | || | | | || | | | || | | | @@ -640,6 +640,7 @@ NetBSD 6.0.52014-04-19 [NDB] NetBSD 6.1.4 2014-04-19 [NDB] OpenBSD 5.52014-05-01 [OBD] DragonFly 3.8.02014-06-04 [DFB] +FreeBSD 9.32014-07-05 [FBD] Bibliography ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r268461 - in head: . gnu/lib/libreadline gnu/lib/libreadline/history gnu/lib/libreadline/readline gnu/lib/libreadline/readline/doc gnu/usr.bin/gdb gnu/usr.bin/gdb/gdb gnu/usr.bin/gdb/g
On Thu, 10 Jul 2014, Bruce Evans wrote: [snip] FreeBSD-~5.2 i386, statically linked: PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND 681 root1 760 1676K 1132K select 0:00 0.00% sshd 659 root1 44 r0 848K 536K select 0:00 0.00% ntpd 688 root1 760 2084K 1796K select 0:00 0.00% sendmail FreeBSD-11 i386, dynamically linked: PID USERNAME THR PRI NICE SIZERES STATE C TIMEWCPU COMMAN 25072 bde 1 200 17836K 6556K select 1 0:00 0.00% sshd 693 root 1 200 12356K 4168K select 4 0:02 0.00% ntpd 744 root 1 200 12868K 4752K select 0 0:01 0.00% sendma The output also shows misformatting of the USERNAME column in newer versions of FreeBSD (lots of unused whitespace to kill the command name non-whitespace). IIUC, this is historical tolp behaviour: username field width depends on the longest username on the system -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r267357 - head/sys/geom/part
On Thu, 12 Jun 2014, Andrey V. Elsukov wrote: Author: ae Date: Wed Jun 11 10:19:11 2014 New Revision: 267357 URL: http://svnweb.freebsd.org/changeset/base/267357 Log: Add aliases for DragonFlyBSD's partition types. These should be documented in sbin/geom/class/part/gpart.8 also. I don't think we should document partition types for all foreign systems. gpart(8) exists only in FreeBSD and it's purpose manage partitions in FreeBSD. We already have a lot of NetBSD's and Apple's aliases that aren't documented, but nobody complained about that. In this case it is mostly cosmetic change. It allows to see aliases in the `gpart show` output. Having a lot of partition types documented can confuse users. IMHO. :) I do not have strong opinion about it, but at least jmg@ asked me to document my set of VMware FSes additions ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r267357 - head/sys/geom/part
On Wed, 11 Jun 2014, Andrey V. Elsukov wrote: Author: ae Date: Wed Jun 11 10:19:11 2014 New Revision: 267357 URL: http://svnweb.freebsd.org/changeset/base/267357 Log: Add aliases for DragonFlyBSD's partition types. These should be documented in sbin/geom/class/part/gpart.8 also. [snip] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r266859 - head/share/man/man4
Author: marck (doc committer) Date: Thu May 29 21:02:57 2014 New Revision: 266859 URL: http://svnweb.freebsd.org/changeset/base/266859 Log: Change examples to have master skew above 0 to have ability to overwrite this from the slave (for example, when master is failing on disk IO and could not be logged into or execute cronjob). Commented out examples changed too to simplify future merging. Idea by: k...@zvuki.ru Discussed with: glebius MFC after:1 week Modified: head/share/man/man4/carp.4 Modified: head/share/man/man4/carp.4 == --- head/share/man/man4/carp.4 Thu May 29 21:00:06 2014(r266858) +++ head/share/man/man4/carp.4 Thu May 29 21:02:57 2014(r266859) @@ -210,17 +210,18 @@ Enable it on both hosts A and B: .Pp Assume that host A is the preferred master and we are running the 192.168.1.0/24 prefix on em0 and 192.168.2.0/24 on em1. -This is the setup for host A: +This is the setup for host A (advskew is above 0 so it could be overwritten +in the emergency situation from the other host): .Bd -literal -offset indent -ifconfig em0 vhid 1 pass mekmitasdigoat 192.168.1.1/24 -ifconfig em1 vhid 2 pass mekmitasdigoat 192.168.2.1/24 +ifconfig em0 vhid 1 advskew 100 pass mekmitasdigoat 192.168.1.1/24 +ifconfig em1 vhid 2 advskew 100 pass mekmitasdigoat 192.168.2.1/24 .Ed .Pp The setup for host B is identical, but it has a higher .Cm advskew : .Bd -literal -offset indent -ifconfig em0 vhid 1 advskew 100 pass mekmitasdigoat 192.168.1.1/24 -ifconfig em1 vhid 2 advskew 100 pass mekmitasdigoat 192.168.2.1/24 +ifconfig em0 vhid 1 advskew 200 pass mekmitasdigoat 192.168.1.1/24 +ifconfig em1 vhid 2 advskew 200 pass mekmitasdigoat 192.168.2.1/24 .Ed .Pp When one of the physical interfaces of host A fails, @@ -246,9 +247,9 @@ preempt host A on both interfaces instea .\out slightly less frequently. .\.Bd -literal -offset indent .\ifconfig carp0 create -.\ifconfig carp0 vhid 1 pass mekmitasdigoat 192.168.1.10/24 +.\ifconfig carp0 vhid 1 advskew 100 pass mekmitasdigoat 192.168.1.10/24 .\ifconfig carp1 create -.\ifconfig carp1 vhid 2 advskew 100 pass mekmitasdigoat 192.168.1.10/24 +.\ifconfig carp1 vhid 2 advskew 200 pass mekmitasdigoat 192.168.1.10/24 .\.Ed .\.Pp .\The configuration for host B is identical, except the @@ -256,9 +257,9 @@ preempt host A on both interfaces instea .\is on virtual host 1 rather than virtual host 2. .\.Bd -literal -offset indent .\ifconfig carp0 create -.\ifconfig carp0 vhid 1 advskew 100 pass mekmitasdigoat 192.168.1.10/24 +.\ifconfig carp0 vhid 1 advskew 200 pass mekmitasdigoat 192.168.1.10/24 .\ifconfig carp1 create -.\ifconfig carp1 vhid 2 pass mekmitasdigoat 192.168.1.10/24 +.\ifconfig carp1 vhid 2 advskew 100 pass mekmitasdigoat 192.168.1.10/24 .\.Ed .\.Pp .\Finally, the ARP balancing feature must be enabled on both hosts: ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r266483 - head/sbin/geom/class/part
Author: marck (doc committer) Date: Wed May 21 05:27:57 2014 New Revision: 266483 URL: http://svnweb.freebsd.org/changeset/base/266483 Log: Document VMware-related filesystems additions. Reviewed by:jmg MFC after: 1 week Modified: head/sbin/geom/class/part/gpart.8 Modified: head/sbin/geom/class/part/gpart.8 == --- head/sbin/geom/class/part/gpart.8 Wed May 21 03:11:27 2014 (r266482) +++ head/sbin/geom/class/part/gpart.8 Wed May 21 05:27:57 2014 (r266483) @@ -657,6 +657,30 @@ A partition that contains a NTFS or exFA The scheme-specific type is .Qq Li !7 for MBR. +.It Cm vmware-vmfs +A partition that contains a VMware File System (VMFS). +The scheme-specific types are +.Qq Li !251 +for MBR and +.Qq Li !aa31e02a-400f-11db-9590-000c2911d1b8 +for GPT. +.It Cm vmware-vmkdiag +A partition that contains a VMware diagostic filesystem. +The scheme-specific types are +.Qq Li !252 +for MBR and +.Qq Li !9d275380-40ad-11db-bf97-000c2911d1b8 +for GPT. +.It Cm vmware-reserved +A VMware reserved partition. +The scheme-specific type is +.Qq Li !9198effc-31c0-11db-8f-78-000c2911d1b8 +for GPT. +.It Cm vmware-vsanhdr +A partition claimed by VMware VSAN. +The scheme-specific type is +.Qq Li !381cfccc-7288-11e0-92ee-000c2911d0b2 +for GPT. .El .Sh ATTRIBUTES The scheme-specific attributes for EBR: ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r265472 - head/bin/dd
On Wed, 7 May 2014, Alan Somers wrote: [snip] Even if nanosecond resolution isn't useful, monotonicity is. Nobody should be using a nonmonotonic clock just to measure durations. I started an audit of all of FreeBSD to look for other programs that use gettimeofday to measure durations. I haven't finished, but I've already found a lot, including xz, ping, hastd, fetch, systat, powerd, and others. I don't have time to fix them, though. Would you be interested, or do you know anyone else who would? From your list, hastd seems to be the most dangerous point to me. Adding trociny@ as one of the most active hastd-related committers so the issue would not be lost in the areas... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r264907 - in head/release: amd64 i386
On Thu, 24 Apr 2014, Don Lewis wrote: [snip] GPT may not be the best choice here. On a number of, in particular, Lenovo hardware, the BIOS will unconditionally boot with EFI from GPT media. I'm not sure we want to just swap the set of machines on which this will not boot. It probably needs to be nested MBR (or straight MBR -- I forget if that works) until the boot media work with EFI (which should be soon on -CURRENT). Noted. The thing here is that I want to get an EFI GPT partition on the image eventually, which unless I'm missing something obvious, we cannot mix GPT and MBR. I don't particularly like swapping which machines boot with this hack. Maybe it's time to do a MBR stick for legacy boot, and the GPT stick for UEFI and/or fails-to-boot-DD case? I've got a fairly recent Gigabyte motherboard that refused to boot an Ultimate Boot CD memstick which uses MBR. I found out that I was was able to boot and install from a 'dangerously dedicated' FreeBSD 9.x memstick. Given that clue, I built a 'dangerously dedicated' Ultimate Boot CD memstick, which worked just fine. seconded, till now the most bootable case for machines under my hands were happy with no-partition at all (fake MBR with 50k@s4, dd from UFS) this situation could drift in the near future though... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r264046 - in head: release share/man/man7
Glen, On Wed, 2 Apr 2014, Glen Barber wrote: Author: gjb Date: Wed Apr 2 16:53:07 2014 New Revision: 264046 URL: http://svnweb.freebsd.org/changeset/base/264046 Log: Use xz(1) instead of gzip(1) to compress release images when WITH_COMPRESSED_IMAGES is used. Maybe invent some variable defaulting to /usr/bin/xz so admin could use /usr/local/bin/pxz or other compatible implementation? On 4-core not-too-fast machine I observed pxz more than 3 time faster than xz while only slighly (5-10%) worse in packing ratio -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r259925 - in head/sys: geom/part sys
Author: marck (doc committer)
Date: Thu Dec 26 21:06:12 2013
New Revision: 259925
URL: http://svnweb.freebsd.org/changeset/base/259925
Log:
Add GPT UUID for VMware vSAN meta-data partition.
Approved by: ae
MFC after:2 weeks
Modified:
head/sys/geom/part/g_part.c
head/sys/geom/part/g_part.h
head/sys/geom/part/g_part_gpt.c
head/sys/sys/gpt.h
Modified: head/sys/geom/part/g_part.c
==
--- head/sys/geom/part/g_part.c Thu Dec 26 19:58:30 2013(r259924)
+++ head/sys/geom/part/g_part.c Thu Dec 26 21:06:12 2013(r259925)
@@ -107,6 +107,7 @@ struct g_part_alias_list {
{ vmware-vmfs, G_PART_ALIAS_VMFS },
{ vmware-vmkdiag, G_PART_ALIAS_VMKDIAG },
{ vmware-reserved, G_PART_ALIAS_VMRESERVED },
+ { vmware-vsanhdr, G_PART_ALIAS_VMVSANHDR },
};
SYSCTL_DECL(_kern_geom);
Modified: head/sys/geom/part/g_part.h
==
--- head/sys/geom/part/g_part.h Thu Dec 26 19:58:30 2013(r259924)
+++ head/sys/geom/part/g_part.h Thu Dec 26 21:06:12 2013(r259925)
@@ -74,6 +74,7 @@ enum g_part_alias {
G_PART_ALIAS_VMFS, /* A VMware VMFS partition entry */
G_PART_ALIAS_VMKDIAG, /* A VMware vmkDiagnostic partition
entry */
G_PART_ALIAS_VMRESERVED,/* A VMware reserved partition entry */
+ G_PART_ALIAS_VMVSANHDR, /* A VMware vSAN header partition entry
*/
/* Keep the following last */
G_PART_ALIAS_COUNT
};
Modified: head/sys/geom/part/g_part_gpt.c
==
--- head/sys/geom/part/g_part_gpt.c Thu Dec 26 19:58:30 2013
(r259924)
+++ head/sys/geom/part/g_part_gpt.c Thu Dec 26 21:06:12 2013
(r259925)
@@ -167,6 +167,7 @@ static struct uuid gpt_uuid_linux_swap =
static struct uuid gpt_uuid_vmfs = GPT_ENT_TYPE_VMFS;
static struct uuid gpt_uuid_vmkdiag = GPT_ENT_TYPE_VMKDIAG;
static struct uuid gpt_uuid_vmreserved = GPT_ENT_TYPE_VMRESERVED;
+static struct uuid gpt_uuid_vmvsanhdr = GPT_ENT_TYPE_VMVSANHDR;
static struct uuid gpt_uuid_ms_basic_data = GPT_ENT_TYPE_MS_BASIC_DATA;
static struct uuid gpt_uuid_ms_reserved = GPT_ENT_TYPE_MS_RESERVED;
static struct uuid gpt_uuid_ms_ldm_data = GPT_ENT_TYPE_MS_LDM_DATA;
@@ -208,6 +209,7 @@ static struct g_part_uuid_alias {
{ gpt_uuid_vmfs, G_PART_ALIAS_VMFS, 0 },
{ gpt_uuid_vmkdiag,G_PART_ALIAS_VMKDIAG,0 },
{ gpt_uuid_vmreserved, G_PART_ALIAS_VMRESERVED, 0 },
+ { gpt_uuid_vmvsanhdr, G_PART_ALIAS_VMVSANHDR, 0 },
{ gpt_uuid_mbr,G_PART_ALIAS_MBR,0 },
{ gpt_uuid_ms_basic_data, G_PART_ALIAS_MS_BASIC_DATA, 0x0b },
{ gpt_uuid_ms_ldm_data,G_PART_ALIAS_MS_LDM_DATA,0 },
Modified: head/sys/sys/gpt.h
==
--- head/sys/sys/gpt.h Thu Dec 26 19:58:30 2013(r259924)
+++ head/sys/sys/gpt.h Thu Dec 26 21:06:12 2013(r259925)
@@ -128,6 +128,8 @@ struct gpt_ent {
{0x9d275380,0x40ad,0x11db,0xbf,0x97,{0x00,0x0c,0x29,0x11,0xd1,0xb8}}
#defineGPT_ENT_TYPE_VMRESERVED \
{0x9198effc,0x31c0,0x11db,0x8f,0x78,{0x00,0x0c,0x29,0x11,0xd1,0xb8}}
+#defineGPT_ENT_TYPE_VSANHDR
+ {0x381cfccc,0x7288,0x11e0,0x92,0xee,{0x00,0x0c,0x29,0x11,0xd0,0xb2}}
#defineGPT_ENT_TYPE_APPLE_BOOT \
{0x426F6F74,0x,0x11aa,0xaa,0x11,{0x00,0x30,0x65,0x43,0xec,0xac}}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r258672 - in head: . share/mk
On Tue, 26 Nov 2013, Peter Wemm wrote: [snip] It seems more likely we can do a better job with packages. With some massaging, we should be able to use the compat-6.x/i386 libraries as-is, and solve the old 4.x/6.x binary issue in one go. sorry for my possible ignorance, but aren't compat6 suspected to non-closed (probablly non-trivial) security concerns? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254787 - head/sys/kern
On Sat, 24 Aug 2013, Alexander Motin wrote: MFprojects/camlock r254460: Remove locking from taskqueue_member(). The list of threads is static during the taskqueue life cycle, so there is no need to protect it, taking quite congested lock several more times for each ZFS I/O. Great, thanks! Any chances to MFC this to 9? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254787 - head/sys/kern
On Sat, 24 Aug 2013, Alexander Motin wrote: MFprojects/camlock r254460: Remove locking from taskqueue_member(). The list of threads is static during the taskqueue life cycle, so there is no need to protect it, taking quite congested lock several more times for each ZFS I/O. Great, thanks! Any chances to MFC this to 9? I don't see any problem to do it after some time. Ah, so IIUC, it does not depend on other changes and could be tested on stock stable/9 right now? If so, I'd merge this to our tinderbox/poudriere builder and test. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254787 - head/sys/kern
On Sat, 24 Aug 2013, Alexander Motin wrote: Remove locking from taskqueue_member(). The list of threads is Ah, so IIUC, it does not depend on other changes and could be tested on stock stable/9 right now? If so, I'd merge this to our tinderbox/poudriere builder and test. Yes, it is completely independent. Please, welcome. I am just not sure whether you notice much difference unless you have really a lot of IOPS. On my tests doing 90K IOPS over bunch of SSDs I've measured difference of several percents. Yes, this is not a case of a builder, as most of IOSP is done in tmpfs (BTW, doesn't this lock appliy there as well?) OTOH, we have a couple of iSCSI storages where this could be useable too... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254615 - head/sys/dev/mps
Ken,
On Wed, 21 Aug 2013, Kenneth D. Merry wrote:
Author: ken
Date: Wed Aug 21 21:30:56 2013
New Revision: 254615
URL: http://svnweb.freebsd.org/changeset/base/254615
Log:
Fix mps(4) driver breakage that came in in change 253550 that
manifested itself in out of chain frame conditions.
When the driver ran out of chain frames, the request in question
would get completed early, and go through mpssas_scsiio_complete().
In mpssas_scsiio_complete(), the negation of the CAM status values
(CAM_STATUS_MASK | CAM_SIM_QUEUED) was ORed in instead of being
ANDed in. This resulted in a bogus CAM CCB status value. This
didn't show up in the non-error case, because the status was reset
to something valid (e.g. CAM_REQ_CMP) later on in the function.
But in the error case, such as when the driver ran out of chain
frames, the CAM_REQUEUE_REQ status was ORed in to the bogus status
value. This led to the CAM transport layer repeatedly releasing
the SIM queue, because it though that the CAM_RELEASE_SIMQ flag had
been set. The symptom was messages like this on the console when
INVARIANTS were enabled:
xpt_release_simq: requested 1 present 0
xpt_release_simq: requested 1 present 0
xpt_release_simq: requested 1 present 0
what is real impact of the bug?
mps_sas.c: In mpssas_scsiio_complete(), use = to take status
bits out. |= adds them in.
In the error case in mpssas_scsiio_complete(), set
the status to CAM_REQUEUE_REQ, don't OR it in.
MFC after: 3 days
This patch does not apply cleanly as r253550 had not been merged, and the first
masking does not occur on contemporary stable/9. Comments?
Thank you!
Sponsored by: Spectra Logic
Modified:
head/sys/dev/mps/mps_sas.c
Modified: head/sys/dev/mps/mps_sas.c
==
--- head/sys/dev/mps/mps_sas.cWed Aug 21 21:30:06 2013
(r254614)
+++ head/sys/dev/mps/mps_sas.cWed Aug 21 21:30:56 2013
(r254615)
@@ -2103,7 +2103,7 @@ mpssas_scsiio_complete(struct mps_softc
cm-cm_targ-completed++;
cm-cm_targ-outstanding--;
TAILQ_REMOVE(cm-cm_targ-commands, cm, cm_link);
- ccb-ccb_h.status |= ~(CAM_STATUS_MASK | CAM_SIM_QUEUED);
+ ccb-ccb_h.status = ~(CAM_STATUS_MASK | CAM_SIM_QUEUED);
if (cm-cm_state == MPS_CM_STATE_TIMEDOUT) {
TAILQ_REMOVE(cm-cm_targ-timedout_commands, cm, cm_recovery);
@@ -2145,7 +2145,7 @@ mpssas_scsiio_complete(struct mps_softc
* because there can be no reply when we haven't actually
* gone out to the hardware.
*/
- ccb-ccb_h.status |= CAM_REQUEUE_REQ;
+ ccb-ccb_h.status = CAM_REQUEUE_REQ;
/*
* Currently the only error included in the mask is
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
--
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: ma...@freebsd.org ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r254615 - head/sys/dev/mps
On Thu, 22 Aug 2013, Kenneth D. Merry wrote: Fix mps(4) driver breakage that came in in change 253550 that manifested itself in out of chain frame conditions. When the driver ran out of chain frames, the request in question would get completed early, and go through mpssas_scsiio_complete(). what is real impact of the bug? Your system will essentially hang, certainly as far as anything connected to the controller in question. [snip] 5. Look for an out of chain frames message on the console. To see how far you are towards using the chain frames, run 'sysctl dev.mps'. You can see how many chain frames you have free, and how many requests have failed. This change just needs to be merged along with the other changes to avoid having the regression in stable. Thank you very much for the explanation. We use a couple of servers with mps (and many spindles there), all on stable/9 from this summer, and you commit turns on an alarm light in my head ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r253069 - head/sys/dev/ahci
On Tue, 9 Jul 2013, Alexander Motin wrote: Author: mav Date: Tue Jul 9 08:32:17 2013 New Revision: 253069 URL: http://svnweb.freebsd.org/changeset/base/253069 Log: Add one more ID of Marvell SATA controller. Submitted by: marck MFC after: 3 days Thanks a lot for lightning-fast commit! ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r253002 - head
On Mon, 8 Jul 2013, Garance A Drosehn wrote: I think it's probably helpful to point out the -j flag, but I'm not sure I would phrase it as if we're sure that the values here are the ideal ones. I expect the ideal values depend too much on hardware (e.g.: the CPU, type of disk used, and amount of memory on the machine). Just a quick note on the last sentense: building world with clang on core2Q with 8 gigs of RAM with even -j4 starts intense swapping, especially if using ZFS... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252608 - in head: include lib/libc/stdlib
On Thu, 4 Jul 2013, Andrey Chernov wrote: We already pass that moment in the past, changing oldbad formula with new one which cause the same effect: non-repeating sequence in the very global scope. We already agree that repeating depends on something like OS release numbers. I can't find that discussion right now. But you are changing it in between releases. Development and stable branches are not official releases. sorry for nitpicking: ther is quite large difference between official/unofficial status and users/vendors expectations regarding interface/APIs stability. development (aka -current or head/) is not, while stable (aka stable/*/) are, ate least they are great subject to POLA. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252032 - head/sys/amd64/include
On Wed, 26 Jun 2013, Gleb Smirnoff wrote: On Wed, Jun 26, 2013 at 11:42:39AM +1000, Bruce Evans wrote: B Anyway, as Gleb said, there is no point in B optimizing the i386 kernel. B B I said that there is every point in optimizing the i386 kernel. This B applies even more to other 32-bit arches. Some CPUs are much slower B than modern x86's. They shouldn't be slowed down more by inefficient B KPIs. I didn't mean that i386 arch is a relic and should be ignored at all. What I actually meant, is that the problem of performance drop due to cache poisoning and loss of statistics with simple += operation can be observed only at extremely high event rates, with multiple processors involved. The counter(9) is solution for these conditions. Thus we are interested in optimising amd64, not i386. The latter isn't affected neither positively nor negatively with these changes, just because last i386 CPUs can't reach the event rates where need for counter(9) arises. Yes, you can tweak implementation and obtain better results with microbenchmarks, but I bet that any change in counter(9) implementation won't affect packet forwarding rate on any i386. What we claim for i386 (and all other arches) that counter(9) is lossless, and that's all. I second to Konstantin, that we don't have objections in any changes to i386 part of counter, including a daemon, but the changes shouldn't affect amd64. Ah, apparently this mostly answers the question I've just asked ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r252032 - head/sys/amd64/include
On Tue, 25 Jun 2013, Konstantin Belousov wrote: Updates to the counter cannot be done from the interrupt context. This is fragile, however. It prevents using counters for things like counting interrupts. Most interrupt counting is now done directlyly and doesn't use PCPU_INC(). i386/i386 has just 1 use of PCPU_INC(). It is to count traps in machdep.c. Traps include nonmaskable interrupts. Even hard-disabling of interrupts doesn't prevent these. Otherwise, PCPU is used mainly for vm counters. E.g., for pagefaults. Now the trap is not an interrupt, so it shouldn't occur in the middle of the counter update and the PCPU_INC() can safely be replaced by a counter, but this is not clear. Traps are not performance critical in the sense that there is no need to count up to 1-10G traps per second. Anyway, as Gleb said, there is no point in optimizing the i386 kernel. Hmm, don't we count semi-embedded routers? Or, do we think they are either amd64 or arm/mips? [snip all the rest] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r250565 - head/etc
On Sun, 12 May 2013, Eitan Adler wrote: Author: eadler Date: Sun May 12 15:23:59 2013 New Revision: 250565 URL: http://svnweb.freebsd.org/changeset/base/250565 Log: Make newsyslog compress logs with xz instead of bzip2 to save space. While it may be useful for contemporary x64 machines, where CPU power is not an issue, I'm afraid it could produce more harm than goodness on old hardware and/or other architectures like arm. Do you have any estimation chart on different CPUs and architectures? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r250565 - head/etc
On Sun, 12 May 2013, Baptiste Daroussin wrote: Log: Make newsyslog compress logs with xz instead of bzip2 to save space. While it may be useful for contemporary x64 machines, where CPU power is not an issue, I'm afraid it could produce more harm than goodness on old hardware and/or other architectures like arm. +1 iirc there was a discussion about it a year or 2 ago, where it was stated that most of the time the gain of using xz for newsyslog was insignificant, pretty much no space saved, but the loss in cpu time was significant. I've just prepared quick test to be feeded to ministat, but preliminary results are: on *real* contemporary server hw.model: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz hw.ncpu: 12 amd64 stable/9 ~1.5G maillog on md (and otherwise unloaded machine, LA .3) is compressed to: method realtm arsize gzip45s 183M bzip2 5m32s 115M xz 11m43s 112M all archivers are used without any special switches, just $arch $log $log.$suffix I would tend to use xz for distributives (including freebsd-updates or portsnap), where compression process is quite rare, but download size is significant -- but not for logs, backups, or other similar once-packed data... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r250579 - head/etc
On Sun, 12 May 2013, Eitan Adler wrote: Author: eadler Date: Sun May 12 21:24:18 2013 New Revision: 250579 URL: http://svnweb.freebsd.org/changeset/base/250579 Log: Revert r250565 which causes issues for older CPUs PR: conf/178504 Requested by: many Thank you! BTW, isn't it time when we could increase default rotate size from 100 kB to, well, possibly 5M or something? It should fit even into standard md-backed /var on a diskless machine (which I suppose should be grown to somewhat more useful size as well) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r250565 - head/etc
Ed, On Sun, 12 May 2013, Ed Schouten wrote: 2013/5/12 Dmitry Morozovsky ma...@rinet.ru: I'm afraid it could produce more harm than goodness on old hardware and/or other architectures like arm. Any change we make at FreeBSD may or may not cause problems on old hardware and/or other architectures like ARM. It's typically a case of trial and error to see what happens. In fact, I think that for embedded systems, using xz compression would even be better. Many of those systems are often more storage space constrained than CPU constrained (e.g. a 200 MHz wireless device with only 8 MB of flash). I think it's a pity the change has been reverted without bringing any hard data to the table. I would pretty much like more statistics about the issue as well; unfortunately, all I have handy are x86 hardware, and most of embedded-like systems aer amd64 atoms... I think some testing should be done on different platforms before making any kind of decisions. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r249741 - head/sbin/hastctl
On Sun, 21 Apr 2013, Mikolaj Golub wrote: Author: trociny Date: Sun Apr 21 20:51:53 2013 New Revision: 249741 URL: http://svnweb.freebsd.org/changeset/base/249741 Log: Remove code duplication. ah yes thanks, I overlooked this when producing initial patch. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r248572 - in head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys
On Thu, 21 Mar 2013, Steven Hartland wrote: (I possibly missed -- when did TRIM support for regular ZFS MFCed to stable/9?) We've been doing extensive testing in production of ZFS TRIM and following this latest set of patches I intend to get TRIM MFC'ed to stable-8 stable-9 baring any objections. Great! Thank you for clarification, waiting eagerly :) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r248291 - head/sbin/hastctl
Author: marck (doc committer)
Date: Thu Mar 14 22:29:37 2013
New Revision: 248291
URL: http://svnweb.freebsd.org/changeset/base/248291
Log:
Rename 'status' command to 'list' and introduce new 'status' which produces
more terse output more observable for both scripts and humans.
Also, it shifts hastctl closer to GEOM utilities with their list/status
command
pairs.
Approved by: pjd
MFC after:4 weeks
Modified:
head/sbin/hastctl/hastctl.8
head/sbin/hastctl/hastctl.c
Modified: head/sbin/hastctl/hastctl.8
==
--- head/sbin/hastctl/hastctl.8 Thu Mar 14 22:16:13 2013(r248290)
+++ head/sbin/hastctl/hastctl.8 Thu Mar 14 22:29:37 2013(r248291)
@@ -27,7 +27,7 @@
.\
.\ $FreeBSD$
.\
-.Dd April 10, 2011
+.Dd March 14, 2013
.Dt HASTCTL 8
.Os
.Sh NAME
@@ -49,6 +49,11 @@
.Aq init | primary | secondary
.Ar all | name ...
.Nm
+.Cm list
+.Op Fl d
+.Op Fl c Ar config
+.Op Ar all | name ...
+.Nm
.Cm status
.Op Fl d
.Op Fl c Ar config
@@ -139,8 +144,11 @@ GEOM provider
.Pa /dev/hast/name
will not be created on secondary node.
.El
+.It Cm list
+Present verbose status of the configured resources.
.It Cm status
-Present status of the configured resources.
+Present terse (and more easy machine-parseable) status of the configured
+resources.
.It Cm dump
Dump metadata stored on local component for the configured resources.
.El
Modified: head/sbin/hastctl/hastctl.c
==
--- head/sbin/hastctl/hastctl.c Thu Mar 14 22:16:13 2013(r248290)
+++ head/sbin/hastctl/hastctl.c Thu Mar 14 22:29:37 2013(r248291)
@@ -60,7 +60,8 @@ enum {
CMD_CREATE,
CMD_ROLE,
CMD_STATUS,
- CMD_DUMP
+ CMD_DUMP,
+ CMD_LIST
};
static __dead2 void
@@ -75,6 +76,9 @@ usage(void)
%s role [-d] [-c config] init | primary | secondary all |
name ...\n,
getprogname());
fprintf(stderr,
+ %s list [-d] [-c config] [all | name ...]\n,
+ getprogname());
+ fprintf(stderr,
%s status [-d] [-c config] [all | name ...]\n,
getprogname());
fprintf(stderr,
@@ -287,7 +291,7 @@ control_set_role(struct nv *nv, const ch
}
static int
-control_status(struct nv *nv)
+control_list(struct nv *nv)
{
unsigned int ii;
const char *str;
@@ -351,6 +355,43 @@ control_status(struct nv *nv)
return (ret);
}
+static int
+control_status(struct nv *nv)
+{
+ unsigned int ii;
+ const char *str;
+ int error, hprinted, ret;
+
+ hprinted = 0;
+ ret = 0;
+
+ for (ii = 0; ; ii++) {
+ str = nv_get_string(nv, resource%u, ii);
+ if (str == NULL)
+ break;
+ if (!hprinted) {
+ printf(Name\tStatus\t Role\t\tComponents\n);
+ hprinted = 1;
+ }
+ printf(%s\t, str);
+ error = nv_get_int16(nv, error%u, ii);
+ if (error != 0) {
+ if (ret == 0)
+ ret = error;
+ printf(ERR%d\n, error);
+ continue;
+ }
+ str = nv_get_string(nv, status%u, ii);
+ printf(%-9s, (str != NULL) ? str : -);
+ printf(%-15s, nv_get_string(nv, role%u, ii));
+ printf(%s\t,
+ nv_get_string(nv, localpath%u, ii));
+ printf(%s\n,
+ nv_get_string(nv, remoteaddr%u, ii));
+ }
+ return (ret);
+}
+
int
main(int argc, char *argv[])
{
@@ -371,6 +412,9 @@ main(int argc, char *argv[])
} else if (strcmp(argv[1], role) == 0) {
cmd = CMD_ROLE;
optstr = c:dh;
+ } else if (strcmp(argv[1], list) == 0) {
+ cmd = CMD_LIST;
+ optstr = c:dh;
} else if (strcmp(argv[1], status) == 0) {
cmd = CMD_STATUS;
optstr = c:dh;
@@ -459,8 +503,19 @@ main(int argc, char *argv[])
for (ii = 0; ii argc - 1; ii++)
nv_add_string(nv, argv[ii + 1], resource%d, ii);
break;
+ case CMD_LIST:
+ /* Obtain verbose status of the given resources. */
+ nv = nv_alloc();
+ nv_add_uint8(nv, HASTCTL_CMD_STATUS, cmd);
+ if (argc == 0)
+ nv_add_string(nv, all, resource%d, 0);
+ else {
+ for (ii = 0; ii argc; ii++)
+ nv_add_string(nv, argv[ii], resource%d, ii);
+ }
+ break;
case CMD_STATUS:
- /* Obtain status of the given resources. */
+ /* Obtain brief status of the given resources. */
nv
Re: svn commit: r248151 - in head: . share/examples/cvsup
On Mon, 11 Mar 2013, Waitman Gobble wrote: Baptiste Daroussin b...@freebsd.org wrote .. Author: bapt Date: Mon Mar 11 10:48:26 2013 New Revision: 248151 URL: http://svnweb.freebsd.org/changeset/base/248151 [snip] I'm getting make installworld .. install -o root -g wheel -m 444 /usr/src/share/examples/cvsup/ports-supfile /usr/share/examples/cvsup/ports-supfile install: /usr/src/share/examples/cvsup/ports-supfile: No such file or directory *** [copies] Error code 71 Maybe I pulled the src at the wrong time ? or something to check out.. I seems so, rev 248168 possibly should be committed in ahead of 248151 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r240868 - in head: cddl/lib/libzpool sys/cddl/compat/opensolaris/sys sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys sys/modules/zfs
On Sun, 23 Sep 2012, Pawel Jakub Dawidek wrote: Author: pjd Date: Sun Sep 23 19:40:58 2012 New Revision: 240868 URL: http://svn.freebsd.org/changeset/base/240868 Log: Add TRIM support. [snip] Yesss! ;-) Thank you very much. Based on your thoughts, how could you estimate stablility (and, therefore, MFCability) of this feature? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r232702 - head/sys/kern
Dear Peter, On Thu, 8 Mar 2012, Peter Holm wrote: Author: pho Date: Thu Mar 8 20:34:13 2012 New Revision: 232702 URL: http://svn.freebsd.org/changeset/base/232702 Log: Free up allocated memory used by posix_fadvise(2). Time to MFC this? We've found huge kernel memory leaks in massive rrdtool usage without this change. Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r234417 - in head/sys: geom/part sys
Author: marck (doc committer)
Date: Wed Apr 18 11:59:03 2012
New Revision: 234417
URL: http://svn.freebsd.org/changeset/base/234417
Log:
VMware environments are not unusual now. Add VMware partitions recognition
(both MBR for ESXi = 4.1 and GPT for ESXi 5) to g_part.
Reviewed by: ae
Approved by: ae
MFC after:2 weeks
Modified:
head/sys/geom/part/g_part.c
head/sys/geom/part/g_part.h
head/sys/geom/part/g_part_gpt.c
head/sys/geom/part/g_part_mbr.c
head/sys/sys/diskmbr.h
head/sys/sys/gpt.h
Modified: head/sys/geom/part/g_part.c
==
--- head/sys/geom/part/g_part.c Wed Apr 18 10:23:42 2012(r234416)
+++ head/sys/geom/part/g_part.c Wed Apr 18 11:59:03 2012(r234417)
@@ -103,6 +103,9 @@ struct g_part_alias_list {
{ netbsd-lfs, G_PART_ALIAS_NETBSD_LFS },
{ netbsd-raid, G_PART_ALIAS_NETBSD_RAID },
{ netbsd-swap, G_PART_ALIAS_NETBSD_SWAP },
+ { vmware-vmfs, G_PART_ALIAS_VMFS },
+ { vmware-vmkdiag, G_PART_ALIAS_VMKDIAG },
+ { vmware-reserved, G_PART_ALIAS_VMRESERVED },
};
SYSCTL_DECL(_kern_geom);
Modified: head/sys/geom/part/g_part.h
==
--- head/sys/geom/part/g_part.h Wed Apr 18 10:23:42 2012(r234416)
+++ head/sys/geom/part/g_part.h Wed Apr 18 11:59:03 2012(r234417)
@@ -69,6 +69,9 @@ enum g_part_alias {
G_PART_ALIAS_EBR, /* A EBR partition entry. */
G_PART_ALIAS_MS_FAT32, /* A Microsoft FAT32 partition entry. */
G_PART_ALIAS_BIOS_BOOT, /* A GRUB 2 boot partition entry. */
+ G_PART_ALIAS_VMFS, /* A VMware VMFS partition entry */
+ G_PART_ALIAS_VMKDIAG, /* A VMware vmkDiagnostic partition
entry */
+ G_PART_ALIAS_VMRESERVED,/* A VMware reserved partition entry */
/* Keep the following last */
G_PART_ALIAS_COUNT
};
Modified: head/sys/geom/part/g_part_gpt.c
==
--- head/sys/geom/part/g_part_gpt.c Wed Apr 18 10:23:42 2012
(r234416)
+++ head/sys/geom/part/g_part_gpt.c Wed Apr 18 11:59:03 2012
(r234417)
@@ -163,6 +163,9 @@ static struct uuid gpt_uuid_linux_data =
static struct uuid gpt_uuid_linux_lvm = GPT_ENT_TYPE_LINUX_LVM;
static struct uuid gpt_uuid_linux_raid = GPT_ENT_TYPE_LINUX_RAID;
static struct uuid gpt_uuid_linux_swap = GPT_ENT_TYPE_LINUX_SWAP;
+static struct uuid gpt_uuid_vmfs = GPT_ENT_TYPE_VMFS;
+static struct uuid gpt_uuid_vmkdiag = GPT_ENT_TYPE_VMKDIAG;
+static struct uuid gpt_uuid_vmreserved = GPT_ENT_TYPE_VMRESERVED;
static struct uuid gpt_uuid_ms_basic_data = GPT_ENT_TYPE_MS_BASIC_DATA;
static struct uuid gpt_uuid_ms_reserved = GPT_ENT_TYPE_MS_RESERVED;
static struct uuid gpt_uuid_ms_ldm_data = GPT_ENT_TYPE_MS_LDM_DATA;
@@ -200,6 +203,9 @@ static struct g_part_uuid_alias {
{ gpt_uuid_linux_lvm, G_PART_ALIAS_LINUX_LVM, 0 },
{ gpt_uuid_linux_raid, G_PART_ALIAS_LINUX_RAID, 0 },
{ gpt_uuid_linux_swap, G_PART_ALIAS_LINUX_SWAP, 0 },
+ { gpt_uuid_vmfs, G_PART_ALIAS_VMFS, 0 },
+ { gpt_uuid_vmkdiag,G_PART_ALIAS_VMKDIAG,0 },
+ { gpt_uuid_vmreserved, G_PART_ALIAS_VMRESERVED, 0 },
{ gpt_uuid_mbr,G_PART_ALIAS_MBR,0 },
{ gpt_uuid_ms_basic_data, G_PART_ALIAS_MS_BASIC_DATA, 0x0b },
{ gpt_uuid_ms_ldm_data,G_PART_ALIAS_MS_LDM_DATA,0 },
Modified: head/sys/geom/part/g_part_mbr.c
==
--- head/sys/geom/part/g_part_mbr.c Wed Apr 18 10:23:42 2012
(r234416)
+++ head/sys/geom/part/g_part_mbr.c Wed Apr 18 11:59:03 2012
(r234417)
@@ -126,6 +126,8 @@ static struct g_part_mbr_alias {
{ DOSPTYP_LINLVM, G_PART_ALIAS_LINUX_LVM },
{ DOSPTYP_LINRAID, G_PART_ALIAS_LINUX_RAID },
{ DOSPTYP_PPCBOOT, G_PART_ALIAS_FREEBSD_BOOT },
+ { DOSPTYP_VMFS, G_PART_ALIAS_VMFS },
+ { DOSPTYP_VMKDIAG, G_PART_ALIAS_VMKDIAG },
};
static int
Modified: head/sys/sys/diskmbr.h
==
--- head/sys/sys/diskmbr.h Wed Apr 18 10:23:42 2012(r234416)
+++ head/sys/sys/diskmbr.h Wed Apr 18 11:59:03 2012(r234417)
@@ -55,6 +55,8 @@
#defineDOSPTYP_LINUX 0x83/* Linux partition */
#defineDOSPTYP_LINLVM 0x8e/* Linux LVM partition */
#defineDOSPTYP_PMBR0xee/* GPT Protective MBR */
+#defineDOSPTYP_VMFS0xfb/* VMware VMFS partition */
+#defineDOSPTYP_VMKDIAG 0xfc/* VMware vmkDiagnostic partition */
#defineDOSPTYP_LINRAID
svn commit: r234345 - head/sbin/fdisk
Author: marck (doc committer) Date: Mon Apr 16 17:30:19 2012 New Revision: 234345 URL: http://svn.freebsd.org/changeset/base/234345 Log: VMware environment is frequent nowadays. Add VMFS id. MFC after:2 weeks Modified: head/sbin/fdisk/fdisk.c Modified: head/sbin/fdisk/fdisk.c == --- head/sbin/fdisk/fdisk.c Mon Apr 16 15:43:31 2012(r234344) +++ head/sbin/fdisk/fdisk.c Mon Apr 16 17:30:19 2012(r234345) @@ -218,6 +218,7 @@ static const char *const part_types[256] [0xF1] = SpeedStor, [0xF2] = DOS 3.3+ Secondary, [0xF4] = SpeedStor large partition, + [0xFB] = VMware VMFS, [0xFE] = SpeedStor 1024 cyl. or LANstep, [0xFF] = Xenix bad blocks table, }; ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r233629 - head/sys/ufs/ffs
Dear Kirk, On Wed, 28 Mar 2012, Kirk McKusick wrote: Author: mckusick Date: Wed Mar 28 21:21:19 2012 New Revision: 233629 URL: http://svn.freebsd.org/changeset/base/233629 Log: A refinement of change 232351 to avoid a race with a forcible unmount. While we have a snapshot vnode unlocked to avoid a deadlock with another inode in the same inode block being updated, the filesystem containing it may be forcibly unmounted. When that happens the snapshot vnode is revoked. We need to check for that condition and fail appropriately. Thank you and Kostik very much! How far we are from enabling snapshot of SU+J UFS back? [snip] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r233167 - head/etc
On Mon, 19 Mar 2012, Gleb Smirnoff wrote: Author: glebius Date: Mon Mar 19 09:30:40 2012 New Revision: 233167 URL: http://svn.freebsd.org/changeset/base/233167 Log: Rotate auth.log and messages at the beginning of a year. Otherwise, daily security checks 800.loginfail and 900.tcpwrap may produce false positive alerts. [snip] -/var/log/auth.log600 7 100 * JC +/var/log/auth.log600 7 100 @0101T JC Did I miss newsyslog behaviour change? IIRC size limit is totally ignored if timed rotation is selected, and some time ago I even proposed to change this, but it was rejected, as one can use two lines, one with size limit, and other with timed rotation -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r232960 - head/sys/fs/tmpfs
On Wed, 14 Mar 2012, Gleb Kurtsou wrote: Author: gleb Date: Wed Mar 14 09:15:50 2012 New Revision: 232960 URL: http://svn.freebsd.org/changeset/base/232960 Log: Prevent tmpfs_rename() deadlock in a way similar to UFS Unlock vnodes and try to lock them one by one. Relookup fvp and tvp. Is this change applicable to other branches? If so, any plans for MFC? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r230869 - head/usr.sbin/daemon
On Mon, 13 Feb 2012, Andrey Zonov wrote: [snip] Please don't. Even if you can't write the pidfile, you should run the service. The same as for pidfile_open() failure as documented in example. Feel free to warn about problem with writing to pidfile, but don't treat it as critial error. The problem is the following you cannot stop such a service with standard rc.d script and empty pidfile. As for me, unstoppable (via standard way) service is at least slightly better than unstartable. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r227457 - head/sys/dev/puc
On Fri, 11 Nov 2011, Eitan Adler wrote: Author: eadler (ports committer) Date: Fri Nov 11 22:24:16 2011 New Revision: 227457 URL: http://svn.freebsd.org/changeset/base/227457 Log: - add support for CP-104EL-A and CP-104JU to puc PR: 151365 Submitted by: Joerg Niendorf f5d...@internode.on.net Approved by:jhb this change seems to be non-intrusive, could we please have it in 9.0-R? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r225201 - in head/sys: amd64/conf i386/conf
On Mon, 29 Aug 2011, Vadim Goncharov wrote: [snip] The possible solution to this may be to have a MINIMAL kernel, also updated by freebsd-update(8), but that will double requirements for space in /boot... Axing .symbols from boot (and storing them elsewhere, say, /var/crash) would actually decreases /boot space usage by a factor of ~3 ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r225122 - head/sys/boot/forth
Author: marck (doc committer)
Date: Tue Aug 23 20:25:11 2011
New Revision: 225122
URL: http://svn.freebsd.org/changeset/base/225122
Log:
Add kern.cam.boot_delay description (with reasonable default) to
default/loader.conf
This should help people installing ${OS} to USB devices, where there are
frequently cases where kernel tries to mount root before actual umass sensing
is finished.
Reviewed by: mav
Approved by: re (kib)
MFC after:1 week
Modified:
head/sys/boot/forth/loader.conf
Modified: head/sys/boot/forth/loader.conf
==
--- head/sys/boot/forth/loader.conf Tue Aug 23 19:49:06 2011
(r225121)
+++ head/sys/boot/forth/loader.conf Tue Aug 23 20:25:11 2011
(r225122)
@@ -109,6 +109,8 @@ module_path=/boot/modules # Set the mo
#kern.ncallout= # Set the maximum # of timer events
#kern.ngroups=1023 # Set the maximum # of supplemental groups
#kern.sgrowsiz= # Set the amount to grow stack
+#kern.cam.boot_delay=1 # Delay (in ms) of root mount for CAM bus
+ # registration, useful for USB sticks as root
#kern.cam.scsi_delay=2000# Delay (in ms) before probing SCSI
#kern.ipc.maxsockets=# Set the maximum number of sockets
avaliable
#kern.ipc.nmbclusters= # Set the number of mbuf clusters
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r224140 - head/sys/compat/freebsd32
Author: marck (doc committer)
Date: Sun Jul 17 17:12:17 2011
New Revision: 224140
URL: http://svn.freebsd.org/changeset/base/224140
Log:
Correct small typo in a do{}while(0) define
Approved by: kib
MFC after:2 weeks
Modified:
head/sys/compat/freebsd32/freebsd32.h
Modified: head/sys/compat/freebsd32/freebsd32.h
==
--- head/sys/compat/freebsd32/freebsd32.h Sun Jul 17 16:50:12 2011
(r224139)
+++ head/sys/compat/freebsd32/freebsd32.h Sun Jul 17 17:12:17 2011
(r224140)
@@ -58,7 +58,7 @@ struct timespec32 {
#define TS_CP(src,dst,fld) do {\
CP((src).fld,(dst).fld,tv_sec); \
CP((src).fld,(dst).fld,tv_nsec);\
-} while (0);
+} while (0)
struct rusage32 {
struct timeval32 ru_utime;
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r220576 - head/sys/dev/ahci
On Tue, 12 Apr 2011, Alexander Motin wrote: AM Author: mav AM Date: Tue Apr 12 20:50:57 2011 AM New Revision: 220576 AM URL: http://svn.freebsd.org/changeset/base/220576 AM AM Log: AM Refactor hard-reset implementation in ahci(4). AM AM Instead of spinning in a tight loop for up to 15 seconds, polling for device AM readiness while it spins up, return reset completion just after PHY reports AM connect well or 100ms connection timeout. If device was found, use callout AM for checking device readiness with 100ms period up to full 31 second timeout. AM AM This fixes system freeze for 5-10 seconds on drives hot plug-in. Great, thank you! Any plans to MFC this? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r213765 - head/sys/dev/aic7xxx/aicasm
On Thu, 14 Oct 2010, John Nielsen wrote: JN I'm migrating a box from 8-STABLE to -CURRENT this morning and this JN commit seems to break buildkernel: JN JN cc -O2 -pipe -nostdinc -I/usr/include -I. JN -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers JN -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter JN -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith JN -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow JN -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_scan.c JN cc1: warnings being treated as errors JN /usr/src/sys/dev/aic7xxx/aicasm/aicasm_scan.l:840: warning: JN function declaration isn't a prototype *** Error code 1 JN JN I don't have any custom CFLAGS, etc defined. Commenting out the new JN #defines from this patch allows the build to continue. JN JN I'm guessing this doesn't happen on machines already running JN -CURRENT or tinderbox (and others) would have noticed. However if JN this is (going to be) a supported upgrade path from 8.x to 9.0 JN perhaps there's a way to make both clang and gcc from 8.x happy? JN JN If you want to upgrade from N to N+1, make buildworld is required. JN JN Sorry, I did do a make buildworld (which succeeded) prior to the make buildkernel (which failed as I described). I can confirm this: my build machine, which is FreeBSD beaver.rinet.ru 8.1-STABLE FreeBSD 8.1-STABLE #1 r213380M: Sun Oct 3 13:25:15 MSD 2010 is now failing 'buildworld buildkernel __MAKE_CONF=/dev/null' for HEAD sources both for TARGET=amd64 and i386 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r213765 - head/sys/dev/aic7xxx/aicasm
On Thu, 14 Oct 2010, Jung-uk Kim wrote: JK JN I'm migrating a box from 8-STABLE to -CURRENT this morning JK and this JN commit seems to break buildkernel: [snip] JK I can confirm this: my build machine, which is JK JK FreeBSD beaver.rinet.ru 8.1-STABLE FreeBSD 8.1-STABLE #1 JK r213380M: Sun Oct 3 13:25:15 MSD 2010 JK JK is now failing 'buildworld buildkernel __MAKE_CONF=/dev/null' for JK HEAD sources both for TARGET=amd64 and i386 JK JK The tinderboxes are also failing (at least sun4v). JK JK No, it's fixed already: JK JK http://svn.freebsd.org/viewvc/base?view=revisionrevision=213764 It does not seem so, at least in my case: ma...@beaver:/FreeBSD svn info src.current.svn/ Path: src.current.svn URL: file:///FreeBSD/svnmirror/base/head Repository Root: file:///FreeBSD/svnmirror/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 213844 Node Kind: directory Schedule: normal Last Changed Author: yongari Last Changed Rev: 213844 Last Changed Date: 2010-10-14 22:31:40 +0400 (Thu, 14 Oct 2010) ma...@beaver:/FreeBSD tail /var/tmp/buildlog.svn.i386 cc -O2 -pipe -nostdinc -I/usr/include -I. -I/FreeBSD/src.current.svn/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_macro_gram.c cc -O2 -pipe -nostdinc -I/usr/include -I. -I/FreeBSD/src.current.svn/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_scan.c cc1: warnings being treated as errors /FreeBSD/src.current.svn/sys/dev/aic7xxx/aicasm/aicasm_scan.l:840: warning: function declaration isn't a prototype *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r213765 - head/sys/dev/aic7xxx/aicasm
On Thu, 14 Oct 2010, Jung-uk Kim wrote: JK JK JK JN I'm migrating a box from 8-STABLE to -CURRENT this JK morning JK and this JN commit seems to break buildkernel: JK JK [snip] JK JK JK I can confirm this: my build machine, which is JK JK JK JK FreeBSD beaver.rinet.ru 8.1-STABLE FreeBSD 8.1-STABLE #1 JK JK r213380M: Sun Oct 3 13:25:15 MSD 2010 JK JK JK JK is now failing 'buildworld buildkernel JK __MAKE_CONF=/dev/null' for JK HEAD sources both for JK TARGET=amd64 and i386 JK JK JK JK The tinderboxes are also failing (at least sun4v). JK JK JK JK No, it's fixed already: JK JK JK JK JK http://svn.freebsd.org/viewvc/base?view=revisionrevision=213764 JK JK It does not seem so, at least in my case: JK JK ma...@beaver:/FreeBSD svn info src.current.svn/ JK Path: src.current.svn JK URL: file:///FreeBSD/svnmirror/base/head JK Repository Root: file:///FreeBSD/svnmirror/base JK Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f JK Revision: 213844 JK Node Kind: directory JK Schedule: normal JK Last Changed Author: yongari JK Last Changed Rev: 213844 JK Last Changed Date: 2010-10-14 22:31:40 +0400 (Thu, 14 Oct 2010) JK JK ma...@beaver:/FreeBSD tail /var/tmp/buildlog.svn.i386 JK cc -O2 -pipe -nostdinc -I/usr/include -I. JK -I/FreeBSD/src.current.svn/sys/dev/aic7xxx/aicasm -std=gnu99 JK -Wsystem-headers -Werror -Wall -Wno-format-y2k -W JK -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes JK -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch JK -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c JK aicasm_macro_gram.c JK cc -O2 -pipe -nostdinc -I/usr/include -I. JK -I/FreeBSD/src.current.svn/sys/dev/aic7xxx/aicasm -std=gnu99 JK -Wsystem-headers -Werror -Wall -Wno-format-y2k -W JK -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes JK -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch JK -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c JK aicasm_scan.c JK cc1: warnings being treated as errors JK /FreeBSD/src.current.svn/sys/dev/aic7xxx/aicasm/aicasm_scan.l:840: JK warning: function declaration isn't a prototype JK *** Error code 1 JK 1 error JK *** Error code 2 JK 1 error JK *** Error code 2 JK 1 error JK JK Hmm... That means make buildkernel did not pick up newly built lex. JK That's bad. :-( It seems Rui's r213845 should fix this; I'm checking this right now... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r213765 - head/sys/dev/aic7xxx/aicasm
On Thu, 14 Oct 2010, Dmitry Morozovsky wrote: [snip] DM JK Hmm... That means make buildkernel did not pick up newly built lex. DM JK That's bad. :-( DM DM It seems Rui's r213845 should fix this; I'm checking this right now... Confirmed: this revision really fixed build. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r213398 - head/bin/rm
On Mon, 4 Oct 2010, Alexander Best wrote: AB On Mon Oct 4 10, Pawel Jakub Dawidek wrote: AB On Mon, Oct 04, 2010 at 06:17:46AM +, Xin LI wrote: AB Author: delphij AB Date: Mon Oct 4 06:17:45 2010 AB New Revision: 213398 AB URL: http://svn.freebsd.org/changeset/base/213398 AB AB Log: AB Clarify the combination effect of -P and -f to make it clear. AB AB While you're at it, it would be nice to add a note that this doesn't AB work with all file systems. In case of eg. ZFS the data won't be AB overwritten. AB AB isn't this detail already being covered by the existing note in the BUGS AB section? AB AB The -P option assumes that the underlying file system is a fixed-block AB file system. UFS is a fixed-block file system, LFS is not. In addition, AB only regular files are overwritten, other types of files are not. Maybe s/LFS/ZFS/ then, as LFS is no more relevant for FreeBSD users while ZFS now is? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
