NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
xsrc/51736: wsfb driver uses revoked descriptors
>Number: 51736
>Category: xsrc
>Synopsis: wsfb driver uses revoked descriptors
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: xsrc-manager
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Dec 23 00:15:00 +0000 2016
>Originator: Michael van Elst
>Release: NetBSD 7.99.51
>Organization:
>Environment:
System: NetBSD tazz 7.99.51 NetBSD 7.99.51 (TAZZ) #3: Mon Dec 19 00:59:32 CET 2016 mlelstv@gossam:/home/netbsd-current/obj.amd64/home/netbsd-current/src/sys/arch/amd64/compile/TAZZ amd64
Architecture: x86_64
Machine: amd64
>Description:
The standard setup with xdm is to run X on vt04 which is /dev/ttyE4.
The wsfb driver however falls back to /dev/ttyE0 unless there is
also a driver option set in xorg.conf that specifies /dev/ttyE4.
When xdm is started when the system is booted, it therefore uses
the wrong terminal to map the framebufer or to control the screen
saver. This works until getty is launched on that terminal which
revokes every open file descriptor.
The consequence are X crashes, mixup between wscons and X11 display,
and/or lacking functionality.
Restarting xdm solves the problem until you log into /dev/ttyE0
which revokes /dev/ttyE0 again.
>How-To-Repeat:
Boot a machine using wsfb and xdm enabled in rc.conf
>Fix:
Tell wsfb to use /dev/ttyE4 with an option in xorg.conf like:
Section "Device"
Driver "wsfb"
Option "device" "/dev/ttyE4"
EndSection "Device"
The real fix is of course to teach wsfb to find out the "virtual terminal"
parameter to the X server and deduce the correct device from that.
Home |
Main Index |
Thread Index |
Old Index