public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander van Heukelum <heukelum@mailshack.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	"Antonino A. Daplas" <adaplas@gmail.com>
Cc: Andi Kleen <ak@suse.de>, "H. Peter Anvin" <hpa@zytor.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Make bootsector stub 16-bit-only (i386)
Date: Tue, 8 May 2007 20:32:32 +0200	[thread overview]
Message-ID: <20070508183232.GA13225@mailshack.com> (raw)
In-Reply-To: <20070508032817.e4734798.akpm@linux-foundation.org>

On Tue, May 08, 2007 at 03:28:17AM -0700, Andrew Morton wrote:
> On Sat, 5 May 2007 12:44:52 +0200 Alexander van Heukelum <heukelum@mailshack.com> wrote:
> > --- a/arch/i386/boot/bootsect.S
> > +++ b/arch/i386/boot/bootsect.S
> > @@ -44,7 +44,7 @@ #endif
> >  _start:
> >  
> >  	# Normalize the start address
> > -	jmpl	$BOOTSEG, $start2
> > +	jmpw	$BOOTSEG, $start2
> 
> Sigh, another blow struck in the ongoing struggle between my Vaio and the
> rest of the world.
> 
> Stone-cold black-screen lockup immediately upon boot.
> 
> Stock FC5 install, config at
> http://userweb.kernel.org/~akpm/config-sony.txt

Sigh... sounds impossible.

I assume this is repeatable? And this patch changes behaviour? What do
you mean by immediate? Before or after decompression?

Fishy... As Andi and Peter have mentioned, this code is not executed.
There is only one user of the same memory area this early... video.S
uses it to store some collected data, but as far as I can see only the
'CONFIG_VIDEO_RETAIN' code also reads it back. If it happens before
decompression, could you see if changing
	#define CONFIG_VIDEO_RETAIN -> #undef CONFIG_VIDEO_RETAIN
in arch/i386/boot/video.S changes anything?

Do you select a non-standard textmode? Does vga=ask show up?

*looks around some*

Oh! A padding hole in a struct! That could be a problem. If the freeze
is after decompression, could you test if this makes it work again?

Greetings,
	Alexander

---

Commit 89ec4c238e7a3d7e660291f3f1a8181381baad77 introduced a discrepancy
between the struct screen_info which is used by the C code, and the
PARAM_* offsets which are used in the real-mode kernel. This is an
attempt to rectify the situation, but I have no way to test it.

Signed-off-by: Alexander van Heukelum <heukelum@mailshack.com>

---

diff --git a/arch/i386/boot/bootsect.S b/arch/i386/boot/bootsect.S
diff --git a/arch/i386/boot/video.S b/arch/i386/boot/video.S
index 8143c95..8e404cb 100644
--- a/arch/i386/boot/video.S
+++ b/arch/i386/boot/video.S
@@ -95,7 +95,8 @@ #define PARAM_VESAPM_SEG	0x2e
 #define PARAM_VESAPM_OFF	0x30
 #define PARAM_LFB_PAGES		0x32
 #define PARAM_VESA_ATTRIB	0x34
-#define PARAM_CAPABILITIES	0x36
+#define PARAM_VESA_PAD		0x36
+#define PARAM_CAPABILITIES	0x38
 
 /* Define DO_STORE according to CONFIG_VIDEO_RETAIN */
 #ifdef CONFIG_VIDEO_RETAIN
diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
index b02308e..0a2e892 100644
--- a/include/linux/screen_info.h
+++ b/include/linux/screen_info.h
@@ -41,8 +41,8 @@ struct screen_info {
 	u16 vesapm_off;		/* 0x30 */
 	u16 pages;		/* 0x32 */
 	u16 vesa_attributes;	/* 0x34 */
-	u32 capabilities;       /* 0x36 */
-				/* 0x3a -- 0x3b reserved for future expansion */
+	u16 vesa_pad;		/* 0x36 */
+	u32 capabilities;       /* 0x38 */
 				/* 0x3c -- 0x3f micro stack for relocatable kernels */
 };
 

  parent reply	other threads:[~2007-05-08 18:36 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-05 10:44 [PATCH] Make bootsector stub 16-bit-only (i386) Alexander van Heukelum
2007-05-05 18:07 ` H. Peter Anvin
2007-05-08 10:28 ` Andrew Morton
2007-05-08 11:25   ` H. Peter Anvin
2007-05-08 12:27     ` Andi Kleen
2007-05-08 17:13       ` H. Peter Anvin
2007-05-08 18:12     ` Andrew Morton
2007-05-08 18:27       ` H. Peter Anvin
2007-05-08 18:32   ` Alexander van Heukelum [this message]
2007-05-08 18:45     ` H. Peter Anvin
2007-05-08 19:19       ` Alexander van Heukelum
2007-05-08 22:27         ` H. Peter Anvin
2007-05-08 20:00     ` Andrew Morton
2007-05-09  0:04     ` Antonino A. Daplas
2007-05-09  8:54       ` Alexander van Heukelum
2007-05-09 13:45         ` Antonino A. Daplas
2007-05-09 16:51         ` H. Peter Anvin
2007-05-09 18:18           ` Alexander van Heukelum
2007-05-09 18:27             ` H. Peter Anvin
2007-05-09 14:30       ` Lennart Sorensen
2007-05-09 14:51         ` Antonino A. Daplas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070508183232.GA13225@mailshack.com \
    --to=heukelum@mailshack.com \
    --cc=adaplas@gmail.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox