NetBSD Problem Report #49495
From www@NetBSD.org Mon Dec 22 17:33:42 2014
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id A529AA6528
for <gnats-bugs@gnats.NetBSD.org>; Mon, 22 Dec 2014 17:33:42 +0000 (UTC)
Message-Id: <20141222173341.B2777A6554@mollari.NetBSD.org>
Date: Mon, 22 Dec 2014 17:33:41 +0000 (UTC)
From: prlw1@cam.ac.uk
Reply-To: prlw1@cam.ac.uk
To: gnats-bugs@NetBSD.org
Subject: serial console prevents use of X with drmkms
X-Send-Pr-Version: www-1.0
>Number: 49495
>Category: kern
>Synopsis: serial console prevents use of X with drmkms
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: riastradh
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Dec 22 17:35:01 +0000 2014
>Closed-Date: Sat Aug 26 10:33:02 +0000 2023
>Last-Modified: Sat Aug 26 10:33:02 +0000 2023
>Originator: Patrick Welche
>Release: NetBSD-7.99.3/amd64
>Organization:
>Environment:
18 December -current code (but the issue is old - I don't remember ever being able to use a serial console and X with drmkms)
>Description:
Given a working -current + native X, try "consdev com0" at the boot
prompt. Now the monitor will remain blank. Everything seems to be in a "working" state - X process and xdm are running, no errors in messages
nor Xorg.0.log. Just no visible output.
(Happens to be an ivy bridge.)
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: re: kern/49495: serial console prevents use of X with drmkms
Date: Tue, 23 Dec 2014 05:09:24 +1100
sure you haven't forgotten to adjust /etc/wscons.conf to create
ttyE0?
i've been using drmkms with radeon and serial console for months.
.mrg.
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/49495: serial console prevents use of X with drmkms
Date: Mon, 22 Dec 2014 18:29:02 +0000
On Mon, Dec 22, 2014 at 06:10:01PM +0000, matthew green wrote:
> sure you haven't forgotten to adjust /etc/wscons.conf to create
> ttyE0?
My /etc/wscons.conf looks like
...
screen 0 - vt100
screen 1 - vt100
screen 2 - vt100
screen 3 - vt100
screen 4 80x50 vt100
screen 5 80x50 vt100
screen 6 80x50 vt100
screen 7 - -
...
so that should do?
/etc/ttys has
console "/usr/libexec/getty Pc" vt100 on secure
constty "/usr/libexec/getty Pc" vt100 off secure
ttyE0 "/usr/libexec/getty Pc" wsvt25 off secure
...
ttyE7 "/usr/libexec/getty Pc" wsvt25 off secure
/etc/rc.d/xdm stop hangs...
From: matthew green <mrg@eterna.com.au>
To: Patrick Welche <prlw1@cam.ac.uk>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: re: kern/49495: serial console prevents use of X with drmkms
Date: Tue, 23 Dec 2014 06:36:33 +1100
Patrick Welche writes:
> On Mon, Dec 22, 2014 at 06:10:01PM +0000, matthew green wrote:
> > sure you haven't forgotten to adjust /etc/wscons.conf to create
> > ttyE0?
>
> My /etc/wscons.conf looks like
> ...
> screen 0 - vt100
> screen 1 - vt100
> screen 2 - vt100
> screen 3 - vt100
> screen 4 80x50 vt100
> screen 5 80x50 vt100
> screen 6 80x50 vt100
> screen 7 - -
> ...
> so that should do?
hmmm, mine has just this for screens:
screen 0 - vt100
screen 1 - vt100
screen 2 - vt100
screen 3 - vt100
screen 4 - -
and screen4 is where X will run, and 0-3 are gettys:
constty "/usr/libexec/getty std.115200" vt100 on secure
ttyE0 "/usr/libexec/getty Pc" vt220 on secure
ttyE1 "/usr/libexec/getty Pc" vt220 on secure
ttyE2 "/usr/libexec/getty Pc" vt220 on secure
ttyE3 "/usr/libexec/getty Pc" vt220 on secure
that gives me a login: prompt on the serial console as well as
4 virtual terminal logins on the display and then X runs on the
5th...
this setup works for me with drmkms, but i've only got radeon
PCI cards for testing here.
is this i386 or amd64? can you confirm that you only have one
wsdisplay (wsdisplay0) and that wskbd0 and wsmux1 connect to it?
.mrg.
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/49495: serial console prevents use of X with drmkms
Date: Wed, 24 Dec 2014 03:20:54 -0600 (CST)
I have experienced the same problem on my Dell Optiplex GX260 w/I82845GL
graphics. As long as the console is the video display it works. If
the console is the serial port, the video display is disabled. ISTR
this is deliberate, but I would rather it be otherwise. I also seem to
recall that it worked in the distant past. Later, the display would
stay on, but no text would appear. Now, the video output is disabled.
The /etc/ttys file on this machine:
#
# from: @(#)ttys 5.1 (Berkeley) 4/17/89
# $NetBSD: ttys,v 1.20 2012/06/13 20:49:13 martin Exp $
#
# name getty type status comments
#
console "/usr/libexec/getty Pc" vt100 off secure
constty "/usr/libexec/getty Pc" vt100 off secure
ttyE0 "/usr/libexec/getty Pc" wsvt25 on secure
ttyE1 "/usr/libexec/getty Pc" wsvt25 on secure
ttyE2 "/usr/libexec/getty Pc" wsvt25 on secure
ttyE3 "/usr/libexec/getty Pc" wsvt25 on secure
tty00 "/usr/libexec/getty std.9600" vt100 on secure
tty01 "/usr/libexec/getty std.9600" unknown off secure
tty02 "/usr/libexec/getty std.9600" unknown off secure
tty03 "/usr/libexec/getty std.9600" unknown off secure
tty04 "/usr/libexec/getty std.9600" unknown off secure
tty05 "/usr/libexec/getty std.9600" unknown off secure
tty06 "/usr/libexec/getty std.9600" unknown off secure
tty07 "/usr/libexec/getty std.9600" unknown off secure
With the display operating (console on video), starting X panics the
machine immediately. With display on serial port, starting X spins
forever looking for an active display, which it never finds, since all
video outputs were disabled when booting w/serial console.
I've never seen a description/man page for "constty". I'd always set
up my "/etc/ttys" file as shown above to keep getty and xconsole from
fighting each other over "/dev/console". Should I be using "constty"
instead?
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: "John D. Baker" <jdbaker@mylinuxisp.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/49495: serial console prevents use of X with drmkms
Date: Wed, 24 Dec 2014 03:54:28 -0600 (CST)
I should also have mentioned that with serial console (video output
disabled by i915drmkms), one may still log in blindly at the PC keyboard.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: Patrick Welche <prlw1@cam.ac.uk>
To: matthew green <mrg@eterna.com.au>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: Re: kern/49495: serial console prevents use of X with drmkms
Date: Fri, 26 Dec 2014 11:03:13 +0000
On Tue, Dec 23, 2014 at 06:36:33AM +1100, matthew green wrote:
> that gives me a login: prompt on the serial console as well as
> 4 virtual terminal logins on the display and then X runs on the
> 5th...
Just for the record, I also have
:0 local /usr/X11R7/bin/X :0 -noretro vt08
in /etc/X11/xdm/Xservers - which is why I have screen 7 - -
> this setup works for me with drmkms, but i've only got radeon
> PCI cards for testing here.
Would I be right in guessing that if the above were wrong, X without
the serial console wouldn't work? (It works without the serial console)
> is this i386 or amd64? can you confirm that you only have one
> wsdisplay (wsdisplay0) and that wskbd0 and wsmux1 connect to it?
That is on amd64 with
$ dmesg | grep ws
wskbd0 at pckbd0: console keyboard
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
wsmux1: connecting to wsdisplay0
spdmem0: 12 rows, 13 cols, 8 log. banks, 2 phys. banks, 1.500ns cycle time
spdmem1: 12 rows, 13 cols, 8 log. banks, 2 phys. banks, 1.500ns cycle time
wsmouse0 at ums0 mux 0
wsdisplay0: screen 1 added (default, vt100 emulation)
wsdisplay0: screen 2 added (default, vt100 emulation)
wsdisplay0: screen 3 added (default, vt100 emulation)
wsdisplay0: screen 7 added (default, vt100 emulation)
Also:
i915drmkms0 at pci0 dev 2 function 0: Intel Ivy Bridge Integrated Graphics Device (rev. 0x09)
Now on a different machine: a Dell OptiPlex GX620 (as opposed to GX260)
running 25 Dec -current/amd64 with an additional radeon card, X works
with the serial console => this must be an intel specific problem.
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/49495: serial console prevents use of X with drmkms
Date: Fri, 9 Jan 2015 16:07:28 +0000
Just tried a simple experiment on the pineview of PR 49285:
boot debug kernel with cons=pc
boot debug kernel with cons=com0
diff /var/run/dmesg.boot
Slightly trimmed output is:
@@ -93,7 +92,7 @@
WARNING: module error: vfs load failed for `acpiverbose', error 45
pckbd0 at pckbc1 (kbd slot)
pckbc1: using irq 1 for kbd slot
-wskbd0 at pckbd0: console keyboard
+wskbd0 at pckbd0 mux 1
pms0 at pckbc1 (aux slot)
pms0: synaptics_probe: Not synaptics.
pckbc1: using irq 12 for aux slot
@@ -270,7 +269,7 @@
DRM debug in drm_framebuffer_reference: FB ID: 39
intelfb0 at i915drmkms0
intelfb0: WARNING: power management not supported
-DRM debug in intelfb_create: allocated 1920x1080 fb: 0x00030000, bo 0xfffffe8043b058c0
+DRM debug in intelfb_create: allocated 1920x1080 fb: 0x00030000, bo 0xfffffe8043ac68c0
i915drmkms0: info: registered panic notifier
intelfb0: framebuffer at 0xffff800024b8b000, size 1920x1080, depth 32, stride 7680
DRM debug in intel_crtc_cursor_set: cursor off
@@ -386,11 +385,14 @@
DRM debug in drm_framebuffer_reference: FB ID: 39
DRM debug in drm_framebuffer_unreference: FB ID: 39
DRM debug in drm_framebuffer_reference: FB ID: 39
-wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
+wsdisplay0 at intelfb0 kbdmux 1
wsmux1: connecting to wsdisplay0
+wskbd0: connecting to wsdisplay0
+genfb0 at pci0 dev 2 function 1WARNING: module error: vfs load failed for `pciverbose', error 45
WARNING: module error: vfs load failed for `pciverbose', error 45
-WARNING: module error: vfs load failed for `pciverbose', error 45
-vendor 8086 product a002 (miscellaneous display, revision 0x02) at pci0 dev 2 function 1 not configured
+: vendor 8086 product a002 (rev. 0x02)
+no width property
+genfb0: not configured by firmware
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at ioapic0 pin 16
hdafg0 at hdaudio0 vendor 0x10EC product 0x0662 nid 0x01WARNING: module error: vfs load failed for `hdaudioverbose', error 45
@@ -518,6 +520,7 @@
isa0 at ichlpcib0
lpt0 at isa0 port 0x378-0x37b irq 7
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
+com0: console
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
acpicpu0 at cpu0: ACPI CPU
so genfb0 appears appears in the output - connection to PR/46376 ?
Difference from original ivy bridge report (must try again with newer code)
is that rather than a blank screen, I see 5 small copies of the xdm prompt
arranged horizontally and flashing.
From: Patrick Welche <prlw1@cam.ac.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/49495: serial console prevents use of X with drmkms
Date: Fri, 9 Jan 2015 16:36:50 +0000
> so genfb0 appears appears in the output - connection to PR/46376 ?
genfb is a red herring - the same corrupt output occurs after
+userconf: configure system autoconfiguration:
+uc> disable genfb
+[ 97] genfb* disabled
-wskbd0 at pckbd0: console keyboard
+wskbd0 at pckbd0 mux 1
-DRM debug in intelfb_create: allocated 1920x1080 fb: 0x00030000, bo 0xfffffe8043b058c0
+DRM debug in intelfb_create: allocated 1920x1080 fb: 0x00030000, bo 0xfffffe8043ac68c0
-wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation), using
+wskbd0
+wsdisplay0 at intelfb0 kbdmux 1
wsmux1: connecting to wsdisplay0
+wskbd0: connecting to wsdisplay0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
+com0: console
Responsible-Changed-From-To: kern-bug-people->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Thu, 14 May 2015 00:22:09 +0000
Responsible-Changed-Why:
mine
State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 14 May 2015 00:22:09 +0000
State-Changed-Why:
feedback requested
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: Patrick Welche <prlw1@cam.ac.uk>
Subject: Re: xsrc/49495
Date: Thu, 14 May 2015 00:23:19 +0000
This is a multi-part message in MIME format.
--=_j4H1Dtu0UMIkgkrRSI18P508xTD6/eku
[resent to gnats-bugs, hoping that's the right address for PR followup]
Can you please try running the attached program and seeing whether
anything shows up on your display?
make writefb
./writefb /dev/ttyE0 0xff350053
(Run as root; this will permanently set ttyE0 into dumbfb mode, unless
you write another program that puts it back into text mode.)
This will determine whether the problem is just with the kernel
driver, or whether X is actually involved too.
--=_j4H1Dtu0UMIkgkrRSI18P508xTD6/eku
Content-Type: text/plain; charset="ISO-8859-1"; name="writefb"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="writefb.c"
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <sys/time.h>
#include <dev/wscons/wsconsio.h>
#include <err.h>
#include <errno.h>
#include <fcntl.h>
#include <limits.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>
#define howmany(n, d) (((n) + ((d) - 1)) / (d))
#define roundup(n, d) (howmany(n, d) * (d))
static void
signal_ignore(int signo __unused)
{
}
int
main(int argc, char **argv)
{
const char *device;
char *ep;
unsigned long value;
int fd;
struct wsdisplay_fbinfo fbi;
unsigned int mode;
size_t fbsize;
uint32_t *fb;
size_t i;
setprogname(argv[0]);
if (signal(SIGPIPE, &signal_ignore) =3D=3D SIG_ERR)
err(1, "signal(SIGPIPE)");
if (argc !=3D 3)
errx(1, "Usage: %s <device> <value>\n", getprogname());
device =3D argv[1];
errno =3D 0;
value =3D strtoul(argv[2], &ep, 0);
if ((argv[2][0] =3D=3D '\0') || (*ep !=3D '\0'))
errx(1, "bad value");
if ((errno =3D=3D ERANGE) && (value =3D=3D ULONG_MAX))
errx(1, "value too large");
fd =3D open(argv[1], O_RDWR);
if (fd =3D=3D -1)
err(1, "open fb");
if (ioctl(fd, WSDISPLAYIO_GINFO, &fbi) =3D=3D -1)
err(1, "ioctl(WSDISPLAYIO_GINFO)");
warnx("width %u", fbi.width);
warnx("height %u", fbi.height);
warnx("depth %u", fbi.depth);
warnx("cmsize %u", fbi.cmsize);
if (fbi.depth !=3D 32)
errx(1, "bad depth");
if (ioctl(fd, WSDISPLAYIO_GMODE, &mode) =3D=3D -1)
err(1, "ioctl(WSDISPLAYIO_GMODE)");
warnx("mode %u", mode);
mode =3D WSDISPLAYIO_MODE_DUMBFB;
if (ioctl(fd, WSDISPLAYIO_SMODE, &mode) =3D=3D -1)
err(1, "ioctl(WSDISPLAYIO_SMODE)");
fbsize =3D roundup((fbi.width * fbi.height * howmany(fbi.depth, 8)),
getpagesize());
fb =3D mmap(NULL, fbsize, (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd, 0);
if (fb =3D=3D MAP_FAILED)
err(1, "mmap fb");
for (i =3D 0; i < (fbsize / 4); i++)
fb[i] =3D value;
if (munmap(fb, fbsize) =3D=3D -1)
err(1, "munmap fb");
if (close(fd) =3D=3D -1)
err(1, "close fb");
return 0;
}
--=_j4H1Dtu0UMIkgkrRSI18P508xTD6/eku--
From: Patrick Welche <prlw1@cam.ac.uk>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: xsrc/49495
Date: Mon, 1 Jun 2015 16:28:53 +0100
On Thu, May 14, 2015 at 12:23:19AM +0000, Taylor R Campbell wrote:
> [resent to gnats-bugs, hoping that's the right address for PR followup]
>
> Can you please try running the attached program and seeing whether
> anything shows up on your display?
>
> make writefb
> ./writefb /dev/ttyE0 0xff350053
>
> (Run as root; this will permanently set ttyE0 into dumbfb mode, unless
> you write another program that puts it back into text mode.)
>
> This will determine whether the problem is just with the kernel
> driver, or whether X is actually involved too.
I reproduced the no X with serial console problem on a Dell OptiPlex GX620
without extra radeon card, i.e., with a
i915drmkms0 at pci0 dev 2 function 0: Intel 82945G/P Integrated Graphics Device (rev. 0x02)
From ttyE0, without serial console, without X running:
# ./writefb /dev/ttyE0 0xff350053
writefb: width 1024
writefb: height 768
writefb: depth 32
writefb: cmsize 256
writefb: mod 0
and the background went purple (!)
This is the same as the output of xdpyinfo on this particular setup.
(With serial console, I can't get to ttyE0 - all is black (Out of Range
on this monitor), if I ssh in, I get the same result)
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Patrick Welche <prlw1@cam.ac.uk>
Cc: gnats-bugs@NetBSD.org
Subject: Re: xsrc/49495
Date: Mon, 1 Jun 2015 17:16:40 +0000
Date: Mon, 1 Jun 2015 16:28:53 +0100
From: Patrick Welche <prlw1@cam.ac.uk>
I reproduced the no X with serial console problem on a Dell OptiPlex GX6=
20
without extra radeon card, i.e., with a
i915drmkms0 at pci0 dev 2 function 0: Intel 82945G/P Integrated Graphi=
cs Device (rev. 0x02)
Great, thanks!
>From ttyE0, without serial console, without X running:
# ./writefb /dev/ttyE0 0xff350053
writefb: width 1024
writefb: height 768
writefb: depth 32
writefb: cmsize 256
writefb: mod 0
and the background went purple (!)
This is intentional. Intentional purple is the best kind.
...I think I see the problem: when console is serial, genfb steals the
display registers for some reason. If you disable genfb at pci, does
it work?
(I'm not yet sure why this is happening: I don't think I ever needed
to disable genfb at pci. But I haven't had a setup like this to test
in a while.)
From: Patrick Welche <prlw1@cam.ac.uk>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: xsrc/49495
Date: Sun, 7 Jun 2015 10:46:42 +0100
On Mon, Jun 01, 2015 at 05:16:40PM +0000, Taylor R Campbell wrote:
> ...I think I see the problem: when console is serial, genfb steals the
> display registers for some reason. If you disable genfb at pci, does
> it work?
No luck:
$ dmesg | grep fb
[ 53] genfb* disabled
uc> find genfb
[ 53] genfb* at pci? disable dev ? function ?
uc> find intelfb
[107] intelfb* at intelfbbus?
intelfb0 at i915drmkms0
intelfb0: framebuffer at 0xffff800024b20000, size 1024x768, depth 32, stride 4096
wsdisplay0 at intelfb0 kbdmux 1
and the screen is blank :-/
State-Changed-From-To: feedback->open
State-Changed-By: prlw1@NetBSD.org
State-Changed-When: Sat, 20 Jun 2015 10:13:26 +0000
State-Changed-Why:
feedback provided
State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sun, 20 Aug 2023 06:33:42 +0000
State-Changed-Why:
Lotta drm updates and changes to the console attach mechanism,
is this still an issue?
State-Changed-From-To: feedback->closed
State-Changed-By: prlw1@NetBSD.org
State-Changed-When: Sat, 26 Aug 2023 10:33:02 +0000
State-Changed-Why:
I remember having seen the same problem on nouveau, which was fixed by
the changes to the console attach mechanism, and assume it must have
also fixed this problem.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home