All of lore.kernel.org
 help / color / mirror / Atom feed
* ACPI video mode patch review
@ 2007-09-13 21:37 H. Peter Anvin
  2007-09-13 23:23 ` Jeff Chua
                   ` (3 more replies)
  0 siblings, 4 replies; 11+ messages in thread
From: H. Peter Anvin @ 2007-09-13 21:37 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Jeff Chua, Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 111 bytes --]

Pavel, want to look at the patch before sending it to Linus?

	--- THIS IS NOT (YET) A PULL REQUEST ---

	-hpa

[-- Attachment #2: msg --]
[-- Type: text/plain, Size: 6487 bytes --]

From: H. Peter Anvin <hpa@zytor.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Bcc: H. Peter Anvin <hpa+sent@zytor.com>
Subject: [GIT PULL] Fix decoding of video mode numbers in acpi/wakeup.S

Hi Linus,

Please pull:

  git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git for-linus

H. Peter Anvin (2):
      [x86 setup] Present the canonical video mode number to the kernel
      [acpi] Correct the decoding of video mode numbers in wakeup.S

 arch/i386/boot/video.c           |   14 ++++++++---
 arch/i386/kernel/acpi/wakeup.S   |   41 ++++++++-------------------------
 arch/x86_64/kernel/acpi/wakeup.S |   47 ++++++++++---------------------------
 3 files changed, 33 insertions(+), 69 deletions(-)

[Log messages and full diffs follow]

commit 5178fb23e3e41500fd066ecd4be15a60dd373e75
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Thu Sep 13 14:16:37 2007 -0700

    [acpi] Correct the decoding of video mode numbers in wakeup.S
    
    wakeup.S looks at the video mode number from the setup header and
    looks to see if it is a VESA mode.  Unfortunately, the decoding is
    done incorrectly and it will attempt to frob the VESA BIOS for any
    mode number 0x0200 or larger.  Correct this, and remove a bunch of #if
    0'd code.
    
    Massive thanks to Jeff Chua for reporting the bug, and suffering
    though a large number of experiments in order to track this problem
    down.
    
    Cc: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>

diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
index ed0a0f2..f22ba85 100644
--- a/arch/i386/kernel/acpi/wakeup.S
+++ b/arch/i386/kernel/acpi/wakeup.S
@@ -151,51 +151,30 @@ bogus_real_magic:
 #define VIDEO_FIRST_V7 0x0900
 
 # Setting of user mode (AX=mode ID) => CF=success
+
+# For now, we only handle VESA modes (0x0200..0x03ff).  To handle other
+# modes, we should probably compile in the video code from the boot
+# directory.
 mode_set:
 	movw	%ax, %bx
-#if 0
-	cmpb	$0xff, %ah
-	jz	setalias
-
-	testb	$VIDEO_RECALC>>8, %ah
-	jnz	_setrec
-
-	cmpb	$VIDEO_FIRST_RESOLUTION>>8, %ah
-	jnc	setres
-	
-	cmpb	$VIDEO_FIRST_SPECIAL>>8, %ah
-	jz	setspc
-
-	cmpb	$VIDEO_FIRST_V7>>8, %ah
-	jz	setv7
-#endif
-	
-	cmpb	$VIDEO_FIRST_VESA>>8, %ah
-	jnc	check_vesa
-#if 0	
-	orb	%ah, %ah
-	jz	setmenu
-#endif
-	
-	decb	%ah
-#	jz	setbios				  Add bios modes later
+	subb	$VIDEO_FIRST_VESA>>8, %bh
+	cmpb	$2, %bh
+	jb	check_vesa
 
-setbad:	clc
+setbad:
+	clc
 	ret
 
 check_vesa:
-	subb	$VIDEO_FIRST_VESA>>8, %bh
 	orw	$0x4000, %bx			# Use linear frame buffer
 	movw	$0x4f02, %ax			# VESA BIOS mode set call
 	int	$0x10
 	cmpw	$0x004f, %ax			# AL=4f if implemented
-	jnz	_setbad				# AH=0 if OK
+	jnz	setbad				# AH=0 if OK
 
 	stc
 	ret
 
-_setbad: jmp setbad
-
 	.code32
 	ALIGN
 
diff --git a/arch/x86_64/kernel/acpi/wakeup.S b/arch/x86_64/kernel/acpi/wakeup.S
index 13f1480..a06f2bc 100644
--- a/arch/x86_64/kernel/acpi/wakeup.S
+++ b/arch/x86_64/kernel/acpi/wakeup.S
@@ -81,7 +81,7 @@ wakeup_code:
 	testl	$2, realmode_flags - wakeup_code
 	jz	1f
 	mov	video_mode - wakeup_code, %ax
-	call	mode_seta
+	call	mode_set
 1:
 
  	movw	$0xb800, %ax
@@ -291,52 +291,31 @@ no_longmode:
 #define VIDEO_FIRST_V7 0x0900
 
 # Setting of user mode (AX=mode ID) => CF=success
+
+# For now, we only handle VESA modes (0x0200..0x03ff).  To handle other
+# modes, we should probably compile in the video code from the boot
+# directory.
 .code16
-mode_seta:
+mode_set:
 	movw	%ax, %bx
-#if 0
-	cmpb	$0xff, %ah
-	jz	setalias
-
-	testb	$VIDEO_RECALC>>8, %ah
-	jnz	_setrec
-
-	cmpb	$VIDEO_FIRST_RESOLUTION>>8, %ah
-	jnc	setres
-	
-	cmpb	$VIDEO_FIRST_SPECIAL>>8, %ah
-	jz	setspc
-
-	cmpb	$VIDEO_FIRST_V7>>8, %ah
-	jz	setv7
-#endif
-	
-	cmpb	$VIDEO_FIRST_VESA>>8, %ah
-	jnc	check_vesaa
-#if 0	
-	orb	%ah, %ah
-	jz	setmenu
-#endif
-	
-	decb	%ah
-#	jz	setbios				  Add bios modes later
+	subb	$VIDEO_FIRST_VESA>>8, %bh
+	cmpb	$2, %bh
+	jb	check_vesa
 
-setbada:	clc
+setbad:
+	clc
 	ret
 
-check_vesaa:
-	subb	$VIDEO_FIRST_VESA>>8, %bh
+check_vesa:
 	orw	$0x4000, %bx			# Use linear frame buffer
 	movw	$0x4f02, %ax			# VESA BIOS mode set call
 	int	$0x10
 	cmpw	$0x004f, %ax			# AL=4f if implemented
-	jnz	_setbada				# AH=0 if OK
+	jnz	setbad				# AH=0 if OK
 
 	stc
 	ret
 
-_setbada: jmp setbada
-
 wakeup_stack_begin:	# Stack grows down
 
 .org	0xff0

commit f41b4d086c58ca531ad512e1e9d6712b2310969e
Author: H. Peter Anvin <hpa@zytor.com>
Date:   Thu Sep 13 14:14:29 2007 -0700

    [x86 setup] Present the canonical video mode number to the kernel
    
    Canonicalize the video mode number as presented to the kernel.  The
    video mode number may be user-entered (e.g. ASK_VGA), an alias
    (e.g. NORMAL_VGA), or a size specification, and that confuses the
    suspend wakeup code.
    
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>

diff --git a/arch/i386/boot/video.c b/arch/i386/boot/video.c
index 693f20d..e4ba897 100644
--- a/arch/i386/boot/video.c
+++ b/arch/i386/boot/video.c
@@ -147,7 +147,7 @@ int mode_defined(u16 mode)
 }
 
 /* Set mode (without recalc) */
-static int raw_set_mode(u16 mode)
+static int raw_set_mode(u16 mode, u16 *real_mode)
 {
 	int nmode, i;
 	struct card_info *card;
@@ -165,8 +165,10 @@ static int raw_set_mode(u16 mode)
 
 			if ((mode == nmode && visible) ||
 			    mode == mi->mode ||
-			    mode == (mi->y << 8)+mi->x)
+			    mode == (mi->y << 8)+mi->x) {
+				*real_mode = mi->mode;
 				return card->set_mode(mi);
+			}
 
 			if (visible)
 				nmode++;
@@ -178,7 +180,7 @@ static int raw_set_mode(u16 mode)
 		if (mode >= card->xmode_first &&
 		    mode < card->xmode_first+card->xmode_n) {
 			struct mode_info mix;
-			mix.mode = mode;
+			*real_mode = mix.mode = mode;
 			mix.x = mix.y = 0;
 			return card->set_mode(&mix);
 		}
@@ -223,6 +225,7 @@ static void vga_recalc_vertical(void)
 static int set_mode(u16 mode)
 {
 	int rv;
+	u16 real_mode;
 
 	/* Very special mode numbers... */
 	if (mode == VIDEO_CURRENT_MODE)
@@ -232,13 +235,16 @@ static int set_mode(u16 mode)
 	else if (mode == EXTENDED_VGA)
 		mode = VIDEO_8POINT;
 
-	rv = raw_set_mode(mode);
+	rv = raw_set_mode(mode, &real_mode);
 	if (rv)
 		return rv;
 
 	if (mode & VIDEO_RECALC)
 		vga_recalc_vertical();
 
+	/* Save the canonical mode number for the kernel, not
+	   an alias, size specification or menu position */
+	boot_params.hdr.vid_mode = real_mode;
 	return 0;
 }
 

^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-13 21:37 ACPI video mode patch review H. Peter Anvin
@ 2007-09-13 23:23 ` Jeff Chua
  2007-09-14  9:25 ` Pavel Machek
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 11+ messages in thread
From: Jeff Chua @ 2007-09-13 23:23 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Pavel Machek, Linux Kernel Mailing List, Michal Piotrowski

On 9/14/07, H. Peter Anvin <hpa@zytor.com> wrote:
> Pavel, want to look at the patch before sending it to Linus?
>
>     [acpi] Correct the decoding of video mode numbers in wakeup.S

HPA,

After a day, still works, no video mess-up after s2ram resume. I guess
we can close this regression for -rc6 now. I'll test it again after
Linus release the next update.

Thanks for the patch. Great work!

Jeff.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-13 21:37 ACPI video mode patch review H. Peter Anvin
  2007-09-13 23:23 ` Jeff Chua
@ 2007-09-14  9:25 ` Pavel Machek
  2007-09-16 20:08 ` Rafael J. Wysocki
  2007-09-20 14:19 ` Jiri Kosina
  3 siblings, 0 replies; 11+ messages in thread
From: Pavel Machek @ 2007-09-14  9:25 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Jeff Chua, Linux Kernel Mailing List

Hi!

> Pavel, want to look at the patch before sending it to Linus?

Looks okay from a quick look. I'm on conference just now, will test
shortly.

								Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-13 21:37 ACPI video mode patch review H. Peter Anvin
  2007-09-13 23:23 ` Jeff Chua
  2007-09-14  9:25 ` Pavel Machek
@ 2007-09-16 20:08 ` Rafael J. Wysocki
  2007-09-16 20:53   ` H. Peter Anvin
  2007-09-20 14:19 ` Jiri Kosina
  3 siblings, 1 reply; 11+ messages in thread
From: Rafael J. Wysocki @ 2007-09-16 20:08 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Pavel Machek, Jeff Chua, Linux Kernel Mailing List

On Thursday, 13 September 2007 23:37, H. Peter Anvin wrote:
> Pavel, want to look at the patch before sending it to Linus?

Many thanks for taking care of this!

We already have a patch in -mm, s2ram-kill-old-debugging-junk.patch from Pavel
(http://marc.info/?l=linux-mm-commits&m=118737955611331&w=1), that removes the
#ifdefed blocks and it clashes with your first patch a bit.

FYI, I have rebased your first patch on top of the Pavel's patch:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc6/patches/39-acpi-video-mode-fix.patch

Greetings,
Rafael

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-16 20:08 ` Rafael J. Wysocki
@ 2007-09-16 20:53   ` H. Peter Anvin
  2007-09-16 20:59     ` Pavel Machek
  0 siblings, 1 reply; 11+ messages in thread
From: H. Peter Anvin @ 2007-09-16 20:53 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: Pavel Machek, Jeff Chua, Linux Kernel Mailing List

Rafael J. Wysocki wrote:
> On Thursday, 13 September 2007 23:37, H. Peter Anvin wrote:
>> Pavel, want to look at the patch before sending it to Linus?
> 
> Many thanks for taking care of this!
> 
> We already have a patch in -mm, s2ram-kill-old-debugging-junk.patch from Pavel
> (http://marc.info/?l=linux-mm-commits&m=118737955611331&w=1), that removes the
> #ifdefed blocks and it clashes with your first patch a bit.
> 
> FYI, I have rebased your first patch on top of the Pavel's patch:
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc6/patches/39-acpi-video-mode-fix.patch
> 

Thanks Rafael,

However, I need to send something upstream to Linus for this kernel
cycle, so I don't want to base it on an -mm patch.  There are two
alternatives, obviously: 1. send my patch in now based on the "change as
little as necessary to fix the immediate problem" and then rebase
Pavel's patch on top of mine, or 2. for me to send both Pavel's patch
and the rebased patch upstream.

Personally, I would prefer to avoid strategy 2 at this late stage in the
2.6.23-rc series.

Please let me know what you think.

	-hpa

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-16 20:53   ` H. Peter Anvin
@ 2007-09-16 20:59     ` Pavel Machek
  2007-09-16 22:04       ` Rafael J. Wysocki
  0 siblings, 1 reply; 11+ messages in thread
From: Pavel Machek @ 2007-09-16 20:59 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Rafael J. Wysocki, Jeff Chua, Linux Kernel Mailing List

Hi!

> > Many thanks for taking care of this!
> > 
> > We already have a patch in -mm, s2ram-kill-old-debugging-junk.patch from Pavel
> > (http://marc.info/?l=linux-mm-commits&m=118737955611331&w=1), that removes the
> > #ifdefed blocks and it clashes with your first patch a bit.
> > 
> > FYI, I have rebased your first patch on top of the Pavel's patch:
> > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc6/patches/39-acpi-video-mode-fix.patch
> > 
> 
> Thanks Rafael,
> 
> However, I need to send something upstream to Linus for this kernel
> cycle, so I don't want to base it on an -mm patch.  There are two
> alternatives, obviously: 1. send my patch in now based on the "change as
> little as necessary to fix the immediate problem" and then rebase
> Pavel's patch on top of mine, or 2. for me to send both Pavel's patch
> and the rebased patch upstream.
> 
> Personally, I would prefer to avoid strategy 2 at this late stage in the
> 2.6.23-rc series.

Agreed we should have the fix in 2.6.23... Actually doing 2 does not
seem like a big problem, my patch is pretty straight cleanup (and may
even fix some machines, as we avoid touching video ram)... But
resolving conflict is not hard, either; I know, I did it :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-16 20:59     ` Pavel Machek
@ 2007-09-16 22:04       ` Rafael J. Wysocki
  0 siblings, 0 replies; 11+ messages in thread
From: Rafael J. Wysocki @ 2007-09-16 22:04 UTC (permalink / raw)
  To: Pavel Machek, H. Peter Anvin; +Cc: Jeff Chua, Linux Kernel Mailing List

On Sunday, 16 September 2007 22:59, Pavel Machek wrote:
> Hi!
> 
> > > Many thanks for taking care of this!
> > > 
> > > We already have a patch in -mm, s2ram-kill-old-debugging-junk.patch from Pavel
> > > (http://marc.info/?l=linux-mm-commits&m=118737955611331&w=1), that removes the
> > > #ifdefed blocks and it clashes with your first patch a bit.
> > > 
> > > FYI, I have rebased your first patch on top of the Pavel's patch:
> > > http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc6/patches/39-acpi-video-mode-fix.patch
> > > 
> > 
> > Thanks Rafael,
> > 
> > However, I need to send something upstream to Linus for this kernel
> > cycle, so I don't want to base it on an -mm patch.  There are two
> > alternatives, obviously: 1. send my patch in now based on the "change as
> > little as necessary to fix the immediate problem" and then rebase
> > Pavel's patch on top of mine, or 2. for me to send both Pavel's patch
> > and the rebased patch upstream.
> > 
> > Personally, I would prefer to avoid strategy 2 at this late stage in the
> > 2.6.23-rc series.
> 
> Agreed we should have the fix in 2.6.23... Actually doing 2 does not
> seem like a big problem, my patch is pretty straight cleanup (and may
> even fix some machines, as we avoid touching video ram)... But
> resolving conflict is not hard, either; I know, I did it :-).

OK, let's take path 1, then.

Greetings,
Rafael

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-13 21:37 ACPI video mode patch review H. Peter Anvin
                   ` (2 preceding siblings ...)
  2007-09-16 20:08 ` Rafael J. Wysocki
@ 2007-09-20 14:19 ` Jiri Kosina
  2007-09-20 14:22   ` Jeff Chua
  3 siblings, 1 reply; 11+ messages in thread
From: Jiri Kosina @ 2007-09-20 14:19 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Pavel Machek, Jeff Chua, Linux Kernel Mailing List

On Thu, 13 Sep 2007, H. Peter Anvin wrote:

> Pavel, want to look at the patch before sending it to Linus?

Hi,

sorry for this taking too long, I was physically located away from the 
hardware. 

Without your patch, after resume I got corrupted image (looked like 
remains of BIOS POST graphics, in bad resolution, or something like that).

With your patch applied, I get no video at all after resume (I tried all 
three possible combinations of acpi_sleep parameter).

-- 
Jiri Kosina

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-20 14:19 ` Jiri Kosina
@ 2007-09-20 14:22   ` Jeff Chua
  2007-09-20 14:37     ` Jiri Kosina
  0 siblings, 1 reply; 11+ messages in thread
From: Jeff Chua @ 2007-09-20 14:22 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: H. Peter Anvin, Pavel Machek, Linux Kernel Mailing List

On 9/20/07, Jiri Kosina <jikos@jikos.cz> wrote:

> With your patch applied, I get no video at all after resume (I tried all
> three possible combinations of acpi_sleep parameter).

Can you please try again with 2.6.23-rc7. The patch is already
included in -rc7 and it works for me on Lenono X60s.

Jeff.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-20 14:22   ` Jeff Chua
@ 2007-09-20 14:37     ` Jiri Kosina
  2007-09-20 14:51       ` Jeff Chua
  0 siblings, 1 reply; 11+ messages in thread
From: Jiri Kosina @ 2007-09-20 14:37 UTC (permalink / raw)
  To: Jeff Chua; +Cc: H. Peter Anvin, Pavel Machek, Linux Kernel Mailing List

On Thu, 20 Sep 2007, Jeff Chua wrote:

> > With your patch applied, I get no video at all after resume (I tried all
> > three possible combinations of acpi_sleep parameter).
> Can you please try again with 2.6.23-rc7. The patch is already
> included in -rc7 and it works for me on Lenono X60s.

With current -git, I still get the same behavior as with 
previous 2.6.23-rcX kernels - i.e. after resume (with 
acpi_sleep=s3_bios,s3_mode), I get corrupted image resembling the BIOS 
POST graphics.

Previous kernels (I am currently pretty sure that 
15028aad00ddf241581fbe74a02ec89cbb28d35d was OK, but I haven't done the 
bisection yet) resumed perfectly with acpi_sleep=s3_bios,s3_mode on this 
machine.

Please note that this is very different HW than you have - it is sort-of a 
desktop machine, not a notebook at all.

-- 
Jiri Kosina

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: ACPI video mode patch review
  2007-09-20 14:37     ` Jiri Kosina
@ 2007-09-20 14:51       ` Jeff Chua
  0 siblings, 0 replies; 11+ messages in thread
From: Jeff Chua @ 2007-09-20 14:51 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: H. Peter Anvin, Pavel Machek, Linux Kernel Mailing List

On 9/20/07, Jiri Kosina <jikos@jikos.cz> wrote:
> On Thu, 20 Sep 2007, Jeff Chua wrote:
>

> With current -git, I still get the same behavior as with
> previous 2.6.23-rcX kernels - i.e. after resume (with
> acpi_sleep=s3_bios,s3_mode), I get corrupted image resembling the BIOS
> POST graphics.
>
> Previous kernels (I am currently pretty sure that
> 15028aad00ddf241581fbe74a02ec89cbb28d35d was OK, but I haven't done the
> bisection yet) resumed perfectly with acpi_sleep=s3_bios,s3_mode on this
> machine.
>
> Please note that this is very different HW than you have - it is sort-of a
> desktop machine, not a notebook at all.

Sorry, with -rc7, still needs the patch. Apparently it's still not
included in the -rc7 kernel.

It might already be in the latest git, but just want to be sure that's the case.

Jeff.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2007-09-20 14:52 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-13 21:37 ACPI video mode patch review H. Peter Anvin
2007-09-13 23:23 ` Jeff Chua
2007-09-14  9:25 ` Pavel Machek
2007-09-16 20:08 ` Rafael J. Wysocki
2007-09-16 20:53   ` H. Peter Anvin
2007-09-16 20:59     ` Pavel Machek
2007-09-16 22:04       ` Rafael J. Wysocki
2007-09-20 14:19 ` Jiri Kosina
2007-09-20 14:22   ` Jeff Chua
2007-09-20 14:37     ` Jiri Kosina
2007-09-20 14:51       ` Jeff Chua

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.