NetBSD Problem Report #40322

From www@NetBSD.org  Sat Jan  3 08:30:55 2009
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id DF87663BA1C
	for <gnats-bugs@gnats.netbsd.org>; Sat,  3 Jan 2009 08:30:55 +0000 (UTC)
Message-Id: <20090103083055.A1A3D63B8C6@narn.NetBSD.org>
Date: Sat,  3 Jan 2009 08:30:55 +0000 (UTC)
From: mm_lists@pulsar-zone.net
Reply-To: mm_lists@pulsar-zone.net
To: gnats-bugs@NetBSD.org
Subject: netbsd-5: xorg destroys console
X-Send-Pr-Version: www-1.0

>Number:         40322
>Notify-List:    rafal@netbsd.org, mrg@netbsd.org
>Category:       xsrc
>Synopsis:       netbsd-5: xorg destroys console
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    xsrc-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 03 08:35:00 +0000 2009
>Last-Modified:  Mon May 18 03:10:03 +0000 2009
>Originator:     Matthew Mondor
>Release:        netbsd-5
>Organization:
>Environment:
NetBSD hal.xisop 5.0_BETA NetBSD 5.0_BETA (GENERIC_MM) #1: Thu Jan  1 22:39:44 EST 2009  root@hal.xisop:/usr/obj/sys/arch/i386/compile/GENERIC_MM i386

>Description:
Using the rage128 driver with netbsd-5 xorg, whenever X11 is started console becomes blank and remains blank.  Thus, switching VT or exiting X11 leaves an unusable system until reboot.  This did not occur with XFree86 on netbsd-4 using the "ati" driver, but occurs with Xorg using the "rage128" driver.

        BoardName   "Rage 128 PF/PRO AGP 4x TMDS"

Moreover, an Radeon card I tried as an alternative also has the same problem, using the "radeon" driver.

        BoardName   "Radeon R100 QD [Radeon 7200]"

This happens weither DRI is used or not.
This appears somewhat related to xsrc/23352.
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:
From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: xsrc/40322: netbsd-5: xorg destroys console
Date: Tue, 10 Feb 2009 05:05:56 -0500

 Interestingly, I noticed that what happens is almost black text on
 black background.  A tool, sysutils/vbetool is able to reset the console
 via its post option,  so this appears less serious than it seemed.

 It still could be considered an xorg bug however since xfree86 did not
 have this problem, with the same hardware (and its 2d accelerated
 drivers).
 -- 
 Matt

From: Rafal Boni <rafal@pobox.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: xsrc/40322
Date: Thu, 16 Apr 2009 14:41:29 -0400

 Adding another instance of this from the now-closed-as-duplicate xsrc/40606:

 	(on a i386 dual-Pentium-III / 440BX system running 5.0_RC3 + xorg
          r128 driver)

         Switching VTs from an X session back to a text-mode console session
         is broken on this machine; occasionally switching to the text VT will
 	give purple character cells with horizontal lines scattered all over
 	the screen (some blinking, some not); other times the screen will
 	simply be blank.

         Occasionally switching to the text VT will give purple character cells
         with horizontal lines scattered all over the screen (some blinking,
         some not); other times the screen will simply be blank.  Note that
 	when I ran with DRM enabled for the card, the failure mode was of
 	the 'screen is empty' on X -> text console transisiton just about
 	100% of the time... ie, I didn't see the purple junk like before.

         vbetool-0.7.1nb2 is able to restore the screen OK, although with
         some artifacts remaining (see xsrc/40606).

         The video card details from kernel messages look like the following:

 [...]
 pci0 at mainbus0 bus 0: configuration mode 1
 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
 pchb0 at pci0 dev 0 function 0
 pchb0: vendor 0x8086 product 0x7190 (rev. 0x03)
 agp0 at pchb0: aperture at 0xe0000000, size 0x10000000
 ppb0 at pci0 dev 1 function 0: vendor 0x8086 product 0x7191 (rev. 0x03)
 pci1 at ppb0 bus 1
 pci1: i/o space, memory space enabled
 vga1 at pci1 dev 0 function 0: vendor 0x1002 product 0x5246 (rev. 0x00)
 wsdisplay0 at vga1 kbdmux 1: console (80x25, vt100 emulation), using wskbd0
 wsmux1: connecting to wsdisplay0
 drm at vga1 not configured
 [...]

 	Per Joerg Sonnenberger's suggestion, I ran the X server in 16bpp
 	mode which elimited the blank-screen issues, and mostly restored
 	the text-mode screen correctly, with the exception of the font..
 	Typing characters showed them appear in the right places, and
 	output from commands would appear in the right places, but all
 	character cells were junk patterns vs. empty cells / actual
 	character glyphs.  Joerg things this points to this being the
 	same issue that was once fixed in the XFree86 tree's ati / r128
 	driver.

 --rafal

 -- 
   Time is an illusion; lunchtime, doubly so.     |/\/\|           Rafal Boni
                    -- Ford Prefect               |\/\/|      rafal@pobox.com

From: Rafal Boni <rafal@pobox.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: xsrc/40322
Date: Thu, 16 Apr 2009 23:17:53 -0400

 At least for the r128 driver, the problem is that the driver is built without
 VGAHW support, so it doesn't appear to do any VGA-state restoration.  To see
 if you are having the same problem, look for the following message in your
 Xorg log:

 	VGAHW support not compiled, VGA module load skipped

 The following patch makes it build with VGAHW support -- that build restores
 the console state on VT switch just fine on my i386 / r128 test machine I
 had the initial trouble with (see earlier comments and the now-closed-as-dup
 xsrc/40606).  Ignore the commented out CPPFLAGS; that requires more work to
 get a correct config.h generated for the r128 driver, which for the purposes
 of getting this fixed is largely un-necessary even if it might be the better
 fix.

 I suspect other drivers have the same issue, but haven't audited which ones
 depend on WITH_VGAHW and don't define it in Makefiles / get it via one of
 xorg-config.h / xorg-server.h

 --rafal

 ---8<------8<------8<------8<------8<------8<------8<------8<------8<---
 diff --git a/external/mit/xorg/server/drivers/xf86-video-r128/Makefile b/external/mit/xorg/server/drivers/xf86-video-r128/Makefile
 index 2105d57..d6bf27c 100644
 --- a/external/mit/xorg/server/drivers/xf86-video-r128/Makefile
 +++ b/external/mit/xorg/server/drivers/xf86-video-r128/Makefile
 @@ -8,4 +8,7 @@ SRCS=	r128_accel.c r128_cursor.c r128_dga.c r128_driver.c \

  MAN=	r128.4

 +#CPPFLAGS+=	-DHAVE_CONFIG_H -I${X11SRCDIR.${DRIVER}}/../include
 +CPPFLAGS+=	-DWITH_VGAHW
 +
  .include "../Makefile.xf86-driver"
 ---8<------8<------8<------8<------8<------8<------8<------8<------8<---

 -- 
   Time is an illusion; lunchtime, doubly so.     |/\/\|           Rafal Boni
                    -- Ford Prefect               |\/\/|      rafal@pobox.com

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: rafal@netbsd.org, xsrc-manager@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, mm_lists@pulsar-zone.net
Subject: re: xsrc/40322
Date: Fri, 17 Apr 2009 16:41:09 +1000

 WITH_VGAHW only exists in ati and r128 drivers.

 thanks for figuring this one out.


 .mrg.

From: Michael <macallan@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: xsrc/40322
Date: Fri, 17 Apr 2009 13:39:42 -0400

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 We don't want VGAHW support on most non-x86 platforms, namely =20
 sparc(64) and macppc. Or rather, it's useless on machines that never =20
 use VGA text mode.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (Darwin)

 iQEVAwUBSei+38pnzkX8Yg2nAQLH1wgAsVeiDOApQvxqqP12CDBA08p37Ima/QQS
 41hwO/tuGAQKNCYIdcZv0p5qswyyIxAjoDymQbPZlZQfGr8HCGHe7beZNezTH5jb
 qBOB1s5eS2qSRqgdxHFfrogvYZE+NQ98Cvun9XeUvxw5b1orzE7xsfejCaKLxAdR
 Tr80M6mEmyTiXlcjPJMEEKn3Fh2OeLquic0P1earQ9rttrgeqIT44KqFNf5rlgQM
 sA0dClQ3h+9GUNuDaqJcnbFJVhbSrlF9ku0tm4Zd6dh+3OyLjo9/0U4W7ygSvX0j
 pKuXyp43n7GwgQhrVJ9Cj3pibmlCew6u2P8vsrOjpLzr72STA3nTcg=3D=3D
 =3DfA8y
 -----END PGP SIGNATURE-----

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: xsrc/40322
Date: Fri, 17 Apr 2009 19:29:46 -0400

 Unfortunately I can't test this anymore as I gave away the r128 card
 when I replaced it with a radeon one shortly after submitting this PR.
 -- 
 Matt

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: xsrc/40322 (netbsd-5: xorg destroys console)
Date: Sun, 17 May 2009 21:18:30 -0400

 I just looked now and it seems that the radeon driver doesn't have this
 VGAHW support.  I'm not sure if the solution would be to also include
 support for this in it or if a more general solution can be found.
 Should VGA be reset for all drivers in the case of i386?  If so, this
 code could probably be from the ATI drivers to another location...

 -- 
 Matt

From: Rafal Boni <rafal@pobox.com>
To: gnats-bugs@NetBSD.org
Cc: xsrc-manager@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	mm_lists@pulsar-zone.net, rafal@netbsd.org, mrg@netbsd.org
Subject: Re: xsrc/40322 (netbsd-5: xorg destroys console)
Date: Sun, 17 May 2009 23:05:00 -0400

 On Mon, May 18, 2009 at 02:15:05AM +0000, Matthew Mondor wrote:
 > The following reply was made to PR xsrc/40322; it has been noted by GNATS.
 > 
 > From: Matthew Mondor <mm_lists@pulsar-zone.net>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: xsrc/40322 (netbsd-5: xorg destroys console)
 > Date: Sun, 17 May 2009 21:18:30 -0400
 > 
 >  I just looked now and it seems that the radeon driver doesn't have this
 >  VGAHW support.  I'm not sure if the solution would be to also include
 >  support for this in it or if a more general solution can be found.
 >  Should VGA be reset for all drivers in the case of i386?  If so, this
 >  code could probably be from the ATI drivers to another location...

 I think the radeon / ati driver picks up VGAHW support via a #define in
 xorg-server.h which is included from it's local config.h

 I've tested the radeon driver with a radeon 9200 agp and while it still has
 the 'dark font on console restore' issue that the r128 driver also has in
 non-16-bpp modes (I've been meaning to look at this in more depth at some
 point, but haven't gotten the round-tuits), but otherwise restore VGA mode
 fine.

 To your latter point, I think Jared McNeill has convinced me that The Right
 Thing is to make the vga(4) driver restore proper text mode settings when
 it gets control from the X server again.. but again, I haven't had the time
 to look at this.  Certainly Linux takes this path (hence the wealth of text-
 mode restore bugs resulting from "All the world's a Linux" mindset ;)) and
 I've been told that OpeBSD does as well, so there's likely code there we can
 steal.  I won't preach further until I have something to show off ;)

 --rafal

 -- 
   Time is an illusion; lunchtime, doubly so.     |/\/\|           Rafal Boni
                    -- Ford Prefect               |\/\/|      rafal@pobox.com

>Unformatted:

Home	PR Database Search