Re: Race VT+X11 on -current
On 05/11/15 21:52, Ed Maste wrote: On 10 May 2015 at 13:14, Hans Petter Selasky wrote: Your patch is correct from what I can see. Signed modulus can be creepy sometimes! Better if VT_MAXWINDOWS was power of two and we used a bitwise AND. The patch is correct, although signedness doesn't come into play. The unsigned vw_number just wraps to 2^32-1, which is 3 modulo 12. FYI: https://svnweb.freebsd.org/changeset/base/283187 --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: Race VT+X11 on -current
On 10 May 2015 at 13:14, Hans Petter Selasky wrote: > > Your patch is correct from what I can see. Signed modulus can be creepy > sometimes! Better if VT_MAXWINDOWS was power of two and we used a bitwise > AND. The patch is correct, although signedness doesn't come into play. The unsigned vw_number just wraps to 2^32-1, which is 3 modulo 12. ___ 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/10/15 19:00, Oliver Pinter wrote: Hi Hans! > Hi, Sounds good. I'll MFC the patch sometime next week. Seems like more people need it for daily FreeBSD use :-) I have this fix or enhancements in our HardenedBSD codebase: https://github.com/HardenedBSD/hardenedBSD/commit/18058137da01598403b6ffa40c37b0a907441530 Please review them, and if you feel this required in FreeBSD too, and cherry-pick them. Hi Oliver, Your patch is correct from what I can see. Signed modulus can be creepy sometimes! Better if VT_MAXWINDOWS was power of two and we used a bitwise AND. https://svnweb.freebsd.org/changeset/base/282730 --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: Race VT+X11 on -current
Hi Hans! On 5/10/15, Hans Petter Selasky wrote: > On 05/10/15 18:53, Wolfgang Zenker wrote: >> Hi, >> >> * Hans Petter Selasky [150510 14:47]: >>> On 05/09/15 23:05, Wolfgang Zenker wrote: * Allan Jude [150508 16:29]: > [..] > My experience is a little different. >> > When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) >> > Sometimes when I resume, it seems like the keyboard is frozen. If I > alt+f1, then alt+f9, it seems to work fine after that. I'd never > though > of trying just alt+f9 right away, as I could already see my X session. >> > Not sure if this is related, but it sounds very similar. >> Similar problem on 10-STABLE: I usually start X by running startx on ttyv0. After exiting X screen shows ttyv0 again but keyboard appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to ttyv1 and back "unfreezes" keyboard. >> >>> Can you try applying to 10-stable: >> >>> https://svnweb.freebsd.org/changeset/base/282645 >> >> Patch needs a little tweaking to apply in vt_resume() on 10-stable >> (vd is main_vd here), but appears to fix the problem. >> > > Hi, > > Sounds good. I'll MFC the patch sometime next week. Seems like more > people need it for daily FreeBSD use :-) I have this fix or enhancements in our HardenedBSD codebase: https://github.com/HardenedBSD/hardenedBSD/commit/18058137da01598403b6ffa40c37b0a907441530 Please review them, and if you feel this required in FreeBSD too, and cherry-pick them. > > --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" > ___ 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/10/15 18:53, Wolfgang Zenker wrote: Hi, * Hans Petter Selasky [150510 14:47]: On 05/09/15 23:05, Wolfgang Zenker wrote: * Allan Jude [150508 16:29]: [..] My experience is a little different. When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) Sometimes when I resume, it seems like the keyboard is frozen. If I alt+f1, then alt+f9, it seems to work fine after that. I'd never though of trying just alt+f9 right away, as I could already see my X session. Not sure if this is related, but it sounds very similar. Similar problem on 10-STABLE: I usually start X by running startx on ttyv0. After exiting X screen shows ttyv0 again but keyboard appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to ttyv1 and back "unfreezes" keyboard. Can you try applying to 10-stable: https://svnweb.freebsd.org/changeset/base/282645 Patch needs a little tweaking to apply in vt_resume() on 10-stable (vd is main_vd here), but appears to fix the problem. Hi, Sounds good. I'll MFC the patch sometime next week. Seems like more people need it for daily FreeBSD use :-) --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: Race VT+X11 on -current
Hi, * Hans Petter Selasky [150510 14:47]: > On 05/09/15 23:05, Wolfgang Zenker wrote: >> * Allan Jude [150508 16:29]: >>> [..] >>> My experience is a little different. >>> When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) >>> Sometimes when I resume, it seems like the keyboard is frozen. If I >>> alt+f1, then alt+f9, it seems to work fine after that. I'd never though >>> of trying just alt+f9 right away, as I could already see my X session. >>> Not sure if this is related, but it sounds very similar. >> Similar problem on 10-STABLE: I usually start X by running startx >> on ttyv0. After exiting X screen shows ttyv0 again but keyboard >> appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to >> ttyv1 and back "unfreezes" keyboard. > Can you try applying to 10-stable: > https://svnweb.freebsd.org/changeset/base/282645 Patch needs a little tweaking to apply in vt_resume() on 10-stable (vd is main_vd here), but appears to fix the problem. Wolfgang ___ 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/09/15 23:05, Wolfgang Zenker wrote: * Allan Jude [150508 16:29]: [..] My experience is a little different. When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) Sometimes when I resume, it seems like the keyboard is frozen. If I alt+f1, then alt+f9, it seems to work fine after that. I'd never though of trying just alt+f9 right away, as I could already see my X session. Not sure if this is related, but it sounds very similar. Similar problem on 10-STABLE: I usually start X by running startx on ttyv0. After exiting X screen shows ttyv0 again but keyboard appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to ttyv1 and back "unfreezes" keyboard. Can you try applying to 10-stable: https://svnweb.freebsd.org/changeset/base/282645 --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: Race VT+X11 on -current
* Allan Jude [150508 16:29]: > [..] > My experience is a little different. > When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) > Sometimes when I resume, it seems like the keyboard is frozen. If I > alt+f1, then alt+f9, it seems to work fine after that. I'd never though > of trying just alt+f9 right away, as I could already see my X session. > Not sure if this is related, but it sounds very similar. Similar problem on 10-STABLE: I usually start X by running startx on ttyv0. After exiting X screen shows ttyv0 again but keyboard appears frozen. Using ctrl-alt-f2 and ctrl-alt-f1 to switch to ttyv1 and back "unfreezes" keyboard. Wolfgang ___ 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 2015-05-08 06:07, Hans Petter Selasky wrote: > On 05/08/15 11:56, Garrett Cooper wrote: >> >>> On May 7, 2015, at 21:34, Hans Petter Selasky wrote: >>> >>> 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 >> >> Hi Hans, >> Can you please toss that up on phabricator? >> Thanks! >> -NGie > > If it helps getting the stuff committed ... > > https://reviews.freebsd.org/D2480 > > --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" My experience is a little different. When suspend/resuming my laptop (Lenovo T530 with nVidia gpu) Sometimes when I resume, it seems like the keyboard is frozen. If I alt+f1, then alt+f9, it seems to work fine after that. I'd never though of trying just alt+f9 right away, as I could already see my X session. Not sure if this is related, but it sounds very similar. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Race VT+X11 on -current
On 05/08/15 11:56, Garrett Cooper wrote: On May 7, 2015, at 21:34, Hans Petter Selasky wrote: 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 Hi Hans, Can you please toss that up on phabricator? Thanks! -NGie If it helps getting the stuff committed ... https://reviews.freebsd.org/D2480 --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: Race VT+X11 on -current
> On May 7, 2015, at 21:34, Hans Petter Selasky wrote: > > 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 Hi Hans, Can you please toss that up on phabricator? 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: 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"
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 wrote: On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky 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"
Re: Race VT+X11 on -current
On 05/07/15 20:23, Garrett Cooper wrote: On May 7, 2015, at 09:43, Kevin Oberman wrote: On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky 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: Race VT+X11 on -current
> On May 7, 2015, at 09:43, Kevin Oberman wrote: > >> On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky 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: Race VT+X11 on -current
On Thu, May 7, 2015 at 5:39 AM, Hans Petter Selasky 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"
