Date: Thu, 18 Jan 2001 01:18:20 -0800 (PST) From: michiel.dewilde@rug.ac.be To: freebsd-gnats-submit@FreeBSD.org Subject: kern/24423: [Fix] syscons VT switching code errors Message-ID: <200101180918.f0I9IKc99980@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 24423
>Category: kern
>Synopsis: [Fix] syscons VT switching code errors
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jan 18 01:20:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Michiel De Wilde
>Release: 4.2-STABLE (actually RELENG_4 as of 2001/01/17)
>Organization:
University of Gent, Belgium
>Environment:
FreeBSD mdw.elis.rug.ac.be 4.2-STABLE FreeBSD 4.2-STABLE #0: Wed Jan 17 17:30:08 CET 2001 root@mdw.elis.rug.ac.be:/usr/src/sys/compile/MDW_20001209_FBSD42_TOSHIBA_SATELLITE_2540CDT i386
>Description:
I ran across these minor errors in syscons:
In src/sys/dev/syscons/syscons.c [rev. 1.336.2.3], lines 954-963:
When using ioctl VT_WAITACTIVE, parameter "data" is checked to see if it
references a valid vty on the same adapter as the vty used for the
request (lines 961-962). This check is "one off", because "data" is
decremented by one later on.
Furthermore, when looking at the code at line 969, I presume a value of
0 was meant to block the calling process until the requesting vty is
activated. The same initial parameter check at lines 961-962 doesn't
like zero, however.
Finally, for conformity with VT_WAITACTIVE, VT_ACTIVATE should also be
adapted to interpret a vty index of zero as "the requesting vty".
In src/usr.sbin/vidcontrol/vidcontrol.c [rev. 1.32] (line 326):
When switching back to VESA mode, "_IO('V', cur_mode - M_VESA_BASE)"
should be used instead of "_IO('V', cur_mode)". Please take a look at
the bottom of include file <sys/consio.h> for the reason why this
should be.
>How-To-Repeat:
syscons.c:
Try to VT_WAITACTIVE the last vty and watch it fail.
vidcontrol.c: (somewhat elaborate, sorry)
Use a machine which hasn't compiled rastered text support into the
kernel. Write an application to switch to some VESA mode and draw
something, and quit the app without restoring text mode. Now you need
vidcontrol to fix things.
Try to switch back to rastered SW_VESA_800x600 using vidcontrol. It will
fail, of course, but to which mode will it switch?
>Fix:
You can apply the following patches (please check for correctness
first, we all make mistakes and I in particular):
First, in plain text (for easy reference). Use the uuencoded versions
below for the real stuff.
=== BEGIN syscons.c.diff
--- src/sys/dev/syscons/syscons.c 2000/10/29 16:59:27 1.336.2.3
+++ src/sys/dev/syscons/syscons.c 2001/01/10 10:14:54
@@ -955,11 +955,14 @@
s = spltty();
sc_clean_up(sc->cur_scp);
splx(s);
- return sc_switch_scr(sc, *(int *)data - 1);
+ if (*(int *)data != 0)
+ return sc_switch_scr(sc, *(int *)data - 1);
+ else
+ return sc_switch_scr(sc, scp->index);
case VT_WAITACTIVE: /* wait for switch to occur */
- if ((*(int *)data >= sc->first_vty + sc->vtys)
- || (*(int *)data < sc->first_vty))
+ if (((*(int *)data > sc->first_vty + sc->vtys)
+ || (*(int *)data <= sc->first_vty)) && (*(int *)data != 0))
return EINVAL;
s = spltty();
error = sc_clean_up(sc->cur_scp);
=== END syscons.c.diff
=== BEGIN vidcontrol.c.diff
--- src/usr.sbin/vidcontrol/vidcontrol.c 2000/01/12 12:30:33 1.32
+++ src/usr.sbin/vidcontrol/vidcontrol.c 2001/01/10 10:04:15
@@ -323,7 +323,7 @@
if (ioctl(0, KDRASTER, size)) {
ioerr = errno;
if (cur_mode >= M_VESA_BASE)
- ioctl(0, _IO('V', cur_mode), NULL);
+ ioctl(0, _IO('V', cur_mode - M_VESA_BASE), NULL);
else
ioctl(0, _IO('S', cur_mode), NULL);
warnc(ioerr, "cannot activate raster display");
=== END vidcontrol.c.diff
Here they are again tar-gzip-uuencoded, because if GNATS chooses to wrap
lines, you'd better use these instead:
begin 644 patch-syscons-vidcontrol.tgz
M'XL(`'^Q9CH``^V5WV_:,!#'>0U_Q:T/;4(28N<'4=.U@FT\H'6=5!A[C#(G
M:)9H@F(#9>L?/R=`!Q5MMX=NVG0?13B)[X[SV?F>6`E6Y*+-VBF?3!HO`B6D
MX_O0`*!A0';'&NJ&'D#H>C3PB!]2]<8+W$X#R,NDL\]<R*0$:-RDV9)/T^PQ
MN^?F_U%LVP91,D>LA)-FBVJLSL-V;#/-)80XE#CN*=!.%)Q&;KC>MK;G==IN
MVVN:IOE\#.JHBQ*@)*)^%/C-;A?LTR"P*`6S'GWH=IN@"3@',9M*N=*-L^J9
MQ6R:)7D\G^F"V1=L7L:"S=9SL^FM+M2MK969G)<Y*&NQY))]53:ELK>@I?-<
M0LM($YF`#519FQJ?@+XW\>H<B*$F`'XO4#85V=-N*E?[@N=I=ENEW*QKQQ*1
MP7@4?^X-1KVWH\&X'X'FM&"9<`F3HH1U#)`%%$PM&%J.6F*5]'[6%ZI4JB03
M7@H9+^0*S/I9W0E#.6AW=P^6^7K?WC`VM7@8]XFPYJ&PYP_CPO'QH0H;:M.J
M`FRJU1]<C7N79P=V/2M+588J[&.[_[>_G/^#!4_5-RK+8OIR+>`9_8=.&-SK
M?T!\->W3T$7]_Q-L]7\NRK;XPG/GYX%P=L_&N@U4$NZJAAUY)/*\;1MP[SO`
MKT39:03$CVA0-P+/]:P0S/50MP&MUB5>,#G5B07OWUWWAJ/^M=)3_BU3^O*]
MMM%XH91"Z83ZS8NSS3OE6.G$39%FE41^B,?]82]^TQOV:U6LW39QX\%'_61\
M8L'6P;#@ZM/E92WN3UNJ'K`;^=ZOSJ'N"W`@PO#@?]66RZ3,F5ZOR((CEN1Y
M(2%ADB\2F4&9")F5D'(ED\GJ"!4001`$01`$01`$01`$01`$01`$01`$V>$'
(88DQ^0`H``"9
`
end
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101180918.f0I9IKc99980>