Bug 16164

>>Number:         16164
>>Category:       i386
>>Synopsis:       "vga"/"sc" don't work when a video card is not whacked into s
>hape
[...]
>>Release:        FreeBSD 4.0-CURRENT i386
>>Organization:
>The FreeBSD Project
>>Environment:
>
>	It happens with -current as of any time, my AMI BIOS from a few
>months ago (latest), and latest working BIOS (1.20) for my SIIG66 HPT366
>controller.
>
>>Description:
>
>	The HPT366's BIOS makes a highly lame video mode change and things
>are very screwy; the BIOS doesn't reset the video card after that, though
>I don't know if it _should_, and FreeBSD has a cow with it.  The "vga"
>and "sc" devices don't work, VESA fails, and the system isn't usable from the
>console.

I would like to see the output from dmesg when you give "boot -v" to 
boot the system.

What does the HPT366 BIOS do to the screen?  Does it draw some sort of
graphics?  At which point does it do that?  The motherboard AMI BIOS
runs POST and prints something about CPU, serial ports, parallel ports
and PnP device info before looking for a boot device.

>>Fix:
>
>This knocks the video card into shape, and FreeBSD works after it runs.
>This was submitted to me by W. G. Hicks, but a better place should really
>be found for it.  It definitely seems to be necessary.

This patch sets the video mode #3: 80x25 color text.  It is fine
for CGA/EGA/VGA cards, but not good for MDA and Hercules mono cards.
(Well, maybe we shouldn't bother too much about monochrome video cards
nowadays, but they are still in use, I believe.)

Kazu

>Index: i386/boot2/boot1.s
>===================================================================
>RCS file: /usr2/ncvs/src/sys/boot/i386/boot2/boot1.s,v
>retrieving revision 1.10
>diff -u -r1.10 boot1.s
>--- i386/boot2/boot1.s	1999/08/28 00:40:01	1.10
>+++ i386/boot2/boot1.s	2000/01/14 06:53:20
>@@ -58,7 +58,10 @@
> 
> # Bootstrap
> 
>-main:		cld				# String ops inc
>+main:		movb $0x0,%ah
>+		movb $0x3,%al
>+		int $0x10	
>+		cld				# String ops inc
> 		xorl %ecx,%ecx			# Zero
> 		movl %cx,%es			# Address
> 		movl %cx,%ds			#  data

Comment 2 Brian Feldman 2000-01-18 17:32:22 UTC

On Tue, 18 Jan 2000, Kazutaka YOKOTA wrote:

> What does the HPT366 BIOS do to the screen?  Does it draw some sort of
> graphics?  At which point does it do that?  The motherboard AMI BIOS
> runs POST and prints something about CPU, serial ports, parallel ports
> and PnP device info before looking for a boot device.

Yes, but the HPT366 BIOS runs  before it prints all that info.  And
it puts it in some graphics mode for some reason, even though it
_uses_only_color_text_!  Yeesh!  So, it does screw up my screen.

> 
> >>Fix:
> >
> >This knocks the video card into shape, and FreeBSD works after it runs.
> >This was submitted to me by W. G. Hicks, but a better place should really
> >be found for it.  It definitely seems to be necessary.
> 
> This patch sets the video mode #3: 80x25 color text.  It is fine
> for CGA/EGA/VGA cards, but not good for MDA and Hercules mono cards.
> (Well, maybe we shouldn't bother too much about monochrome video cards
> nowadays, but they are still in use, I believe.)

I think jhicks is working on it :)

> 
> Kazu

-- 
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green@FreeBSD.org                    `------------------------------'

On Mon, Jan 17, 2000 at 03:41:08PM -0500, green@FreeBSD.ORG wrote:
> 
> >Number:         16164
> >Category:       i386
> >Synopsis:       "vga"/"sc" don't work when a video card is not whacked into shape
> 
> 	It happens with -current as of any time, my AMI BIOS from a few
> months ago (latest), and latest working BIOS (1.20) for my SIIG66 HPT366
> controller.

hmm.. I have an HPT366 (built into my bp6 motherboard) and it's BIOS
revision is 1.21.
>
> >Description:
> 
> 	The HPT366's BIOS makes a highly lame video mode change and things
> are very screwy; the BIOS doesn't reset the video card after that, though
> I don't know if it _should_, and FreeBSD has a cow with it.  The "vga"
> and "sc" devices don't work, VESA fails, and the system isn't usable from the
> console.

My HPT366 BIOS does the same mode change, but it must switch it back
because I'm not having any problems whatsoever with it:

Preloaded elf kernel "kernel" at 0xc0309000.
VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc02b54c2 (1000022)
VESA: NVidia
vga-pci0: <NVidia Riva TNT graphics accelerator> mem 0xe6000000-0xe6ffffff,0xe40
00000-0xe4ffffff irq 9 at device 0.0 on pci1
[with no error message].

> 	I suppose you have to have the same hardware, or hardware which
> also causes this problem.

My hardware seems similar to yours except for maybe the motherboard and
BIOS revision.

-Chris
-- 
cpiazza@jaxon.net   cpiazza@FreeBSD.org
        Abbotsford, BC, Canada

Comment 4 Søren Schmidt 2001-05-30 10:22:06 UTC

State Changed
From-To: open->closed

I also have one of those SIIG controllers, but everything is fine now in 4.3.