From: "Antonino A. Daplas" <adaplas@gmail.com>
To: Alexander van Heukelum <heukelum@mailshack.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
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: Wed, 09 May 2007 08:04:07 +0800 [thread overview]
Message-ID: <1178669047.4747.15.camel@daplas> (raw)
In-Reply-To: <20070508183232.GA13225@mailshack.com>
On Tue, 2007-05-08 at 20:32 +0200, Alexander van Heukelum wrote:
> 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 */
> };
>
You would also need this minor change.
Tony
diff --git a/arch/i386/boot/video.S b/arch/i386/boot/video.S
index 5e2280c..2d637d1 100644
--- a/arch/i386/boot/video.S
+++ b/arch/i386/boot/video.S
@@ -95,7 +95,7 @@ #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_CAPABILITIES 0x38
/* Define DO_STORE according to CONFIG_VIDEO_RETAIN */
#ifdef CONFIG_VIDEO_RETAIN
next prev parent reply other threads:[~2007-05-09 0:04 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
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 [this message]
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=1178669047.4747.15.camel@daplas \
--to=adaplas@gmail.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=heukelum@mailshack.com \
--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