NetBSD Problem Report #26007
Received: (qmail 8485 invoked by uid 605); 22 Jun 2004 02:54:54 -0000
Message-Id: <200406220253.i5M2rWxe012825@t23.ephemeral.org>
Date: Mon, 21 Jun 2004 22:53:32 -0400 (EDT)
From: rumble@ephemeral.org
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: rumble@ephemeral.org
To: gnats-bugs@gnats.NetBSD.org
Subject: i386 bootstrap fails on via epia 5000 in 2.0/-current
X-Send-Pr-Version: 3.95
>Number: 26007
>Category: port-i386
>Synopsis: i386 bootstrap fails on via epia 5000 in 2.0/-current
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: dsl
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jun 22 02:55:01 +0000 2004
>Closed-Date: Mon Dec 23 22:57:21 +0000 2013
>Last-Modified: Mon Dec 23 22:57:21 +0000 2013
>Originator: Steve Rumble
>Release: NetBSD 2.0_BETA
>Organization:
>Environment:
System: NetBSD t23.ephemeral.org 2.0_BETA NetBSD 2.0_BETA (T23) #10: Sun Jun 13 17:53:30 EDT 2004 rumble@t23.ephemeral.org:/usr/src/sys/arch/i386/compile/T23 i386
Architecture: i386
Machine: i386
>Description:
For some reason the new boot code present in 2.0 and -current
fails to function properly on my VIA Epia 5000 mini-itx board.
While 1.6 works fine, the present code causes the monitor to
attempt to resync like crazy, followed by either an eventual
reboot, or a hard hang.
The screen blanks quickly, but the issue appears to occur either
late in bootxx (past the boot1() function return) or early in boot2.
As a minor datapoint, the pxe boot works fine.
>How-To-Repeat:
Install 2.0 or -current bootstrap onto your favourite media and
attempt to run on a VIA Epia 5000-based system.
>Fix:
Unknown.
>Release-Note:
>Audit-Trail:
From: David Laight <david@l8s.co.uk>
To: rumble@ephemeral.org, netbsd-bugs@netbsd.org
Cc: gnats-bugs@gnats.NetBSD.org
Subject: Re: kern/26007: i386 bootstrap fails on via epia 5000 in 2.0/-current
Date: Wed, 23 Jun 2004 21:08:21 +0100
> >Synopsis: i386 bootstrap fails on via epia 5000 in 2.0/-current
> For some reason the new boot code present in 2.0 and -current
> fails to function properly on my VIA Epia 5000 mini-itx board.
> While 1.6 works fine, the present code causes the monitor to
> attempt to resync like crazy, followed by either an eventual
> reboot, or a hard hang.
>
> The screen blanks quickly, but the issue appears to occur either
> late in bootxx (past the boot1() function return) or early in boot2.
Unfortunately this is impossible to debug without access to the
failing hardware. Even then it may be difficult - as the problem
could easily be a bios bug.
If you are getting out of boot1 (make it return an error if it actually
finds /boot) then a lot of things aren't wrong!
Once the code is running in boot2() (or rather in C code from /boot)
it runs with the real-mode %sp != %esp. The %ss segment is fixedup
on entry/exit real mode so that this all works. But it could easily
have unexpected side effects (the pxe code doesn't do this).
Since there isn't a massive space problem in the boot2 code (not
when %ss != %ds) debugging is only mildly painful!
If you find out exactly when it dies, I might have some suggestions...
David
--
David Laight: david@l8s.co.uk
From: Steve Rumble <rumble@ephemeral.org>
To: rumble@ephemeral.org, netbsd-bugs@netbsd.org, gnats-bugs@gnats.NetBSD.org
Cc: david@l8s.co.uk
Subject: Re: kern/26007: i386 bootstrap fails on via epia 5000 in 2.0/-current
Date: Wed, 23 Jun 2004 22:30:16 -0400
--3V7upXqbjpZ4EhLz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 23, 2004 at 09:08:21PM +0100, David Laight wrote:
> If you are getting out of boot1 (make it return an error if it actually
> finds /boot) then a lot of things aren't wrong!
I've been doing some painfully slow debugging, mainly putting for
(;;); loops in various parts to see if it hard hangs or goes
nuts. So far it looks like it enters boot2(). initio(), which
appears functionally unchanged from 1.6, clears the screen.
That's odd, but it doesn't appear to be what sends the code over
the edge. As far as I can tell it goes berserk on the first printf
statement (print_banner()).
I've tried commenting bits out and sticking in loops to see where
things go awry and I can't make sense of the results. printf's,
bios2dev(), awaitkey() all cause resets. I've gotten all the way
down to loadfile() in exec.c from boot2() to bootit() with enough
commenting, and that produces the same wild monitor sync hang as
the printfs. It seems to me that it may not be a problem within
boot2, but rather a manifestation of some previous error.=20
Cheers,
Steve
--3V7upXqbjpZ4EhLz
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)
iQEVAwUBQNo8uMuCaQyb9VOkAQJ30gf6Ah0Sz/6epyJMx/rSmYNpIOvakWZ+vAy1
+PGufyzSoEmTwzZMyuKbJFUJ5HFAgQzOYJqt/5umzh5Te69I1DBQ8X7YRyZ+4fkb
/zo+s8VgZ9LpoxdPAf6QdBBy8KFcrUEew3bTtL3rN7TwnxTBvsuf7Qh1cPPKGBHr
m+/stjfrzsVNqcpJDDCobda7zcPPXHy84pJmiRJp+vm1Jt1ahslmd6VZRyt/mnz7
RSYCYVZOxyG39EcH1HS4c+KxC/kBH1zjkL6PUDu5K9w3R5jasn9gDbwfLFR2hI2J
KhWVCaf3tsHUFv0ewirOMKViUd+TcK7hvmzX/JWnQgYNrmM6ffPxTw==
=4Xi9
-----END PGP SIGNATURE-----
--3V7upXqbjpZ4EhLz--
Responsible-Changed-From-To: kern-bug-people->port-i386-maintainer
Responsible-Changed-By: rumble
Responsible-Changed-When: Mon Jul 5 16:28:49 UTC 2004
Responsible-Changed-Why:
This PR is port-i386-specific.
From: Dick Davies <rasputnik@hellooperator.net>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: Re: port-i386/26007: i386 bootstrap fails on via epia 5000 in 2.0/-current
Date: Tue, 6 Jul 2004 09:51:46 +0100
Just for the log, I have a M6000 fanless epia board doing the same thing.
I run netbsd on a via 8000 board with no problems, so it must have
worked at some point...?
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@gnats.netbsd.org
Cc: port-i386@netbsd.org
Subject: re: port-i386/26007: i386 boot fails
Date: Sun, 15 Aug 2004 21:34:53 +0100
wrt problems booting with the boot code from 2.0, on systems where the
code from 1.6.x and pxeboot both work.
If a hunch I have is correct, a change I've made (locally) migth help.
I've put the modified /boot onto www.l8s.co.uk netbsd/boot
David
--
David Laight: david@l8s.co.uk
From: Steve Rumble <rumble@ephemeral.org>
To: gnats-bugs@gnats.netbsd.org
Cc:
Subject: re: port-i386/26007: i386 boot fails
Date: Sat, 28 Aug 2004 14:31:30 -0400
--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
David,
The August 15th /boot you provided doesn't appear to
behave any differently on my epia 5000 - the problem persists.
Cheers,
Steve
--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)
iQEVAwUBQTDPgsuCaQyb9VOkAQItSgf+JTqLtAl5SVIkPbQZ2g4p3cmLtW3ud3Yw
M0Tqe0sN04nTrCTdjPPHzioItQBHjdgIc/F0o5l2dptbmX+LFgcUl3OGk9tZQZ+S
lPLP9HKKIY+gKxV+WKnQ1KjRl7n4rkQVB2mG7riqtzHADtJWNYMKHZvKEDob/gWY
lXJt5ypmC/R3KT6hj0gaIAyUgnGALUqOI+dH0tdNjjSJzCsqdqrTC0E531xg5ckD
dngWo4/yi4QR8fpflwYwrmDMSheZt52LL3h16NimK6alwwggUHzb0EcLfvJVWEt5
Wov//dLgiX8pB6WcfnH5pGI04ThICYQd4itNkPD+w/axQnK/yEdsvQ==
=F0D9
-----END PGP SIGNATURE-----
--y0ulUmNC+osPPQO6--
From: "Thomas Miller" <tom@insolvencyhelp.org>
To: gnats-bugs@gnats.netbsd.org
Cc: rasputnik@hellooperator.net, rumble@ephemeral.org, david@l8s.co.uk
Subject: port-i386/26007 : boot failure w/epia boards
Date: Mon, 30 Aug 2004 20:11:59 -0400
Hi,
FWIW, I have an older DFI CA64-BC motherboard with
Via chips that appears to exhibit the problem described
in bug 26007. So, it looks like the problem might
not be confined to the Epia boards.
Kindest regards,
Tom
From: Teemu Rinta-aho <teemu@rinta-aho.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/26007: i386 bootstrap fails on via epia 5000 in 2.0/-current
Date: Thu, 18 Nov 2004 14:38:28 +0200
FYI,
I have an EPIA PD6000 board and the very same problem.
Both the BIOS and the netbsd code are the very latest.
I will try to debug this until further notice. Please
tell me if there's something new on this issue.
BR,
Teemu
From: Teemu Rinta-aho <teemu@rinta-aho.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/26007: i386 bootstrap fails on via epia 5000 in 2.0/-current
Date: Thu, 18 Nov 2004 14:07:16 +0200
FYI,
I have an EPIA PD6000 board and the very same problem.
Both the BIOS and the netbsd code are the very latest.
I will try to debug this until further notice. Please
tell me if there's something new on this issue.
BR,
Teemu
From: cpghost@cordula.ws
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/26007: i386 bootstrap fails on via epia 5000 in 2.0/-current
Date: Sun, 6 Feb 2005 01:31:08 +0100
Same problem here on an EPIA 5000 board with Eden ESP processor,
512 MB RAM and 2.0-RELEASE.
The board boots and runs FreeBSD 5.3 without any problems, both
in a disk and diskless (pxeboot) setup.
Sorry, I don't have the expertise to debug the problem, just
reporting it.
Thanks,
-cpghost.
--
Cordula's Web. http://www.cordula.ws/
From: "Karuschka, Roman" <roman.karuschka@cryptographic.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/26007
Date: Fri, 22 Apr 2005 13:15:34 +0200
Hello,
>unfortunately the release of NetBSD 2.0.2 didn't make things any better.
>Boot-Cycle of a 2.0.2-Install-CD quits even faster now, resetting the
>machine over and over.
>
>I'm open to suggestions...
>I'd classify this problem as pretty severe.
>
>
>Roman
>
>
From: "Karuschka, Roman" <roman.karuschka@cryptographic.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Subject: Re: port-i386/26007
Date: Fri, 22 Apr 2005 13:12:55 +0200
Hello,
unfortunately the release of NetBSD 2.0.2 didn't make things any better.
Boot-Cycle of a 2.0.2-Install-CD quits even faster now, resetting the
machine over and over.
I'm open to suggestions...
I'd classify this problem as pretty severe.
Roman
Responsible-Changed-From-To: port-i386-maintainer->gavan
Responsible-Changed-By: gavan@netbsd.org
Responsible-Changed-When: Tue, 10 May 2005 13:38:56 +0000
Responsible-Changed-Why:
I'll take this
State-Changed-From-To: open->feedback
State-Changed-By: gavan@netbsd.org
State-Changed-When: Tue, 10 May 2005 13:46:12 +0000
State-Changed-Why:
Feedback requested
From: Gavan Fantom <gavan@coolfactor.org>
To: rumble@ephemeral.org, tom@insolvencyhelp.org,
rasputnik@hellooperator.net, teemu@rinta-aho.org, cpghost@cordula.ws,
roman.karuschka@cryptographic.de
Cc: gnats-bugs@netbsd.org
Subject: Re: port-i386/26007
Date: Tue, 10 May 2005 14:45:40 +0100
Hi folks,
Please try out this patch:
http://frog.coolfactor.org/~gavan/epia_hack.diff
See also my mail to port-i386:
http://mail-index.netbsd.org/port-i386/2005/05/04/0007.html
Please let me know if this patch works for you.
--
Gilette - the best a man can forget
From: Gavan Fantom <gavan@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/26007 CVS commit: src/sys/arch/i386/stand
Date: Fri, 27 May 2005 21:40:09 +0000 (UTC)
Module Name: src
Committed By: gavan
Date: Fri May 27 21:40:09 UTC 2005
Modified Files:
src/sys/arch/i386/stand/boot: Makefile.boot
src/sys/arch/i386/stand/lib: realprot.S
Log Message:
Workaround for issues seen on VIA C3-based systems. PR port-i386/26007
Tested on ML5000 board. This may not fix the problem on all variations of the
hardware, but it's likely that variations on the theme will. This workaround
is non-intrusive and should not affect any other CPUs.
To generate a diff of this commit:
cvs rdiff -r1.20 -r1.21 src/sys/arch/i386/stand/boot/Makefile.boot
cvs rdiff -r1.3 -r1.4 src/sys/arch/i386/stand/lib/realprot.S
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Jeff Rizzo <riz@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/26007 CVS commit: [netbsd-2] src/sys/arch/i386/stand/lib
Date: Mon, 30 May 2005 00:18:17 +0000 (UTC)
Module Name: src
Committed By: riz
Date: Mon May 30 00:18:17 UTC 2005
Modified Files:
src/sys/arch/i386/stand/lib [netbsd-2]: realprot.S
Log Message:
Pull up revision 1.4 (requested by gavan in ticket #1870):
Workaround for issues seen on VIA C3-based systems. PR port-i386/26007
Tested on ML5000 board. This may not fix the problem on all variations
of the
hardware, but it's likely that variations on the theme will. This workaround
is non-intrusive and should not affect any other CPUs.
To generate a diff of this commit:
cvs rdiff -r1.3 -r1.3.6.1 src/sys/arch/i386/stand/lib/realprot.S
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Jeff Rizzo <riz@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/26007 CVS commit: [netbsd-2] src/sys/arch/i386/stand/boot
Date: Mon, 30 May 2005 00:18:19 +0000 (UTC)
Module Name: src
Committed By: riz
Date: Mon May 30 00:18:18 UTC 2005
Modified Files:
src/sys/arch/i386/stand/boot [netbsd-2]: Makefile.boot
Log Message:
Pull up revision 1.21 (requested by gavan in ticket #1870):
Workaround for issues seen on VIA C3-based systems. PR port-i386/26007
Tested on ML5000 board. This may not fix the problem on all variations
of the
hardware, but it's likely that variations on the theme will. This workaround
is non-intrusive and should not affect any other CPUs.
To generate a diff of this commit:
cvs rdiff -r1.14.2.1 -r1.14.2.1.2.1 \
src/sys/arch/i386/stand/boot/Makefile.boot
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Jeff Rizzo <riz@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/26007 CVS commit: [netbsd-3] src/sys/arch/i386/stand/lib
Date: Mon, 30 May 2005 00:23:01 +0000 (UTC)
Module Name: src
Committed By: riz
Date: Mon May 30 00:23:01 UTC 2005
Modified Files:
src/sys/arch/i386/stand/lib [netbsd-3]: realprot.S
Log Message:
Pull up revision 1.4 (requested by gavan in ticket #356):
Workaround for issues seen on VIA C3-based systems. PR port-i386/26007
Tested on ML5000 board. This may not fix the problem on all variations
of the
hardware, but it's likely that variations on the theme will. This workaround
is non-intrusive and should not affect any other CPUs.
To generate a diff of this commit:
cvs rdiff -r1.3 -r1.3.14.1 src/sys/arch/i386/stand/lib/realprot.S
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Jeff Rizzo <riz@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: PR/26007 CVS commit: [netbsd-3] src/sys/arch/i386/stand/boot
Date: Mon, 30 May 2005 00:23:02 +0000 (UTC)
Module Name: src
Committed By: riz
Date: Mon May 30 00:23:02 UTC 2005
Modified Files:
src/sys/arch/i386/stand/boot [netbsd-3]: Makefile.boot
Log Message:
Pull up revision 1.21 (requested by gavan in ticket #356):
Workaround for issues seen on VIA C3-based systems. PR port-i386/26007
Tested on ML5000 board. This may not fix the problem on all variations
of the
hardware, but it's likely that variations on the theme will. This workaround
is non-intrusive and should not affect any other CPUs.
To generate a diff of this commit:
cvs rdiff -r1.18 -r1.18.10.1 src/sys/arch/i386/stand/boot/Makefile.boot
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Patrik Weiskircher <pat@icore.at>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-i386/26007
Date: Sat, 27 Aug 2005 00:29:52 +0200
Hello,
I had the same Problem with the 2.0.2 bootloader.
Atfirst, I tried the bootloader from base.tgz from
ftp://ftp.de.netbsd.org/NetBSD-daily/HEAD/200508220000Z
This one *didn't* work.
As soon as it was loaded, the system rebooted.
Now, as I didn't know what to do next, I tried the base.tgz from
ftp://ftp.de.netbsd.org/NetBSD-daily/netbsd-3/200508120000Z
This one works perfectly.
Maybe I did something wrong with the daily base.tgz,
but I doubt it, as I tried it 2 times - just to make sure I
did everything correctly.
Regards,
Patrik
From: Petar Bogdanovic <p+netbsd@2005.smokva.net>
To: gavan@coolfactor.org, rumble@ephemeral.org,
tom@insolvencyhelp.org, rasputnik@hellooperator.net,
teemu@rinta-aho.org, cpghost@cordula.ws,
roman.karuschka@cryptographic.de
Cc: gnats-bugs@netbsd.org
Subject: Re: port-i386/26007
Date: Thu, 27 Oct 2005 20:56:34 +0200
A few weeks ago, I bought a VIA EPIA 5000. Today, I tried to boot NetBSD
3-BETA (cvs update: 26.10.2005) from a bootable CD but I had no luck:
The system hung in three different flavours.
1. I do not touch the keyboard. The monitor syncs one time after the
banner and goes into a mad resolution: The characters are extremely
small - I just can see (not read) the first line of the kernel
load-process (something like "35357345/7453528234=234563563") and then,
it hangs.
2. I press <tab> after the banner and type manually 'boot fd0a:netbsd'.
The monitor syncs approx. three times and I see a truncated
kernel-load-process line (something like "234=234563563"). This time the
characters are big and the font-color is blue.
3. I press <tab> after the banner and type manually 'consdev com0'. I
get the same banner again over com0. Then 'boot fd0a:netbsd' and the
result looks like:
**************************************************************
>> NetBSD/i386 BIOS Boot, Revision 3.2
>> (bogdanov@submit64, Thu Oct 27 13:16:54 CEST 2005)
>> Memory: 640/515072 k
> boot fd0a:netbsd
booting fd0a:netbsd
3788516|
**************************************************************
Hard hang.
Should I update my BIOS?
BTW: Linux boots trouble-free.
Thank you and with kind regards,
Petar
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@netbsd.org
Cc: p+netbsd@2005.smokva.net
Subject: Re: port-i386/26007
Date: Thu, 27 Oct 2005 22:00:39 +0100
On Thu, Oct 27, 2005 at 06:58:02PM +0000, Petar Bogdanovic wrote:
>
> A few weeks ago, I bought a VIA EPIA 5000. Today, I tried to boot NetBSD
> 3-BETA (cvs update: 26.10.2005) from a bootable CD but I had no luck:
> The system hung in three different flavours.
Can you try booting install-tiny?
or maybe one of the small, ramdisk-free kernels?
(they should get as far as failing to find init)
Might also be worth rebuilding /boot with DEBUG_MEMSIZE defined
(for src/sys/arch/i386/stand/lib/getextmemx.c)
David
--
David Laight: david@l8s.co.uk
From: Petar Bogdanovic <p+netbsd@2005.smokva.net>
To: gnats-bugs@netbsd.org
Cc: gavan@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-i386/26007
Date: Fri, 28 Oct 2005 00:15:02 +0200
David Laight wrote:
> Can you try booting install-tiny?
> or maybe one of the small, ramdisk-free kernels?
> (they should get as far as failing to find init)
David, thanks a million - boot-tiny.fs works!
I assume that my problem had nothing to do with port-i386/26007, so I'll
transform my concern into a feedback:
My EPIA 5000 boots properly NetBSD 3-BETA (26.10.2005).
From: Teemu Rinta-aho <teemu@rinta-aho.org>
To: Petar Bogdanovic <p+netbsd@2005.smokva.net>
Cc: gavan@coolfactor.org, rumble@ephemeral.org,
tom@insolvencyhelp.org, rasputnik@hellooperator.net,
cpghost@cordula.ws, roman.karuschka@cryptographic.de,
gnats-bugs@netbsd.org
Subject: Re: port-i386/26007
Date: Fri, 28 Oct 2005 09:02:43 +0300
Try this (from Gavan Fantom, I haven't had time for it yet):
===
Hi folks,
Please try out this patch:
http://frog.coolfactor.org/~gavan/epia_hack.diff
See also my mail to port-i386:
http://mail-index.netbsd.org/port-i386/2005/05/04/0007.html
Please let me know if this patch works for you.
===
Another option, which I did, is that I installed
NetBSD 1.6 from a CD-ROM, after which I just updated
it to current, except the boot sector of course :-)
Teemu
Petar Bogdanovic wrote:
> A few weeks ago, I bought a VIA EPIA 5000. Today, I tried to boot NetBSD
> 3-BETA (cvs update: 26.10.2005) from a bootable CD but I had no luck:
> The system hung in three different flavours.
>
> 1. I do not touch the keyboard. The monitor syncs one time after the
> banner and goes into a mad resolution: The characters are extremely
> small - I just can see (not read) the first line of the kernel
> load-process (something like "35357345/7453528234=234563563") and then,
> it hangs.
>
> 2. I press <tab> after the banner and type manually 'boot fd0a:netbsd'.
> The monitor syncs approx. three times and I see a truncated
> kernel-load-process line (something like "234=234563563"). This time the
> characters are big and the font-color is blue.
>
> 3. I press <tab> after the banner and type manually 'consdev com0'. I
> get the same banner again over com0. Then 'boot fd0a:netbsd' and the
> result looks like:
>
> **************************************************************
> >> NetBSD/i386 BIOS Boot, Revision 3.2
> >> (bogdanov@submit64, Thu Oct 27 13:16:54 CEST 2005)
> >> Memory: 640/515072 k
> > boot fd0a:netbsd
> booting fd0a:netbsd
> 3788516|
>
> **************************************************************
>
> Hard hang.
>
>
> Should I update my BIOS?
>
> BTW: Linux boots trouble-free.
>
>
> Thank you and with kind regards,
>
> Petar
>
>
--
teemu@rinta-aho.org -+- http://www.rinta-aho.org
From: Urban Boquist <urban@boquist.net>
To: Petar Bogdanovic <p+netbsd@2005.smokva.net>
Cc: gnats-bugs@netbsd.org, gavan@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/26007
Date: Fri, 28 Oct 2005 08:32:28 +0200
>>>>> Petar Bogdanovic writes:
Petar> David Laight wrote:
>> Can you try booting install-tiny? or maybe one of the small,
>> ramdisk-free kernels? (they should get as far as failing to find
>> init)
Petar> David, thanks a million - boot-tiny.fs works!
Petar> I assume that my problem had nothing to do with
Petar> port-i386/26007, so I'll transform my concern into a feedback:
Actually, I think your problem is most probably the same as 26007. The
problem now, I think, is that the work-around Gavan committed in
August works for some people but not for all (which he also noted in
the commit message).
FWIW I also have an (older) VIA cpu machine that exhibits very similar
symptoms; very early in boot the display goes either very weird, or
completely black, or the text size gets very small. In all cases it
hangs hard. Interestingly Gavan's change helped i bit in that it can
now boot from floppy, but the same boot blocks booting from a CD still
hangs... ;-(
I've tried modifying Gavan's changes, inserting more jumps and more
nop:s to try to get this machine to boot from CD too, but nothing I do
seems to help.
What's even more depressing is that NetBSD 1.6.x booted flawlessly on
all these machines... ;-)
Best regards,
-- Urban
From: Petar Bogdanovic <p+netbsd@2005.smokva.net>
To: Teemu Rinta-aho <teemu@rinta-aho.org>
Cc: gavan@coolfactor.org, rumble@ephemeral.org,
tom@insolvencyhelp.org, rasputnik@hellooperator.net,
cpghost@cordula.ws, roman.karuschka@cryptographic.de,
gnats-bugs@netbsd.org
Subject: Re: port-i386/26007
Date: Fri, 28 Oct 2005 10:48:24 +0200
Teemu Rinta-aho wrote:
> Try this (from Gavan Fantom, I haven't had time for it yet):
>
> ===
> Hi folks,
>
> Please try out this patch:
>
> http://frog.coolfactor.org/~gavan/epia_hack.diff
>
> See also my mail to port-i386:
>
> http://mail-index.netbsd.org/port-i386/2005/05/04/0007.html
>
> Please let me know if this patch works for you.
> ===
This patch was commited to 'netbsd-2' and 'netbsd-3', AFAIK.
From: Petar Bogdanovic <p+netbsd@2005.smokva.net>
To: Urban Boquist <urban@boquist.net>
Cc: gnats-bugs@netbsd.org, gavan@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/26007
Date: Fri, 28 Oct 2005 11:03:18 +0200
Urban Boquist wrote:
> Actually, I think your problem is most probably the same as 26007. The
> problem now, I think, is that the work-around Gavan committed in
> August works for some people but not for all (which he also noted in
> the commit message).
>
> FWIW I also have an (older) VIA cpu machine that exhibits very similar
> symptoms; very early in boot the display goes either very weird, or
> completely black, or the text size gets very small. In all cases it
> hangs hard. Interestingly Gavan's change helped i bit in that it can
> now boot from floppy, but the same boot blocks booting from a CD still
> hangs... ;-(
The funny thing is also the 'randomness' of the hangs - if you play with
the 'interactive boot-loader', you can get the weirdest
color/resolution/size-combinations!
BTW: Yesterday, I installed 3-BETA (boot-tiny.fs) without any problems.
Afterwards, you could boot - but only, if you pressed the <Enter>-Key
before the count-down ended, otherwise, it just hung.
And now the most funny thing: Because it was 3 o'clock in the morning, I
wanted to go to bed and I disconnected the machine from the monitor &
keyboard and started it again in an other room with serial- &
power-cable plugged-in only. Suddenly, the count-down problem was gone.
Kind regards,
Petar
From: Gavan Fantom <gavan@coolfactor.org>
To: Petar Bogdanovic <p+netbsd@2005.smokva.net>
Cc: Urban Boquist <urban@boquist.net>, gnats-bugs@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-i386/26007
Date: Fri, 28 Oct 2005 13:06:42 +0100
Petar Bogdanovic wrote:
> Urban Boquist wrote:
>
>> Actually, I think your problem is most probably the same as 26007. The
>> problem now, I think, is that the work-around Gavan committed in
>> August works for some people but not for all (which he also noted in
>> the commit message).
>>
>> FWIW I also have an (older) VIA cpu machine that exhibits very similar
>> symptoms; very early in boot the display goes either very weird, or
>> completely black, or the text size gets very small. In all cases it
>> hangs hard. Interestingly Gavan's change helped i bit in that it can
>> now boot from floppy, but the same boot blocks booting from a CD still
>> hangs... ;-(
>
>
> The funny thing is also the 'randomness' of the hangs - if you play with
> the 'interactive boot-loader', you can get the weirdest
> color/resolution/size-combinations!
The basic problem is that when switching back from protected mode to
real mode, and switching back to 16 bit code, the switch back to 16 bit
code doesn't always work. As noted in the comment in the code, the
reason for this is unknown.
BIOS calls are wrapped with code to switch to real mode before entering
the BIOS, and back to protected mode afterwards. The results of entering
the BIOS in the wrong CPU mode are, well, undefined and vary wildly
between machines. On my EPIA board this would range from a simple hang
through clearing the screen to reconfiguring the video to display text
in strange sizes and colours.
The branches and nops that I put in worked around the problem
sufficiently that my board booted using biosboot. I subsequently
discovered that less common cases still don't work. Booting single-user,
for example, caused my board to fail. pxeboot didn't work, and some
people reported that dosboot didn't work.
I had speculated that this may be a CPU bug. I'm now starting to wonder
whether the BIOS is enabling more caches than we're expecting.
--
Gillette - the best a man can forget
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/26007
Date: Fri, 28 Oct 2005 17:40:19 +0100
On Fri, Oct 28, 2005 at 12:08:02PM +0000, Gavan Fantom wrote:
>
> I had speculated that this may be a CPU bug. I'm now starting to wonder
> whether the BIOS is enabling more caches than we're expecting.
One difference between the 1.6 bootcode and the current copy is that
prot_to_real used to do an immediate ljmp having just written to the
code to patch the instruction. I changed it to do an indirect longjump.
I don't think anyone has tried reverting that change.
(Nor the other subtle changes required to get the correct address mode
and bound bits set in the segment descriptor - IIRC especially SS)
David
--
David Laight: david@l8s.co.uk
From: Gavan Fantom <gavan@coolfactor.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/26007
Date: Fri, 28 Oct 2005 19:54:32 +0100
David Laight wrote:
> The following reply was made to PR port-i386/26007; it has been noted by GNATS.
>
> From: David Laight <david@l8s.co.uk>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: port-i386/26007
> Date: Fri, 28 Oct 2005 17:40:19 +0100
>
> On Fri, Oct 28, 2005 at 12:08:02PM +0000, Gavan Fantom wrote:
> >
> > I had speculated that this may be a CPU bug. I'm now starting to wonder
> > whether the BIOS is enabling more caches than we're expecting.
>
> One difference between the 1.6 bootcode and the current copy is that
> prot_to_real used to do an immediate ljmp having just written to the
> code to patch the instruction. I changed it to do an indirect longjump.
>
> I don't think anyone has tried reverting that change.
> (Nor the other subtle changes required to get the correct address mode
> and bound bits set in the segment descriptor - IIRC especially SS)
Does any other OS do it the way we currently do?
--
Gillette - the best a man can forget
From: Eric Horch <ehorch@gmail.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-i386/26007
Date: Thu, 8 Dec 2005 01:22:17 -0700
Gavan Fantom wrote:
> David Laight wrote:
> > One difference between the 1.6 bootcode and the current copy is that
> > prot_to_real used to do an immediate ljmp having just written to the
> > code to patch the instruction. I changed it to do an indirect longjum=
p.
> >
> > I don't think anyone has tried reverting that change.
> > (Nor the other subtle changes required to get the correct address mode
> > and bound bits set in the segment descriptor - IIRC especially SS)
>
> Does any other OS do it the way we currently do?
Doesn't look like it. I checked the other BSDs and two popular Linux
booters and they all use immediate operands to their far jumps.
Here are a few observations I noted while inspecting those other ones.
1) Most play it conservative and keep real mode cs =3D=3D ds =3D=3D ss =
=3D=3D 0.
2) Several use split stacks. That is, one stack for real mode and
one for protected, which requires passing items back and forth.
3) For the ones that use gas and ld, segments tend to be hard coded
and there are a lot of address fixups in the 16-bit code.
Looking again at our code, I noticed these things.
1) In prot_to_real, the operand to the indirect far jump should
point to a six-byte object (lower four -> eip, upper two -> cs)
just like a far return (lret) pops six bytes off the stack
(for example, see the last few lines of startprog.S).
2) Adding two bytes to realprot.S makes things worse while adding
a dozen printfs to boot2.c makes it work on my machine.
The first one appears to be innocuous. The second one has me thinking
that something's scribbling in the wrong spot. Perhaps our stack or
data areas are not where we think they are and these VIA systems are
different enough to follow a code path that more normal machines
don't and therefore they hit the damage.
--
Eric Horch
ehorch@gmail.com
From: Eric Horch <ehorch@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/26007
Date: Fri, 9 Dec 2005 03:39:53 -0700
Oops, I need to make a correction. I wrote:
> Looking again at our code, I noticed these things.
> 1) In prot_to_real, the operand to the indirect far jump should
> point to a six-byte object (lower four -> eip, upper two -> cs)
It's correct the way it is because the jump is being executed from
a 16-bit code segment. So never mind.
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 04 May 2008 02:37:12 +0000
State-Changed-Why:
There's quite a lot of feedback, but it looks like the problem isn't (or
wasn't) solved in all cases.
State-Changed-From-To: open->feedback
State-Changed-By: dsl@NetBSD.org
State-Changed-When: Sat, 21 Nov 2009 13:39:34 +0000
State-Changed-Why:
Possible fix applied
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: PR/26007 VIA epia/samuel booting problems
Date: Sat, 21 Nov 2009 13:38:44 +0000
I've done a load more experiments, aided by writing to the serial
port from 32bit mode.
Trashing the return address cache seeme to fix the issues on the
system I was using.
So possibly fixed by rev 1.9 of realprot.S
David
--
David Laight: david@l8s.co.uk
Responsible-Changed-From-To: gavan->dsl
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Mon, 23 Dec 2013 22:57:21 +0000
Responsible-Changed-Why:
dsl handled it most recently
State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 23 Dec 2013 22:57:21 +0000
State-Changed-Why:
four-year feedback timeout
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home