RE: svn commit: r328625 - in head/sys: amd64/amd64 amd64/ia32 amd64/include dev/cpuctl i386/i386 x86/include x86/x86
> From: carpedd...@gmail.com On Behalf Of Ed
> Maste
> Sent: Friday, March 9, 2018 17:58
> On 9 March 2018 at 19:41, Dexuan-BSD Cui wrote:
> > Hi,
> >
> > In my FreeBSD 11.1 VM, I'm getting this build failure and it looks
> > this revision causes the failure:
> >
> > /root/bsd.git/sys/amd64/amd64/support.S:855:2: error: unknown directive
> > .altmacro
> > ^
>
> Are you trying to build a head kernel using the toolchain in 11.1?
Yes.
> That won't work (because of missing .altmacro support). Building
> kernel-toolchain first should get a working toolchain.
"make kernel-toolchain" first works for me! :-)
Thank you, Ed!
> > It looks -fno-integrated-as might fix the failure for me according to:
>
> Avoiding the integrated assembler is indeed the workaround for this
> issue, but you'll want to apply it only to the affected file.
>
> Kostik's 11.1 merge candidate patch adds to sys/conf/Makefile.amd64
> ASM_CFLAGS.support.S= ${CLANG_NO_IAS}
Thanks for the explanation. Good to know this!
Thanks,
-- Dexuan
___
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: r330705 - head/sbin/mount
On Fri, Mar 09, 2018 at 09:32:08PM +, Warner Losh wrote:
> New Revision: 330705
> URL: https://svnweb.freebsd.org/changeset/base/330705
>
> Log:
> Remove decade's old whine about msdos vs msdosfs.
>
> Retain the compatibility silently though.
Shouldn't it be the other way around? That is, after a decade of whining
people would've updated their configs/scripts and old (deprecated) gimmick
can now be removed? That's what usually implied by "deprecated", right?
./danfe
> Modified: head/sbin/mount/mount.c
> ...
> @@ -589,11 +589,8 @@ mountfs(const char *vfstype, const char *spec, const c
> optbuf = catopt(optbuf, "update");
>
> /* Compatibility glue. */
> - if (strcmp(vfstype, "msdos") == 0) {
> - warnx(
> - "Using \"-t msdosfs\", since \"-t msdos\" is deprecated.");
> + if (strcmp(vfstype, "msdos") == 0)
> vfstype = "msdosfs";
> - }
___
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: r330644 - in head/sys/dev/mlx5: . mlx5_core
On 03/10/18 04:38, Alan Somers wrote: Yeah, looks like it's working now. Thanks. No problem, thanks for handling. --HPS ___ 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: r330644 - in head/sys/dev/mlx5: . mlx5_core
On 03/10/18 04:38, Alan Somers wrote: Yeah, looks like it's working now. Thanks. No problem. Thanks for handling! --HPS ___ 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: r328013 - head/sbin/fsck_ffs
On 0309T2136, David Bright wrote: > On Mar 9, 2018, at 17:31, Ian Lepore wrote: > > > > On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: > >> > >> etc/rc.d/fsck doesn't know how to interpret the new exit code and now > >> just drops to a single-user shell when it is encountered. […] > >> > >> Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to > > This is, in fact, the reason that I made the change I did. I was trying to > put in a retry loop to rc.d/fsck, but found that I couldn’t get it to work > because fsck and fsck_ffs were not exiting with non-zero status. The drop to > single user is not really due to the specific (new) error code of 16, it is > due to the fact that fsck_ffs is now exiting with a non-zero status when it > hasn’t completely cleaned the file system; /any/ non-zero status would cause > the current rc.d/fsck script to go to single user. Prior to my change, > fsck_ffs was exiting with a zero status even though it had not completely > cleaned the filesystem and told the user to run it again. > > > > > fsck_ffs already has a -R flag to automatically retry, wouldn't that be > > a better mechanism for handling this new type of retry? > > That’s true; however, there is currently no way to pass that flag through the > filesystem-agnostic fsck wrapper called from rc.d/fsck to the > filesystem-specific fsck_ffs program that it calls. One could implement a > similar flag on the fsck wrapper to be passed along to the > filesystem-specific checker, but I think fsck_ffs is the only one that > currently implements such a flag. Sure there is. See /etc/defaults/rc.conf: fsck_y_flags="-T ffs:-R -T ufs:-R" # Additional flags for fsck -y ___ 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: r328013 - head/sbin/fsck_ffs
On Fri, 2018-03-09 at 21:36 -0500, David Bright wrote: > On Mar 9, 2018, at 17:31, Ian Lepore wrote: > > > > > > On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: > > > > > > > > > etc/rc.d/fsck doesn't know how to interpret the new exit code and > > > now > > > just drops to a single-user shell when it is encountered. […] > > > > > > Is there any reason etc/rc.d/fsck shouldn't automatically retry > > > (up to > This is, in fact, the reason that I made the change I did. I was > trying to put in a retry loop to rc.d/fsck, but found that I couldn’t > get it to work because fsck and fsck_ffs were not exiting with non- > zero status. The drop to single user is not really due to the > specific (new) error code of 16, it is due to the fact that fsck_ffs > is now exiting with a non-zero status when it hasn’t completely > cleaned the file system; /any/ non-zero status would cause the > current rc.d/fsck script to go to single user. Prior to my change, > fsck_ffs was exiting with a zero status even though it had not > completely cleaned the filesystem and told the user to run it again. > > > > > > > fsck_ffs already has a -R flag to automatically retry, wouldn't > > that be > > a better mechanism for handling this new type of retry? > That’s true; however, there is currently no way to pass that flag > through the filesystem-agnostic fsck wrapper called from rc.d/fsck to > the filesystem-specific fsck_ffs program that it calls. One could > implement a similar flag on the fsck wrapper to be passed along to > the filesystem-specific checker, but I think fsck_ffs is the only one > that currently implements such a flag. > > fsck -T ffs:-R -- Ian ___ 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: r330740 - head/sys/dev/iscsi
Author: trasz
Date: Sat Mar 10 14:21:37 2018
New Revision: 330740
URL: https://svnweb.freebsd.org/changeset/base/330740
Log:
Check for duplicates when modifying an iSCSI session. Previously we did
this check on open, but "iscsictl -M", or an iSCSI redirect received by
iscsid(8) could end up with two sessions with the same target name and
portal.
MFC after:2 weeks
Modified:
head/sys/dev/iscsi/iscsi.c
Modified: head/sys/dev/iscsi/iscsi.c
==
--- head/sys/dev/iscsi/iscsi.c Sat Mar 10 09:17:52 2018(r330739)
+++ head/sys/dev/iscsi/iscsi.c Sat Mar 10 14:21:37 2018(r330740)
@@ -1983,6 +1983,7 @@ iscsi_ioctl_session_modify(struct iscsi_softc *sc,
struct iscsi_session_modify *ism)
{
struct iscsi_session *is;
+ const struct iscsi_session *is2;
iscsi_sanitize_session_conf(&ism->ism_conf);
if (iscsi_valid_session_conf(&ism->ism_conf) == false)
@@ -1991,14 +1992,42 @@ iscsi_ioctl_session_modify(struct iscsi_softc *sc,
sx_xlock(&sc->sc_lock);
TAILQ_FOREACH(is, &sc->sc_sessions, is_next) {
ISCSI_SESSION_LOCK(is);
- if (is->is_id == ism->ism_session_id)
+ if (is->is_id == ism->ism_session_id) {
+ /* Note that the session remains locked. */
break;
+ }
ISCSI_SESSION_UNLOCK(is);
}
if (is == NULL) {
sx_xunlock(&sc->sc_lock);
return (ESRCH);
}
+
+ /*
+* Prevent duplicates.
+*/
+ TAILQ_FOREACH(is2, &sc->sc_sessions, is_next) {
+ if (is == is2)
+ continue;
+
+ if (!!ism->ism_conf.isc_discovery !=
+ !!is2->is_conf.isc_discovery)
+ continue;
+
+ if (strcmp(ism->ism_conf.isc_target_addr,
+ is2->is_conf.isc_target_addr) != 0)
+ continue;
+
+ if (ism->ism_conf.isc_discovery == 0 &&
+ strcmp(ism->ism_conf.isc_target,
+ is2->is_conf.isc_target) != 0)
+ continue;
+
+ ISCSI_SESSION_UNLOCK(is);
+ sx_xunlock(&sc->sc_lock);
+ return (EBUSY);
+ }
+
sx_xunlock(&sc->sc_lock);
memcpy(&is->is_conf, &ism->ism_conf, sizeof(is->is_conf));
___
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: r330741 - head/usr.bin/iscsictl
Author: trasz
Date: Sat Mar 10 14:33:00 2018
New Revision: 330741
URL: https://svnweb.freebsd.org/changeset/base/330741
Log:
Make iscsictl(1) display "Disabled" status for disabled sessions.
MFC after:2 weeks
Modified:
head/usr.bin/iscsictl/iscsictl.c
Modified: head/usr.bin/iscsictl/iscsictl.c
==
--- head/usr.bin/iscsictl/iscsictl.cSat Mar 10 14:21:37 2018
(r330740)
+++ head/usr.bin/iscsictl/iscsictl.cSat Mar 10 14:33:00 2018
(r330741)
@@ -605,7 +605,8 @@ kernel_list(int iscsi_fd, const struct target *targ __
xo_emit("{V:name/%-36s/%s} {V:portal/%-16s/%s} ",
conf->isc_target, conf->isc_target_addr);
- if (state->iss_reason[0] != '\0') {
+ if (state->iss_reason[0] != '\0' &&
+ conf->isc_enable != 0) {
xo_emit("{V:state/%s}\n", state->iss_reason);
} else {
if (conf->isc_discovery) {
___
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: r330705 - head/sbin/mount
On Sat, Mar 10, 2018 at 1:43 AM, Alexey Dokuchaev wrote:
> On Fri, Mar 09, 2018 at 09:32:08PM +, Warner Losh wrote:
> > New Revision: 330705
> > URL: https://svnweb.freebsd.org/changeset/base/330705
> >
> > Log:
> > Remove decade's old whine about msdos vs msdosfs.
> >
> > Retain the compatibility silently though.
>
> Shouldn't it be the other way around? That is, after a decade of whining
> people would've updated their configs/scripts and old (deprecated) gimmick
> can now be removed? That's what usually implied by "deprecated", right?
>
Nope. We accept both because even after a decade, people's fingers haven't
changed. The original change was poorly socialized and met with scorn at
the time. It's better to just accept both as some people have changed and
others haven't. The 'deprecated' part never took hold, so I just removed
the warning because the consensus is we are never going to stop accepting
both.
Warner
> ./danfe
>
> > Modified: head/sbin/mount/mount.c
> > ...
> > @@ -589,11 +589,8 @@ mountfs(const char *vfstype, const char *spec,
> const c
> > optbuf = catopt(optbuf, "update");
> >
> > /* Compatibility glue. */
> > - if (strcmp(vfstype, "msdos") == 0) {
> > - warnx(
> > - "Using \"-t msdosfs\", since \"-t msdos\" is
> deprecated.");
> > + if (strcmp(vfstype, "msdos") == 0)
> > vfstype = "msdosfs";
> > - }
>
___
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: r328013 - head/sbin/fsck_ffs
On Fri, Mar 09, 2018 at 09:36:25PM -0500, David Bright wrote: > On Mar 9, 2018, at 17:31, Ian Lepore wrote: > > > > On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: > >> > >> etc/rc.d/fsck doesn't know how to interpret the new exit code and now > >> just drops to a single-user shell when it is encountered. […] > >> > >> Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to > > This is, in fact, the reason that I made the change I did. I was trying to > put in a retry loop to rc.d/fsck, but found that I couldn’t get it to work > because fsck and fsck_ffs were not exiting with non-zero status. The drop to > single user is not really due to the specific (new) error code of 16, it is > due to the fact that fsck_ffs is now exiting with a non-zero status when it > hasn’t completely cleaned the file system; Sure, but that's a regression IMO: before, I believe we'd successfully mount the FS even without retrying fsck, and continue booting. > /any/ non-zero status would cause the current rc.d/fsck script to go to > single user. Prior to my change, fsck_ffs was exiting with a zero status even > though it had not completely cleaned the filesystem and told the user to run > it again. > > > > > fsck_ffs already has a -R flag to automatically retry, wouldn't that be > > a better mechanism for handling this new type of retry? > > That’s true; however, there is currently no way to pass that flag through the > filesystem-agnostic fsck wrapper called from rc.d/fsck to the > filesystem-specific fsck_ffs program that it calls. One could implement a > similar flag on the fsck wrapper to be passed along to the > filesystem-specific checker, but I think fsck_ffs is the only one that > currently implements such a flag. As was pointed out by others, this isn't true. In my experience it's fsck -p that is exiting with status 16. It thus seems like it would be desirable to add "-T ffs:-R" to the initial fsck invocation in rc.d/fsck. ___ 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: r328013 - head/sbin/fsck_ffs
[ Charset UTF-8 unsupported, converting... ] > On Fri, Mar 09, 2018 at 09:36:25PM -0500, David Bright wrote: > > On Mar 9, 2018, at 17:31, Ian Lepore wrote: > > > > > > On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: > > >> > > >> etc/rc.d/fsck doesn't know how to interpret the new exit code and now > > >> just drops to a single-user shell when it is encountered. [?] > > >> > > >> Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to > > > > This is, in fact, the reason that I made the change I did. I was trying to > > put in a retry loop to rc.d/fsck, but found that I couldn?t get it to work > > because fsck and fsck_ffs were not exiting with non-zero status. The drop > > to single user is not really due to the specific (new) error code of 16, it > > is due to the fact that fsck_ffs is now exiting with a non-zero status when > > it hasn?t completely cleaned the file system; > > Sure, but that's a regression IMO: before, I believe we'd successfully > mount the FS even without retrying fsck, and continue booting. > > > /any/ non-zero status would cause the current rc.d/fsck script to go to > > single user. Prior to my change, fsck_ffs was exiting with a zero status > > even though it had not completely cleaned the filesystem and told the user > > to run it again. > > > > > > > > fsck_ffs already has a -R flag to automatically retry, wouldn't that be > > > a better mechanism for handling this new type of retry? > > > > That?s true; however, there is currently no way to pass that flag through > > the filesystem-agnostic fsck wrapper called from rc.d/fsck to the > > filesystem-specific fsck_ffs program that it calls. One could implement a > > similar flag on the fsck wrapper to be passed along to the > > filesystem-specific checker, but I think fsck_ffs is the only one that > > currently implements such a flag. > > As was pointed out by others, this isn't true. In my experience it's > fsck -p that is exiting with status 16. It thus seems like it would be > desirable to add "-T ffs:-R" to the initial fsck invocation in > rc.d/fsck. Please do not do that, if fsck -p fails YOU may optionally wish to continue, or do retries, but please do not make this a hardcoded situation. At most make it a controllable knob that defaults to the old behavior please. Thanks you, -- Rod Grimes rgri...@freebsd.org ___ 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: r328013 - head/sbin/fsck_ffs
On Sat, 2018-03-10 at 08:44 -0800, Rodney W. Grimes wrote: > [ Charset UTF-8 unsupported, converting... ] > > > > On Fri, Mar 09, 2018 at 09:36:25PM -0500, David Bright wrote: > > > > > > On Mar 9, 2018, at 17:31, Ian Lepore wrote: > > > > > > > > > > > > On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: > > > > > > > > > > > > > > > etc/rc.d/fsck doesn't know how to interpret the new exit code and now > > > > > just drops to a single-user shell when it is encountered. [?] > > > > > > > > > > Is there any reason etc/rc.d/fsck shouldn't automatically retry (up to > > > This is, in fact, the reason that I made the change I did. I was trying > > > to put in a retry loop to rc.d/fsck, but found that I couldn?t get it to > > > work because fsck and fsck_ffs were not exiting with non-zero status. The > > > drop to single user is not really due to the specific (new) error code of > > > 16, it is due to the fact that fsck_ffs is now exiting with a non-zero > > > status when it hasn?t completely cleaned the file system; > > Sure, but that's a regression IMO: before, I believe we'd successfully > > mount the FS even without retrying fsck, and continue booting. > > > > > > > > /any/ non-zero status would cause the current rc.d/fsck script to go to > > > single user. Prior to my change, fsck_ffs was exiting with a zero status > > > even though it had not completely cleaned the filesystem and told the > > > user to run it again. > > > > > > > > > > > > > > > fsck_ffs already has a -R flag to automatically retry, wouldn't that be > > > > a better mechanism for handling this new type of retry? > > > That?s true; however, there is currently no way to pass that flag through > > > the filesystem-agnostic fsck wrapper called from rc.d/fsck to the > > > filesystem-specific fsck_ffs program that it calls. One could implement a > > > similar flag on the fsck wrapper to be passed along to the > > > filesystem-specific checker, but I think fsck_ffs is the only one that > > > currently implements such a flag. > > As was pointed out by others, this isn't true. In my experience it's > > fsck -p that is exiting with status 16. It thus seems like it would be > > desirable to add "-T ffs:-R" to the initial fsck invocation in > > rc.d/fsck. > Please do not do that, if fsck -p fails YOU may optionally > wish to continue, or do retries, but please do not make this > a hardcoded situation. At most make it a controllable knob > that defaults to the old behavior please. > > Thanks you, This whole situation with fsck retries is just very strange. How many other tools in the base system exhibit this behavior: I didn't do everything you asked, even though I am completely capable of doing so. If you'd like to actually do the thing you asked for, please run this program again. If there is some reason why fsck should do less than a complete job under some circumstances, isn't THAT the exceptional situation that should need a special flag to make it happen? -- Ian ___ 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: r328013 - head/sbin/fsck_ffs
> On Sat, 2018-03-10 at 08:44 -0800, Rodney W. Grimes wrote: > > [ Charset UTF-8 unsupported, converting... ] > > > > > > On Fri, Mar 09, 2018 at 09:36:25PM -0500, David Bright wrote: > > > > > > > > On Mar 9, 2018, at 17:31, Ian Lepore wrote: > > > > > > > > > > > > > > > On Fri, 2018-03-09 at 17:09 -0500, Mark Johnston wrote: > > > > > > > > > > > > > > > > > > etc/rc.d/fsck doesn't know how to interpret the new exit code and > > > > > > now > > > > > > just drops to a single-user shell when it is encountered. [?] > > > > > > > > > > > > Is there any reason etc/rc.d/fsck shouldn't automatically retry (up > > > > > > to > > > > This is, in fact, the reason that I made the change I did. I was trying > > > > to put in a retry loop to rc.d/fsck, but found that I couldn?t get it > > > > to work because fsck and fsck_ffs were not exiting with non-zero > > > > status. The drop to single user is not really due to the specific (new) > > > > error code of 16, it is due to the fact that fsck_ffs is now exiting > > > > with a non-zero status when it hasn?t completely cleaned the file > > > > system; > > > Sure, but that's a regression IMO: before, I believe we'd successfully > > > mount the FS even without retrying fsck, and continue booting. > > > > > > > > > > > /any/ non-zero status would cause the current rc.d/fsck script to go to > > > > single user. Prior to my change, fsck_ffs was exiting with a zero > > > > status even though it had not completely cleaned the filesystem and > > > > told the user to run it again. > > > > > > > > > > > > > > > > > > > fsck_ffs already has a -R flag to automatically retry, wouldn't that > > > > > be > > > > > a better mechanism for handling this new type of retry? > > > > That?s true; however, there is currently no way to pass that flag > > > > through the filesystem-agnostic fsck wrapper called from rc.d/fsck to > > > > the filesystem-specific fsck_ffs program that it calls. One could > > > > implement a similar flag on the fsck wrapper to be passed along to the > > > > filesystem-specific checker, but I think fsck_ffs is the only one that > > > > currently implements such a flag.? > > > As was pointed out by others, this isn't true. In my experience it's > > > fsck -p that is exiting with status 16. It thus seems like it would be > > > desirable to add "-T ffs:-R" to the initial fsck invocation in > > > rc.d/fsck. > > Please do not do that, if fsck -p fails YOU may optionally > > wish to continue, or do retries, but please do not make this > > a hardcoded situation.??At most make it a controllable knob > > that defaults to the old behavior please. > > > > Thanks you, > > This whole situation with fsck retries is just very strange. ?How many > other tools in the base system exhibit this behavior:? > > I didn't do everything you asked, even though I am completely > capable of doing so. ?If you'd like to actually do the thing you > asked for, please run this program again. > > If there is some reason why fsck should do less than a complete job > under some circumstances, isn't THAT the exceptional situation that > should need a special flag to make it happen? The job is "make sure my data is ok, keep my data at all costs, do not however do something that may damange my data". The job is NOT "do everything you can to bring the file system to a consistent state, even if you have to screw my data all up". -- Rod Grimes rgri...@freebsd.org ___ 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: r328013 - head/sbin/fsck_ffs
On Sat, 2018-03-10 at 09:02 -0800, Rodney W. Grimes wrote: > > > > On Sat, 2018-03-10 at 08:44 -0800, Rodney W. Grimes wrote: > > > [...] > > > > add "-T ffs:-R" to the initial fsck invocation in rc.d/fsck. > > > Please do not do that, if fsck -p fails YOU may optionally > > > wish to continue, or do retries, but please do not make this > > > a hardcoded situation.??At most make it a controllable knob > > > that defaults to the old behavior please. > > > > > > Thanks you, > > This whole situation with fsck retries is just very strange. ?How > > many other tools in the base system exhibit this behavior:? > > > > I didn't do everything you asked, even though I am completely > > capable of doing so. ?If you'd like to actually do the thing > > you asked for, please run this program again. > > > > If there is some reason why fsck should do less than a complete job > > under some circumstances, isn't THAT the exceptional situation that > > should need a special flag to make it happen? > The job is "make sure my data is ok, keep my data at all costs, do > not however do something that may damange my data". > > The job is NOT "do everything you can to bring the file system to > a consistent state, even if you have to screw my data all up". > I'm not sure why you think the -R flag is some sort of "ruin my data" request. Maybe because all of this stuff is so scantily documented in the manpage? -R Instruct fsck_ffs to restart itself if it encounters certain errors that warrant another run. Who knows what "certain errors" means? Looking at the code, it appears -R has no effect if you're in preen mode. Hmmm, what's "preen mode" again? Don't bother looking in the man page, you'll just find a bunch of mentions of the word preen that say "see the -p flag" and then, surrealistically, when you look at the -p flag it says "Preen file systems (see above)". Of course, what was above was all the places that told you to see -p. So, I guess I'll just keep using fsck_y_enable=YES and relying on the fact that by default that now includes the -R option. -- Ian ___ 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: r328013 - head/sbin/fsck_ffs
On Sat, Mar 10, 2018 at 10:26 AM, Ian Lepore wrote: > On Sat, 2018-03-10 at 09:02 -0800, Rodney W. Grimes wrote: > > > > > > On Sat, 2018-03-10 at 08:44 -0800, Rodney W. Grimes wrote: > > > > > [...] > > > > > add "-T ffs:-R" to the initial fsck invocation in rc.d/fsck. > > > > Please do not do that, if fsck -p fails YOU may optionally > > > > wish to continue, or do retries, but please do not make this > > > > a hardcoded situation.??At most make it a controllable knob > > > > that defaults to the old behavior please. > > > > > > > > Thanks you, > > > This whole situation with fsck retries is just very strange. ?How > > > many other tools in the base system exhibit this behavior:? > > > > > > I didn't do everything you asked, even though I am completely > > > capable of doing so. ?If you'd like to actually do the thing > > > you asked for, please run this program again. > > > > > > If there is some reason why fsck should do less than a complete job > > > under some circumstances, isn't THAT the exceptional situation that > > > should need a special flag to make it happen? > > The job is "make sure my data is ok, keep my data at all costs, do > > not however do something that may damange my data". > > > > The job is NOT "do everything you can to bring the file system to > > a consistent state, even if you have to screw my data all up". > > > > I'm not sure why you think the -R flag is some sort of "ruin my data" > request. Maybe because all of this stuff is so scantily documented in > the manpage? > > -R Instruct fsck_ffs to restart itself if it encounters certain > errors that warrant another run. > > Who knows what "certain errors" means? > There are some classes of errors that fsck correct that it must recompute a large amount of state to make sure it is consistent. Rather than doing that, it exits with a message saying to re-run fsck to make sure that there aren't more errors that were hidden by the now-corrected errors from the past pass. > Looking at the code, it appears -R has no effect if you're in preen > mode. Hmmm, what's "preen mode" again? Don't bother looking in the > man page, you'll just find a bunch of mentions of the word preen that > say "see the -p flag" and then, surrealistically, when you look at the > -p flag it says "Preen file systems (see above)". Of course, what was > above was all the places that told you to see -p. > The man page could use some improvement. Preen mode means 'fix all the stupid inconsistencies that crop up that never result in data loss'. non-preen mode means to do that, and ask if you want to correct other errors that usually don't cause data loss, but might and some modicum of human intelligence is required to tell the two apart. Eg, I usually give up hitting 'y' after a dozen or so times in FSCK unless I have a specific reason to keep going. fsck -y has no such nuance. Warner > So, I guess I'll just keep using fsck_y_enable=YES and relying on the > fact that by default that now includes the -R option. > > -- Ian > > > ___ 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: r328013 - head/sbin/fsck_ffs
> On Sat, Mar 10, 2018 at 10:26 AM, Ian Lepore wrote: > > > On Sat, 2018-03-10 at 09:02 -0800, Rodney W. Grimes wrote: > > > > > > > > On Sat, 2018-03-10 at 08:44 -0800, Rodney W. Grimes wrote: > > > > > > > [...] > > > > > > add "-T ffs:-R" to the initial fsck invocation in rc.d/fsck. > > > > > Please do not do that, if fsck -p fails YOU may optionally > > > > > wish to continue, or do retries, but please do not make this > > > > > a hardcoded situation.??At most make it a controllable knob > > > > > that defaults to the old behavior please. > > > > > > > > > > Thanks you, > > > > This whole situation with fsck retries is just very strange. ?How > > > > many other tools in the base system exhibit this behavior:? > > > > > > > > I didn't do everything you asked, even though I am completely > > > > capable of doing so. ?If you'd like to actually do the thing > > > > you asked for, please run this program again. > > > > > > > > If there is some reason why fsck should do less than a complete job > > > > under some circumstances, isn't THAT the exceptional situation that > > > > should need a special flag to make it happen? > > > The job is "make sure my data is ok, keep my data at all costs, do > > > not however do something that may damange my data". > > > > > > The job is NOT "do everything you can to bring the file system to > > > a consistent state, even if you have to screw my data all up". > > > > > > > I'm not sure why you think the -R flag is some sort of "ruin my data" > > request. Maybe because all of this stuff is so scantily documented in > > the manpage? > > > > -R Instruct fsck_ffs to restart itself if it encounters certain > > errors that warrant another run. > > > > Who knows what "certain errors" means? > > > > There are some classes of errors that fsck correct that it must recompute a > large amount of state to make sure it is consistent. Rather than doing > that, it exits with a message saying to re-run fsck to make sure that there > aren't more errors that were hidden by the now-corrected errors from the > past pass. > > > > Looking at the code, it appears -R has no effect if you're in preen > > mode. Hmmm, what's "preen mode" again? Don't bother looking in the > > man page, you'll just find a bunch of mentions of the word preen that > > say "see the -p flag" and then, surrealistically, when you look at the > > -p flag it says "Preen file systems (see above)". Of course, what was > > above was all the places that told you to see -p. > > > > The man page could use some improvement. Preen mode means 'fix all the > stupid inconsistencies that crop up that never result in data loss'. > non-preen mode means to do that, and ask if you want to correct other > errors that usually don't cause data loss, but might and some modicum of > human intelligence is required to tell the two apart. Eg, I usually give up > hitting 'y' after a dozen or so times in FSCK unless I have a specific > reason to keep going. fsck -y has no such nuance. I do not believe that normal mode has any intellegnce to as if data loss will or will not occur. It will gladly ask you if you want to clear an inode that is the root of a rather large tree, and you end up with either data loss, or a huge lost+found, sometimes even over flowing the size of lost+found (though that may of been fixed in ufs2). It simply runs along and if it finds an error it asks if you want to correct it or not. Y is not always the correct answer, but most people are oblivious to what the questions imply with respect to the file system, and hence answer Y. fsck does do thing in a sequence that tries to make Y the correct answer, but as you say human intelligence may do better. Some times if you had answered N at the right question you would not of gotten all of the other 11 questions that lead you to giving up, sometimes the N answer maybe 100's of Y's in, often to a clear inode question. When I get a preen failure my usual next step is to run a logged fsck -n to see what that says so I can evaluate the extent of fs damage, especially if this is a critical file system containing very valuable data. > Warner > > > > So, I guess I'll just keep using fsck_y_enable=YES and relying on the > > fact that by default that now includes the -R option. And if your running ufs2 with soft updates your in a pretty safe place. I would not recommend doing this on ufs1 or without soft updates enabled. One must try to remeber that fsck -p during /etc/rc processing can run into many different file systems, some more resilent to running things like fsck -R -y, some not. -- Rod Grimes rgri...@freebsd.org ___ 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: r328013 - head/sbin/fsck_ffs
In message <1520702802.84937.126.ca...@freebsd.org>, Ian Lepore writes: > On Sat, 2018-03-10 at 09:02 -0800, Rodney W. Grimes wrote: > > > > > > On Sat, 2018-03-10 at 08:44 -0800, Rodney W. Grimes wrote: > > > > > [...] > > > > > add "-T ffs:-R" to the initial fsck invocation in rc.d/fsck. > > > > Please do not do that, if fsck -p fails YOU may optionally > > > > wish to continue, or do retries, but please do not make this > > > > a hardcoded situation.??At most make it a controllable knob > > > > that defaults to the old behavior please. > > > > > > > > Thanks you, > > > This whole situation with fsck retries is just very strange. ?How > > > many other tools in the base system exhibit this behavior:? > > > > > >     I didn't do everything you asked, even though I am completely > > >     capable of doing so. ?If you'd like to actually do the thing > > >   you asked for, please run this program again. > > > > > > If there is some reason why fsck should do less than a complete job > > > under some circumstances, isn't THAT the exceptional situation that > > > should need a special flag to make it happen? > > The job is "make sure my data is ok, keep my data at all costs, do > > not however do something that may damange my data". > > > > The job is NOT "do everything you can to bring the file system to > > a consistent state, even if you have to screw my data all up". > > > > I'm not sure why you think the -R flag is some sort of "ruin my data" > request.  Maybe because all of this stuff is so scantily documented in > the manpage? > > -R Instruct fsck_ffs to restart itself if it encounters certain  >  errors that warrant another run. > > Who knows what "certain errors" means?  > > Looking at the code, it appears -R has no effect if you're in preen > mode.  Hmmm, what's "preen mode" again?  Don't bother looking in the > man page, you'll just find a bunch of mentions of the word preen that > say "see the -p flag" and then, surrealistically, when you look at the > -p flag it says "Preen file systems (see above)".  Of course, what was > above was all the places that told you to see -p. > > So, I guess I'll just keep using fsck_y_enable=YES and relying on the > fact that by default that now includes the -R option. That's how I've set up my firewall/gateway. For it I'm much more concerned to have it successfully boot than data loss. The reason is if I'm remote I want to be able to ssh back in. So, I'm willing to take the risk to be able to do so. Having said that, I maintain backup slices on an alternate disk in case of loss should the primary slice fail to boot. In that case data loss is tolerable to allow a better chance I can remotely ssh in. (Of course there's no 100% guarantee if there's data loss but it's better than 0% if the gateway dropped into single user state from the get-go.) With my other gear using UFS I want a failing fsck to fall to single user as I can get in using a console server to examine the damage decide for myself. Long story short, it depends. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: r330742 - head/libexec/tftpd/tests
Author: asomers
Date: Sat Mar 10 18:07:31 2018
New Revision: 330742
URL: https://svnweb.freebsd.org/changeset/base/330742
Log:
tftpd: fix the build of tests on i386 after 330696
It's those darn printf format specifiers again
Reported by: cy, kibab
MFC after:20 days
X-MFC-With: 330696
Modified:
head/libexec/tftpd/tests/functional.c
Modified: head/libexec/tftpd/tests/functional.c
==
--- head/libexec/tftpd/tests/functional.c Sat Mar 10 14:33:00 2018
(r330741)
+++ head/libexec/tftpd/tests/functional.c Sat Mar 10 18:07:31 2018
(r330742)
@@ -248,10 +248,10 @@ require_bufeq(const char *expected, ssize_t expected_l
ssize_t i;
ATF_REQUIRE_EQ_MSG(expected_len, len,
- "Expected %ld bytes but got %ld", expected_len, len);
+ "Expected %zd bytes but got %zd", expected_len, len);
for (i = 0; i < len; i++) {
ATF_REQUIRE_EQ_MSG(actual[i], expected[i],
- "Expected %#hhx at position %ld; got %hhx instead",
+ "Expected %#hhx at position %zd; got %hhx instead",
expected[i], i, actual[i]);
}
}
___
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: r328013 - head/sbin/fsck_ffs
In message <201803101751.w2ahphph070...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Gri mes" writes: > > On Sat, Mar 10, 2018 at 10:26 AM, Ian Lepore wrote: > > > > > On Sat, 2018-03-10 at 09:02 -0800, Rodney W. Grimes wrote: > > > > > > > > > > On Sat, 2018-03-10 at 08:44 -0800, Rodney W. Grimes wrote: > > > > > > > > > [...] > > > > > > > add "-T ffs:-R" to the initial fsck invocation in rc.d/fsck. > > > > > > Please do not do that, if fsck -p fails YOU may optionally > > > > > > wish to continue, or do retries, but please do not make this > > > > > > a hardcoded situation.??At most make it a controllable knob > > > > > > that defaults to the old behavior please. > > > > > > > > > > > > Thanks you, > > > > > This whole situation with fsck retries is just very strange. ?How > > > > > many other tools in the base system exhibit this behavior:? > > > > > > > > > > I didn't do everything you asked, even though I am completely > > > > > capable of doing so. ?If you'd like to actually do the thing > > > > > you asked for, please run this program again. > > > > > > > > > > If there is some reason why fsck should do less than a complete job > > > > > under some circumstances, isn't THAT the exceptional situation that > > > > > should need a special flag to make it happen? > > > > The job is "make sure my data is ok, keep my data at all costs, do > > > > not however do something that may damange my data". > > > > > > > > The job is NOT "do everything you can to bring the file system to > > > > a consistent state, even if you have to screw my data all up". > > > > > > > > > > I'm not sure why you think the -R flag is some sort of "ruin my data" > > > request. Maybe because all of this stuff is so scantily documented in > > > the manpage? > > > > > > -R Instruct fsck_ffs to restart itself if it encounters certain > > > errors that warrant another run. > > > > > > Who knows what "certain errors" means? > > > > > > > There are some classes of errors that fsck correct that it must recompute a > > large amount of state to make sure it is consistent. Rather than doing > > that, it exits with a message saying to re-run fsck to make sure that there > > aren't more errors that were hidden by the now-corrected errors from the > > past pass. > > > > > > > Looking at the code, it appears -R has no effect if you're in preen > > > mode. Hmmm, what's "preen mode" again? Don't bother looking in the > > > man page, you'll just find a bunch of mentions of the word preen that > > > say "see the -p flag" and then, surrealistically, when you look at the > > > -p flag it says "Preen file systems (see above)". Of course, what was > > > above was all the places that told you to see -p. > > > > > > > The man page could use some improvement. Preen mode means 'fix all the > > stupid inconsistencies that crop up that never result in data loss'. > > non-preen mode means to do that, and ask if you want to correct other > > errors that usually don't cause data loss, but might and some modicum of > > human intelligence is required to tell the two apart. Eg, I usually give up > > hitting 'y' after a dozen or so times in FSCK unless I have a specific > > reason to keep going. fsck -y has no such nuance. > > I do not believe that normal mode has any intellegnce to as if data > loss will or will not occur. It will gladly ask you if you want to > clear an inode that is the root of a rather large tree, and you end > up with either data loss, or a huge lost+found, sometimes even over > flowing the size of lost+found (though that may of been fixed in ufs2). > > It simply runs along and if it finds an error it asks if you want > to correct it or not. Y is not always the correct answer, but > most people are oblivious to what the questions imply with respect > to the file system, and hence answer Y. fsck does do thing in > a sequence that tries to make Y the correct answer, but as you > say human intelligence may do better. > > Some times if you had answered N at the right question you would not > of gotten all of the other 11 questions that lead you to giving up, > sometimes the N answer maybe 100's of Y's in, often to a clear > inode question. > > When I get a preen failure my usual next step is to run a logged > fsck -n to see what that says so I can evaluate the extent of fs > damage, especially if this is a critical file system containing > very valuable data. > > > Warner > > > > > > > So, I guess I'll just keep using fsck_y_enable=YES and relying on the > > > fact that by default that now includes the -R option. > > And if your running ufs2 with soft updates your in a > pretty safe place. I would not recommend doing this on ufs1 > or without soft updates enabled. > > One must try to remeber that fsck -p during /etc/rc processing can > run into many different file systems, some more resilent to running > things like fsck -R -y, some not. Having been in this situation with FreeBSD, Solaris, Linux, and many other oper
Re: svn commit: r330696 - in head/libexec/tftpd: . tests
Sorry, should be fixed by 330742.
On Fri, Mar 9, 2018 at 11:49 PM, Ilya Bakulin wrote:
> This broke build for at least ARM.
> Fix:
> diff --git a/libexec/tftpd/tests/functional.c b/libexec/tftpd/tests/
> functional.c
> index fea6870cac59..c467dfee3ba0 100644
> --- a/libexec/tftpd/tests/functional.c
> +++ b/libexec/tftpd/tests/functional.c
> @@ -248,10 +248,10 @@ require_bufeq(const char *expected, ssize_t
> expected_len, const char *actual,
> ssize_t i;
>
> ATF_REQUIRE_EQ_MSG(expected_len, len,
> - "Expected %ld bytes but got %ld", expected_len, len);
> + "Expected %zd bytes but got %zd", expected_len, len);
> for (i = 0; i < len; i++) {
> ATF_REQUIRE_EQ_MSG(actual[i], expected[i],
> - "Expected %#hhx at position %ld; got %hhx instead",
> + "Expected %#hhx at position %zd; got %hhx instead",
> expected[i], i, actual[i]);
> }
> }
>
> On Sat, Mar 10, 2018 at 12:30 AM Alan Somers wrote:
>
>> Author: asomers
>> Date: Fri Mar 9 15:30:20 2018
>> New Revision: 330696
>> URL: https://svnweb.freebsd.org/changeset/base/330696
>>
>> Log:
>> Add some functional tests for tftpd(8)
>>
>> tftpd(8) is difficult to test in isolation due to its relationship with
>> inetd. Create a test program that mimics the behavior of tftp(1) and
>> inetd(8) and verifies tftpd's response in several different scenarios.
>>
>> These test cases cover all of the basic TFTP protocol, but not the
>> optional
>> parts.
>>
>> PR: 157700
>> PR: 225996
>> PR: 226004
>> PR: 226005
>> MFC after:3 weeks
>> Differential Revision:https://reviews.freebsd.org/D14310
>>
>> Added:
>> head/libexec/tftpd/tests/
>> head/libexec/tftpd/tests/Makefile (contents, props changed)
>> head/libexec/tftpd/tests/functional.c (contents, props changed)
>> Modified:
>> head/libexec/tftpd/Makefile
>>
>> Modified: head/libexec/tftpd/Makefile
>>
>> ==
>> --- head/libexec/tftpd/Makefile Fri Mar 9 14:45:47 2018(r330695)
>> +++ head/libexec/tftpd/Makefile Fri Mar 9 15:30:20 2018(r330696)
>> @@ -14,4 +14,7 @@ CFLAGS+= -DLIBWRAP
>> LIBADD=wrap
>> .endif
>>
>> +HAS_TESTS=
>> +SUBDIR.${MK_TESTS}+= tests
>> +
>> .include
>>
>> Added: head/libexec/tftpd/tests/Makefile
>>
>> ==
>> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
>> +++ head/libexec/tftpd/tests/Makefile Fri Mar 9 15:30:20 2018
>> (r330696)
>> @@ -0,0 +1,14 @@
>> +# $FreeBSD$
>> +
>> +.include
>> +
>> +# Skip on GCC 4.2, because it lacks __COUNTER__
>> +.if ${COMPILER_TYPE} != "gcc" || ${COMPILER_VERSION} >= 40300
>> +ATF_TESTS_C= functional
>> +TEST_METADATA.functional+= timeout=15
>> +.endif
>> +
>> +LIBADD=util
>> +WARNS?=6
>> +
>> +.include
>>
>> Added: head/libexec/tftpd/tests/functional.c
>>
>> ==
>> --- /dev/null 00:00:00 1970 (empty, because file is newly added)
>> +++ head/libexec/tftpd/tests/functional.c Fri Mar 9 15:30:20
>> 2018(r330696)
>> @@ -0,0 +1,1006 @@
>> +/*-
>> + * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
>> + *
>> + * Copyright (c) 2018 Alan Somers. All rights reserved.
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + *notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + *notice, this list of conditions and the following disclaimer in the
>> + *documentation and/or other materials provided with the
>> distribution.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
>> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> + * ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE
>> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> CONSEQUENTIAL
>> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
>> GOODS
>> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
>> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
>> STRICT
>> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
>> WAY
>> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>> + * SUCH DAMAGE.
>> + */
>> +
>> +#include
>> +__FBSDID("$FreeBSD$");
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
svn commit: r330743 - in head: etc/rc.d share/man/man5
Author: jamie
Date: Sat Mar 10 20:13:07 2018
New Revision: 330743
URL: https://svnweb.freebsd.org/changeset/base/330743
Log:
Don't warn when the "hostname" rc variable is unset, but the hostname
is already non-empty (common in jails).
Modified:
head/etc/rc.d/hostname
head/share/man/man5/rc.conf.5
Modified: head/etc/rc.d/hostname
==
--- head/etc/rc.d/hostname Sat Mar 10 18:07:31 2018(r330742)
+++ head/etc/rc.d/hostname Sat Mar 10 20:13:07 2018(r330743)
@@ -60,9 +60,11 @@ hostname_start()
# Have we got a hostname yet?
#
if [ -z "${hostname}" ]; then
- # Null hostname is probably OK if DHCP is in use.
+ # Null hostname is probably OK if DHCP is in use,
+ # or when hostname is already set (common for jails).
#
- if [ -z "`list_net_interfaces dhcp`" ]; then
+ if [ -z "`list_net_interfaces dhcp`" -a \
+-z "`/bin/hostname`" ]; then
warn "\$hostname is not set -- see rc.conf(5)."
fi
return
Modified: head/share/man/man5/rc.conf.5
==
--- head/share/man/man5/rc.conf.5 Sat Mar 10 18:07:31 2018
(r330742)
+++ head/share/man/man5/rc.conf.5 Sat Mar 10 20:13:07 2018
(r330743)
@@ -24,7 +24,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd February 15, 2018
+.Dd March 10, 2018
.Dt RC.CONF 5
.Os
.Sh NAME
@@ -421,6 +421,9 @@ If
.Xr dhclient 8
is used to set the hostname via DHCP,
this variable should be set to an empty string.
+Within a
+.Xr jail 8
+the hostname is generally already set and this variable may absent.
If this value remains unset when the system is done booting
your console login will display the default hostname of
.Dq Amnesiac .
___
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: r328013 - head/sbin/fsck_ffs
With regard to: fsck_y_flags="-T ffs:-R -T ufs:-R" # Additional flags for fsck -y I don’t know how, but I completely missed the -T option for fsck when I was investigating this issue. That would be very useful, although I wanted my solution to be applicable to file systems other than ffs/ufs. With regard to the fsck_ffs behavior being a regression because formerly the FS would be mounted successfully: That was not my experience. What I observed was that the “fsck -y” would give the “please re-run” message, exit with 0 status so the boot would continue, the subsequent mount would fail because the filesystem was not clean, and *then* the boot would stop and drop to single user. -- David Bright d...@freebsd.org ___ 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: r330745 - head/sys/kern
Author: ian
Date: Sat Mar 10 22:07:57 2018
New Revision: 330745
URL: https://svnweb.freebsd.org/changeset/base/330745
Log:
Make root mount timeout logic work for filesystems other than ufs.
The vfs.mountroot.timeout tunable and .timeout directive in a mount.conf(5)
file allow specifying a wait timeout for the device(s) hosting the root
filesystem to become usable. The current mechanism for waiting for devices
and detecting their availability can't be used for zfs-hosted filesystems.
See the comment #20 in the PR for some expanded detail on these points.
This change adds retry logic to the actual root filesystem mount. That is,
insted of relying on device availability using device name lookups, it uses
the kernel_mount() call itself to detect whether the filesystem can be
mounted, and loops until it succeeds or the configured timeout is exceeded.
These changes are based on the patch attached to the PR, but it's rewritten
enough that all mistakes belong to me.
PR: 208882
X-MFC after: sufficient testing, and hopefully in time for 11.1
Modified:
head/sys/kern/vfs_mountroot.c
Modified: head/sys/kern/vfs_mountroot.c
==
--- head/sys/kern/vfs_mountroot.c Sat Mar 10 20:46:36 2018
(r330744)
+++ head/sys/kern/vfs_mountroot.c Sat Mar 10 22:07:57 2018
(r330745)
@@ -714,7 +714,7 @@ parse_mount(char **conf)
char *errmsg;
struct mntarg *ma;
char *dev, *fs, *opts, *tok;
- int error;
+ int delay, error, timeout;
error = parse_token(conf, &tok);
if (error)
@@ -755,15 +755,31 @@ parse_mount(char **conf)
if (error != 0)
goto out;
- ma = NULL;
- ma = mount_arg(ma, "fstype", fs, -1);
- ma = mount_arg(ma, "fspath", "/", -1);
- ma = mount_arg(ma, "from", dev, -1);
- ma = mount_arg(ma, "errmsg", errmsg, ERRMSGL);
- ma = mount_arg(ma, "ro", NULL, 0);
- ma = parse_mountroot_options(ma, opts);
- error = kernel_mount(ma, MNT_ROOTFS);
+ delay = hz / 10;
+ timeout = root_mount_timeout * hz;
+ for (;;) {
+ ma = NULL;
+ ma = mount_arg(ma, "fstype", fs, -1);
+ ma = mount_arg(ma, "fspath", "/", -1);
+ ma = mount_arg(ma, "from", dev, -1);
+ ma = mount_arg(ma, "errmsg", errmsg, ERRMSGL);
+ ma = mount_arg(ma, "ro", NULL, 0);
+ ma = parse_mountroot_options(ma, opts);
+
+ error = kernel_mount(ma, MNT_ROOTFS);
+ if (error == 0 || timeout <= 0)
+ break;
+
+ if (root_mount_timeout * hz == timeout ||
+ (bootverbose && timeout % hz == 0)) {
+ printf("Mounting from %s:%s failed with error %d; "
+ "retrying for %d more second%s\n", fs, dev, error,
+ timeout / hz, (timeout / hz > 1) ? "s" : "");
+ }
+ pause("rmretry", delay);
+ timeout -= delay;
+ }
out:
if (error) {
printf("Mounting from %s:%s failed with error %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"
svn commit: r330747 - head/sys/dev/usb/wlan
Author: avos
Date: Sat Mar 10 22:52:39 2018
New Revision: 330747
URL: https://svnweb.freebsd.org/changeset/base/330747
Log:
run(4): drop few unused variables.
Found by: Clang static analyzer
Modified:
head/sys/dev/usb/wlan/if_run.c
Modified: head/sys/dev/usb/wlan/if_run.c
==
--- head/sys/dev/usb/wlan/if_run.c Sat Mar 10 22:47:26 2018
(r330746)
+++ head/sys/dev/usb/wlan/if_run.c Sat Mar 10 22:52:39 2018
(r330747)
@@ -3483,7 +3483,6 @@ run_tx_mgt(struct run_softc *sc, struct mbuf *m, struc
struct rt2860_txwi *txwi;
uint16_t dur;
uint8_t ridx = rn->mgt_ridx;
- uint8_t type;
uint8_t xflags = 0;
uint8_t wflags = 0;
@@ -3491,8 +3490,6 @@ run_tx_mgt(struct run_softc *sc, struct mbuf *m, struc
wh = mtod(m, struct ieee80211_frame *);
- type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK;
-
/* tell hardware to add timestamp for probe responses */
if ((wh->i_fc[0] &
(IEEE80211_FC0_TYPE_MASK | IEEE80211_FC0_SUBTYPE_MASK)) ==
@@ -3609,11 +3606,9 @@ run_tx_param(struct run_softc *sc, struct mbuf *m, str
const struct ieee80211_bpf_params *params)
{
struct ieee80211com *ic = ni->ni_ic;
- struct ieee80211_frame *wh;
struct run_tx_data *data;
struct rt2870_txd *txd;
struct rt2860_txwi *txwi;
- uint8_t type;
uint8_t ridx;
uint8_t rate;
uint8_t opflags = 0;
@@ -3623,9 +3618,6 @@ run_tx_param(struct run_softc *sc, struct mbuf *m, str
RUN_LOCK_ASSERT(sc, MA_OWNED);
KASSERT(params != NULL, ("no raw xmit params"));
-
- wh = mtod(m, struct ieee80211_frame *);
- type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK;
rate = params->ibp_rate0;
if (!ieee80211_isratevalid(ic->ic_rt, rate)) {
___
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: r328013 - head/sbin/fsck_ffs
On Sat, Mar 10, 2018 at 05:01:40PM -0500, David Bright wrote: > With regard to the fsck_ffs behavior being a regression because formerly the > FS would be mounted successfully: > > That was not my experience. What I observed was that the “fsck -y” would give > the “please re-run” message, exit with 0 status so the boot would continue, > the subsequent mount would fail because the filesystem was not clean, and > *then* the boot would stop and drop to single user. I think my problem is specific to SU without journaling. The UFS code allows one to mount an unclean filesystem in that configuration since SU guarantees that on-disk metadata is consistent. A background fsck takes care of leaked inodes and data blocks. (FWIW, I'm not using journaling only because makefs(8) doesn't support the creation of SU+J filesystems.) /dev/gpt/rootfs: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED) /dev/gpt/rootfs: SUMMARY INFORMATION BAD (SALVAGED) /dev/gpt/rootfs: BLK(S) MISSING IN BIT MAPS (SALVAGED) /dev/gpt/rootfs: 32664 files, 495447 used, 813272 free (176 frags, 203274 blocks, 0.0% fragmentation) * PLEASE RERUN FSCK * WARNING: /: reload pending error: blocks 192 files 3 Unknown error 16; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! Mar 10 12:47:50 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: # mount /dev/gpt/rootfs on / (ufs, local, read-only) devfs on /dev (devfs, local, multilabel) # mount -u -o rw / WARNING: / was not properly dismounted # echo $? 0 # mount /dev/gpt/rootfs on / (ufs, local, soft-updates) devfs on /dev (devfs, local, multilabel) ___ 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: r330749 - in head/sys: dev/usb/wlan modules/usb/rum modules/usb/run modules/usb/uath modules/usb/upgt modules/usb/ural modules/usb/urtw modules/usb/zyd
Author: avos
Date: Sat Mar 10 23:16:24 2018
New Revision: 330749
URL: https://svnweb.freebsd.org/changeset/base/330749
Log:
usb/wlan/*: properly include "opt_wlan.h" into all drivers
Without it driver cannot be loaded when wlan(4) module is built with
'options IEEE80211_DEBUG_REFCNT'.
Modified:
head/sys/dev/usb/wlan/if_rum.c
head/sys/dev/usb/wlan/if_run.c
head/sys/dev/usb/wlan/if_uath.c
head/sys/dev/usb/wlan/if_upgt.c
head/sys/dev/usb/wlan/if_ural.c
head/sys/dev/usb/wlan/if_urtw.c
head/sys/dev/usb/wlan/if_zyd.c
head/sys/modules/usb/rum/Makefile
head/sys/modules/usb/run/Makefile
head/sys/modules/usb/uath/Makefile
head/sys/modules/usb/upgt/Makefile
head/sys/modules/usb/ural/Makefile
head/sys/modules/usb/urtw/Makefile
head/sys/modules/usb/zyd/Makefile
Modified: head/sys/dev/usb/wlan/if_rum.c
==
--- head/sys/dev/usb/wlan/if_rum.c Sat Mar 10 23:04:03 2018
(r330748)
+++ head/sys/dev/usb/wlan/if_rum.c Sat Mar 10 23:16:24 2018
(r330749)
@@ -27,6 +27,8 @@ __FBSDID("$FreeBSD$");
* http://www.ralinktech.com.tw/
*/
+#include "opt_wlan.h"
+
#include
#include
#include
Modified: head/sys/dev/usb/wlan/if_run.c
==
--- head/sys/dev/usb/wlan/if_run.c Sat Mar 10 23:04:03 2018
(r330748)
+++ head/sys/dev/usb/wlan/if_run.c Sat Mar 10 23:16:24 2018
(r330749)
@@ -25,6 +25,8 @@ __FBSDID("$FreeBSD$");
* http://www.ralinktech.com/
*/
+#include "opt_wlan.h"
+
#include
#include
#include
Modified: head/sys/dev/usb/wlan/if_uath.c
==
--- head/sys/dev/usb/wlan/if_uath.c Sat Mar 10 23:04:03 2018
(r330748)
+++ head/sys/dev/usb/wlan/if_uath.c Sat Mar 10 23:16:24 2018
(r330749)
@@ -67,6 +67,9 @@ __FBSDID("$FreeBSD$");
* for these devices does not work in this way and so does not work
* with this driver.
*/
+
+#include "opt_wlan.h"
+
#include
#include
#include
Modified: head/sys/dev/usb/wlan/if_upgt.c
==
--- head/sys/dev/usb/wlan/if_upgt.c Sat Mar 10 23:04:03 2018
(r330748)
+++ head/sys/dev/usb/wlan/if_upgt.c Sat Mar 10 23:16:24 2018
(r330749)
@@ -17,6 +17,8 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include "opt_wlan.h"
+
#include
#include
#include
Modified: head/sys/dev/usb/wlan/if_ural.c
==
--- head/sys/dev/usb/wlan/if_ural.c Sat Mar 10 23:04:03 2018
(r330748)
+++ head/sys/dev/usb/wlan/if_ural.c Sat Mar 10 23:16:24 2018
(r330749)
@@ -28,6 +28,8 @@ __FBSDID("$FreeBSD$");
* http://www.ralinktech.com/
*/
+#include "opt_wlan.h"
+
#include
#include
#include
Modified: head/sys/dev/usb/wlan/if_urtw.c
==
--- head/sys/dev/usb/wlan/if_urtw.c Sat Mar 10 23:04:03 2018
(r330748)
+++ head/sys/dev/usb/wlan/if_urtw.c Sat Mar 10 23:16:24 2018
(r330749)
@@ -16,6 +16,9 @@
#include
__FBSDID("$FreeBSD$");
+
+#include "opt_wlan.h"
+
#include
#include
#include
Modified: head/sys/dev/usb/wlan/if_zyd.c
==
--- head/sys/dev/usb/wlan/if_zyd.c Sat Mar 10 23:04:03 2018
(r330748)
+++ head/sys/dev/usb/wlan/if_zyd.c Sat Mar 10 23:16:24 2018
(r330749)
@@ -26,6 +26,8 @@ __FBSDID("$FreeBSD$");
* ZyDAS ZD1211/ZD1211B USB WLAN driver.
*/
+#include "opt_wlan.h"
+
#include
#include
#include
Modified: head/sys/modules/usb/rum/Makefile
==
--- head/sys/modules/usb/rum/Makefile Sat Mar 10 23:04:03 2018
(r330748)
+++ head/sys/modules/usb/rum/Makefile Sat Mar 10 23:16:24 2018
(r330749)
@@ -30,7 +30,7 @@ S=${SRCTOP}/sys
.PATH: $S/dev/usb/wlan
KMOD= if_rum
-SRCS= opt_bus.h opt_usb.h device_if.h bus_if.h usb_if.h usbdevs.h \
- if_rum.c
+SRCS= opt_bus.h opt_usb.h opt_wlan.h device_if.h bus_if.h usb_if.h \
+ usbdevs.h if_rum.c
.include
Modified: head/sys/modules/usb/run/Makefile
==
--- head/sys/modules/usb/run/Makefile Sat Mar 10 23:04:03 2018
(r330748)
+++ head/sys/modules/usb/run/Makefile Sat Mar 10 23:16:24 2018
(r330749)
@@ -30,7 +30,7 @@ S=${SRCTOP}/sys
.PATH: $S/dev/usb/wlan
KMOD= if_run
-SRCS= opt_bus.h opt_usb.h device_if.h bus_if.h usb_if.h usbdevs.h \
- if_run.c
+SRCS= opt_bus.h opt_usb.h opt_wlan.h device_if.h bus_if.h usb_if.h \
+ usbdevs.h if_run.c
.include
Modified: head/sys/modules/us
svn commit: r330750 - in head/sys/dev/rtwn: rtl8188e rtl8192c
Author: avos
Date: Sat Mar 10 23:47:03 2018
New Revision: 330750
URL: https://svnweb.freebsd.org/changeset/base/330750
Log:
rtwn(4): reset Tx power values before calling get_txpower()
for RTL8192C / RTL8188E (like it is done for other chipsets).
Modified:
head/sys/dev/rtwn/rtl8188e/r88e_chan.c
head/sys/dev/rtwn/rtl8192c/r92c_chan.c
Modified: head/sys/dev/rtwn/rtl8188e/r88e_chan.c
==
--- head/sys/dev/rtwn/rtl8188e/r88e_chan.c Sat Mar 10 23:16:24 2018
(r330749)
+++ head/sys/dev/rtwn/rtl8188e/r88e_chan.c Sat Mar 10 23:47:03 2018
(r330750)
@@ -104,8 +104,6 @@ r88e_get_txpower(struct rtwn_softc *sc, int chain,
max_mcs = RTWN_RIDX_HT_MCS(sc->ntxchains * 8 - 1);
KASSERT(max_mcs <= RTWN_RIDX_COUNT, ("increase ridx limit\n"));
- memset(power, 0, max_mcs * sizeof(power[0]));
-
/* Compute per-CCK rate Tx power. */
cckpow = rt->cck_tx_pwr[group];
for (ridx = RTWN_RIDX_CCK1; ridx <= RTWN_RIDX_CCK11; ridx++) {
Modified: head/sys/dev/rtwn/rtl8192c/r92c_chan.c
==
--- head/sys/dev/rtwn/rtl8192c/r92c_chan.c Sat Mar 10 23:16:24 2018
(r330749)
+++ head/sys/dev/rtwn/rtl8192c/r92c_chan.c Sat Mar 10 23:47:03 2018
(r330750)
@@ -102,7 +102,6 @@ r92c_get_txpower(struct rtwn_softc *sc, int chain,
max_mcs = RTWN_RIDX_HT_MCS(sc->ntxchains * 8 - 1);
KASSERT(max_mcs <= RTWN_RIDX_COUNT, ("increase ridx limit\n"));
- memset(power, 0, max_mcs * sizeof(power[0]));
if (rs->regulatory == 0) {
for (ridx = RTWN_RIDX_CCK1; ridx <= RTWN_RIDX_CCK11; ridx++)
power[ridx] = base[chain].pwr[0][ridx];
@@ -225,6 +224,7 @@ r92c_set_txpower(struct rtwn_softc *sc, struct ieee802
int i;
for (i = 0; i < sc->ntxchains; i++) {
+ memset(power, 0, sizeof(power));
/* Compute per-rate Tx power values. */
rtwn_r92c_get_txpower(sc, i, c, power);
#ifdef RTWN_DEBUG
___
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: r330753 - head/sys/dev/otus
Author: avos
Date: Sun Mar 11 00:38:08 2018
New Revision: 330753
URL: https://svnweb.freebsd.org/changeset/base/330753
Log:
otus(4): check mcast / mgt / ucast rates during Tx descriptor setup
These parameters may be changed via ifconfig(8); by default,
mgt / mcast rates are lowest possible and ucast rate is not set
(matches previous configuration).
While here, store some variables locally for better readability.
Modified:
head/sys/dev/otus/if_otus.c
Modified: head/sys/dev/otus/if_otus.c
==
--- head/sys/dev/otus/if_otus.c Sun Mar 11 00:08:09 2018(r330752)
+++ head/sys/dev/otus/if_otus.c Sun Mar 11 00:38:08 2018(r330753)
@@ -2182,6 +2182,7 @@ static int
otus_tx(struct otus_softc *sc, struct ieee80211_node *ni, struct mbuf *m,
struct otus_data *data, const struct ieee80211_bpf_params *params)
{
+ const struct ieee80211_txparam *tp = ni->ni_txparms;
struct ieee80211com *ic = &sc->sc_ic;
struct ieee80211vap *vap = ni->ni_vap;
struct ieee80211_frame *wh;
@@ -2190,7 +2191,7 @@ otus_tx(struct otus_softc *sc, struct ieee80211_node *
uint32_t phyctl;
uint16_t macctl, qos;
uint8_t qid, rate;
- int hasqos, xferlen;
+ int hasqos, xferlen, type, ismcast;
wh = mtod(m, struct ieee80211_frame *);
if (wh->i_fc[1] & IEEE80211_FC1_PROTECTED) {
@@ -2228,17 +2229,19 @@ otus_tx(struct otus_softc *sc, struct ieee80211_node *
qid = WME_AC_BE;
}
+ type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK;
+ ismcast = IEEE80211_IS_MULTICAST(wh->i_addr1);
+
/* Pickup a rate index. */
- if (params != NULL) {
+ if (params != NULL)
rate = otus_rate_to_hw_rate(sc, params->ibp_rate0);
- } else if (m->m_flags & M_EAPOL) {
- /* Get lowest rate */
- rate = otus_rate_to_hw_rate(sc, 0);
- } else if (IEEE80211_IS_MULTICAST(wh->i_addr1) ||
- (wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK) != IEEE80211_FC0_TYPE_DATA)
{
- /* Get lowest rate */
- rate = otus_rate_to_hw_rate(sc, 0);
- } else {
+ else if (!!(m->m_flags & M_EAPOL) || type != IEEE80211_FC0_TYPE_DATA)
+ rate = otus_rate_to_hw_rate(sc, tp->mgmtrate);
+ else if (ismcast)
+ rate = otus_rate_to_hw_rate(sc, tp->mcastrate);
+ else if (tp->ucastrate != IEEE80211_FIXED_RATE_NONE)
+ rate = otus_rate_to_hw_rate(sc, tp->ucastrate);
+ else {
(void) ieee80211_ratectl_rate(ni, NULL, 0);
rate = otus_rate_to_hw_rate(sc, ni->ni_txrate);
}
@@ -2249,12 +2252,12 @@ otus_tx(struct otus_softc *sc, struct ieee80211_node *
/*
* XXX TODO: params for NOACK, ACK, RTS, CTS, etc
*/
- if (IEEE80211_IS_MULTICAST(wh->i_addr1) ||
+ if (ismcast ||
(hasqos && ((qos & IEEE80211_QOS_ACKPOLICY) ==
IEEE80211_QOS_ACKPOLICY_NOACK)))
macctl |= AR_TX_MAC_NOACK;
- if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) {
+ if (!ismcast) {
if (m->m_pkthdr.len + IEEE80211_CRC_LEN >= vap->iv_rtsthreshold)
macctl |= AR_TX_MAC_RTS;
else if (ic->ic_flags & IEEE80211_F_USEPROT) {
___
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: r330754 - head/sys/powerpc/ofw
Author: nwhitehorn
Date: Sun Mar 11 01:09:31 2018
New Revision: 330754
URL: https://svnweb.freebsd.org/changeset/base/330754
Log:
Make FDT-using parts of ofw_machdep.c condition on options FDT. This fixes
the kernel build when options FDT is absent.
Modified:
head/sys/powerpc/ofw/ofw_machdep.c
Modified: head/sys/powerpc/ofw/ofw_machdep.c
==
--- head/sys/powerpc/ofw/ofw_machdep.c Sun Mar 11 00:38:08 2018
(r330753)
+++ head/sys/powerpc/ofw/ofw_machdep.c Sun Mar 11 01:09:31 2018
(r330754)
@@ -223,6 +223,7 @@ parse_ofw_memory(phandle_t node, const char *prop, str
return (sz);
}
+#ifdef FDT
static int
excise_fdt_reserved(struct mem_region *avail, int asz)
{
@@ -310,6 +311,7 @@ excise_fdt_reserved(struct mem_region *avail, int asz)
return (asz);
}
+#endif
/*
* This is called during powerpc_init, before the system is really initialized.
@@ -348,9 +350,11 @@ ofw_mem_regions(struct mem_region *memp, int *memsz,
asz += res/sizeof(struct mem_region);
}
+#ifdef FDT
phandle = OF_finddevice("/chosen");
if (OF_hasprop(phandle, "fdtmemreserv"))
asz = excise_fdt_reserved(availp, asz);
+#endif
*memsz = msz;
*availsz = asz;
@@ -409,6 +413,7 @@ OF_bootstrap()
} else
#endif
if (fdt != NULL) {
+#ifdef FDT
#ifdef AIM
bus_space_tag_t fdt_bt;
vm_offset_t tmp_fdt_ptr;
@@ -445,6 +450,7 @@ OF_bootstrap()
err = OF_init((void *)fdt_va);
#else
err = OF_init(fdt);
+#endif
#endif
}
___
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: r330759 - in head: sbin/nvmecontrol sys/dev/nvme
Author: mav
Date: Sun Mar 11 05:09:02 2018
New Revision: 330759
URL: https://svnweb.freebsd.org/changeset/base/330759
Log:
Add new identify data structures fields from NVMe 1.3a.
Some of them are already supported by existing hardware, so reporting
them `nvmecontrol identify` can be useful.
Modified:
head/sbin/nvmecontrol/identify.c
head/sys/dev/nvme/nvme.h
Modified: head/sbin/nvmecontrol/identify.c
==
--- head/sbin/nvmecontrol/identify.cSun Mar 11 04:37:05 2018
(r330758)
+++ head/sbin/nvmecontrol/identify.cSun Mar 11 05:09:02 2018
(r330759)
@@ -95,25 +95,35 @@ print_controller(struct nvme_controller_data *cdata)
printf("Controller Capabilities/Features\n");
printf("\n");
- printf("Vendor ID: %04x\n", cdata->vid);
- printf("Subsystem Vendor ID:%04x\n", cdata->ssvid);
+ printf("Vendor ID: %04x\n", cdata->vid);
+ printf("Subsystem Vendor ID: %04x\n", cdata->ssvid);
nvme_strvis(str, cdata->sn, sizeof(str), NVME_SERIAL_NUMBER_LENGTH);
- printf("Serial Number: %s\n", str);
+ printf("Serial Number: %s\n", str);
nvme_strvis(str, cdata->mn, sizeof(str), NVME_MODEL_NUMBER_LENGTH);
- printf("Model Number: %s\n", str);
+ printf("Model Number:%s\n", str);
nvme_strvis(str, cdata->fr, sizeof(str), NVME_FIRMWARE_REVISION_LENGTH);
- printf("Firmware Version: %s\n", str);
- printf("Recommended Arb Burst: %d\n", cdata->rab);
- printf("IEEE OUI Identifier:%02x %02x %02x\n",
+ printf("Firmware Version:%s\n", str);
+ printf("Recommended Arb Burst: %d\n", cdata->rab);
+ printf("IEEE OUI Identifier: %02x %02x %02x\n",
cdata->ieee[0], cdata->ieee[1], cdata->ieee[2]);
- printf("Multi-Interface Cap:%02x\n", cdata->mic);
+ printf("Multi-Path I/O Capabilities: %s%s%s%s\n",
+ (cdata->mic == 0) ? "Not Supported" : "",
+ ((cdata->mic >> NVME_CTRLR_DATA_MIC_SRIOVVF_SHIFT) &
+NVME_CTRLR_DATA_MIC_SRIOVVF_MASK) ? "SR-IOV VF, " : "",
+ ((cdata->mic >> NVME_CTRLR_DATA_MIC_MCTRLRS_SHIFT) &
+NVME_CTRLR_DATA_MIC_MCTRLRS_MASK) ? "Multiple controllers, " : "",
+ ((cdata->mic >> NVME_CTRLR_DATA_MIC_MPORTS_SHIFT) &
+NVME_CTRLR_DATA_MIC_MPORTS_MASK) ? "Multiple ports" : "");
/* TODO: Use CAP.MPSMIN to determine true memory page size. */
- printf("Max Data Transfer Size: ");
+ printf("Max Data Transfer Size: ");
if (cdata->mdts == 0)
printf("Unlimited\n");
else
printf("%d\n", PAGE_SIZE * (1 << cdata->mdts));
- printf("Controller ID: 0x%02x\n", cdata->ctrlr_id);
+ printf("Controller ID: 0x%02x\n", cdata->ctrlr_id);
+ printf("Version: %d.%d.%d\n",
+ (cdata->ver >> 16) & 0x, (cdata->ver >> 8) & 0xff,
+ cdata->ver & 0xff);
printf("\n");
printf("Admin Command Set Attributes\n");
@@ -126,6 +136,21 @@ print_controller(struct nvme_controller_data *cdata)
fw ? "Supported" : "Not Supported");
printf("Namespace Managment: %s\n",
nsmgmt ? "Supported" : "Not Supported");
+ printf("Device Self-test:%sSupported\n",
+ ((oacs >> NVME_CTRLR_DATA_OACS_SELFTEST_SHIFT) &
+NVME_CTRLR_DATA_OACS_SELFTEST_MASK) ? "" : "Not ");
+ printf("Directives: %sSupported\n",
+ ((oacs >> NVME_CTRLR_DATA_OACS_DIRECTIVES_SHIFT) &
+NVME_CTRLR_DATA_OACS_DIRECTIVES_MASK) ? "" : "Not ");
+ printf("NVMe-MI Send/Receive:%sSupported\n",
+ ((oacs >> NVME_CTRLR_DATA_OACS_NVMEMI_SHIFT) &
+NVME_CTRLR_DATA_OACS_NVMEMI_MASK) ? "" : "Not ");
+ printf("Virtualization Management: %sSupported\n",
+ ((oacs >> NVME_CTRLR_DATA_OACS_VM_SHIFT) &
+NVME_CTRLR_DATA_OACS_VM_MASK) ? "" : "Not ");
+ printf("Doorbell Buffer Config %sSupported\n",
+ ((oacs >> NVME_CTRLR_DATA_OACS_DBBUFFER_SHIFT) &
+NVME_CTRLR_DATA_OACS_DBBUFFER_MASK) ? "" : "Not ");
printf("Abort Command Limit: %d\n", cdata->acl+1);
printf("Async Event Request Limit: %d\n", cdata->aerl+1);
printf("Number of Firmware Slots:");
@@ -159,6 +184,18 @@ print_controller(struct nvme_controller_data *cdata)
write_unc ? "Supported" : "Not Supported");
printf("Dataset Management Command: %s\n",
dsm ? "Supported" : "Not Supported");
+ printf("Write Zeroes Command:%sSupported\n",
+ ((oncs >> NVME_CTRLR_DATA_ONCS_WRZERO_SHI
svn commit: r330756 - head/sys/arm/allwinner/clkng
Author: manu
Date: Sun Mar 11 04:01:23 2018
New Revision: 330756
URL: https://svnweb.freebsd.org/changeset/base/330756
Log:
allwinner: Add IR clock to sun8i
Add ir clock definition to sun8i-r-ccu.
No idea if it's working but aw_cir seems happy now and the frequency
is set to 3Mhz as it should.
Modified:
head/sys/arm/allwinner/clkng/ccu_sun8i_r.c
Modified: head/sys/arm/allwinner/clkng/ccu_sun8i_r.c
==
--- head/sys/arm/allwinner/clkng/ccu_sun8i_r.c Sun Mar 11 02:45:52 2018
(r330755)
+++ head/sys/arm/allwinner/clkng/ccu_sun8i_r.c Sun Mar 11 04:01:23 2018
(r330756)
@@ -108,6 +108,17 @@ DIV_CLK(apb0_clk,
0, 2, /* shift, width */
0, NULL); /* flags, div table */
+static const char *ir_parents[] = {"osc32k", "osc24M"};
+NM_CLK(ir_clk,
+CLK_IR,/* id */
+"ir", ir_parents, /* names, parents */
+0x54, /* offset */
+0, 4, 0, 0,/* N factor */
+16, 2, 0, 0, /* M flags */
+24, 2, /* mux */
+31,/* gate */
+AW_CLK_HAS_MUX | AW_CLK_REPARENT); /* flags */
+
static struct aw_clk_prediv_mux_def *r_ccu_prediv_mux_clks[] = {
&ar100_clk,
};
@@ -124,6 +135,10 @@ static struct clk_fixed_def *fixed_factor_clks[] = {
&ahb0_clk,
};
+static struct aw_clk_nm_def *nm_clks[] = {
+ &ir_clk,
+};
+
void
ccu_sun8i_r_register_clocks(struct aw_ccung_softc *sc)
{
@@ -147,4 +162,6 @@ ccu_sun8i_r_register_clocks(struct aw_ccung_softc *sc)
clknode_div_register(sc->clkdom, div_clks[i]);
for (i = 0; i < nitems(fixed_factor_clks); i++)
clknode_fixed_register(sc->clkdom, fixed_factor_clks[i]);
+ for (i = 0; i < nitems(nm_clks); i++)
+ aw_clk_nm_register(sc->clkdom, nm_clks[i]);
}
___
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: r330759 - in head: sbin/nvmecontrol sys/dev/nvme
On Sat, Mar 10, 2018 at 9:09 PM, Alexander Motin wrote: > Author: mav > Date: Sun Mar 11 05:09:02 2018 > New Revision: 330759 > URL: https://svnweb.freebsd.org/changeset/base/330759 > > Log: > Add new identify data structures fields from NVMe 1.3a. > > ... > Modified: head/sbin/nvmecontrol/identify.c > == > --- head/sbin/nvmecontrol/identify.cSun Mar 11 04:37:05 2018 > (r330758) > +++ head/sbin/nvmecontrol/identify.cSun Mar 11 05:09:02 2018 > (r330759) > @@ -95,25 +95,35 @@ print_controller(struct nvme_controller_data *cdata) > ... > + ((cdata->mic >> NVME_CTRLR_DATA_MIC_SRIOVVF_SHIFT) & > +NVME_CTRLR_DATA_MIC_SRIOVVF_MASK) ? "SR-IOV VF, " : "", > + ((cdata->mic >> NVME_CTRLR_DATA_MIC_MCTRLRS_SHIFT) & > +NVME_CTRLR_DATA_MIC_MCTRLRS_MASK) ? "Multiple controllers, " : > "", > + ((cdata->mic >> NVME_CTRLR_DATA_MIC_MPORTS_SHIFT) & > +NVME_CTRLR_DATA_MIC_MPORTS_MASK) ? "Multiple ports" : ""); > ... > Modified: head/sys/dev/nvme/nvme.h > == > --- head/sys/dev/nvme/nvme.hSun Mar 11 04:37:05 2018(r330758) > +++ head/sys/dev/nvme/nvme.hSun Mar 11 05:09:02 2018(r330759) > @@ -153,6 +153,17 @@ > #define NVME_PWR_ST_APS_SHIFT (6) > #define NVME_PWR_ST_APS_MASK (0x3) > > +/** Controller Multi-path I/O and Namespace Sharing Capabilities */ > +/* More then one port */ > +#define NVME_CTRLR_DATA_MIC_MPORTS_SHIFT (0) > +#define NVME_CTRLR_DATA_MIC_MPORTS_MASK(0x1) > +/* More then one controller */ > +#define NVME_CTRLR_DATA_MIC_MCTRLRS_SHIFT (1) > +#define NVME_CTRLR_DATA_MIC_MCTRLRS_MASK (0x1) > +/* SR-IOV Virtual Function */ > +#define NVME_CTRLR_DATA_MIC_SRIOVVF_SHIFT (2) > +#define NVME_CTRLR_DATA_MIC_SRIOVVF_MASK (0x1) > + > /** OACS - optional admin command support */ > /* supports security send/receive commands */ > #define NVME_CTRLR_DATA_OACS_SECURITY_SHIFT(0) > @@ -166,6 +177,21 @@ > /* supports namespace management commands */ > #define NVME_CTRLR_DATA_OACS_NSMGMT_SHIFT (3) > #define NVME_CTRLR_DATA_OACS_NSMGMT_MASK (0x1) > +/* supports Device Self-test command */ > +#define NVME_CTRLR_DATA_OACS_SELFTEST_SHIFT(4) > +#define NVME_CTRLR_DATA_OACS_SELFTEST_MASK (0x1) > +/* supports Directives */ > +#define NVME_CTRLR_DATA_OACS_DIRECTIVES_SHIFT (5) > +#define NVME_CTRLR_DATA_OACS_DIRECTIVES_MASK (0x1) > +/* supports NVMe-MI Send/Receive */ > +#define NVME_CTRLR_DATA_OACS_NVMEMI_SHIFT (6) > +#define NVME_CTRLR_DATA_OACS_NVMEMI_MASK (0x1) > +/* supports Virtualization Management */ > +#define NVME_CTRLR_DATA_OACS_VM_SHIFT (7) > +#define NVME_CTRLR_DATA_OACS_VM_MASK (0x1) > +/* supports Doorbell Buffer Config */ > +#define NVME_CTRLR_DATA_OACS_DBBUFFER_SHIFT(8) > +#define NVME_CTRLR_DATA_OACS_DBBUFFER_MASK (0x1) This seems like a suboptimal way to represent and check single flag bits. Is there a reason the conventional (1
svn commit: r330757 - head/stand/common
Author: kevans
Date: Sun Mar 11 04:10:18 2018
New Revision: 330757
URL: https://svnweb.freebsd.org/changeset/base/330757
Log:
stand/interp_lua: correct errorr => error
Modified:
head/stand/common/interp_lua.c
Modified: head/stand/common/interp_lua.c
==
--- head/stand/common/interp_lua.c Sun Mar 11 04:01:23 2018
(r330756)
+++ head/stand/common/interp_lua.c Sun Mar 11 04:10:18 2018
(r330757)
@@ -123,7 +123,7 @@ interp_init(void)
if (interp_include(filename) != 0) {
const char *errstr = lua_tostring(luap, -1);
errstr = errstr == NULL ? "unknown" : errstr;
-printf("Startup errorr in %s:\nLUA ERROR: %s.\n", filename,
errstr);
+printf("Startup error in %s:\nLUA ERROR: %s.\n", filename,
errstr);
lua_pop(luap, 1);
}
}
___
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: r330758 - head/sys/dev/extres/regulator
Author: manu
Date: Sun Mar 11 04:37:05 2018
New Revision: 330758
URL: https://svnweb.freebsd.org/changeset/base/330758
Log:
extres/regulators: Add sysctls for regulators
For each regulators create an hw.regulator.. :
uvolt: Current value
always_on: 1 If the reg is always on
boot_on: 1 If the reg is set at boot time
enable_cnt: Number of consumer(s)
enable_delay: Delay before enabling the regulator
ramp_delay: The Ramp delay
max_uamp: The maximum value of the regulator in uAmps
min_uamp: The minimal value of the regulator in uAmps
max_uvolt: The maximum value of the regulator in uVolts
min_uvolt: The minimal value of the regulator in uVolts
Reviewed by: ian
Differential Revision:https://reviews.freebsd.org/D14578
Modified:
head/sys/dev/extres/regulator/regulator.c
head/sys/dev/extres/regulator/regulator.h
Modified: head/sys/dev/extres/regulator/regulator.c
==
--- head/sys/dev/extres/regulator/regulator.c Sun Mar 11 04:10:18 2018
(r330757)
+++ head/sys/dev/extres/regulator/regulator.c Sun Mar 11 04:37:05 2018
(r330758)
@@ -51,6 +51,8 @@ __FBSDID("$FreeBSD$");
#include "regdev_if.h"
+SYSCTL_NODE(_hw, OID_AUTO, regulator, CTLFLAG_RD, NULL, "Regulators");
+
MALLOC_DEFINE(M_REGULATOR, "regulator", "Regulator framework");
#defineDIV_ROUND_UP(n,d) howmany(n, d)
@@ -112,6 +114,8 @@ struct regnode {
int enable_cnt; /* Enabled counter */
struct regnode_std_param std_param; /* Standard parameters */
+
+ struct sysctl_ctx_list sysctl_ctx;
};
/*
@@ -147,6 +151,29 @@ SX_SYSINIT(regulator_topology, ®node_topo_lock, "Re
#define REGNODE_XLOCK(_sc) sx_xlock(&((_sc)->lock))
#define REGNODE_UNLOCK(_sc)sx_unlock(&((_sc)->lock))
+/*
+ * sysctl handler
+ */
+static int
+regnode_uvolt_sysctl(SYSCTL_HANDLER_ARGS)
+{
+ struct regnode *regnode = arg1;
+ int rv, uvolt;
+
+ if (regnode->std_param.min_uvolt == regnode->std_param.max_uvolt) {
+ uvolt = regnode->std_param.min_uvolt;
+ } else {
+ REG_TOPO_SLOCK();
+ if ((rv = regnode_get_voltage(regnode, &uvolt)) != 0) {
+ REG_TOPO_UNLOCK();
+ return (rv);
+ }
+ REG_TOPO_UNLOCK();
+ }
+
+ return sysctl_handle_int(oidp, &uvolt, sizeof(uvolt), req);
+}
+
/*
*
* Default regulator methods for base class.
@@ -233,6 +260,7 @@ regnode_create(device_t pdev, regnode_class_t regnode_
struct regnode_init_def *def)
{
struct regnode *regnode;
+ struct sysctl_oid *regnode_oid;
KASSERT(def->name != NULL, ("regulator name is NULL"));
KASSERT(def->name[0] != '\0', ("regulator name is empty"));
@@ -276,6 +304,66 @@ regnode_create(device_t pdev, regnode_class_t regnode_
#ifdef FDT
regnode->ofw_node = def->ofw_node;
#endif
+
+ sysctl_ctx_init(®node->sysctl_ctx);
+ regnode_oid = SYSCTL_ADD_NODE(®node->sysctl_ctx,
+ SYSCTL_STATIC_CHILDREN(_hw_regulator),
+ OID_AUTO, regnode->name,
+ CTLFLAG_RD, 0, "A regulator node");
+
+ SYSCTL_ADD_INT(®node->sysctl_ctx,
+ SYSCTL_CHILDREN(regnode_oid),
+ OID_AUTO, "min_uvolt",
+ CTLFLAG_RD, ®node->std_param.min_uvolt, 0,
+ "Minimal voltage (in uV)");
+ SYSCTL_ADD_INT(®node->sysctl_ctx,
+ SYSCTL_CHILDREN(regnode_oid),
+ OID_AUTO, "max_uvolt",
+ CTLFLAG_RD, ®node->std_param.max_uvolt, 0,
+ "Maximal voltage (in uV)");
+ SYSCTL_ADD_INT(®node->sysctl_ctx,
+ SYSCTL_CHILDREN(regnode_oid),
+ OID_AUTO, "min_uamp",
+ CTLFLAG_RD, ®node->std_param.min_uamp, 0,
+ "Minimal amperage (in uA)");
+ SYSCTL_ADD_INT(®node->sysctl_ctx,
+ SYSCTL_CHILDREN(regnode_oid),
+ OID_AUTO, "max_uamp",
+ CTLFLAG_RD, ®node->std_param.max_uamp, 0,
+ "Maximal amperage (in uA)");
+ SYSCTL_ADD_INT(®node->sysctl_ctx,
+ SYSCTL_CHILDREN(regnode_oid),
+ OID_AUTO, "ramp_delay",
+ CTLFLAG_RD, ®node->std_param.ramp_delay, 0,
+ "Ramp delay (in uV/us)");
+ SYSCTL_ADD_INT(®node->sysctl_ctx,
+ SYSCTL_CHILDREN(regnode_oid),
+ OID_AUTO, "enable_delay",
+ CTLFLAG_RD, ®node->std_param.enable_delay, 0,
+ "Enable delay (in us)");
+ SYSCTL_ADD_INT(®node->sysctl_ctx,
+ SYSCTL_CHILDREN(regnode_oid),
+ OID_AUTO, "enable_cnt",
+ CTLFLAG_RD, ®node->enable_cnt, 0,
+ "The regulator enable counter");
+ SYSCTL_ADD_INT(®node->sysctl_ctx,
+ SYSCTL_CHILDREN(regnode_oid),
+ OID_AUTO, "boot_on",
+ CTLFLAG_RD, (int *) ®node->std_param.boot_on, 0,
+
Re: svn commit: r330759 - in head: sbin/nvmecontrol sys/dev/nvme
On 11.03.2018 01:12, Conrad Meyer wrote: > On Sat, Mar 10, 2018 at 9:09 PM, Alexander Motin wrote: >> Author: mav >> Date: Sun Mar 11 05:09:02 2018 >> New Revision: 330759 >> URL: https://svnweb.freebsd.org/changeset/base/330759 >> >> Log: >> Add new identify data structures fields from NVMe 1.3a. >> >> ... >> Modified: head/sbin/nvmecontrol/identify.c >> == >> --- head/sbin/nvmecontrol/identify.cSun Mar 11 04:37:05 2018 >> (r330758) >> +++ head/sbin/nvmecontrol/identify.cSun Mar 11 05:09:02 2018 >> (r330759) >> @@ -95,25 +95,35 @@ print_controller(struct nvme_controller_data *cdata) >> ... >> + ((cdata->mic >> NVME_CTRLR_DATA_MIC_SRIOVVF_SHIFT) & >> +NVME_CTRLR_DATA_MIC_SRIOVVF_MASK) ? "SR-IOV VF, " : "", >> + ((cdata->mic >> NVME_CTRLR_DATA_MIC_MCTRLRS_SHIFT) & >> +NVME_CTRLR_DATA_MIC_MCTRLRS_MASK) ? "Multiple controllers, " : >> "", >> + ((cdata->mic >> NVME_CTRLR_DATA_MIC_MPORTS_SHIFT) & >> +NVME_CTRLR_DATA_MIC_MPORTS_MASK) ? "Multiple ports" : ""); >> ... >> Modified: head/sys/dev/nvme/nvme.h >> == >> --- head/sys/dev/nvme/nvme.hSun Mar 11 04:37:05 2018(r330758) >> +++ head/sys/dev/nvme/nvme.hSun Mar 11 05:09:02 2018(r330759) >> @@ -153,6 +153,17 @@ >> #define NVME_PWR_ST_APS_SHIFT (6) >> #define NVME_PWR_ST_APS_MASK (0x3) >> >> +/** Controller Multi-path I/O and Namespace Sharing Capabilities */ >> +/* More then one port */ >> +#define NVME_CTRLR_DATA_MIC_MPORTS_SHIFT (0) >> +#define NVME_CTRLR_DATA_MIC_MPORTS_MASK(0x1) >> +/* More then one controller */ >> +#define NVME_CTRLR_DATA_MIC_MCTRLRS_SHIFT (1) >> +#define NVME_CTRLR_DATA_MIC_MCTRLRS_MASK (0x1) >> +/* SR-IOV Virtual Function */ >> +#define NVME_CTRLR_DATA_MIC_SRIOVVF_SHIFT (2) >> +#define NVME_CTRLR_DATA_MIC_SRIOVVF_MASK (0x1) >> + >> /** OACS - optional admin command support */ >> /* supports security send/receive commands */ >> #define NVME_CTRLR_DATA_OACS_SECURITY_SHIFT(0) >> @@ -166,6 +177,21 @@ >> /* supports namespace management commands */ >> #define NVME_CTRLR_DATA_OACS_NSMGMT_SHIFT (3) >> #define NVME_CTRLR_DATA_OACS_NSMGMT_MASK (0x1) >> +/* supports Device Self-test command */ >> +#define NVME_CTRLR_DATA_OACS_SELFTEST_SHIFT(4) >> +#define NVME_CTRLR_DATA_OACS_SELFTEST_MASK (0x1) >> +/* supports Directives */ >> +#define NVME_CTRLR_DATA_OACS_DIRECTIVES_SHIFT (5) >> +#define NVME_CTRLR_DATA_OACS_DIRECTIVES_MASK (0x1) >> +/* supports NVMe-MI Send/Receive */ >> +#define NVME_CTRLR_DATA_OACS_NVMEMI_SHIFT (6) >> +#define NVME_CTRLR_DATA_OACS_NVMEMI_MASK (0x1) >> +/* supports Virtualization Management */ >> +#define NVME_CTRLR_DATA_OACS_VM_SHIFT (7) >> +#define NVME_CTRLR_DATA_OACS_VM_MASK (0x1) >> +/* supports Doorbell Buffer Config */ >> +#define NVME_CTRLR_DATA_OACS_DBBUFFER_SHIFT(8) >> +#define NVME_CTRLR_DATA_OACS_DBBUFFER_MASK (0x1) > > This seems like a suboptimal way to represent and check single flag > bits. Is there a reason the conventional (1
svn commit: r330761 - head/share/misc
Author: joneum (ports committer) Date: Sun Mar 11 07:33:49 2018 New Revision: 330761 URL: https://svnweb.freebsd.org/changeset/base/330761 Log: Add myself to committers-ports.dot Modified: head/share/misc/committers-ports.dot Modified: head/share/misc/committers-ports.dot == --- head/share/misc/committers-ports.dotSun Mar 11 06:30:09 2018 (r330760) +++ head/share/misc/committers-ports.dotSun Mar 11 07:33:49 2018 (r330761) @@ -131,6 +131,7 @@ jkim [label="Jung-uk Kim\nj...@freebsd.org\n2007/09/12 jlaffaye [label="Julien Laffaye\njlaff...@freebsd.org\n2011/06/06"] jmd [label="Johannes M. Dieterich\n...@freebsd.org\n2017/01/09"] jmelo [label="Jean Milanez Melo\njm...@freebsd.org\n2006/03/31"] +joneum [label="Jochen Neumeister\jon...@freebsd.org\n2017/05/11" joerg [label="Joerg Wunsch\njo...@freebsd.org\n1994/08/22"] johans [label="Johan Selst\njoh...@freebsd.org\n2006/04/01"] josef [label="Josef El-Rayes\njo...@freebsd.org\n2004/12/20"] @@ -530,6 +531,7 @@ miwi -> dhn miwi -> farrokhi miwi -> fluffy miwi -> gahr +miwi -> joneum miwi -> kmoore miwi -> lme miwi -> makc @@ -597,6 +599,7 @@ rene -> cmt rene -> crees rene -> jgh rene -> jmd +rene -> joneum rene -> ler rene -> olivierd @@ -658,6 +661,7 @@ tabthorpe -> zi tabthorpe -> gblach tcberner -> adridg +tcberner -> joneum tcberner -> yuri thierry -> jadawin @@ -665,6 +669,8 @@ thierry -> riggs tmclaugh -> itetcu tmclaugh -> xride + +tz -> joneum vsevolod -> eugen ___ 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"
