Re: nmount, mountd drops high order MNT_xx flags during a mount update
You could add a single integer-valued vfsopt which holds the high-order bits of f_flags? On 7 May 2015 at 02:10, Rick Macklem rmack...@uoguelph.ca wrote: David Boyd reported a problem to freebsd-current@ w.r.t. the MNT_AUTOMOUNTED flag getting cleared by mountd. http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel I just took a look at this and it's kinda ugly... mountd acquires a list of mounts via getmntinfo() and then does an nmount() for each of them to get rid of any exports. It uses f_flags from the statfs returned by getmntinfo() as the 3rd argument to nmount(). -- Since nmount()s 3rd argument is a int, it silently drops any MNT_xx flag in the high order 32bits of f_flags. At this time, it happens that MNT_AUTOMOUNTED is the only one, but... I can think of a couple of ways to fix this, but I don't like any of them;-) 1) I suppose mountd could check for each flag set in f_flags and generate a vfsopts string for it, but that means that every time a new flag that can be updated is added to MNT_xx, this mountd.c code would have to updated. -- Ugly!! 2) Require that all flags in MNT_UPDATEMASK be in the low order 32bits. I wouldn`t mind this except in means that the MNT_xx flags must be redefined and I don`t think that could get MFC`d. 3) Add a new newernmount(2) which has a 64bit flags argument instead of int. Hopefully someone can think of a nice way to fix this, rick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
What to do about RCS/OpenRCS
Hello; Some of you might recall that right before 10.0-Release there was a painful attempt to remove GNU RCS from the base system. From my point of view, the lessons learned from that were: -A lot more people than you might think find it useful to have a small version control system for thing like the files in /etc. -Just removing features without a discussion is not wise. -IMHO, people wondering about the bloat in the OS should focus on other bigger VCS we carry, namely svn. For all I know, it looks like OpenRCS is the most viable option and can completely replace the old RCS we have in base. In order to avoid painful surprises late in the release cycle, I started the process to consider OpenRCS by bringing it to the vendor area (OpenBSD/usr.bin/rcs/*). I also have an initial patch[1] so that it builds on FreeBSD. Unfortunately I don't use RCS enough (it looks like I should though) so I am not in a good position to take the next step and deal with any fallout it may produce. All in all, it looks like whatever is done about RCS it may be controversial so I am opening the discussion in the hope that someone else will take the lead and do something about it much ahead of 11-Release. Regards, Pedro. [1] Follow the link in: https://wiki.freebsd.org/GPLinBase ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Race VT+X11 on -current
On 05/07/15 20:23, Garrett Cooper wrote: On May 7, 2015, at 09:43, Kevin Oberman rkober...@gmail.com wrote: On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky h...@selasky.org wrote: Hi, Sometimes when logging into X11 the keyboard input is not working. Pressing ALT+F9 makes it work. Any idea where the race is? --HPS Actually, I have found that switching to ANY other terminal (e.g. ALT-F2) and back to vty1 does the job. I must admit that this is a pretty minor annoyance, so I never got around to reporting it. Still, any bug report should show that it impacts multiple users. Speaking of which, please file a bug for this issue so it doesn't get lost! Thanks, -NGie Hi, Here it is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200032 --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What to do about RCS/OpenRCS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/07/15 12:09, Pedro Giffuni wrote: Hello; Some of you might recall that right before 10.0-Release there was a painful attempt to remove GNU RCS from the base system. From my point of view, the lessons learned from that were: -A lot more people than you might think find it useful to have a small version control system for thing like the files in /etc. -Just removing features without a discussion is not wise. -IMHO, people wondering about the bloat in the OS should focus on other bigger VCS we carry, namely svn. For all I know, it looks like OpenRCS is the most viable option and can completely replace the old RCS we have in base. I have objected this in 2013 because OpenRCS did not pass GNU RCS's test suite: https://lists.freebsd.org/pipermail/freebsd-current/2013-October/045185. html More specifically: + : -Dhas_conf_h + : cc + : diff + CL='cc -Dhas_conf_h -o a.out' + L='' + RCSINIT=-x + export RCSINIT + SLASH=/ + RCSfile=RCS/a.c + RCS_alt=RCS/a.d + lockfile=RCS/a._ + q=-q + test -d RCS + rmdir=rmdir + mkdir RCS + rm -f 'a.*' RCS/a.c RCS/a.d RCS/a._ + echo 1.1 + echo 1.1.1.1 + echo 1.2 + diff -c a.11 a.3x1 + diff='diff -c' + rcs -i -L -ta.11 -q a.c + test -r RCS/a.c + rlog a.c + rm -f RCS/a.c + cp a.11 a.c + ci -ta.11 -mm -q a.c + test -r RCS/a.c + rcs -L -q a.c + test ! -f a.c + co -q a.c + test -f a.c + diff -c a.11 a.c + co -l -q a.c + test -f a.c + diff -c a.11 a.c + cp a.12 a.c + ci -mm -q a.c + co -q a.c + diff -c a.12 a.c + rm -f a.c + co -r1.1 -q a.c + diff -c a.11 a.c + rm -f a.c + cp a.3x1 a.c + ci -r1.1.1 -mm -q a.c ci: RCS/a.c: no lock set by delphij + echo '#branches failed' #branches failed + exit 1 The checkout as of today ported to FreeBSD still does not pass the test cases, so I still object the replacement unless the issues have been taken care of. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.1.2 (FreeBSD) iQIcBAEBCgAGBQJVS8j7AAoJEJW2GBstM+nsUR4P/1X9hvotuBLzjgY1S6389HJP 3FXoT0+xjJqW0L6Ke5wGJy01Q3awJBGG6OUgSYufZhg32uIwPbLmKKouUuscPj/p 77e+EdonjkNcKIDYurtL8ifLm6bhPUvuWX4JSPcy8SBZtehqXUF0s4WdLqISGXpM t8iJ56AoGAffQAHEAeHzJDxf41+7Jdb8aw314aFyAAcrcH2Q3giuo6QH75psGoSy 0X3BLu7Wi0eADcTgvLps6eJ6Uwwt+FbCKFySqkNeiXy9+LRnNg8lGUyzHp1gwSJW 5KQ9l+8vFabnAkwVZWkwnZ0mFZRRu24Ui97nwfLOrv0fDYflZIcmfEQQUHTZNp5Z zsZEulU9MZDA10LgNvIAr4rsDDa41HOY3KA89rGuWXQpxZUOwzibWNnNfHOJIW9c b4rGJ+femjr5wllvjG3vURGS6mkPvtLt7e/nO4pAZ+ev06KBLQAp+qd3RCjFPMRw +cFpFXwSN+O2e6aQbYLduk18UAJFLkZf/1tH1AaO4pnjxyM3liZeE5oeIVoqUVMu 2iNNyb15Vk7dJL2DIam1MSX4UA+mCLgsJ6m+SIbigB6zYusUm2vPbDkx+e82fnhu QlXml8k+ZQjZm6nZl45l2yaRmhRyIVq2b4GgiC6zG/WUfn4mSju83gI2hEfuGqhj VgaTuJMDK6pjCpTKfA/B =di1X -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Race VT+X11 on -current
On May 7, 2015, at 09:43, Kevin Oberman rkober...@gmail.com wrote: On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky h...@selasky.org wrote: Hi, Sometimes when logging into X11 the keyboard input is not working. Pressing ALT+F9 makes it work. Any idea where the race is? --HPS Actually, I have found that switching to ANY other terminal (e.g. ALT-F2) and back to vty1 does the job. I must admit that this is a pretty minor annoyance, so I never got around to reporting it. Still, any bug report should show that it impacts multiple users. Speaking of which, please file a bug for this issue so it doesn't get lost! Thanks, -NGie ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What to do about RCS/OpenRCS
On Thu, 7 May 2015, Pedro Giffuni wrote: Unfortunately I don't use RCS enough (it looks like I should though) so I am not in a good position to take the next step and deal with any fallout it may produce. If we can have a build-knob to disable GNU RCS and enable the new one I will happily twist up the new version and hammer on it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What to do about RCS/OpenRCS
On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org wrote: Hello; On 05/07/15 14:56, Lyndon Nerenberg wrote: On Thu, 7 May 2015, Pedro Giffuni wrote: Unfortunately I don't use RCS enough (it looks like I should though) so I am not in a good position to take the next step and deal with any fallout it may produce. If we can have a build-knob to disable GNU RCS and enable the new one I will happily twist up the new version and hammer on it. Yes, that's usually the next step in the process. It is a little bit messy because there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and perhaps something else that we don't use). I really want to check out first if there is some strong opinion against OpenRCS. Perhaps someone that has used it before and thinks it is a bad idea. It looks like there are voices against it, so those have to be addressed first. Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs bits); check with jhb first to make sure that OpenRCS works with etcupdate. Cheers! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What to do about RCS/OpenRCS
Il giorno 08/mag/2015, alle ore 00:26, Doug Brewer brewer.d...@gmail.com ha scritto: On Thu, May 07, 2015 at 04:18:38PM -0700, NGie Cooper wrote: On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org mailto:p...@freebsd.org wrote: Hello; On 05/07/15 14:56, Lyndon Nerenberg wrote: On Thu, 7 May 2015, Pedro Giffuni wrote: Unfortunately I don't use RCS enough (it looks like I should though) so I am not in a good position to take the next step and deal with any fallout it may produce. If we can have a build-knob to disable GNU RCS and enable the new one I will happily twist up the new version and hammer on it. Yes, that's usually the next step in the process. It is a little bit messy because there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and perhaps something else that we don't use). I really want to check out first if there is some strong opinion against OpenRCS. Perhaps someone that has used it before and thinks it is a bad idea. It looks like there are voices against it, so those have to be addressed first. Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs bits); check with jhb first to make sure that OpenRCS works with etcupdate. Confirmed. Pedro, are you also willing to fix fallout as Xin Li pointed out? If not, please revert, thanks. I haven’t committed anything to base so there’s nothing to revert (?). Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Race VT+X11 on -current
Hi,
I have a fix, attached.
I'll just throw this in if nobody objects. Seems like a trivial issue:
Prevent switching to NULL or own window in the vt_proc_window_switch
function. This fixes an issue where X11 keyboard input can appear
stuck. The cause of the problem is a duplicate TTY device window
switch IOCTL during boot, which leaves the vt_switch_timer running,
because the current window is already selected. While at it factor out
some NULL checks.
PR: 200032
Reported by:multiple people
MFC after: 1 week
--HPS
Index: vt_core.c
===
--- vt_core.c (revision 282504)
+++ vt_core.c (working copy)
@@ -451,9 +451,22 @@
struct vt_device *vd;
int ret;
+ /* Prevent switching to NULL */
+ if (vw == NULL) {
+ DPRINTF(30, %s: Cannot switch to NULL., __func__);
+ return (EINVAL);
+ }
vd = vw-vw_device;
curvw = vd-vd_curwindow;
+ /*
+ * Prevent switching to self to avoid starting the
+ * vt_switch_timer() again:
+ */
+ if (vw == curvw) {
+ DPRINTF(30, %s: Cannot switch to self., __func__);
+ return (0);
+ }
if (curvw-vw_flags VWF_VTYLOCK)
return (EBUSY);
@@ -664,8 +677,7 @@
if (console == 0) {
if (c = F_SCR c = MIN(L_SCR, F_SCR + VT_MAXWINDOWS - 1)) {
vw = vd-vd_windows[c - F_SCR];
- if (vw != NULL)
-vt_proc_window_switch(vw);
+ vt_proc_window_switch(vw);
return;
}
VT_LOCK(vd);
@@ -750,8 +762,7 @@
if (c = F_SCR c = MIN(L_SCR, F_SCR + VT_MAXWINDOWS - 1)) {
vw = vd-vd_windows[c - F_SCR];
- if (vw != NULL)
-vt_proc_window_switch(vw);
+ vt_proc_window_switch(vw);
return (0);
}
@@ -760,15 +771,13 @@
/* Switch to next VT. */
c = (vw-vw_number + 1) % VT_MAXWINDOWS;
vw = vd-vd_windows[c];
- if (vw != NULL)
-vt_proc_window_switch(vw);
+ vt_proc_window_switch(vw);
return (0);
case PREV:
/* Switch to previous VT. */
c = (vw-vw_number - 1) % VT_MAXWINDOWS;
vw = vd-vd_windows[c];
- if (vw != NULL)
-vt_proc_window_switch(vw);
+ vt_proc_window_switch(vw);
return (0);
case SLK: {
vt_save_kbd_state(vw, kbd);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD #2742
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2742/changes Changes: [adrian] Add initial memory locality cost awareness to the VM, and include a basic ACPI SLIT table parser. For now this just exports the map via sysctl; it'll eventually be useful to userland when there's more useful NUMA support in -HEAD. * Add an optional mem_locality map; * add a mapping function taking from/to domain and returning the relative cost, or -1 if it's not available; * Add a very basic SLIT parser to x86 ACPI. Differential Revision: https://reviews.freebsd.org/D2460 Reviewed by:rpaulo, stas, jhb Sponsored by: Norse Corp, Inc (hardware, coding); Dell (hardware) [delphij] MFV r282611: netcat from OpenBSD 5.7. MFC after: 2 weeks -- [...truncated 277250 lines...] --- drm_dma.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/sys/GENERIC/opt_global.h -I. -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/sys/GENERIC -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=iso 9899:1999 -c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys/modules/drm2/drm2/../../../dev/drm2/drm_dma.c -o drm_dma.o --- all_subdir_i915kms --- ctfconvert -L VERSION -g i915_gem_context.o --- all_subdir_drm --- ctfconvert -L VERSION -g drm_mm.o --- drm_pci.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/sys/GENERIC/opt_global.h -I. -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/sys/GENERIC -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=iso 9899:1999 -c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys/modules/drm/drm/../../../dev/drm/drm_pci.c -o drm_pci.o --- all_subdir_drm2 --- --- i915_gem_execbuffer.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/sys/GENERIC/opt_global.h -I. -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/obj/builds/FreeBSD_HEAD/sys/GENERIC -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -mno-aes -mno-avx -std=iso 9899:1999 -c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c -o i915_gem_execbuffer.o --- all_subdir_drm2 --- ctfconvert -L VERSION -g drm_dma.o --- all_subdir_dtrace --- --- dtmalloc.o --- cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys/cddl/compat/opensolaris -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys/cddl/contrib/opensolaris/uts/common -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/sys -DHAVE_KERNEL_OPTION_HEADERS -include
Re: What to do about RCS/OpenRCS
On Thu, May 07, 2015 at 04:18:38PM -0700, NGie Cooper wrote: On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni p...@freebsd.org wrote: Hello; On 05/07/15 14:56, Lyndon Nerenberg wrote: On Thu, 7 May 2015, Pedro Giffuni wrote: Unfortunately I don't use RCS enough (it looks like I should though) so I am not in a good position to take the next step and deal with any fallout it may produce. If we can have a build-knob to disable GNU RCS and enable the new one I will happily twist up the new version and hammer on it. Yes, that's usually the next step in the process. It is a little bit messy because there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and perhaps something else that we don't use). I really want to check out first if there is some strong opinion against OpenRCS. Perhaps someone that has used it before and thinks it is a bad idea. It looks like there are voices against it, so those have to be addressed first. Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs bits); check with jhb first to make sure that OpenRCS works with etcupdate. Confirmed. Pedro, are you also willing to fix fallout as Xin Li pointed out? If not, please revert, thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What to do about RCS/OpenRCS
Hello; On 05/07/15 14:56, Lyndon Nerenberg wrote: On Thu, 7 May 2015, Pedro Giffuni wrote: Unfortunately I don't use RCS enough (it looks like I should though) so I am not in a good position to take the next step and deal with any fallout it may produce. If we can have a build-knob to disable GNU RCS and enable the new one I will happily twist up the new version and hammer on it. Yes, that's usually the next step in the process. It is a little bit messy because there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and perhaps something else that we don't use). I really want to check out first if there is some strong opinion against OpenRCS. Perhaps someone that has used it before and thinks it is a bad idea. It looks like there are voices against it, so those have to be addressed first. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: nmount, mountd drops high order MNT_xx flags during a mount update
Doug Rabson wrote: You could add a single integer-valued vfsopt which holds the high-order bits of f_flags? Yes, that sounds better than any of my ideas. I'll code up a patch and put it up for review unless someone has a better solution. Thanks Doug, rick On 7 May 2015 at 02:10, Rick Macklem rmack...@uoguelph.ca wrote: David Boyd reported a problem to freebsd-current@ w.r.t. the MNT_AUTOMOUNTED flag getting cleared by mountd. http://docs.FreeBSD.org/cgi/mid.cgi?1429477202.29812.38.camel I just took a look at this and it's kinda ugly... mountd acquires a list of mounts via getmntinfo() and then does an nmount() for each of them to get rid of any exports. It uses f_flags from the statfs returned by getmntinfo() as the 3rd argument to nmount(). -- Since nmount()s 3rd argument is a int, it silently drops any MNT_xx flag in the high order 32bits of f_flags. At this time, it happens that MNT_AUTOMOUNTED is the only one, but... I can think of a couple of ways to fix this, but I don't like any of them;-) 1) I suppose mountd could check for each flag set in f_flags and generate a vfsopts string for it, but that means that every time a new flag that can be updated is added to MNT_xx, this mountd.c code would have to updated. -- Ugly!! 2) Require that all flags in MNT_UPDATEMASK be in the low order 32bits. I wouldn`t mind this except in means that the MNT_xx flags must be redefined and I don`t think that could get MFC`d. 3) Add a new newernmount(2) which has a 64bit flags argument instead of int. Hopefully someone can think of a nice way to fix this, rick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Race VT+X11 on -current
On 05/07/15 22:00, Hans Petter Selasky wrote: On 05/07/15 20:23, Garrett Cooper wrote: On May 7, 2015, at 09:43, Kevin Oberman rkober...@gmail.com wrote: On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky h...@selasky.org wrote: Hi, Sometimes when logging into X11 the keyboard input is not working. Pressing ALT+F9 makes it work. Any idea where the race is? --HPS Actually, I have found that switching to ANY other terminal (e.g. ALT-F2) and back to vty1 does the job. I must admit that this is a pretty minor annoyance, so I never got around to reporting it. Still, any bug report should show that it impacts multiple users. Speaking of which, please file a bug for this issue so it doesn't get lost! Thanks, -NGie Hi, Here it is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200032 --HPS Hi, It might look like you can reproduce like this: 1) Boot computer into GDM / slim. 2) Wait more than 15 seconds. 3) Keyboard appears frozen. 4) Press ALT+F9 5) Keyboard works again. If waiting less than 15 seconds everything is fine. Might be related to vw_proc_dead_timer in VT. I'll debug more tomorrow. Seems trivial. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
hastd fail and panic on MAXPHYS=1m
Hi all, I have problem with MAXPHYS=1m. (I don't know MAXPHYS=1m works on HAST.) I put options MAXPHYS=(1024*1024) in kernel config. Then, update primary node to the kernel and world. If the role back to primary on the machine, writing to the hast device cause an error and panic. I didn't check carefully, but it seems that geom_gate.ko use MAXPHYS=1m and hastd use MAXPHYS=128k. Of course, secondary is MAXPHYS=128k at this time. Is it an expected result? Here is a log while manually mounted test: [DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b240) Request received from the kernel: READ(163840, 28672). [DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b240) Moving request to the send queues. [DEBUG][2] [hast1] (primary) ggate_recv: Taking free request. [DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b1f0) Gotg_vfs_done():hast/hast1p1[WRITE(offset=174784512, length=393216)]error = 6 /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem /mnt: got error 6 while accessing filesystem free request. [DEBUG][2] [hast1] (primary) ggate_recv: (0x20c4b1f0) Waiting for request from the kernel. [DEBUG][2] [hast1] (primary) local_send: (0x20c4b240) Got request. [DEBUG][2] [hast1] (primary) local_send: (0x20c4b240) Moving request to the done queue. [DEBUG][2] [hast1] (primary) [DEBUG][2] [hast1] (primary) ggate_send: (0x20c4b240) Got request. local_send: Taking request. [DEBUG][2] [hast1] (primary) ggate_send: (0x20c4b240) Moving request to the free queue. [DEBUG][2] [hast1] (primary) ggate_send: Taking request. [ERROR] [hast1] (primary) G_GATE_CMD_START failed: Cannot allocate memory. [DEBUG][1] Unable to receive event header: Socket is not connected. softdep_deallocate_dependencies: got error 6 while accessing filesystem /dev: got error 6 while accessing filesystem panic: brelvp: Buffer 0xb33129d0 not on queue. cpuid = 3 KDB: enter: panic -- Daisuke Aoyama ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Race VT+X11 on -current
On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky h...@selasky.org wrote: Hi, Sometimes when logging into X11 the keyboard input is not working. Pressing ALT+F9 makes it work. Any idea where the race is? --HPS Actually, I have found that switching to ANY other terminal (e.g. ALT-F2) and back to vty1 does the job. I must admit that this is a pretty minor annoyance, so I never got around to reporting it. Still, any bug report should show that it impacts multiple users. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is back to stable : FreeBSD_HEAD-tests2 #1011
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/1011/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Race VT+X11 on -current
Hi, Sometimes when logging into X11 the keyboard input is not working. Pressing ALT+F9 makes it work. Any idea where the race is? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
