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:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 22 17:35:01 +0000 2014
>Closed-Date:    
>Last-Modified:  Sat Jun 20 10:13:26 +0000 2015
>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


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.40 2014/08/02 14:16:04 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.