From rhh@pagesz.net  Fri Jan 15 17:48:03 1999
Received: from nina.pagesz.net (nina.pagesz.net [208.194.157.3])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA16898
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 15 Jan 1999 17:48:02 -0800 (PST)
          (envelope-from rhh@pagesz.net)
Received: from stealth.dummynet. (juana-30.pagesz.net [208.213.126.30])
	by nina.pagesz.net (8.8.7/8.8.7) with ESMTP id UAA01488;
	Fri, 15 Jan 1999 20:48:10 -0500
Received: (from rhh@localhost)
	by stealth.dummynet. (8.9.1/8.8.8) id UAA00908;
	Fri, 15 Jan 1999 20:28:59 -0500 (EST)
	(envelope-from rhh)
Message-Id: <199901160128.UAA00908@stealth.dummynet.>
Date: Fri, 15 Jan 1999 20:28:59 -0500 (EST)
From: aa8vb@pagesz.net
Reply-To: aa8vb@pagesz.net
To: FreeBSD-gnats-submit@freebsd.org
Cc: aa8vb@pagesz.net
Subject: VESA Console Lock-ups
X-Send-Pr-Version: 3.2

>Number:         9520
>Category:       kern
>Synopsis:       VESA Console Lock-ups
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 15 17:50:00 PST 1999
>Closed-Date:    Sat Feb 6 03:25:54 PST 1999
>Last-Modified:  Sat Feb  6 03:27:31 PST 1999
>Originator:     Randall Hopper
>Release:        FreeBSD 3.0-RELEASE i386
>Organization:
self
>Environment:

	Stock 3.0-RELEASE.  VESA and VM86 options in compiled into kernel.

        VESA: v1.2, 4096k memory, flags:0x1, mode table:0xf00c4c64 (c0004c64)
        VESA: STB Velocity 3D (S3 86C988)
        sc0 at 0x60-0x6f irq 1 on motherboard
        sc0: VGA color <16 virtual consoles, flags=0x0>

>Description:

	I like the new VESA support!  However, if I'm not careful I can
	lock my system pretty easily.  For example, switch ttyv0 to
	132x43, then Alt-F2 over to ttyv1.  Instant lock.  If I switch
	all the ttys over to the same mode before a tty switch (via 
	vidcontrol < /dev/ttyv1 132x40, etc.) then tty switches seem
	to work OK.  However if I try to switch ttyv0 back to 80x60 while
	ttyv0 is active, I hit another lock up.

	BTW, I'd sure like to do 132x60 on my 21" but it says 
	"not supported" (though that's what it says when you haven't loaded 
	the right font.  I've loaded an 8x8 font and can do 80x60.  Any 
	tricks to getting this to work?

>How-To-Repeat:

	Alt-F1
	vidcontrol 132x60
	Alt-F2

>Fix:
	
	Unknown.

	--Thanks.


>Release-Note:
>Audit-Trail:

From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
To: aa8vb@pagesz.net
Cc: FreeBSD-gnats-submit@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: kern/9520: VESA Console Lock-ups 
Date: Sat, 16 Jan 1999 18:38:58 +0900

 >>Number:         9520
 >>Category:       kern
 >>Synopsis:       VESA Console Lock-ups
 [...]
 >>Release:        FreeBSD 3.0-RELEASE i386
 >>Organization:
 >self
 >>Environment:
 >
 >	Stock 3.0-RELEASE.  VESA and VM86 options in compiled into kernel.
 >
 >        VESA: v1.2, 4096k memory, flags:0x1, mode table:0xf00c4c64 (c0004c64)
 >        VESA: STB Velocity 3D (S3 86C988)
 >        sc0 at 0x60-0x6f irq 1 on motherboard
 >        sc0: VGA color <16 virtual consoles, flags=0x0>
 >
 >>Description:
 >
 >	I like the new VESA support!  However, if I'm not careful I can
 >	lock my system pretty easily.  For example, switch ttyv0 to
 >	132x43, then Alt-F2 over to ttyv1.  Instant lock.  If I switch
 >	all the ttys over to the same mode before a tty switch (via 
 >	vidcontrol < /dev/ttyv1 132x40, etc.) then tty switches seem
 >	to work OK.  However if I try to switch ttyv0 back to 80x60 while
 >	ttyv0 is active, I hit another lock up.
 
 Is it actually lockup?  Does the system beeps when you type anything
 after switching to ttyv0?
 
 I wonder if it is possible to type Alt-F1 to get back to ttyv0...
 
 I have some theory and will send you a patch shortly.
 
 >	BTW, I'd sure like to do 132x60 on my 21" but it says 
 >	"not supported" (though that's what it says when you haven't loaded 
 >	the right font.  I've loaded an 8x8 font and can do 80x60.  Any 
 >	tricks to getting this to work?
 
 Type
 	vidcontrol -i mode
 and you will see supported video modes.  If 132x60 is not listed,
 there is no way to get that mode, I am afraid.
 
 Kazu
 yokota@FreeBSD.ORG

From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
To: aa8vb@pagesz.net
Cc: FreeBSD-gnats-submit@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: kern/9520: VESA Console Lock-ups 
Date: Sat, 16 Jan 1999 19:27:39 +0900

 In my previous mail to you, I wrote:
 
 >>>Number:         9520
 >>>Category:       kern
 >>>Synopsis:       VESA Console Lock-ups
 >[...]
 >>>Release:        FreeBSD 3.0-RELEASE i386
 >>>Organization:
 >>self
 >>>Environment:
 >>
 >>	Stock 3.0-RELEASE.  VESA and VM86 options in compiled into kernel.
 [...]
 >>	I like the new VESA support!  However, if I'm not careful I can
 >>	lock my system pretty easily.  For example, switch ttyv0 to
 >>	132x43, then Alt-F2 over to ttyv1.  Instant lock.  If I switch
 >>	all the ttys over to the same mode before a tty switch (via 
 >>	vidcontrol < /dev/ttyv1 132x40, etc.) then tty switches seem
 >>	to work OK.  However if I try to switch ttyv0 back to 80x60 while
 >>	ttyv0 is active, I hit another lock up.
 >
 >Is it actually lockup?  Does the system beeps when you type anything
 >after switching to ttyv0?
 >
 >I wonder if it is possible to type Alt-F1 to get back to ttyv0...
 >
 >I have some theory and will send you a patch shortly.
 
 Ok, here is the patch. It is relative to 3.0-RELEASE.  However, I have
 not tested this patch as I don't have a 3.0-RELEASE box around me at
 the moment.
 
 Apply the patch to /sys/i386/isa/vesa.c and rebuild the kernel.
 
 Please report if it works.
 
 Kazu
 yokota@FreeBSD.ORG
 
 --- vesa.c-1.8	Sat Jan 16 18:55:46 1999
 +++ vesa.c	Sat Jan 16 19:15:31 1999
 @@ -118,11 +118,14 @@
  /* local macros and functions */
  #define BIOS_SADDRTOLADDR(p) ((((p) & 0xffff0000) >> 12) + ((p) & 0x0000ffff))
  
 +static int int10_set_mode(int mode);
  static int vesa_bios_get_mode(int mode, struct vesa_mode *vmode);
  static int vesa_bios_set_mode(int mode);
  static int vesa_bios_set_dac(int bits);
 -static int vesa_bios_save_palette(int start, int colors, u_char *palette);
 -static int vesa_bios_load_palette(int start, int colors, u_char *palette);
 +static int vesa_bios_save_palette(int start, int colors, u_char *palette,
 +				  int bits);
 +static int vesa_bios_load_palette(int start, int colors, u_char *palette,
 +				  int bits);
  #define STATE_SIZE	0
  #define STATE_SAVE	1
  #define STATE_LOAD	2
 @@ -153,6 +156,18 @@
      }
  }
  
 +/* INT 10 BIOS calls */
 +static int
 +int10_set_mode(int mode)
 +{
 +	struct vm86frame vmf;
 +
 +	bzero(&vmf, sizeof(vmf));
 +	vmf.vmf_eax = 0x0000 | mode;
 +	vm86_intcall(0x10, &vmf);
 +	return 0;
 +}
 +
  /* VESA BIOS calls */
  static int
  vesa_bios_get_mode(int mode, struct vesa_mode *vmode)
 @@ -196,11 +211,13 @@
  	vmf.vmf_eax = 0x4f08;
  	vmf.vmf_ebx = (bits << 8);
  	err = vm86_intcall(0x10, &vmf);
 -	return ((err != 0) || (vmf.vmf_eax != 0x4f));
 +	if ((err != 0) || (vmf.vmf_eax != 0x4f))
 +		return 6;	/* XXX */
 +	return ((vmf.vmf_ebx >> 8) & 0x00ff);
  }
  
  static int
 -vesa_bios_save_palette(int start, int colors, u_char *palette)
 +vesa_bios_save_palette(int start, int colors, u_char *palette, int bits)
  {
  	struct vm86frame vmf;
  	u_char *p;
 @@ -220,17 +237,18 @@
  		return 1;
  	}
  
 +	bits = 8 - bits;
  	for (i = 0; i < colors; ++i) {
 -		palette[i*3]     = p[i*4 + 1];
 -		palette[i*3 + 1] = p[i*4 + 2];
 -		palette[i*3 + 2] = p[i*4 + 3];
 +		palette[i*3]     = p[i*4 + 2] << bits;
 +		palette[i*3 + 1] = p[i*4 + 1] << bits;
 +		palette[i*3 + 2] = p[i*4] << bits;
  	}
  	free(p, M_DEVBUF);
  	return 0;
  }
  
  static int
 -vesa_bios_load_palette(int start, int colors, u_char *palette)
 +vesa_bios_load_palette(int start, int colors, u_char *palette, int bits)
  {
  	struct vm86frame vmf;
  	u_char *p;
 @@ -238,11 +256,12 @@
  	int i;
  
  	p = malloc(colors*4, M_DEVBUF, M_WAITOK);
 +	bits = 8 - bits;
  	for (i = 0; i < colors; ++i) {
 -		p[i*4]     = 0;
 -		p[i*4 + 1] = palette[i*3];
 -		p[i*4 + 2] = palette[i*3 + 1];
 -		p[i*4 + 3] = palette[i*3 + 2];
 +		p[i*4]	   = palette[i*3 + 2] >> bits;
 +		p[i*4 + 1] = palette[i*3 + 1] >> bits;
 +		p[i*4 + 2] = palette[i*3] >> bits;
 +		p[i*4 + 3] = 0;
  	}
  
  	bzero(&vmf, sizeof(vmf));
 @@ -664,21 +683,35 @@
  static int
  vesa_save_palette(int ad, u_char *palette)
  {
 -	if ((ad != vesa_adp->va_index) || !(vesa_adp_info->v_flags & V_DAC8) 
 -	    || vesa_bios_set_dac(8))
 -		return (*prevvidsw.save_palette)(ad, palette);
 +	int bits;
 +	int error;
  
 -	return vesa_bios_save_palette(0, 256, palette);
 +	if ((ad == vesa_adp->va_index) && (vesa_adp_info->v_flags & V_DAC8) 
 +	    && ((bits = vesa_bios_set_dac(8)) > 6)) {
 +		error = vesa_bios_save_palette(0, 256, palette, bits);
 +		if (error == 0)
 +			return 0
 +		vesa_bios_set_dac(6);
 +	}
 +
 +	return (*prevvidsw->save_palette)(ad, palette);
  }
  
  static int
 -vesa_load_palette(int ad, u_char *palette)
 +vesa_load_palette(video_adapter_t *adp, u_char *palette)
  {
 -	if ((ad != vesa_adp->va_index) || !(vesa_adp_info->v_flags & V_DAC8) 
 -	    || vesa_bios_set_dac(8))
 -		return (*prevvidsw.load_palette)(ad, palette);
 +	int bits;
 +	int error;
 +
 +	if ((ad == vesa_adp->va_index) && (vesa_adp_info->v_flags & V_DAC8) 
 +	    && ((bits = vesa_bios_set_dac(8)) > 6)) {
 +		error = vesa_bios_load_palette(0, 256, palette, bits);
 +		if (error == 0)
 +			return 0
 +		vesa_bios_set_dac(6);
 +	}
  
 -	return vesa_bios_load_palette(0, 256, palette);
 +	return (*prevvidsw->load_palette)(ad, palette);
  }
  
  static int

From: Randall Hopper <aa8vb@pagesz.net>
To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/9520: VESA Console Lock-ups
Date: Sat, 16 Jan 1999 08:02:18 -0500

 Kazutaka YOKOTA:
  |
  |>>Number:         9520
  |>>Category:       kern
  |>>Synopsis:       VESA Console Lock-ups
  |>>Release:        FreeBSD 3.0-RELEASE i386
  |>>Description:
  |>
  |>	I like the new VESA support!  However, if I'm not careful I can
  |>	lock my system pretty easily.  For example, switch ttyv0 to
  |>	132x43, then Alt-F2 over to ttyv1.  Instant lock.  If I switch
  |>	all the ttys over to the same mode before a tty switch (via 
  |>	vidcontrol < /dev/ttyv1 132x40, etc.) then tty switches seem
  |>	to work OK.  However if I try to switch ttyv0 back to 80x60 while
  |>	ttyv0 is active, I hit another lock up.
  |
  |Is it actually lockup?  Does the system beeps when you type anything
  |after switching to ttyv0?
 
 Seems to be a lock-up.  The system doesn't beep when I type anything.
 Ctrl-Alt-Del and Alt-F? produce no change in the corrupted display.  Now,
 the machine may not be net dead -- I didn't try telneting in from another
 box on the net, but the console at least is toast.
 
  |I wonder if it is possible to type Alt-F1 to get back to ttyv0...
 
 No, sorry.  I tried that.
 
  |I have some theory and will send you a patch shortly.
 
 Thank you.  I see it here and will test it this morning.  
 
  |>	BTW, I'd sure like to do 132x60 on my 21" but it says 
  |>	"not supported" (though that's what it says when you haven't loaded 
  |>	the right font.  I've loaded an 8x8 font and can do 80x60.  Any 
  |>	tricks to getting this to work?
  |
  |Type
  |	vidcontrol -i mode
  |and you will see supported video modes.  If 132x60 is not listed,
  |there is no way to get that mode, I am afraid.
 
 It appears that 132x43 is as good as I can get with VESA.
 
 Thanks,
 
 Randall

From: Randall Hopper <aa8vb@pagesz.net>
To: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/9520: VESA Console Lock-ups
Date: Sat, 16 Jan 1999 15:46:46 -0500

 --HcAYCG3uE/tztfnV
 Content-Type: text/plain; charset=us-ascii
 
 Kazutaka YOKOTA:
  |Ok, here is the patch. It is relative to 3.0-RELEASE.  However, I have
  |not tested this patch as I don't have a 3.0-RELEASE box around me at
  |the moment.
  |
  |Apply the patch to /sys/i386/isa/vesa.c and rebuild the kernel.
  |
  |Please report if it works.
 
 After a few syntax tweaks (updated patch attached), I got the kernel built.
 Unfortunately it still locks up.  
 
 Also, I tried telneting in and pinging from another box.  No response.  So
 it's a hard system lock and not just behavior isolated to syscons.
 
  |>Seems to be a lock-up.  The system doesn't beep when I type anything.
  |>Ctrl-Alt-Del and Alt-F? produce no change in the corrupted display.  Now,
  |>the machine may not be net dead -- I didn't try telneting in from another
  |>box on the net, but the console at least is toast.
  |
  |How did the screen look?  How corrupted?  Wrong palette colors?
  |Garbage characters?
 
 Well, it seems like once I saw the characters from the old virtual screen
 at the new resolution on the tty switch.  So I guess not really corrupted.
 Just not the right chars displayed on the right screen.  But that could be
 because of where it locked.
 
 The colors looked fine BTW.  I have a color syscons prompt, and it was
 still yellow and green w/ black background.  Rest of the screen was gray
 and white.  Both sets of colors are correct.
 
 Randall
 
 --HcAYCG3uE/tztfnV
 Content-Type: application/octet-stream
 Content-Disposition: attachment; filename="patch.new.gz"
 Content-Transfer-Encoding: base64
 
 H4sICFSToDYAA3BhdGNoLm5ldwDVVm1v2kgQ/rz+FRNVimxsJ15DXBOSKLRwJ+7aIhWai+4U
 WY5fWkuAkW24qE3/+82uX9hggzh6Ot1ZIJbZxzvPzjwzu7quw/jj6OfzdZC6Zx6ZflnB2MsA
 KJjty455SbtAu11bUlUVCszEzeAXdwHUAsO+NOnlhc0wXen2FnRKbY1SUPlvB25vJThvwSz2
 3BnMXS+JU3AXPoSrhZdF8SKF1rkEr/wgjBYBvBmNJ86kPxh8nI7fsR95qYCMD/6cgvEU4mPg
 o8DNDVBTARWqOWZn84oigaSmmZtFHkSLjH2p4aRB5sxjP5CZiQ2UngQCiu3NeYzi1Pm8jdQQ
 l6y8AsMs0FrvXeJwZwzpux4HPkZZikC9GeiuA2fpzoIsy5dFVJJpHOXFszhJNVg53hc3gVYB
 27nWLHb9v7+W+k/x0iSV4AMgbLp58SOINi1e6Wsy7U+HzmT0+5AYNWv/bkjotvXduD8gZq7s
 i7ZmobAvLI3aXNjs+S6xj6SiyEcfpkANLmJAuc+4toWNSeouKUrqN6RdqmxuW2HizgMchRgZ
 nHn8GiSxfIr/UYvR1yAOZRwrLG4EB2f4dQL3Ca6LOoBnvm4+bVsOOmKEZOOJGhqwdfirSZCt
 kgUYOP6Oflih3g0n/a0dCMKVjiuTPHxdizcGk1KNtnn8atw7oWH3RPsjs8ssjXB1BTbLJQmS
 BI2796WX+5JlBj3BhRV4fgZZ9HaSu8tDGIWHYZm0irWtHsFo3d/f8xxvPIrMsUfZZW8KGTOu
 FDGc+o/Vt6T+WB1uakSCbxjZZgECqd7r8UyapqHR15jJ9uuyEqq4UIbnBUF41q7BBp37YBNh
 nIAcsVT3IIKrglgPVDVSkIFOSEHtj6jVfuD1dQ1L/NPBTk8felsIbhQQZhPCFBHtB5bvfV4Q
 jkrLCat7vdF9yI1XAcUjQ8IkCOSlBu+dwfDuzaefuKg3pbhPJMc0blEkx/TTY0XSzu8BJmuX
 Zi4Sfhr32PbIEsMzx9KNPTl33OpsIsJGv/VH0/GvvDyPE1Ie+zy5Rq8yVVkUJPBi1tyaFZRX
 iaiGMAtdcackF9S2HrAdbMSyg0puakJu02pGcWpGWYOw5+BgObKsjmZijiy7rbUveI5qvb7W
 V1y/QWM85ryNuj7rl/xV11/qN2sXu7QfPPG2eiKXE2gMY5x1wpn7OcUmeecM+m+xXeI6LGcI
 rl+SbGzBetVq5NYyCdbryE//PBNZKjKjKNxbSKngcoytPk7yk7XkfN3M+fQUDqCscsoMKxda
 beQON2ApTJ6YME7hJVAMNJ5mrHCgKsLymkQ44+Jtdlrx645wkBNS923xN5kiqrPxML/iLeHQ
 cO/oX7XW06gjtY6F/6zoRJr/U9G9iPS/KLp9fneJbl+4a6L7CxJC8djYDgAA
 
 --HcAYCG3uE/tztfnV--
State-Changed-From-To: open->closed 
State-Changed-By: yokota 
State-Changed-When: Sat Feb 6 03:25:54 PST 1999 
State-Changed-Why:  
The problem has been fixed in 4.0-CURRENT and RELENG_3.  The PR originator 
reports that the back-ported patch worked for home. 
>Unformatted:
