Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On Tue, Apr 09, 2019 at 10:24:16PM +0100, Chris Rees wrote: > On 9 April 2019 22:13:29 BST, Chris Rees wrote: > >On 9 April 2019 22:08:35 BST, "Rodney W. Grimes" > > wrote: > >>> On 09/04/2019 20:59, Chris Rees wrote: > >>> > On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" > >> wrote: > >>> >>> On 09/04/2019 21:33, Rodney W. Grimes wrote: > >>> I think the trigger issue is: > >>> grep zfs /etc/rc.d/zvol > >>> rcvar="zfs_enable" > >>> required_modules="zfs" > >>> that module requires may be going south with the > >>> new code when the module is built into the kernel. > >>> >>> Maybe it's because the module's name is zfsctrl (for whatever > >>reason) > >>> >> while the > >>> >>> module file is named zfs.ko. > >>> >> I suspect that could also lead to issues with the new code. > >>> >> It seems to be failing to detect that zfs is infact functional in > >>the > >>> >> kernel, > >>> >> and blindly, or not so blindly, trying to load zfs,ko, which when > >>you > >>> >> build > >>> >> it into the kernel you usually do so without any modules built, > >so > >>> >> there is > >>> >> no /boot/kernel/zfs.ko, and even if you did build it any attempt > >>to > >>> >> load > >>> >> it would return an error. > >>> > Loading with it built in isn't a problem, as I showed earlier. > >>> > Loading when it doesn't exist *is*. > >>> > I'm torn. Either we could revert this, or add a check to the > >>required_modules function instead, which I think is the better solution. > >>> Hang on, > >>> [crees@pegasus]~% sudo kldload -n zfsctrl && echo yes > >>> yes > >>I think your testing the return value of sudo here? > >Sudo returns the child's return value. > Turns out Oliver had also reported this to current@ with a log > https://lists.freebsd.org/pipermail/freebsd-current/2019-April/073148.html > Jilles@, mind if I revert this while I get some testing on this > scenario done? > It seems to me that zfs may not be included in the kernel, just > zfsctrl, or something like that. It seems like kldload -n does not work as expected for zfs, so reverting seems the right approach. -- Jilles Tjoelker ___ svn-src-all@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"
svn commit: r346070 - head/lib/libsecureboot
Author: sjg
Date: Tue Apr 9 22:20:11 2019
New Revision: 346070
URL: https://svnweb.freebsd.org/changeset/base/346070
Log:
Always report file with incorrect hash.
Modified:
head/lib/libsecureboot/verify_file.c
Modified: head/lib/libsecureboot/verify_file.c
==
--- head/lib/libsecureboot/verify_file.cTue Apr 9 22:15:39 2019
(r346069)
+++ head/lib/libsecureboot/verify_file.cTue Apr 9 22:20:11 2019
(r346070)
@@ -366,7 +366,7 @@ verify_file(int fd, const char *filename, off_t off, i
return (rc);
}
- if (severity || verbose)
+ if (severity || verbose || rc == VE_FINGERPRINT_WRONG)
printf("Unverified: %s\n", ve_error_get());
if (rc == VE_FINGERPRINT_UNKNOWN && severity < VE_MUST)
rc = VE_UNVERIFIED_OK;
___
svn-src-all@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"
svn commit: r346069 - head/sys/sys
Author: glebius
Date: Tue Apr 9 22:15:39 2019
New Revision: 346069
URL: https://svnweb.freebsd.org/changeset/base/346069
Log:
Obvious comment correction.
Modified:
head/sys/sys/sockbuf.h
Modified: head/sys/sys/sockbuf.h
==
--- head/sys/sys/sockbuf.h Tue Apr 9 21:38:20 2019(r346068)
+++ head/sys/sys/sockbuf.h Tue Apr 9 22:15:39 2019(r346069)
@@ -98,7 +98,7 @@ structsockbuf {
u_int sb_ctl; /* (a) non-data chars in buffer */
int sb_lowat; /* (a) low water mark */
sbintime_t sb_timeo; /* (a) timeout for read/write */
- short sb_flags; /* (a) flags, see below */
+ short sb_flags; /* (a) flags, see above */
int (*sb_upcall)(struct socket *, void *, int); /* (a) */
void*sb_upcallarg; /* (a) */
TAILQ_HEAD(, kaiocb) sb_aiojobq; /* (a) pending AIO ops */
___
svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hi again, On 9 April 2019 22:13:29 BST, Chris Rees wrote: > > >On 9 April 2019 22:08:35 BST, "Rodney W. Grimes" > wrote: >>> On 09/04/2019 20:59, Chris Rees wrote: >>> > On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" >> wrote: >>> >>> On 09/04/2019 21:33, Rodney W. Grimes wrote: >>> I think the trigger issue is: >>> grep zfs /etc/rc.d/zvol >>> rcvar="zfs_enable" >>> required_modules="zfs" >>> >>> that module requires may be going south with the >>> new code when the module is built into the kernel. >>> >>> Maybe it's because the module's name is zfsctrl (for whatever >>reason) >>> >> while the >>> >>> module file is named zfs.ko. >>> >> I suspect that could also lead to issues with the new code. >>> >> It seems to be failing to detect that zfs is infact functional in >>the >>> >> kernel, >>> >> and blindly, or not so blindly, trying to load zfs,ko, which when >>you >>> >> build >>> >> it into the kernel you usually do so without any modules built, >so >>> >> there is >>> >> no /boot/kernel/zfs.ko, and even if you did build it any attempt >>to >>> >> load >>> >> it would return an error. >>> > Loading with it built in isn't a problem, as I showed earlier. >>> > >>> > Loading when it doesn't exist *is*. >>> > >>> > I'm torn. Either we could revert this, or add a check to the >>required_modules function instead, which I think is the better >>solution. >>> >>> Hang on, >>> >>> [crees@pegasus]~% sudo kldload -n zfsctrl && echo yes >>> yes >> >>I think your testing the return value of sudo here? > >Sudo returns the child's return value. > Turns out Oliver had also reported this to current@ with a log https://lists.freebsd.org/pipermail/freebsd-current/2019-April/073148.html Jilles@, mind if I revert this while I get some testing on this scenario done? It seems to me that zfs may not be included in the kernel, just zfsctrl, or something like that. Chris -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> On 9 April 2019 22:08:35 BST, "Rodney W. Grimes" > wrote: > >> On 09/04/2019 20:59, Chris Rees wrote: > >> > On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" > > wrote: > >> >>> On 09/04/2019 21:33, Rodney W. Grimes wrote: > >> I think the trigger issue is: > >> grep zfs /etc/rc.d/zvol > >> rcvar="zfs_enable" > >> required_modules="zfs" > >> > >> that module requires may be going south with the > >> new code when the module is built into the kernel. > >> >>> Maybe it's because the module's name is zfsctrl (for whatever > >reason) > >> >> while the > >> >>> module file is named zfs.ko. > >> >> I suspect that could also lead to issues with the new code. > >> >> It seems to be failing to detect that zfs is infact functional in > >the > >> >> kernel, > >> >> and blindly, or not so blindly, trying to load zfs,ko, which when > >you > >> >> build > >> >> it into the kernel you usually do so without any modules built, so > >> >> there is > >> >> no /boot/kernel/zfs.ko, and even if you did build it any attempt > >to > >> >> load > >> >> it would return an error. > >> > Loading with it built in isn't a problem, as I showed earlier. > >> > > >> > Loading when it doesn't exist *is*. > >> > > >> > I'm torn. Either we could revert this, or add a check to the > >required_modules function instead, which I think is the better > >solution. > >> > >> Hang on, > >> > >> [crees@pegasus]~% sudo kldload -n zfsctrl && echo yes > >> yes > > > >I think your testing the return value of sudo here? > > Sudo returns the child's return value. Do you have a static linked zfs in your kernel without a zfs.ko in /boot? kldstat | grep zfs > > Chris > > >> [crees@pegasus]~% find /boot -name zfsctrl\* find /boot -name zfs the module file is called zfs.ko > >> [crees@pegasus]~% > >> > >> I think that, rather than speculating, we should wait for Oliver to > >> confirm that this is actually the problem, because I still don't > >think > >> it is. > >> > >> Chris -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> On 09/04/2019 20:59, Chris Rees wrote: > > On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" > > wrote: > >>> On 09/04/2019 21:33, Rodney W. Grimes wrote: > I think the trigger issue is: > grep zfs /etc/rc.d/zvol > rcvar="zfs_enable" > required_modules="zfs" > > that module requires may be going south with the > new code when the module is built into the kernel. > >>> Maybe it's because the module's name is zfsctrl (for whatever reason) > >> while the > >>> module file is named zfs.ko. > >> I suspect that could also lead to issues with the new code. > >> It seems to be failing to detect that zfs is infact functional in the > >> kernel, > >> and blindly, or not so blindly, trying to load zfs,ko, which when you > >> build > >> it into the kernel you usually do so without any modules built, so > >> there is > >> no /boot/kernel/zfs.ko, and even if you did build it any attempt to > >> load > >> it would return an error. > > Loading with it built in isn't a problem, as I showed earlier. > > > > Loading when it doesn't exist *is*. > > > > I'm torn. Either we could revert this, or add a check to the > > required_modules function instead, which I think is the better solution. > > Hang on, > > [crees@pegasus]~% sudo kldload -n zfsctrl && echo yes > yes I think your testing the return value of sudo here? > [crees@pegasus]~% find /boot -name zfsctrl\* > [crees@pegasus]~% > > I think that, rather than speculating, we should wait for Oliver to > confirm that this is actually the problem, because I still don't think > it is. > > Chris > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
svn commit: r346066 - head/sys/dev/acpica
Author: jhb
Date: Tue Apr 9 21:18:02 2019
New Revision: 346066
URL: https://svnweb.freebsd.org/changeset/base/346066
Log:
Refine r330113 to honor the ProducerConsumer flag most of the time.
While it is true that the ACPI spec says that the flag is only valid
on Extended Address Space Descriptors, examples of other descriptors
in the spec use the ProducerConsumer flag explicitly, and real
hardware uses it as well. In fact, even in the ASL of the Thunder X2
for which r330113 was a workaround, some devices use this flag on
non-Extended Address Space Descriptors correctly. Instead, only
ignore the flag for resources associated with the UART devices on the
Thunder X2 using the "ARMH0011" HID to identify these devices.
This should fix regressions from ignoring this flag in other contexts
such as Hyper-V.
PR: 235876
Reported by: Wei Hu
Tested by:emaste (Thunder X2)
MFC after:2 weeks
Modified:
head/sys/dev/acpica/acpi_resource.c
Modified: head/sys/dev/acpica/acpi_resource.c
==
--- head/sys/dev/acpica/acpi_resource.c Tue Apr 9 20:20:04 2019
(r346065)
+++ head/sys/dev/acpica/acpi_resource.c Tue Apr 9 21:18:02 2019
(r346066)
@@ -202,6 +202,7 @@ struct acpi_resource_context {
struct acpi_parse_resource_set *set;
device_t dev;
void *context;
+bool ignore_producer_flag;
};
#ifdef ACPI_DEBUG_OUTPUT
@@ -385,7 +386,7 @@ acpi_parse_resource(ACPI_RESOURCE *res, void *context)
}
if (length <= 0)
break;
- if (res->Type == ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64 &&
+ if (!arc->ignore_producer_flag &&
res->Data.Address.ProducerConsumer != ACPI_CONSUMER) {
ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES,
"ignored %s %s producer\n", name,
@@ -474,6 +475,12 @@ acpi_parse_resources(device_t dev, ACPI_HANDLE handle,
set->set_init(dev, arg, );
arc.set = set;
arc.dev = dev;
+arc.ignore_producer_flag = false;
+
+/* UARTs on ThunderX2 set ResourceProducer on memory resources. */
+if (acpi_MatchHid(handle, "ARMH0011") != ACPI_MATCHHID_NOMATCH)
+ arc.ignore_producer_flag = true;
+
status = AcpiWalkResources(handle, "_CRS", acpi_parse_resource, );
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
printf("can't fetch resources for %s - %s\n",
___
svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On 9 April 2019 22:08:35 BST, "Rodney W. Grimes" wrote: >> On 09/04/2019 20:59, Chris Rees wrote: >> > On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" > wrote: >> >>> On 09/04/2019 21:33, Rodney W. Grimes wrote: >> I think the trigger issue is: >> grep zfs /etc/rc.d/zvol >> rcvar="zfs_enable" >> required_modules="zfs" >> >> that module requires may be going south with the >> new code when the module is built into the kernel. >> >>> Maybe it's because the module's name is zfsctrl (for whatever >reason) >> >> while the >> >>> module file is named zfs.ko. >> >> I suspect that could also lead to issues with the new code. >> >> It seems to be failing to detect that zfs is infact functional in >the >> >> kernel, >> >> and blindly, or not so blindly, trying to load zfs,ko, which when >you >> >> build >> >> it into the kernel you usually do so without any modules built, so >> >> there is >> >> no /boot/kernel/zfs.ko, and even if you did build it any attempt >to >> >> load >> >> it would return an error. >> > Loading with it built in isn't a problem, as I showed earlier. >> > >> > Loading when it doesn't exist *is*. >> > >> > I'm torn. Either we could revert this, or add a check to the >required_modules function instead, which I think is the better >solution. >> >> Hang on, >> >> [crees@pegasus]~% sudo kldload -n zfsctrl && echo yes >> yes > >I think your testing the return value of sudo here? Sudo returns the child's return value. Chris >> [crees@pegasus]~% find /boot -name zfsctrl\* >> [crees@pegasus]~% >> >> I think that, rather than speculating, we should wait for Oliver to >> confirm that this is actually the problem, because I still don't >think >> it is. >> >> Chris >> >> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ svn-src-all@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"
Re: svn commit: r346052 - head/sys/dev/usb/net
> On 4/9/19 12:48 PM, Rodney W. Grimes wrote: > >> On 4/9/19 9:59 AM, Ian Lepore wrote: > >>> On Tue, 2019-04-09 at 09:33 -0700, John Baldwin wrote: > On 4/9/19 9:17 AM, Ian Lepore wrote: > > On Tue, 2019-04-09 at 09:11 -0700, John Baldwin wrote: > >> On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote: > >>> Author: ganbold > >>> Date: Tue Apr 9 13:54:08 2019 > >>> New Revision: 346052 > >>> URL: https://svnweb.freebsd.org/changeset/base/346052 > >>> > >>> Log: > >>> In some cases like NanoPI R1, its second USB ethernet > >>> RTL8152 (chip version URE_CHIP_VER_4C10) doesn't > >>> have hardwired MAC address, in other words, it is all zeros. > >>> This commit fixes it by setting random MAC address > >>> when MAC address is all zeros. > >>> > >>> Reviewed by:kevlo > >>> Differential Revision: > >>> https://reviews.freebsd.org/D19856 > >> > >> It would be best to not use a purely random mac address and to > >> use > >> the > >> function kevans@ added recently. That function generates a MAC > >> address > >> from the FreeBSD OUI using a cryptographic hash so you get a > >> stable address across boots on a given host. > >> > > > > How could that possibly work? If it's not random, you can't have > > two > > such devices on the same network. If it is random, it's not stable > > from one boot to the next. > > It uses the UUID and interface name as input into the hash. > >>> > The UUID is per-host. > >>> > >>> Oh, so it only works on x86 (or I guess any system that has something > >>> like a bios that can provide you with a uuid that doesn't change from > >>> one boot to the next). > >> > >> The function is in one centralized place where you are free to add other > >> data as input into the hash. We do always generate a uuid that we save > >> on boot if we aren't seeded with one by firmware, though that is probably > >> too late for this driver (so +1 may in fact be a better route). It should > >> be fine for psuedo interfaces created post-boot though even on non-x86 due > >> to /etc/rc.d/hostid. Pure random MAC's are not really great either. > > > > Cant the loader load /etc/rc.d/hostid and put it in something that > > the kernel could get at, or a module written that handles this? > > It's a different file, and yes in theory the loader could look at the file > and set UUID and hostid env vars. However, that's a no-op for most use > cases. If other platforms have some kind of firmware-provided thing that > isn't a UUID, it would be good to teach the centralized function about > those as an input to the hash, but at least that can be done in place > rather than having open-coded MAC generators in various drivers. Simple enough, can one not just store /etc/rc.d/hostid into a env variable in /boot/loader.conf too on those platforms that do not have a uuid mechanism? -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
Re: svn commit: r346039 - head/sys/conf
On Tue, Apr 9, 2019 at 11:40 AM Ian Lepore wrote: > On Tue, 2019-04-09 at 11:19 -0600, Rebecca Cran wrote: > > On 2019-04-08 12:25, Warner Losh wrote: > > > Author: imp > > > Date: Mon Apr 8 18:25:14 2019 > > > New Revision: 346039 > > > URL: https://svnweb.freebsd.org/changeset/base/346039 > > > > > > Log: > > >Style only change: Prefer $() to `` > > > > > >$() is more modern and also nests. Convert the mix of styles to > > > using > > >only the former (although the latter was more common). It's the > > > more > > >dominant style in other shell scripts these days as well. > > > > > >Differential Revision: https://reviews.freebsd.org/D19840 > > > > > > Modified: > > >head/sys/conf/newvers.sh > > > > > > Modified: head/sys/conf/newvers.sh > > > > > > I thought I saw an email a few weeks ago that suggested that the list > > of > > people who reviewed the patch should be copied into a "Reviewed by:" > > line, to avoid only having that information in Phabricator. > > > > Am I remembering correctly, or is just mentioning the Phab review > > considered sufficient? > > > > > > As far as I'm concerned, if I've gone to all the trouble to have > something phab-reviewed, I'm not going to waste a bunch of time hand- > copying metadata from the review to the commit message; citing the > review is sufficient. > There's that too Project norms here have a gap between what people expect to happen, and what actually happens. This is orthogonal to the whole uselessly duplicated metadata issue causing friction. Warner ___ svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On 09/04/2019 20:59, Chris Rees wrote: On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" wrote: On 09/04/2019 21:33, Rodney W. Grimes wrote: I think the trigger issue is: grep zfs /etc/rc.d/zvol rcvar="zfs_enable" required_modules="zfs" that module requires may be going south with the new code when the module is built into the kernel. Maybe it's because the module's name is zfsctrl (for whatever reason) while the module file is named zfs.ko. I suspect that could also lead to issues with the new code. It seems to be failing to detect that zfs is infact functional in the kernel, and blindly, or not so blindly, trying to load zfs,ko, which when you build it into the kernel you usually do so without any modules built, so there is no /boot/kernel/zfs.ko, and even if you did build it any attempt to load it would return an error. Loading with it built in isn't a problem, as I showed earlier. Loading when it doesn't exist *is*. I'm torn. Either we could revert this, or add a check to the required_modules function instead, which I think is the better solution. Hang on, [crees@pegasus]~% sudo kldload -n zfsctrl && echo yes yes [crees@pegasus]~% find /boot -name zfsctrl\* [crees@pegasus]~% I think that, rather than speculating, we should wait for Oliver to confirm that this is actually the problem, because I still don't think it is. Chris -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ svn-src-all@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"
svn commit: r346065 - in head/sys: fs/fuse fs/msdosfs kern sys
Author: kib
Date: Tue Apr 9 20:20:04 2019
New Revision: 346065
URL: https://svnweb.freebsd.org/changeset/base/346065
Log:
Add vn_fsync_buf().
Provide a convenience function to avoid the hack with filling fake
struct vop_fsync_args and then calling vop_stdfsync().
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Modified:
head/sys/fs/fuse/fuse_io.c
head/sys/fs/msdosfs/msdosfs_fat.c
head/sys/kern/vfs_default.c
head/sys/kern/vfs_vnops.c
head/sys/sys/vnode.h
Modified: head/sys/fs/fuse/fuse_io.c
==
--- head/sys/fs/fuse/fuse_io.c Tue Apr 9 19:55:02 2019(r346064)
+++ head/sys/fs/fuse/fuse_io.c Tue Apr 9 20:20:04 2019(r346065)
@@ -771,13 +771,8 @@ fuse_io_strategy(struct vnode *vp, struct buf *bp)
int
fuse_io_flushbuf(struct vnode *vp, int waitfor, struct thread *td)
{
- struct vop_fsync_args a = {
- .a_vp = vp,
- .a_waitfor = waitfor,
- .a_td = td,
- };
- return (vop_stdfsync());
+ return (vn_fsync_buf(vp, waitfor));
}
/*
Modified: head/sys/fs/msdosfs/msdosfs_fat.c
==
--- head/sys/fs/msdosfs/msdosfs_fat.c Tue Apr 9 19:55:02 2019
(r346064)
+++ head/sys/fs/msdosfs/msdosfs_fat.c Tue Apr 9 20:20:04 2019
(r346065)
@@ -980,7 +980,6 @@ extendfile(struct denode *dep, u_long count, struct bu
u_long cn, got;
struct msdosfsmount *pmp = dep->de_pmp;
struct buf *bp;
- struct vop_fsync_args fsync_ap;
daddr_t blkno;
/*
@@ -1092,12 +1091,8 @@ extendfile(struct denode *dep, u_long count, struct bu
bdwrite(bp);
}
if (vm_page_count_severe() ||
- buf_dirty_count_severe()) {
- fsync_ap.a_vp = DETOV(dep);
- fsync_ap.a_waitfor = MNT_WAIT;
- fsync_ap.a_td = curthread;
- vop_stdfsync(_ap);
- }
+ buf_dirty_count_severe())
+ vn_fsync_buf(DETOV(dep), MNT_WAIT);
}
}
}
Modified: head/sys/kern/vfs_default.c
==
--- head/sys/kern/vfs_default.c Tue Apr 9 19:55:02 2019(r346064)
+++ head/sys/kern/vfs_default.c Tue Apr 9 20:20:04 2019(r346065)
@@ -638,98 +638,8 @@ vop_stdfsync(ap)
struct thread *a_td;
} */ *ap;
{
- struct vnode *vp;
- struct buf *bp, *nbp;
- struct bufobj *bo;
- struct mount *mp;
- int error, maxretry;
- error = 0;
- maxretry = 1; /* large, arbitrarily chosen */
- vp = ap->a_vp;
- mp = NULL;
- if (vp->v_type == VCHR) {
- VI_LOCK(vp);
- mp = vp->v_rdev->si_mountpt;
- VI_UNLOCK(vp);
- }
- bo = >v_bufobj;
- BO_LOCK(bo);
-loop1:
- /*
-* MARK/SCAN initialization to avoid infinite loops.
-*/
-TAILQ_FOREACH(bp, >bo_dirty.bv_hd, b_bobufs) {
-bp->b_vflags &= ~BV_SCANNED;
- bp->b_error = 0;
- }
-
- /*
-* Flush all dirty buffers associated with a vnode.
-*/
-loop2:
- TAILQ_FOREACH_SAFE(bp, >bo_dirty.bv_hd, b_bobufs, nbp) {
- if ((bp->b_vflags & BV_SCANNED) != 0)
- continue;
- bp->b_vflags |= BV_SCANNED;
- if (BUF_LOCK(bp, LK_EXCLUSIVE | LK_NOWAIT, NULL)) {
- if (ap->a_waitfor != MNT_WAIT)
- continue;
- if (BUF_LOCK(bp,
- LK_EXCLUSIVE | LK_INTERLOCK | LK_SLEEPFAIL,
- BO_LOCKPTR(bo)) != 0) {
- BO_LOCK(bo);
- goto loop1;
- }
- BO_LOCK(bo);
- }
- BO_UNLOCK(bo);
- KASSERT(bp->b_bufobj == bo,
- ("bp %p wrong b_bufobj %p should be %p",
- bp, bp->b_bufobj, bo));
- if ((bp->b_flags & B_DELWRI) == 0)
- panic("fsync: not dirty");
- if ((vp->v_object != NULL) && (bp->b_flags & B_CLUSTEROK)) {
- vfs_bio_awrite(bp);
- } else {
- bremfree(bp);
- bawrite(bp);
- }
- if (maxretry < 1000)
- pause("dirty", hz < 1000 ? 1 : hz / 1000);
- BO_LOCK(bo);
- goto loop2;
- }
-
Re: svn commit: r346052 - head/sys/dev/usb/net
On 4/9/19 12:48 PM, Rodney W. Grimes wrote: >> On 4/9/19 9:59 AM, Ian Lepore wrote: >>> On Tue, 2019-04-09 at 09:33 -0700, John Baldwin wrote: On 4/9/19 9:17 AM, Ian Lepore wrote: > On Tue, 2019-04-09 at 09:11 -0700, John Baldwin wrote: >> On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote: >>> Author: ganbold >>> Date: Tue Apr 9 13:54:08 2019 >>> New Revision: 346052 >>> URL: https://svnweb.freebsd.org/changeset/base/346052 >>> >>> Log: >>> In some cases like NanoPI R1, its second USB ethernet >>> RTL8152 (chip version URE_CHIP_VER_4C10) doesn't >>> have hardwired MAC address, in other words, it is all zeros. >>> This commit fixes it by setting random MAC address >>> when MAC address is all zeros. >>> >>> Reviewed by: kevlo >>> Differential Revision: >>> https://reviews.freebsd.org/D19856 >> >> It would be best to not use a purely random mac address and to >> use >> the >> function kevans@ added recently. That function generates a MAC >> address >> from the FreeBSD OUI using a cryptographic hash so you get a >> stable address across boots on a given host. >> > > How could that possibly work? If it's not random, you can't have > two > such devices on the same network. If it is random, it's not stable > from one boot to the next. It uses the UUID and interface name as input into the hash. >>> The UUID is per-host. >>> >>> Oh, so it only works on x86 (or I guess any system that has something >>> like a bios that can provide you with a uuid that doesn't change from >>> one boot to the next). >> >> The function is in one centralized place where you are free to add other >> data as input into the hash. We do always generate a uuid that we save >> on boot if we aren't seeded with one by firmware, though that is probably >> too late for this driver (so +1 may in fact be a better route). It should >> be fine for psuedo interfaces created post-boot though even on non-x86 due >> to /etc/rc.d/hostid. Pure random MAC's are not really great either. > > Cant the loader load /etc/rc.d/hostid and put it in something that > the kernel could get at, or a module written that handles this? It's a different file, and yes in theory the loader could look at the file and set UUID and hostid env vars. However, that's a no-op for most use cases. If other platforms have some kind of firmware-provided thing that isn't a UUID, it would be good to teach the centralized function about those as an input to the hash, but at least that can be done in place rather than having open-coded MAC generators in various drivers. -- John Baldwin ___ svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" > wrote: > >> On 09/04/2019 21:33, Rodney W. Grimes wrote: > >> > I think the trigger issue is: > >> > grep zfs /etc/rc.d/zvol > >> > rcvar="zfs_enable" > >> > required_modules="zfs" > >> > > >> > that module requires may be going south with the > >> > new code when the module is built into the kernel. > >> > >> Maybe it's because the module's name is zfsctrl (for whatever reason) > >while the > >> module file is named zfs.ko. > > > >I suspect that could also lead to issues with the new code. > >It seems to be failing to detect that zfs is infact functional in the > >kernel, > >and blindly, or not so blindly, trying to load zfs,ko, which when you > >build > >it into the kernel you usually do so without any modules built, so > >there is > >no /boot/kernel/zfs.ko, and even if you did build it any attempt to > >load > >it would return an error. > > Loading with it built in isn't a problem, as I showed earlier. > > Loading when it doesn't exist *is*. > > I'm torn. Either we could revert this, or add a check to the > required_modules function instead, which I think is the better solution. Ultimately at this time it is your decision, my personal mode of operation is when an unforseen bug comes up in something I did it is to revert, work on the issue until I am confident it is addressed, and addressed without adding any addition issue, then revert the revert and apply the fix. > Chris -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On 9 April 2019 20:55:07 BST, "Rodney W. Grimes" wrote: >> On 09/04/2019 21:33, Rodney W. Grimes wrote: >> > I think the trigger issue is: >> > grep zfs /etc/rc.d/zvol >> > rcvar="zfs_enable" >> > required_modules="zfs" >> > >> > that module requires may be going south with the >> > new code when the module is built into the kernel. >> >> Maybe it's because the module's name is zfsctrl (for whatever reason) >while the >> module file is named zfs.ko. > >I suspect that could also lead to issues with the new code. >It seems to be failing to detect that zfs is infact functional in the >kernel, >and blindly, or not so blindly, trying to load zfs,ko, which when you >build >it into the kernel you usually do so without any modules built, so >there is >no /boot/kernel/zfs.ko, and even if you did build it any attempt to >load >it would return an error. Loading with it built in isn't a problem, as I showed earlier. Loading when it doesn't exist *is*. I'm torn. Either we could revert this, or add a check to the required_modules function instead, which I think is the better solution. Chris -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> On 09/04/2019 21:33, Rodney W. Grimes wrote: > > I think the trigger issue is: > > grep zfs /etc/rc.d/zvol > > rcvar="zfs_enable" > > required_modules="zfs" > > > > that module requires may be going south with the > > new code when the module is built into the kernel. > > Maybe it's because the module's name is zfsctrl (for whatever reason) while > the > module file is named zfs.ko. I suspect that could also lead to issues with the new code. It seems to be failing to detect that zfs is infact functional in the kernel, and blindly, or not so blindly, trying to load zfs,ko, which when you build it into the kernel you usually do so without any modules built, so there is no /boot/kernel/zfs.ko, and even if you did build it any attempt to load it would return an error. > -- > Andriy Gapon -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
svn commit: r346064 - head/sys/fs/msdosfs
Author: kib
Date: Tue Apr 9 19:55:02 2019
New Revision: 346064
URL: https://svnweb.freebsd.org/changeset/base/346064
Log:
Fix dirty buf exhaustion easily triggered with msdosfs.
If truncate(2) is performed on msdosfs file, which extends the file by
system-depended large amount, fs creates corresponding amount of dirty
delayed-write buffers, which can consume all buffers. Such buffers
cannot be flushed by the bufdaemon because the ftruncate() thread owns
the vnode lock. So the system runs out of free buffers, and even
truncate() thread starves, which means deadlock because it owns the
vnode lock.
Fix this by doing vnode fsync in extendfile() when low memory or low
buffers condition detected, which flushes all dirty buffers belonging
to the file being extended.
Note that the more usual fallback to bawrite() does not work
acceptable in this situation, because it would only allow one buffer
to be recycled. Other filesystems, most important UFS, do not allow
userspace to create arbitrary amount of dirty delayed-write buffers
without feedback, so bawrite() is good enough for them.
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Modified:
head/sys/fs/msdosfs/msdosfs_fat.c
Modified: head/sys/fs/msdosfs/msdosfs_fat.c
==
--- head/sys/fs/msdosfs/msdosfs_fat.c Tue Apr 9 19:22:08 2019
(r346063)
+++ head/sys/fs/msdosfs/msdosfs_fat.c Tue Apr 9 19:55:02 2019
(r346064)
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#include
#include
@@ -979,6 +980,7 @@ extendfile(struct denode *dep, u_long count, struct bu
u_long cn, got;
struct msdosfsmount *pmp = dep->de_pmp;
struct buf *bp;
+ struct vop_fsync_args fsync_ap;
daddr_t blkno;
/*
@@ -1086,8 +1088,16 @@ extendfile(struct denode *dep, u_long count, struct bu
if (bpp) {
*bpp = bp;
bpp = NULL;
- } else
+ } else {
bdwrite(bp);
+ }
+ if (vm_page_count_severe() ||
+ buf_dirty_count_severe()) {
+ fsync_ap.a_vp = DETOV(dep);
+ fsync_ap.a_waitfor = MNT_WAIT;
+ fsync_ap.a_td = curthread;
+ vop_stdfsync(_ap);
+ }
}
}
}
___
svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
[ Charset UTF-8 unsupported, converting... ]
> Hi Rod,
>
> On 09/04/2019 19:33, Rodney W. Grimes wrote:
> >> Hey,
> >>
> >> On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
> >>> On Sun, 7 Apr 2019 18:31:45 + (UTC)
> >>> Chris Rees wrote:
> >>>
> Author: crees (doc,ports committer)
> Date: Sun Apr 7 18:31:45 2019
> New Revision: 346017
> URL: https://svnweb.freebsd.org/changeset/base/346017
>
> Log:
> Remove now unnecessary kldstat check before attempting to load
> >>> modules.
> Since r233109, kldload has the -n option, which silently ignores
> >>> options
> that are already loaded.
>
>
> >>> https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
> Note that this script no longer reports if the module is already
> >>> loaded,
> but it could be argued this wasn't particularly useful information.
>
> PR: docs/234248
> Reviewed by: bcr (docs), kib, rgrimes (visual)
> Approved by: jilles
> Differential Revision:https://reviews.freebsd.org/D18670
>
> Modified:
> head/libexec/rc/rc.d/abi
> head/libexec/rc/rc.d/bthidd
> head/libexec/rc/rc.d/cfumass
> head/libexec/rc/rc.d/kld
> head/libexec/rc/rc.d/mdconfig
> head/libexec/rc/rc.d/mdconfig2
> head/libexec/rc/rc.d/mountcritremote
> head/libexec/rc/rc.d/syscons
> head/libexec/rc/rc.subr
> head/share/man/man5/rc.conf.5
>
> Modified: head/libexec/rc/rc.d/abi
>
> >>> ==
> >>
> >> {Snip}
> >>
> >>
> >>> It seems this patch breaks ZFS if ZFS is built-in kernel!
> >>>
> >>> Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
> >>> volume
> >>> at boot time, rendering servers unusable.
> >>> Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
> >>> filesystems as
> >>> expected.
> >>>
> >> Are you sure it's this causing that? Please try reverting it.
> > I think the trigger issue is:
> > grep zfs /etc/rc.d/zvol
> > rcvar="zfs_enable"
> > required_modules="zfs"
> >
> > that module requires may be going south with the
> > new code when the module is built into the kernel.
>
>
> I wondered that, but I don't think so.
>
> [crees@pegasus]~% kldstat -v |head
> Id Refs Address??? Size Name
> ?1?? 30 0x8020 11df240? kernel (/boot/kernel.PEGASUS/kernel)
> ??? Contains modules:
> ??? Id Name
> ??? 227 newreno
> ??? 215 if_lo
> ??? 229 ipsec
> ??? 228 mld
> ??? 226 igmp
> ??? 201 elf32
> [crees@pegasus]~% sudo kldload ipsec
> kldload: can't load ipsec: module already loaded or in kernel
> [crees@pegasus]~% sudo kldload -n ipsec
> [crees@pegasus]~% echo $?
> 0
> [crees@pegasus]~%
>
> The required_modules code calls load_kld, which uses kldload -n. This
> always returns true... unless Oliver has removed the zfs module from
> /boot/kernel perhaps?
He explicitly stated he is running with ZFS compiled into
his kernel, in that situation there well be
no /boot/kernel/zfs.ko file.
--
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"
Re: svn commit: r346052 - head/sys/dev/usb/net
> On 4/9/19 9:59 AM, Ian Lepore wrote: > > On Tue, 2019-04-09 at 09:33 -0700, John Baldwin wrote: > >> On 4/9/19 9:17 AM, Ian Lepore wrote: > >>> On Tue, 2019-04-09 at 09:11 -0700, John Baldwin wrote: > On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote: > > Author: ganbold > > Date: Tue Apr 9 13:54:08 2019 > > New Revision: 346052 > > URL: https://svnweb.freebsd.org/changeset/base/346052 > > > > Log: > > In some cases like NanoPI R1, its second USB ethernet > > RTL8152 (chip version URE_CHIP_VER_4C10) doesn't > > have hardwired MAC address, in other words, it is all zeros. > > This commit fixes it by setting random MAC address > > when MAC address is all zeros. > > > > Reviewed by: kevlo > > Differential Revision: > > https://reviews.freebsd.org/D19856 > > It would be best to not use a purely random mac address and to > use > the > function kevans@ added recently. That function generates a MAC > address > from the FreeBSD OUI using a cryptographic hash so you get a > stable address across boots on a given host. > > >>> > >>> How could that possibly work? If it's not random, you can't have > >>> two > >>> such devices on the same network. If it is random, it's not stable > >>> from one boot to the next. > >> > >> It uses the UUID and interface name as input into the hash. > > > >> The UUID is per-host. > > > > Oh, so it only works on x86 (or I guess any system that has something > > like a bios that can provide you with a uuid that doesn't change from > > one boot to the next). > > The function is in one centralized place where you are free to add other > data as input into the hash. We do always generate a uuid that we save > on boot if we aren't seeded with one by firmware, though that is probably > too late for this driver (so +1 may in fact be a better route). It should > be fine for psuedo interfaces created post-boot though even on non-x86 due > to /etc/rc.d/hostid. Pure random MAC's are not really great either. Cant the loader load /etc/rc.d/hostid and put it in something that the kernel could get at, or a module written that handles this? > -- > John Baldwin -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On 09/04/2019 21:33, Rodney W. Grimes wrote: > I think the trigger issue is: > grep zfs /etc/rc.d/zvol > rcvar="zfs_enable" > required_modules="zfs" > > that module requires may be going south with the > new code when the module is built into the kernel. Maybe it's because the module's name is zfsctrl (for whatever reason) while the module file is named zfs.ko. -- Andriy Gapon ___ svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hi Rod,
On 09/04/2019 19:33, Rodney W. Grimes wrote:
Hey,
On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
On Sun, 7 Apr 2019 18:31:45 + (UTC)
Chris Rees wrote:
Author: crees (doc,ports committer)
Date: Sun Apr 7 18:31:45 2019
New Revision: 346017
URL: https://svnweb.freebsd.org/changeset/base/346017
Log:
Remove now unnecessary kldstat check before attempting to load
modules.
Since r233109, kldload has the -n option, which silently ignores
options
that are already loaded.
https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
Note that this script no longer reports if the module is already
loaded,
but it could be argued this wasn't particularly useful information.
PR: docs/234248
Reviewed by: bcr (docs), kib, rgrimes (visual)
Approved by: jilles
Differential Revision: https://reviews.freebsd.org/D18670
Modified:
head/libexec/rc/rc.d/abi
head/libexec/rc/rc.d/bthidd
head/libexec/rc/rc.d/cfumass
head/libexec/rc/rc.d/kld
head/libexec/rc/rc.d/mdconfig
head/libexec/rc/rc.d/mdconfig2
head/libexec/rc/rc.d/mountcritremote
head/libexec/rc/rc.d/syscons
head/libexec/rc/rc.subr
head/share/man/man5/rc.conf.5
Modified: head/libexec/rc/rc.d/abi
==
{Snip}
It seems this patch breaks ZFS if ZFS is built-in kernel!
Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
volume
at boot time, rendering servers unusable.
Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
filesystems as
expected.
Are you sure it's this causing that? Please try reverting it.
I think the trigger issue is:
grep zfs /etc/rc.d/zvol
rcvar="zfs_enable"
required_modules="zfs"
that module requires may be going south with the
new code when the module is built into the kernel.
I wondered that, but I don't think so.
[crees@pegasus]~% kldstat -v |head
Id Refs Address Size Name
1 30 0x8020 11df240 kernel (/boot/kernel.PEGASUS/kernel)
Contains modules:
Id Name
227 newreno
215 if_lo
229 ipsec
228 mld
226 igmp
201 elf32
[crees@pegasus]~% sudo kldload ipsec
kldload: can't load ipsec: module already loaded or in kernel
[crees@pegasus]~% sudo kldload -n ipsec
[crees@pegasus]~% echo $?
0
[crees@pegasus]~%
The required_modules code calls load_kld, which uses kldload -n. This
always returns true... unless Oliver has removed the zfs module from
/boot/kernel perhaps?
Chris
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
svn-src-all@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"
Re: svn commit: r346063 - head/sys/dev/acpica
On 09/04/2019 22:22, John Baldwin wrote: > Author: jhb > Date: Tue Apr 9 19:22:08 2019 > New Revision: 346063 > URL: https://svnweb.freebsd.org/changeset/base/346063 > > Log: > Don't pre-reserve resources for CPU devices when they are set. > > CPUs can use shared (RF_SHAREABLE) resources for the I/O port used for > entering and exiting C states. If this I/O port is included in an ACPI > system resource device, then this happens to still work, but if the port > wasn't part of a system resource device, only the first CPU could allocate > the I/O port and use C states since resource_list_reserve() was always > allocating the resource from nexus0 without RF_SHAREABLE. By avoiding > the reservation, the flags from the bus_alloc_resource() in the CPU driver > (which include RF_SHAREABLE) are honored. > > PR: 236513 > Reported by:stockhau...@collogia.de > Sleuthing by: avg Actually, 80-90% of it was done by the reporter. I just pieced it together :) > Reviewed by:avg > MFC after: 2 weeks -- Andriy Gapon ___ svn-src-all@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"
Re: svn commit: r346052 - head/sys/dev/usb/net
On 4/9/19 9:59 AM, Ian Lepore wrote: > On Tue, 2019-04-09 at 09:33 -0700, John Baldwin wrote: >> On 4/9/19 9:17 AM, Ian Lepore wrote: >>> On Tue, 2019-04-09 at 09:11 -0700, John Baldwin wrote: On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote: > Author: ganbold > Date: Tue Apr 9 13:54:08 2019 > New Revision: 346052 > URL: https://svnweb.freebsd.org/changeset/base/346052 > > Log: > In some cases like NanoPI R1, its second USB ethernet > RTL8152 (chip version URE_CHIP_VER_4C10) doesn't > have hardwired MAC address, in other words, it is all zeros. > This commit fixes it by setting random MAC address > when MAC address is all zeros. > > Reviewed by:kevlo > Differential Revision: > https://reviews.freebsd.org/D19856 It would be best to not use a purely random mac address and to use the function kevans@ added recently. That function generates a MAC address from the FreeBSD OUI using a cryptographic hash so you get a stable address across boots on a given host. >>> >>> How could that possibly work? If it's not random, you can't have >>> two >>> such devices on the same network. If it is random, it's not stable >>> from one boot to the next. >> >> It uses the UUID and interface name as input into the hash. > >> The UUID is per-host. > > Oh, so it only works on x86 (or I guess any system that has something > like a bios that can provide you with a uuid that doesn't change from > one boot to the next). The function is in one centralized place where you are free to add other data as input into the hash. We do always generate a uuid that we save on boot if we aren't seeded with one by firmware, though that is probably too late for this driver (so +1 may in fact be a better route). It should be fine for psuedo interfaces created post-boot though even on non-x86 due to /etc/rc.d/hostid. Pure random MAC's are not really great either. -- John Baldwin ___ svn-src-all@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"
svn commit: r346063 - head/sys/dev/acpica
Author: jhb
Date: Tue Apr 9 19:22:08 2019
New Revision: 346063
URL: https://svnweb.freebsd.org/changeset/base/346063
Log:
Don't pre-reserve resources for CPU devices when they are set.
CPUs can use shared (RF_SHAREABLE) resources for the I/O port used for
entering and exiting C states. If this I/O port is included in an ACPI
system resource device, then this happens to still work, but if the port
wasn't part of a system resource device, only the first CPU could allocate
the I/O port and use C states since resource_list_reserve() was always
allocating the resource from nexus0 without RF_SHAREABLE. By avoiding
the reservation, the flags from the bus_alloc_resource() in the CPU driver
(which include RF_SHAREABLE) are honored.
PR: 236513
Reported by: stockhau...@collogia.de
Sleuthing by: avg
Reviewed by: avg
MFC after:2 weeks
Modified:
head/sys/dev/acpica/acpi.c
Modified: head/sys/dev/acpica/acpi.c
==
--- head/sys/dev/acpica/acpi.c Tue Apr 9 18:07:17 2019(r346062)
+++ head/sys/dev/acpica/acpi.c Tue Apr 9 19:22:08 2019(r346063)
@@ -1353,6 +1353,14 @@ acpi_set_resource(device_t dev, device_t child, int ty
return (0);
/*
+ * Don't reserve resources for CPU devices. Some of these
+ * resources need to be allocated as shareable, but reservations
+ * are always non-shareable.
+ */
+if (device_get_devclass(child) == devclass_find("cpu"))
+ return (0);
+
+/*
* Reserve the resource.
*
* XXX: Ignores failure for now. Failure here is probably a
___
svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
> Hey,
>
> On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
> >On Sun, 7 Apr 2019 18:31:45 + (UTC)
> >Chris Rees wrote:
> >
> >> Author: crees (doc,ports committer)
> >> Date: Sun Apr 7 18:31:45 2019
> >> New Revision: 346017
> >> URL: https://svnweb.freebsd.org/changeset/base/346017
> >>
> >> Log:
> >> Remove now unnecessary kldstat check before attempting to load
> >modules.
> >>
> >> Since r233109, kldload has the -n option, which silently ignores
> >options
> >> that are already loaded.
> >>
> >>
> >https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
> >>
> >> Note that this script no longer reports if the module is already
> >loaded,
> >> but it could be argued this wasn't particularly useful information.
> >>
> >> PR: docs/234248
> >> Reviewed by: bcr (docs), kib, rgrimes (visual)
> >> Approved by: jilles
> >> Differential Revision: https://reviews.freebsd.org/D18670
> >>
> >> Modified:
> >> head/libexec/rc/rc.d/abi
> >> head/libexec/rc/rc.d/bthidd
> >> head/libexec/rc/rc.d/cfumass
> >> head/libexec/rc/rc.d/kld
> >> head/libexec/rc/rc.d/mdconfig
> >> head/libexec/rc/rc.d/mdconfig2
> >> head/libexec/rc/rc.d/mountcritremote
> >> head/libexec/rc/rc.d/syscons
> >> head/libexec/rc/rc.subr
> >> head/share/man/man5/rc.conf.5
> >>
> >> Modified: head/libexec/rc/rc.d/abi
> >>
> >==
>
>
> {Snip}
>
>
> >It seems this patch breaks ZFS if ZFS is built-in kernel!
> >
> >Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
> >volume
> >at boot time, rendering servers unusable.
> >Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
> >filesystems as
> >expected.
> >
>
> Are you sure it's this causing that? Please try reverting it.
I think the trigger issue is:
grep zfs /etc/rc.d/zvol
rcvar="zfs_enable"
required_modules="zfs"
that module requires may be going south with the
new code when the module is built into the kernel.
> Chris
--
Rod Grimes rgri...@freebsd.org
___
svn-src-all@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"
svn commit: r346062 - in head/sys: amd64/pci i386/pci x86/include x86/x86
Author: kib
Date: Tue Apr 9 18:07:17 2019
New Revision: 346062
URL: https://svnweb.freebsd.org/changeset/base/346062
Log:
pci_cfgreg.c: Use io port config access for early boot time.
Some early PCIe chipsets are explicitly listed in the white-list to
enable use of the MMIO config space accesses, perhaps because ACPI
tables were not reliable source of the base MCFG address at that time.
For that chipsets, MCFG base was read from the known chipset MCFGbase
config register.
During very early stage of boot, when access to the PCI config space
is performed (see e.g. pci_early_quirks.c), we cannot map 255MB of
registers because the method used with pre-boot pmap overflows initial
kernel page tables.
Move fallback to read MCFGbase to the attachment method of the
x86/legacy device, which removes code duplication, and results in the
use of io accesses until MCFG is parsed or legacy attach called.
For amd64, pre-initialize cfgmech with CFGMECH_1, right now we
dynamically assign CFGMECH_1 to it anyway, and remove checks for
CFGMECH_NONE.
There is a mention in the Intel documentation for corresponding
chipsets that OS must use either io port or MMIO access method, but we
already break this rule by reading MCFGbase register, so one more
access seems to be innocent.
Reported by: longw...@incore.de
PR: 236838
Reviewed by: avg (other version), jhb
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Differential revision:https://reviews.freebsd.org/D19833
Modified:
head/sys/amd64/pci/pci_cfgreg.c
head/sys/i386/pci/pci_cfgreg.c
head/sys/x86/include/pci_cfgreg.h
head/sys/x86/x86/legacy.c
Modified: head/sys/amd64/pci/pci_cfgreg.c
==
--- head/sys/amd64/pci/pci_cfgreg.c Tue Apr 9 17:52:11 2019
(r346061)
+++ head/sys/amd64/pci/pci_cfgreg.c Tue Apr 9 18:07:17 2019
(r346062)
@@ -44,12 +44,6 @@ __FBSDID("$FreeBSD$");
#include
#include
-enum {
- CFGMECH_NONE = 0,
- CFGMECH_1,
- CFGMECH_PCIE,
-};
-
static uint32_tpci_docfgregread(int bus, int slot, int func, int reg,
int bytes);
static int pciereg_cfgread(int bus, unsigned slot, unsigned func,
@@ -61,7 +55,13 @@ static void pcireg_cfgwrite(int bus, int slot, int fun
SYSCTL_DECL(_hw_pci);
-static int cfgmech;
+/*
+ * For amd64 we assume that type 1 I/O port-based access always works.
+ * If an ACPI MCFG table exists, pcie_cfgregopen() will be called to
+ * switch to memory-mapped access.
+ */
+int cfgmech = CFGMECH_1;
+
static vm_offset_t pcie_base;
static int pcie_minbus, pcie_maxbus;
static uint32_t pcie_badslots;
@@ -71,47 +71,10 @@ static int mcfg_enable = 1;
SYSCTL_INT(_hw_pci, OID_AUTO, mcfg, CTLFLAG_RDTUN, _enable, 0,
"Enable support for PCI-e memory mapped config access");
-/*
- * Initialise access to PCI configuration space
- */
int
pci_cfgregopen(void)
{
- uint64_t pciebar;
- uint16_t did, vid;
- if (cfgmech != CFGMECH_NONE)
- return (1);
- cfgmech = CFGMECH_1;
-
- /*
-* Grope around in the PCI config space to see if this is a
-* chipset that is capable of doing memory-mapped config cycles.
-* This also implies that it can do PCIe extended config cycles.
-*/
-
- /* Check for supported chipsets */
- vid = pci_cfgregread(0, 0, 0, PCIR_VENDOR, 2);
- did = pci_cfgregread(0, 0, 0, PCIR_DEVICE, 2);
- switch (vid) {
- case 0x8086:
- switch (did) {
- case 0x3590:
- case 0x3592:
- /* Intel 7520 or 7320 */
- pciebar = pci_cfgregread(0, 0, 0, 0xce, 2) << 16;
- pcie_cfgregopen(pciebar, 0, 255);
- break;
- case 0x2580:
- case 0x2584:
- case 0x2590:
- /* Intel 915, 925, or 915GM */
- pciebar = pci_cfgregread(0, 0, 0, 0x48, 4);
- pcie_cfgregopen(pciebar, 0, 255);
- break;
- }
- }
-
return (1);
}
@@ -135,9 +98,6 @@ pci_cfgregread(int bus, int slot, int func, int reg, i
{
uint32_t line;
- if (cfgmech == CFGMECH_NONE)
- return (0x);
-
/*
* Some BIOS writers seem to want to ignore the spec and put
* 0 in the intline rather than 255 to indicate none. Some use
@@ -161,9 +121,6 @@ pci_cfgregread(int bus, int slot, int func, int reg, i
void
pci_cfgregwrite(int bus, int slot, int func, int reg, u_int32_t data, int
bytes)
{
-
- if (cfgmech == CFGMECH_NONE)
- return;
if (cfgmech == CFGMECH_PCIE &&
(bus >= pcie_minbus && bus <= pcie_maxbus) &&
Modified: head/sys/i386/pci/pci_cfgreg.c
svn commit: r346061 - head/tests/sys/netmap
Author: ngie
Date: Tue Apr 9 17:52:11 2019
New Revision: 346061
URL: https://svnweb.freebsd.org/changeset/base/346061
Log:
Polish netmap(4) testcases a bit
1. Not all kernels have netmap(4) support. Check for netmap(4) support before
attempting to run the tests via the `PLAIN_REQUIRE_KERNEL_MODULE(..)`
macro.
2. Libraries shouldn't be added to LDFLAGS; they should be added to LIBADD
instead. This allows the build system to evaluate dependencies for sanity.
3. Sort some of the Makefile variables per bsd.README.
1., in particular, will resolve failures when running this testcase on kernels
lacking netmap(4) support, e.g., the i386 GENERIC kernels on ^/stable/11 and
^/stable/12.
PR: 237129
Reviewed by: vmaffione
Approved by: emaste (mentor)
MFC after:1 week
Differential Revision:https://reviews.freebsd.org/D19864
Modified:
head/tests/sys/netmap/Makefile
head/tests/sys/netmap/ctrl-api-test.c
Modified: head/tests/sys/netmap/Makefile
==
--- head/tests/sys/netmap/Makefile Tue Apr 9 17:23:34 2019
(r346060)
+++ head/tests/sys/netmap/Makefile Tue Apr 9 17:52:11 2019
(r346061)
@@ -6,9 +6,10 @@ TESTSDIR= ${TESTSBASE}/sys/netmap
TEST_METADATA+=required_user="root"
TEST_METADATA+=is_exclusive=true
-LDFLAGS+= -lpthread
-CFLAGS+= -I${SRCTOP}/tests
PLAIN_TESTS_C+=ctrl-api-test
+
+CFLAGS+= -I${SRCTOP}/tests
+LIBADD+= pthread
WARNS?=6
Modified: head/tests/sys/netmap/ctrl-api-test.c
==
--- head/tests/sys/netmap/ctrl-api-test.c Tue Apr 9 17:23:34 2019
(r346060)
+++ head/tests/sys/netmap/ctrl-api-test.c Tue Apr 9 17:52:11 2019
(r346061)
@@ -1839,6 +1839,7 @@ main(int argc, char **argv)
#ifdef __FreeBSD__
PLAIN_REQUIRE_KERNEL_MODULE("if_tap", 0);
+ PLAIN_REQUIRE_KERNEL_MODULE("netmap", 0);
#endif
memset(_, 0, sizeof(ctx_));
___
svn-src-all@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"
Re: svn commit: r346039 - head/sys/conf
On Tue, 2019-04-09 at 11:19 -0600, Rebecca Cran wrote: > On 2019-04-08 12:25, Warner Losh wrote: > > Author: imp > > Date: Mon Apr 8 18:25:14 2019 > > New Revision: 346039 > > URL: https://svnweb.freebsd.org/changeset/base/346039 > > > > Log: > >Style only change: Prefer $() to `` > > > >$() is more modern and also nests. Convert the mix of styles to > > using > >only the former (although the latter was more common). It's the > > more > >dominant style in other shell scripts these days as well. > > > >Differential Revision: https://reviews.freebsd.org/D19840 > > > > Modified: > >head/sys/conf/newvers.sh > > > > Modified: head/sys/conf/newvers.sh > > > I thought I saw an email a few weeks ago that suggested that the list > of > people who reviewed the patch should be copied into a "Reviewed by:" > line, to avoid only having that information in Phabricator. > > Am I remembering correctly, or is just mentioning the Phab review > considered sufficient? > > As far as I'm concerned, if I've gone to all the trouble to have something phab-reviewed, I'm not going to waste a bunch of time hand- copying metadata from the review to the commit message; citing the review is sufficient. -- Ian ___ svn-src-all@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"
Re: svn commit: r346039 - head/sys/conf
On Tue, Apr 9, 2019 at 11:19 AM Rebecca Cran wrote: > On 2019-04-08 12:25, Warner Losh wrote: > > Author: imp > > Date: Mon Apr 8 18:25:14 2019 > > New Revision: 346039 > > URL: https://svnweb.freebsd.org/changeset/base/346039 > > > > Log: > >Style only change: Prefer $() to `` > > > >$() is more modern and also nests. Convert the mix of styles to using > >only the former (although the latter was more common). It's the more > >dominant style in other shell scripts these days as well. > > > >Differential Revision: https://reviews.freebsd.org/D19840 > > > > Modified: > >head/sys/conf/newvers.sh > > > > Modified: head/sys/conf/newvers.sh > > > I thought I saw an email a few weeks ago that suggested that the list of > people who reviewed the patch should be copied into a "Reviewed by:" > line, to avoid only having that information in Phabricator. > > Am I remembering correctly, or is just mentioning the Phab review > considered sufficient? > You remember correctly. Sadly, there's no automation to make it happen, so it's easy to forget. I hate the notion that came out of the last discussion, but am trying to do it, but since there's no automation, I'll fail to do the right thing more often than not. Warner ___ svn-src-all@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"
Re: svn commit: r346039 - head/sys/conf
On 2019-04-08 12:25, Warner Losh wrote: Author: imp Date: Mon Apr 8 18:25:14 2019 New Revision: 346039 URL: https://svnweb.freebsd.org/changeset/base/346039 Log: Style only change: Prefer $() to `` $() is more modern and also nests. Convert the mix of styles to using only the former (although the latter was more common). It's the more dominant style in other shell scripts these days as well. Differential Revision: https://reviews.freebsd.org/D19840 Modified: head/sys/conf/newvers.sh Modified: head/sys/conf/newvers.sh I thought I saw an email a few weeks ago that suggested that the list of people who reviewed the patch should be copied into a "Reviewed by:" line, to avoid only having that information in Phabricator. Am I remembering correctly, or is just mentioning the Phab review considered sufficient? -- Rebecca Cran ___ svn-src-all@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"
Re: svn commit: r346052 - head/sys/dev/usb/net
On Tue, 2019-04-09 at 09:33 -0700, John Baldwin wrote: > On 4/9/19 9:17 AM, Ian Lepore wrote: > > On Tue, 2019-04-09 at 09:11 -0700, John Baldwin wrote: > > > On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote: > > > > Author: ganbold > > > > Date: Tue Apr 9 13:54:08 2019 > > > > New Revision: 346052 > > > > URL: https://svnweb.freebsd.org/changeset/base/346052 > > > > > > > > Log: > > > > In some cases like NanoPI R1, its second USB ethernet > > > > RTL8152 (chip version URE_CHIP_VER_4C10) doesn't > > > > have hardwired MAC address, in other words, it is all zeros. > > > > This commit fixes it by setting random MAC address > > > > when MAC address is all zeros. > > > > > > > > Reviewed by: kevlo > > > > Differential Revision: > > > > https://reviews.freebsd.org/D19856 > > > > > > It would be best to not use a purely random mac address and to > > > use > > > the > > > function kevans@ added recently. That function generates a MAC > > > address > > > from the FreeBSD OUI using a cryptographic hash so you get a > > > stable address across boots on a given host. > > > > > > > How could that possibly work? If it's not random, you can't have > > two > > such devices on the same network. If it is random, it's not stable > > from one boot to the next. > > It uses the UUID and interface name as input into the hash. > The UUID is per-host. Oh, so it only works on x86 (or I guess any system that has something like a bios that can provide you with a uuid that doesn't change from one boot to the next). -- Ian > In this particular use case, the first USB device will > have a varying MAC address which is an input into the UUID. Though, > the other option this driver could use for this specific case would > be > to just take the first MAC address and +1 to get the second one. > ___ svn-src-all@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"
svn commit: r346059 - in stable/12: share/man/man4 sys/sys
Author: ngie Date: Tue Apr 9 16:35:23 2019 New Revision: 346059 URL: https://svnweb.freebsd.org/changeset/base/346059 Log: MFC r344662: Remove references to pdwait4(2) and `CAP_PDWAIT` from rights(4) @cem removed references to pdwait4(2) (a nonexistent syscall) in r320058. This change removes references to pdwait4(2) and `CAP_PDWAIT` in rights(4) to not mislead the user into thinking that pdwait4(2)/`CAP_PDWAIT` is actually implemented in the stock FreeBSD kernel. The goal of this functionality was to simplify monitoring/manipulating processes started with `pdfork`, et al, and avoid races with waiting on pids. The syscall was never completed though--just discussed on the capsicum mailing list back in 2015: https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2015-May/msg00012.html . That being said, there are members of the project (@rwatson, etc) who have longterm goals to implement this syscall to better secure pdfork(2) calls. PR: 235871 Approved by: emaste (mentor) Differential Revision: https://reviews.freebsd.org/D19805 Modified: stable/12/share/man/man4/rights.4 stable/12/sys/sys/capsicum.h Modified: stable/12/share/man/man4/rights.4 == --- stable/12/share/man/man4/rights.4 Tue Apr 9 16:31:30 2019 (r346058) +++ stable/12/share/man/man4/rights.4 Tue Apr 9 16:35:23 2019 (r346059) @@ -32,7 +32,7 @@ .\" .\" $FreeBSD$ .\" -.Dd April 30, 2018 +.Dd February 28, 2019 .Dt RIGHTS 4 .Os .Sh NAME @@ -467,9 +467,6 @@ Permit .It Dv CAP_PDKILL Permit .Xr pdkill 2 . -.It Dv CAP_PDWAIT -Permit -.Xr pdwait4 2 . .It Dv CAP_PEELOFF Permit .Xr sctp_peeloff 2 . Modified: stable/12/sys/sys/capsicum.h == --- stable/12/sys/sys/capsicum.hTue Apr 9 16:31:30 2019 (r346058) +++ stable/12/sys/sys/capsicum.hTue Apr 9 16:35:23 2019 (r346059) @@ -246,7 +246,12 @@ /* Process management via process descriptors. */ /* Allows for pdgetpid(2). */ #defineCAP_PDGETPIDCAPRIGHT(1, 0x0200ULL) -/* Allows for pdwait4(2). */ +/* + * Allows for pdwait4(2). + * + * XXX: this constant was imported unused, but is targeted to be implemented + * in the future (bug 235871). + */ #defineCAP_PDWAIT CAPRIGHT(1, 0x0400ULL) /* Allows for pdkill(2). */ #defineCAP_PDKILL CAPRIGHT(1, 0x0800ULL) ___ svn-src-all@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"
Re: svn commit: r346052 - head/sys/dev/usb/net
On 4/9/19 9:17 AM, Ian Lepore wrote: > On Tue, 2019-04-09 at 09:11 -0700, John Baldwin wrote: >> On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote: >>> Author: ganbold >>> Date: Tue Apr 9 13:54:08 2019 >>> New Revision: 346052 >>> URL: https://svnweb.freebsd.org/changeset/base/346052 >>> >>> Log: >>> In some cases like NanoPI R1, its second USB ethernet >>> RTL8152 (chip version URE_CHIP_VER_4C10) doesn't >>> have hardwired MAC address, in other words, it is all zeros. >>> This commit fixes it by setting random MAC address >>> when MAC address is all zeros. >>> >>> Reviewed by: kevlo >>> Differential Revision:https://reviews.freebsd.org/D19856 >> >> It would be best to not use a purely random mac address and to use >> the >> function kevans@ added recently. That function generates a MAC >> address >> from the FreeBSD OUI using a cryptographic hash so you get a >> stable address across boots on a given host. >> > > How could that possibly work? If it's not random, you can't have two > such devices on the same network. If it is random, it's not stable > from one boot to the next. It uses the UUID and interface name as input into the hash. The UUID is per-host. In this particular use case, the first USB device will have a varying MAC address which is an input into the UUID. Though, the other option this driver could use for this specific case would be to just take the first MAC address and +1 to get the second one. -- John Baldwin ___ svn-src-all@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"
svn commit: r346057 - head/tests/sys/geom/class/eli
Author: ngie
Date: Tue Apr 9 16:20:36 2019
New Revision: 346057
URL: https://svnweb.freebsd.org/changeset/base/346057
Log:
Fix geli device cleanup
Final cleanup routines shouldn't be called from testcases; it should be called
from the testcase cleanup routine.
Furthermore, `geli_test_cleanup` should take care of cleaning up geli
providers
and the memory disks used for the geli providers. `geli_test_cleanup` will
always
be executed whereas the equivalent logic in `geli_test_body`, may not have
been
executed if the test failed prior to the logic being run.
Prior to this change, the test case was trying to clean up `$md` twice: once
in
at the end of the test case body function, and the other in the cleanup
function.
The cleanup function logic was failing because there wasn't anything to clean
up
in the cleanup function and the errors weren't being ignored.
This fixes FreeBSD test suite runs after r345864.
PR: 237128
Reviewed by: asomers, pjd
Approved by: emaste (mentor)
MFC with: r345864
Differential Revision:https://reviews.freebsd.org/D19854
Modified:
head/tests/sys/geom/class/eli/online_resize_test.sh
Modified: head/tests/sys/geom/class/eli/online_resize_test.sh
==
--- head/tests/sys/geom/class/eli/online_resize_test.sh Tue Apr 9 16:17:31
2019(r346056)
+++ head/tests/sys/geom/class/eli/online_resize_test.sh Tue Apr 9 16:20:36
2019(r346057)
@@ -172,22 +172,18 @@ online_resize_body()
atf_check -s exit:0 -o match:'^Flags: .*AUTORESIZE' geli list
${md}p1.eli
atf_check -s exit:0 -o match:resized gpart resize -i 1 -s
30${prefix} ${md}
atf_check -s exit:0 -o
match:"^[[:space:]]${osize30}[[:space:]]+# mediasize in bytes" diskinfo -v
${md}p1.eli
- atf_check geli detach ${md}p1.eli
-
- # Cleanup.
- atf_check -s exit:0 -o match:deleted gpart delete -i 1 ${md}
- atf_check -s exit:0 -o match:destroyed gpart destroy ${md}
- atf_check -s exit:0 -o ignore mdconfig -d -u ${md}
done
}
online_resize_cleanup()
{
if [ -f "$TEST_MDS_FILE" ]; then
while read md; do
- [ -c /dev/${md}p1.eli ] && geli detach ${md}p1.eli
- mdconfig -d -u ${md} 2>/dev/null
+ atf_check -s ignore -e ignore -o ignore geli detach
${md}p1.eli
+ atf_check -s ignore -e ignore -o ignore gpart delete -i
1 ${md}
+ atf_check -s ignore -e ignore -o ignore gpart destroy
${md}
done < $TEST_MDS_FILE
fi
+ geli_test_cleanup
}
atf_init_test_cases()
___
svn-src-all@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"
Re: svn commit: r346052 - head/sys/dev/usb/net
On Tue, 2019-04-09 at 09:11 -0700, John Baldwin wrote: > On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote: > > Author: ganbold > > Date: Tue Apr 9 13:54:08 2019 > > New Revision: 346052 > > URL: https://svnweb.freebsd.org/changeset/base/346052 > > > > Log: > > In some cases like NanoPI R1, its second USB ethernet > > RTL8152 (chip version URE_CHIP_VER_4C10) doesn't > > have hardwired MAC address, in other words, it is all zeros. > > This commit fixes it by setting random MAC address > > when MAC address is all zeros. > > > > Reviewed by: kevlo > > Differential Revision:https://reviews.freebsd.org/D19856 > > It would be best to not use a purely random mac address and to use > the > function kevans@ added recently. That function generates a MAC > address > from the FreeBSD OUI using a cryptographic hash so you get a > stable address across boots on a given host. > How could that possibly work? If it's not random, you can't have two such devices on the same network. If it is random, it's not stable from one boot to the next. -- Ian ___ svn-src-all@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"
svn commit: r346056 - head
Author: ngie
Date: Tue Apr 9 16:17:31 2019
New Revision: 346056
URL: https://svnweb.freebsd.org/changeset/base/346056
Log:
Fix a typo when sanity checking in the bootstrap-tools target
The path is incorrect for the linker in the error message. It should have been
/usr/bin/ld, not /usr/bin/cc .
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after:2 weeks
Differential Revision: https://reviews.freebsd.org/D19852
Modified:
head/Makefile
Modified: head/Makefile
==
--- head/Makefile Tue Apr 9 16:16:10 2019(r346055)
+++ head/Makefile Tue Apr 9 16:17:31 2019(r346056)
@@ -570,7 +570,7 @@ universe-toolchain: .PHONY universe_prologue
false; \
fi
@if [ ! -e "${HOST_OBJTOP}/tmp/usr/bin/ld" ]; then \
- echo "Missing host linker at ${HOST_OBJTOP}/tmp/usr/bin/cc?" >&2; \
+ echo "Missing host linker at ${HOST_OBJTOP}/tmp/usr/bin/ld?" >&2; \
false; \
fi
@echo "--"
___
svn-src-all@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"
svn commit: r346055 - stable/12/tests/sys/cddl/zfs/tests/delegate
Author: ngie
Date: Tue Apr 9 16:16:10 2019
New Revision: 346055
URL: https://svnweb.freebsd.org/changeset/base/346055
Log:
MFC r345216:
Remove duplicate `${PACKAGE}FILES+= cleanup.ksh` line
This mutes the duplicate target warning emitted via bsd.files.mk each build.
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D19806
Modified:
stable/12/tests/sys/cddl/zfs/tests/delegate/Makefile
Directory Properties:
stable/12/ (props changed)
Modified: stable/12/tests/sys/cddl/zfs/tests/delegate/Makefile
==
--- stable/12/tests/sys/cddl/zfs/tests/delegate/MakefileTue Apr 9
15:52:18 2019(r346054)
+++ stable/12/tests/sys/cddl/zfs/tests/delegate/MakefileTue Apr 9
16:16:10 2019(r346055)
@@ -12,7 +12,6 @@ TEST_METADATA+= required_user="root"
TEST_METADATA+=is_exclusive=true
${PACKAGE}FILES+= cleanup.ksh
-${PACKAGE}FILES+= cleanup.ksh
${PACKAGE}FILES+= delegate.cfg
${PACKAGE}FILES+= delegate_common.kshlib
${PACKAGE}FILES+= setup.ksh
___
svn-src-all@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"
Re: svn commit: r346052 - head/sys/dev/usb/net
On 4/9/19 6:54 AM, Ganbold Tsagaankhuu wrote: > Author: ganbold > Date: Tue Apr 9 13:54:08 2019 > New Revision: 346052 > URL: https://svnweb.freebsd.org/changeset/base/346052 > > Log: > In some cases like NanoPI R1, its second USB ethernet > RTL8152 (chip version URE_CHIP_VER_4C10) doesn't > have hardwired MAC address, in other words, it is all zeros. > This commit fixes it by setting random MAC address > when MAC address is all zeros. > > Reviewed by:kevlo > Differential Revision: https://reviews.freebsd.org/D19856 It would be best to not use a purely random mac address and to use the function kevans@ added recently. That function generates a MAC address from the FreeBSD OUI using a cryptographic hash so you get a stable address across boots on a given host. -- John Baldwin ___ svn-src-all@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"
svn commit: r346054 - head/lib/libc/string
Author: emaste
Date: Tue Apr 9 15:52:18 2019
New Revision: 346054
URL: https://svnweb.freebsd.org/changeset/base/346054
Log:
libc: update strstr implementation to match musl
musl commits:
122d67f846cb0be2c9e1c3880db9eb9545bbe38c
0239cd0681e889a269fb7691f60e81ef8d081e6b
8f5a820d147da36bcdbddd201b35d293699dacd8
Submitted by: David CARLIER
Obtained from:musl
MFC after:1 week
Differential Revision:https://reviews.freebsd.org/D19834
Modified:
head/lib/libc/string/strstr.c
Modified: head/lib/libc/string/strstr.c
==
--- head/lib/libc/string/strstr.c Tue Apr 9 15:24:38 2019
(r346053)
+++ head/lib/libc/string/strstr.c Tue Apr 9 15:52:18 2019
(r346054)
@@ -143,9 +143,8 @@ static char *twoway_strstr(const unsigned char *h, con
/* Check last byte first; advance by shift on mismatch */
if (BITOP(byteset, h[l-1], &)) {
k = l-shift[h[l-1]];
- //printf("adv by %zu (on %c) at [%s] (%zu;l=%zu)\n", k,
h[l-1], h, shift[h[l-1]], l);
if (k) {
- if (mem0 && mem && k < p) k = l-p;
+ if (k < mem) k = mem;
h += k;
mem = 0;
continue;
___
svn-src-all@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"
svn commit: r346053 - head/sys/kern
Author: trasz
Date: Tue Apr 9 15:24:38 2019
New Revision: 346053
URL: https://svnweb.freebsd.org/changeset/base/346053
Log:
Factor out section loading into a separate function.
Reviewed by: kib
MFC after:2 weeks
Sponsored by: DARPA, AFRL
Differential Revision:https://reviews.freebsd.org/D19846
Modified:
head/sys/kern/imgact_elf.c
Modified: head/sys/kern/imgact_elf.c
==
--- head/sys/kern/imgact_elf.c Tue Apr 9 13:54:08 2019(r346052)
+++ head/sys/kern/imgact_elf.c Tue Apr 9 15:24:38 2019(r346053)
@@ -649,6 +649,45 @@ __elfN(load_section)(struct image_params *imgp, vm_oof
return (0);
}
+static int
+__elfN(load_sections)(struct image_params *imgp, const Elf_Ehdr *hdr,
+const Elf_Phdr *phdr, u_long rbase, u_long *base_addrp)
+{
+ vm_prot_t prot;
+ u_long base_addr;
+ bool first;
+ int error, i;
+
+ base_addr = 0;
+ first = true;
+
+ for (i = 0; i < hdr->e_phnum; i++) {
+ if (phdr[i].p_type != PT_LOAD || phdr[i].p_memsz == 0)
+ continue;
+
+ /* Loadable segment */
+ prot = __elfN(trans_prot)(phdr[i].p_flags);
+ error = __elfN(load_section)(imgp, phdr[i].p_offset,
+ (caddr_t)(uintptr_t)phdr[i].p_vaddr + rbase,
+ phdr[i].p_memsz, phdr[i].p_filesz, prot);
+ if (error != 0)
+ return (error);
+
+ /*
+* Establish the base address if this is the first segment.
+*/
+ if (first) {
+ base_addr = trunc_page(phdr[i].p_vaddr + rbase);
+ first = false;
+ }
+ }
+
+ if (base_addrp != NULL)
+ *base_addrp = base_addr;
+
+ return (0);
+}
+
/*
* Load the file "file" into memory. It may be either a shared object
* or an executable.
@@ -675,10 +714,9 @@ __elfN(load_file)(struct proc *p, const char *file, u_
struct nameidata *nd;
struct vattr *attr;
struct image_params *imgp;
- vm_prot_t prot;
u_long rbase;
u_long base_addr = 0;
- int error, i, numsegs;
+ int error;
#ifdef CAPABILITY_MODE
/*
@@ -756,25 +794,10 @@ __elfN(load_file)(struct proc *p, const char *file, u_
goto fail;
}
- for (i = 0, numsegs = 0; i < hdr->e_phnum; i++) {
- if (phdr[i].p_type == PT_LOAD && phdr[i].p_memsz != 0) {
- /* Loadable segment */
- prot = __elfN(trans_prot)(phdr[i].p_flags);
- error = __elfN(load_section)(imgp, phdr[i].p_offset,
- (caddr_t)(uintptr_t)phdr[i].p_vaddr + rbase,
- phdr[i].p_memsz, phdr[i].p_filesz, prot);
- if (error != 0)
- goto fail;
- /*
-* Establish the base address if this is the
-* first segment.
-*/
- if (numsegs == 0)
- base_addr = trunc_page(phdr[i].p_vaddr +
- rbase);
- numsegs++;
- }
- }
+ error = __elfN(load_sections)(imgp, hdr, phdr, rbase, _addr);
+ if (error != 0)
+ goto fail;
+
*addr = base_addr;
*entry = (unsigned long)hdr->e_entry + rbase;
@@ -998,7 +1021,6 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *i
char *interp;
Elf_Brandinfo *brand_info;
struct sysentvec *sv;
- vm_prot_t prot;
u_long addr, baddr, et_dyn_addr, entry, proghdr;
u_long maxalign, mapsz, maxv, maxv1;
uint32_t fctl0;
@@ -1055,6 +1077,17 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *i
maxalign = phdr[i].p_align;
mapsz += phdr[i].p_memsz;
n++;
+
+ /*
+* If this segment contains the program headers,
+* remember their virtual address for the AT_PHDR
+* aux entry. Static binaries don't usually include
+* a PT_PHDR entry.
+*/
+ if (phdr[i].p_offset == 0 &&
+ hdr->e_phoff + hdr->e_phnum * hdr->e_phentsize
+ <= phdr[i].p_filesz)
+ proghdr = phdr[i].p_vaddr + hdr->e_phoff;
break;
case PT_INTERP:
/* Path to interpreter */
@@ -1074,6 +1107,9 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *i
__elfN(trans_prot)(phdr[i].p_flags);
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
Hey,
On 9 April 2019 14:13:54 BST, "O. Hartmann" wrote:
>On Sun, 7 Apr 2019 18:31:45 + (UTC)
>Chris Rees wrote:
>
>> Author: crees (doc,ports committer)
>> Date: Sun Apr 7 18:31:45 2019
>> New Revision: 346017
>> URL: https://svnweb.freebsd.org/changeset/base/346017
>>
>> Log:
>> Remove now unnecessary kldstat check before attempting to load
>modules.
>>
>> Since r233109, kldload has the -n option, which silently ignores
>options
>> that are already loaded.
>>
>>
>https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
>>
>> Note that this script no longer reports if the module is already
>loaded,
>> but it could be argued this wasn't particularly useful information.
>>
>> PR:docs/234248
>> Reviewed by: bcr (docs), kib, rgrimes (visual)
>> Approved by: jilles
>> Differential Revision: https://reviews.freebsd.org/D18670
>>
>> Modified:
>> head/libexec/rc/rc.d/abi
>> head/libexec/rc/rc.d/bthidd
>> head/libexec/rc/rc.d/cfumass
>> head/libexec/rc/rc.d/kld
>> head/libexec/rc/rc.d/mdconfig
>> head/libexec/rc/rc.d/mdconfig2
>> head/libexec/rc/rc.d/mountcritremote
>> head/libexec/rc/rc.d/syscons
>> head/libexec/rc/rc.subr
>> head/share/man/man5/rc.conf.5
>>
>> Modified: head/libexec/rc/rc.d/abi
>>
>==
{Snip}
>It seems this patch breaks ZFS if ZFS is built-in kernel!
>
>Having ZFS as kernel built-in leaves the system not mounting ANY(!) ZFS
>volume
>at boot time, rendering servers unusable.
>Mounting ZFS filesystems with "zfs mount -a" bring back the ZFS
>filesystems as
>expected.
>
Are you sure it's this causing that? Please try reverting it.
Chris
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
svn-src-all@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"
Re: svn commit: r346052 - head/sys/dev/usb/net
On 09.04.2019 16:54, Ganbold Tsagaankhuu wrote:
> Author: ganbold
> Date: Tue Apr 9 13:54:08 2019
> New Revision: 346052
> URL: https://svnweb.freebsd.org/changeset/base/346052
>
> Log:
> In some cases like NanoPI R1, its second USB ethernet
> RTL8152 (chip version URE_CHIP_VER_4C10) doesn't
> have hardwired MAC address, in other words, it is all zeros.
> This commit fixes it by setting random MAC address
> when MAC address is all zeros.
>
> - if (sc->sc_chip & URE_CHIP_VER_4C00)
> + if ((sc->sc_chip & URE_CHIP_VER_4C00) ||
> + (sc->sc_chip & URE_CHIP_VER_4C10))
> ure_read_mem(sc, URE_PLA_IDR, URE_MCU_TYPE_PLA,
> ue->ue_eaddr, 8);
> else
> ure_read_mem(sc, URE_PLA_BACKUP, URE_MCU_TYPE_PLA,
> ue->ue_eaddr, 8);
> +
> + if (ETHER_IS_ZERO(sc->sc_ue.ue_eaddr)) {
> + device_printf(sc->sc_ue.ue_dev, "MAC assigned randomly\n");
> + arc4rand(sc->sc_ue.ue_eaddr, ETHER_ADDR_LEN, 0);
> + sc->sc_ue.ue_eaddr[0] &= ~0x01; /* unicast */
> + sc->sc_ue.ue_eaddr[0] |= 0x02; /* locally administered */
> + }
> }
Hi,
there is ether_fakeaddr() function that is used for such purpose.
Maybe is it better to use it? Look at this commit:
https://svnweb.freebsd.org/base?view=revision=345139
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
svn commit: r346052 - head/sys/dev/usb/net
Author: ganbold
Date: Tue Apr 9 13:54:08 2019
New Revision: 346052
URL: https://svnweb.freebsd.org/changeset/base/346052
Log:
In some cases like NanoPI R1, its second USB ethernet
RTL8152 (chip version URE_CHIP_VER_4C10) doesn't
have hardwired MAC address, in other words, it is all zeros.
This commit fixes it by setting random MAC address
when MAC address is all zeros.
Reviewed by: kevlo
Differential Revision:https://reviews.freebsd.org/D19856
Modified:
head/sys/dev/usb/net/if_ure.c
Modified: head/sys/dev/usb/net/if_ure.c
==
--- head/sys/dev/usb/net/if_ure.c Tue Apr 9 12:28:12 2019
(r346051)
+++ head/sys/dev/usb/net/if_ure.c Tue Apr 9 13:54:08 2019
(r346052)
@@ -62,6 +62,9 @@ SYSCTL_INT(_hw_usb_ure, OID_AUTO, debug, CTLFLAG_RWTUN
"Debug level");
#endif
+#defineETHER_IS_ZERO(addr) \
+ (!(addr[0] | addr[1] | addr[2] | addr[3] | addr[4] | addr[5]))
+
/*
* Various supported device vendors/products.
*/
@@ -673,12 +676,20 @@ ure_attach_post(struct usb_ether *ue)
else
ure_rtl8153_init(sc);
- if (sc->sc_chip & URE_CHIP_VER_4C00)
+ if ((sc->sc_chip & URE_CHIP_VER_4C00) ||
+ (sc->sc_chip & URE_CHIP_VER_4C10))
ure_read_mem(sc, URE_PLA_IDR, URE_MCU_TYPE_PLA,
ue->ue_eaddr, 8);
else
ure_read_mem(sc, URE_PLA_BACKUP, URE_MCU_TYPE_PLA,
ue->ue_eaddr, 8);
+
+ if (ETHER_IS_ZERO(sc->sc_ue.ue_eaddr)) {
+ device_printf(sc->sc_ue.ue_dev, "MAC assigned randomly\n");
+ arc4rand(sc->sc_ue.ue_eaddr, ETHER_ADDR_LEN, 0);
+ sc->sc_ue.ue_eaddr[0] &= ~0x01; /* unicast */
+ sc->sc_ue.ue_eaddr[0] |= 0x02; /* locally administered */
+ }
}
static int
@@ -724,8 +735,10 @@ ure_init(struct usb_ether *ue)
ure_reset(sc);
/* Set MAC address. */
+ ure_write_1(sc, URE_PLA_CRWECR, URE_MCU_TYPE_PLA, URE_CRWECR_CONFIG);
ure_write_mem(sc, URE_PLA_IDR, URE_MCU_TYPE_PLA | URE_BYTE_EN_SIX_BYTES,
IF_LLADDR(ifp), 8);
+ ure_write_1(sc, URE_PLA_CRWECR, URE_MCU_TYPE_PLA, URE_CRWECR_NORAML);
/* Reset the packet filter. */
ure_write_2(sc, URE_PLA_FMC, URE_MCU_TYPE_PLA,
___
svn-src-all@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"
Re: svn commit: r346017 - in head: libexec/rc libexec/rc/rc.d share/man/man5
On Sun, 7 Apr 2019 18:31:45 + (UTC)
Chris Rees wrote:
> Author: crees (doc,ports committer)
> Date: Sun Apr 7 18:31:45 2019
> New Revision: 346017
> URL: https://svnweb.freebsd.org/changeset/base/346017
>
> Log:
> Remove now unnecessary kldstat check before attempting to load modules.
>
> Since r233109, kldload has the -n option, which silently ignores options
> that are already loaded.
>
> https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
>
> Note that this script no longer reports if the module is already loaded,
> but it could be argued this wasn't particularly useful information.
>
> PR: docs/234248
> Reviewed by:bcr (docs), kib, rgrimes (visual)
> Approved by:jilles
> Differential Revision: https://reviews.freebsd.org/D18670
>
> Modified:
> head/libexec/rc/rc.d/abi
> head/libexec/rc/rc.d/bthidd
> head/libexec/rc/rc.d/cfumass
> head/libexec/rc/rc.d/kld
> head/libexec/rc/rc.d/mdconfig
> head/libexec/rc/rc.d/mdconfig2
> head/libexec/rc/rc.d/mountcritremote
> head/libexec/rc/rc.d/syscons
> head/libexec/rc/rc.subr
> head/share/man/man5/rc.conf.5
>
> Modified: head/libexec/rc/rc.d/abi
> ==
> --- head/libexec/rc/rc.d/abi Sun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/abi Sun Apr 7 18:31:45 2019(r346017)
> @@ -27,10 +27,10 @@ linux_start()
> local _tmpdir
>
> echo -n ' linux'
> - load_kld -e 'linux(aout|elf)' linux
> + load_kld linux
> case `sysctl -n hw.machine_arch` in
> amd64)
> - load_kld -e 'linux64elf' linux64
> + load_kld linux64
> ;;
> esac
> if [ -x /compat/linux/sbin/ldconfigDisabled ]; then
>
> Modified: head/libexec/rc/rc.d/bthidd
> ==
> --- head/libexec/rc/rc.d/bthidd Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/bthidd Sun Apr 7 18:31:45
> 2019 (r346017) @@ -34,11 +34,11 @@ evdev_enabled()
> bthidd_prestart()
> {
> if evdev_enabled; then
> - load_kld -m uinput uinput
> + load_kld uinput
> fi
> - load_kld -m kbdmux kbdmux
> - load_kld -m vkbd vkbd
> - load_kld -m ng_btsocket ng_btsocket
> + load_kld kbdmux
> + load_kld vkbd
> + load_kld ng_btsocket
> return 0
> }
>
>
> Modified: head/libexec/rc/rc.d/cfumass
> ==
> --- head/libexec/rc/rc.d/cfumass Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/cfumassSun Apr 7 18:31:45
> 2019 (r346017) @@ -75,7 +75,7 @@ cfumass_start()
> return "${err}"
> fi
>
> - load_kld -e cfumass cfumass
> + load_kld cfumass
>
> # If the template is already switched to Mass Storage, then reset
> # it to -1 to force the host to reenumerate it; otherwise it might
>
> Modified: head/libexec/rc/rc.d/kld
> ==
> --- head/libexec/rc/rc.d/kld Sun Apr 7 18:24:26 2019(r346016)
> +++ head/libexec/rc/rc.d/kld Sun Apr 7 18:31:45 2019(r346017)
> @@ -46,7 +46,7 @@ kld_start()
>
> echo 'Loading kernel modules:'
> for _kld in $kld_list ; do
> - load_kld -e ${_kld}.ko $_kld
> + load_kld $_kld
> done
> }
>
>
> Modified: head/libexec/rc/rc.d/mdconfig
> ==
> --- head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/mdconfig Sun Apr 7 18:31:45
> 2019 (r346017) @@ -114,7 +114,7 @@ mdconfig_start()
> continue
> fi
> if [ "${_file}" != "${_file%.uzip}" ]; then
> - load_kld -m g_uzip geom_uzip ||
> return 3
> + load_kld geom_uzip || return 3
> # sleep a bit to allow creation
> of /dev/mdX.uzip sleep 2
> fi
>
> Modified: head/libexec/rc/rc.d/mdconfig2
> ==
> --- head/libexec/rc/rc.d/mdconfig2Sun Apr 7 18:24:26 2019
> (r346016) +++ head/libexec/rc/rc.d/mdconfig2 Sun Apr 7 18:31:45
> 2019 (r346017) @@ -123,7 +123,7 @@ mdconfig2_start()
> # been created.
> if [ "${_type}" = "vnode" -a "${_fs}" != "/" ]; then
> if [ "${_file}" != "${_file%.uzip}" ]; then
> - load_kld -m g_uzip geom_uzip || return 3
> + load_kld geom_uzip || return 3
> fi
> if is_readonly ${_fs}; then
>
svn commit: r346051 - in stable: 11/usr.sbin/daemon 12/usr.sbin/daemon
Author: grembo (ports committer) Date: Tue Apr 9 12:28:12 2019 New Revision: 346051 URL: https://svnweb.freebsd.org/changeset/base/346051 Log: MFC r345512: Correct contradictory information on default syslog logging priority. Modified: stable/12/usr.sbin/daemon/daemon.8 Directory Properties: stable/12/ (props changed) Changes in other areas also in this revision: Modified: stable/11/usr.sbin/daemon/daemon.8 Directory Properties: stable/11/ (props changed) Modified: stable/12/usr.sbin/daemon/daemon.8 == --- stable/12/usr.sbin/daemon/daemon.8 Tue Apr 9 10:33:18 2019 (r346050) +++ stable/12/usr.sbin/daemon/daemon.8 Tue Apr 9 12:28:12 2019 (r346051) @@ -26,7 +26,7 @@ .\" .\" $FreeBSD$ .\" -.Dd April 15, 2018 +.Dd March 25, 2019 .Dt DAEMON 8 .Os .Sh NAME @@ -129,7 +129,7 @@ Requires adequate superuser privileges. .It Fl s Ar syslog_priority These priorities are accepted: emerg, alert, crit, err, warning, notice, info, and debug. -The default is info. +The default is notice. .It Fl l Ar syslog_facility These facilities are accepted: auth, authpriv, console, cron, daemon, ftp, kern, lpr, mail, news, ntp, security, syslog, user, uucp, and ___ svn-src-all@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"
svn commit: r346051 - in stable: 11/usr.sbin/daemon 12/usr.sbin/daemon
Author: grembo (ports committer) Date: Tue Apr 9 12:28:12 2019 New Revision: 346051 URL: https://svnweb.freebsd.org/changeset/base/346051 Log: MFC r345512: Correct contradictory information on default syslog logging priority. Modified: stable/11/usr.sbin/daemon/daemon.8 Directory Properties: stable/11/ (props changed) Changes in other areas also in this revision: Modified: stable/12/usr.sbin/daemon/daemon.8 Directory Properties: stable/12/ (props changed) Modified: stable/11/usr.sbin/daemon/daemon.8 == --- stable/11/usr.sbin/daemon/daemon.8 Tue Apr 9 10:33:18 2019 (r346050) +++ stable/11/usr.sbin/daemon/daemon.8 Tue Apr 9 12:28:12 2019 (r346051) @@ -26,7 +26,7 @@ .\" .\" $FreeBSD$ .\" -.Dd April 15, 2018 +.Dd March 25, 2019 .Dt DAEMON 8 .Os .Sh NAME @@ -129,7 +129,7 @@ Requires adequate superuser privileges. .It Fl s Ar syslog_priority These priorities are accepted: emerg, alert, crit, err, warning, notice, info, and debug. -The default is info. +The default is notice. .It Fl l Ar syslog_facility These facilities are accepted: auth, authpriv, console, cron, daemon, ftp, kern, lpr, mail, news, ntp, security, syslog, user, uucp, and ___ svn-src-all@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"
Re: svn commit: r345970 - head/libexec/rc
> 09.04.2019 16:22, Rodney W. Grimes wrote: > > >> Works as expected (as it should work) for both 11.2 and 12.0 > >^^ for you, not for me If you did not actually get a lease I do not see that your test is complete, so though it worked to a point, it did not work as expected until you actually obtain a lease. > > Are you using a em0 type device, or something else? > > em0 for FreeBSD as guest inside VirtualBox. Real hardware here. > Well, I have no vlans here really outside of VBox so dhclient does not obtain > a lease for vlan32 > but it tries very hard. So this is not configuration problem. It tries very hard here too, and it is not succesful until I do an: ifconfig em0 down; ifconfig em0 up; then it immediatly gets a lease. Something is happening on re-init of em0 that is not happening in the normal situation. Could this be one of the iflib bugs, that is fixed in head or stable/12 but not in releng/12? -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
svn commit: r346050 - head/tools/tools/ioat
Author: tychon
Date: Tue Apr 9 10:33:18 2019
New Revision: 346050
URL: https://svnweb.freebsd.org/changeset/base/346050
Log:
ioatcontrol(8) crc-copy flag bug and misc usage tweak
Reviewed by: cem
Sponsored by: Dell EMC Isilon
Differential Revision:https://reviews.freebsd.org/D19855
Modified:
head/tools/tools/ioat/ioatcontrol.c
Modified: head/tools/tools/ioat/ioatcontrol.c
==
--- head/tools/tools/ioat/ioatcontrol.c Tue Apr 9 10:17:24 2019
(r346049)
+++ head/tools/tools/ioat/ioatcontrol.c Tue Apr 9 10:33:18 2019
(r346050)
@@ -49,7 +49,7 @@ static void
usage(void)
{
- printf("Usage: %s [-c period] [-EfmVz] channel-number num-txns
[ "
+ printf("Usage: %s [-c period] [-EefmVxXz] channel-number num-txns
[ "
"[ [duration]]]\n", getprogname());
printf(" %s -r [-c period] [-vVwz] channel-number address
[]\n\n",
getprogname());
@@ -154,9 +154,11 @@ main(int argc, char **argv)
break;
case 'x':
xflag = true;
+ modeflags++;
break;
case 'X':
Xflag = true;
+ modeflags++;
break;
case 'z':
t.zero_stats = true;
@@ -172,7 +174,7 @@ main(int argc, char **argv)
usage();
if (modeflags > 1) {
- printf("Invalid: Cannot use >1 mode flag (-E, -f, -m, or
-r)\n");
+ printf("Invalid: Cannot use >1 mode flag (-E, -e, -f, -m, -r,
-x or -X)\n");
usage();
}
@@ -191,7 +193,7 @@ main(int argc, char **argv)
t.testkind = IOAT_TEST_MEMCPY;
else if (xflag)
t.testkind = IOAT_TEST_DMA_CRC;
- else if (xflag)
+ else if (Xflag)
t.testkind = IOAT_TEST_DMA_CRC_COPY;
t.channel_index = atoi(argv[0]);
___
svn-src-all@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"
svn commit: r346049 - head/share/man/man7
Author: trasz Date: Tue Apr 9 10:17:24 2019 New Revision: 346049 URL: https://svnweb.freebsd.org/changeset/base/346049 Log: Remove spurious comma. MFC after:2 weeks Sponsored by: DARPA, AFRL Modified: head/share/man/man7/hostname.7 Modified: head/share/man/man7/hostname.7 == --- head/share/man/man7/hostname.7 Tue Apr 9 10:09:59 2019 (r346048) +++ head/share/man/man7/hostname.7 Tue Apr 9 10:17:24 2019 (r346049) @@ -81,7 +81,7 @@ by a system-wide configuration file (see .Xr resolver 5 ) . .Sh SEE ALSO .Xr gethostbyname 3 , -.Xr resolver 5 , +.Xr resolver 5 .Sh HISTORY .Nm Hostname appeared in ___ svn-src-all@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"
Re: svn commit: r345970 - head/libexec/rc
09.04.2019 16:22, Rodney W. Grimes wrote: >> Works as expected (as it should work) for both 11.2 and 12.0 >^^ for you, not for me > > Are you using a em0 type device, or something else? em0 for FreeBSD as guest inside VirtualBox. Well, I have no vlans here really outside of VBox so dhclient does not obtain a lease for vlan32 but it tries very hard. So this is not configuration problem. ___ svn-src-all@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"
svn commit: r346048 - head/lib/libc/sys
Author: trasz Date: Tue Apr 9 10:09:59 2019 New Revision: 346048 URL: https://svnweb.freebsd.org/changeset/base/346048 Log: .Xr protect(1) and proccontrol(1) from procctl(2). MFC after:2 weeks Sponsored by: DARPA, AFRL Modified: head/lib/libc/sys/procctl.2 Modified: head/lib/libc/sys/procctl.2 == --- head/lib/libc/sys/procctl.2 Tue Apr 9 07:36:40 2019(r346047) +++ head/lib/libc/sys/procctl.2 Tue Apr 9 10:09:59 2019(r346048) @@ -29,7 +29,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 23, 2019 +.Dd April 9, 2019 .Dt PROCCTL 2 .Os .Sh NAME @@ -570,6 +570,8 @@ or invalid signal number. .El .Sh SEE ALSO .Xr dtrace 1 , +.Xr proccontrol 1 , +.Xr protect 1 , .Xr cap_enter 2, .Xr kill 2 , .Xr ktrace 2 , ___ svn-src-all@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"
Re: svn commit: r345970 - head/libexec/rc
> > 09.04.2019 15:38, Rodney W. Grimes wrote: > > > > >> I've just checked and this "just works" for me already. > > >> For which version this does not work, exactly? > > >> When did you verify this last time? > > > > > > I believe the last time I tried this was early, in 11.1 iirc. > > > Are you sure it worked? > > > I'll retest on release 12.0. > > > > > > I can not remeber if the failure was no dhcpclient, or > > > if they do not get the vlan 32 vlandev em0 settings, > > > it was one or the other that did not occur. You > > > do get the vlan32 device, but it does not work. > > > > Works as expected (as it should work) for both 11.2 and 12.0 >^^ for you, not for me > > Are you using a em0 type device, or something else? > I can retest on an alc0 device easily. Rested on alc0, this works perfectly fine. So this appears to be em0/vlan interaction problems. Very odd that a flick of the parent down and up makes it work though. > -- > Rod Grimes rgri...@freebsd.org -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
Re: svn commit: r345970 - head/libexec/rc
> 09.04.2019 15:38, Rodney W. Grimes wrote: > > >> I've just checked and this "just works" for me already. > >> For which version this does not work, exactly? > >> When did you verify this last time? > > > > I believe the last time I tried this was early, in 11.1 iirc. > > Are you sure it worked? > > I'll retest on release 12.0. > > > > I can not remeber if the failure was no dhcpclient, or > > if they do not get the vlan 32 vlandev em0 settings, > > it was one or the other that did not occur. You > > do get the vlan32 device, but it does not work. > > Works as expected (as it should work) for both 11.2 and 12.0 ^^ for you, not for me Are you using a em0 type device, or something else? I can retest on an alc0 device easily. -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
Re: svn commit: r345970 - head/libexec/rc
> 09.04.2019 15:38, Rodney W. Grimes wrote: > > >> I've just checked and this "just works" for me already. > >> For which version this does not work, exactly? > >> When did you verify this last time? > > > > I believe the last time I tried this was early, in 11.1 iirc. > > Are you sure it worked? > > I'll retest on release 12.0. > > > > I can not remeber if the failure was no dhcpclient, or > > if they do not get the vlan 32 vlandev em0 settings, > > it was one or the other that did not occur. You > > do get the vlan32 device, but it does not work. > > Works as expected (as it should work) for both 11.2 and 12.0 It works much better than it did just doing testing in 12.0, the interface is infact properly configured, the DHCP client tries to do the right thing, but fails to get a lease on reboot, including attempt to renew the prior lease. This is not a config startup issue any more, but still an issue of some sort. If after booting I down/up the em0 interface I get a lease almost immediatly. -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
Re: svn commit: r345970 - head/libexec/rc
09.04.2019 15:38, Rodney W. Grimes wrote: >> I've just checked and this "just works" for me already. >> For which version this does not work, exactly? >> When did you verify this last time? > > I believe the last time I tried this was early, in 11.1 iirc. > Are you sure it worked? > I'll retest on release 12.0. > > I can not remeber if the failure was no dhcpclient, or > if they do not get the vlan 32 vlandev em0 settings, > it was one or the other that did not occur. You > do get the vlan32 device, but it does not work. Works as expected (as it should work) for both 11.2 and 12.0 ___ svn-src-all@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"
Re: svn commit: r345970 - head/libexec/rc
> On Fri, Apr 05, 2019 at 04:16:24PM -0700, Rodney W. Grimes wrote: > > > If you want another fun one to wrestle with see if you can > > make this work: > > > > cloned_interfaces="vlan32" > > ifconfig_em0="up" > > ifconfig_vlan32="vlan 32 vlandev em0 SYNCDHCP" > > > > I have worked around it, but it would be nice if this "just worked". > > Sorry for late reply, I somehow missed this. It is of low importance, I have worked around it, and I suspect it is a fairly rare thing for someone to do. > I've just checked and this "just works" for me already. > For which version this does not work, exactly? > When did you verify this last time? I believe the last time I tried this was early, in 11.1 iirc. Are you sure it worked? I'll retest on release 12.0. I can not remeber if the failure was no dhcpclient, or if they do not get the vlan 32 vlandev em0 settings, it was one or the other that did not occur. You do get the vlan32 device, but it does not work. > Eugene Grosbein -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@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"
Re: svn commit: r345970 - head/libexec/rc
On Fri, Apr 05, 2019 at 04:16:24PM -0700, Rodney W. Grimes wrote: > If you want another fun one to wrestle with see if you can > make this work: > > cloned_interfaces="vlan32" > ifconfig_em0="up" > ifconfig_vlan32="vlan 32 vlandev em0 SYNCDHCP" > > I have worked around it, but it would be nice if this "just worked". Sorry for late reply, I somehow missed this. I've just checked and this "just works" for me already. For which version this does not work, exactly? When did you verify this last time? Eugene Grosbein ___ svn-src-all@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"
