Bug 8378

Summary: Averatec 3156X laptop doesn't reboot with kernels > 2.6.13.5 (responsible commit found)
Product: Power Management Reporter: Lee Garrett (lee-in-berlin)
Component: OtherAssignee: power-management_other
Status: CLOSED CODE_FIX    
Severity: normal CC: andi-bz, protasnb, venki
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.14 till 2.6.21 Subsystem:
Regression: --- Bisected commit-id:

Description Lee Garrett 2007-04-27 10:42:22 UTC
Most recent kernel where this bug did *NOT* occur: 2.6.13.5

Distribution: Debian
Hardware Environment: Averatec 3156X (seemingly identical to the american model
3150P)
Software Environment:?
Problem Description:
I noticed that with recent kernels my laptop would reboot when I do an 'init 6',
but hang at the end of the init run. The last working vanilla kernel is
2.6.13.5. With some trying and a bit of guessing I found a change to
include/asm-i386/mach-default/mach_reboot.h in 2.6.14 to be the culprit. It can
be found at:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.14.y.git;a=commitdiff;h=59f4e7d572980a521b7bdba74ab71b21f5995538

On a 2.6.21 source tree I can revert this patch, and then rebooting works.

Steps to reproduce:
1) On a Averatec 3156X (or 3150p?) boot to your default runlevel.
2) as root, type "init 6".
3) instead of rebooting, the system will hang at the end with a blank screen.

Greetings, Lee

P.S: I'm not sure if I assigned this bug to the right category. Assign if needed.
Comment 1 Lee Garrett 2007-05-12 12:36:08 UTC
Truxton Fulton wrote:
> Hi,
> 
> I verified on my IDEQ210M that performing the old reboot sequence
> followed by the new reboot sequence works for me, and I suspect that
> it will work for Lee also.  Like this :
> 
> 	/* old method, works on most machines */
>         for (i = 0; i < 100; i++) {
>                 kb_wait();
>                 udelay(50);
>                 outb(0xfe, 0x64);         /* pulse reset low */
>                 udelay(50);
>         }
> 
> 	/* new method, sets the "System flag" which when set,
> 	   indicates successful completion of the keyboard controller
> 	   self-test (Basic Assurance Test, BAT).  This is needed
> 	   for some machines with no keyboard plugged in */
>         for (i = 0; i < 100; i++) {
>                 kb_wait();
>                 udelay(50);
>                 outb(0x60, 0x64);         /* write Controller Command Byte */
>                 udelay(50);
>                 kb_wait();
>                 udelay(50);
>                 outb(0x14, 0x60);         /* set "System flag" */
>                 udelay(50);
>                 kb_wait();
>                 udelay(50);
>                 outb(0xfe, 0x64);         /* pulse reset low */
>                 udelay(50);
>         }
> 
> Thanks,
> 
> -Truxton

Hello everyone,

I compiled a 2.6.21.1 kernel with Truxton's suggestion mentioned 
above. My laptop reboots normally with it. For convenience I've 
diffed a patch, which is appended to this mail.

Regards,
Lee
--- a/include/asm-i386/mach-default/mach_reboot.h	2007-05-11 16:12:56.000000000 +0200
+++ b/include/asm-i386/mach-default/mach_reboot.h	2007-05-11 16:13:54.000000000 +0200
@@ -19,20 +19,32 @@
 static inline void mach_reboot(void)
 {
 	int i;
-	for (i = 0; i < 10; i++) {
-		kb_wait();
-		udelay(50);
-		outb(0x60, 0x64);	/* write Controller Command Byte */
-		udelay(50);
-		kb_wait();
-		udelay(50);
-		outb(0x14, 0x60);	/* set "System flag" */
-		udelay(50);
-		kb_wait();
-		udelay(50);
-		outb(0xfe, 0x64);	/* pulse reset low */
-		udelay(50);
-	}
+	/* old method, works on most machines */
+        for (i = 0; i < 100; i++) {
+                kb_wait();
+                udelay(50);
+                outb(0xfe, 0x64);         /* pulse reset low */
+                udelay(50);
+        }
+
+	/* new method, sets the "System flag" which when set,
+	   indicates successful completion of the keyboard controller
+	   self-test (Basic Assurance Test, BAT).  This is needed
+	   for some machines with no keyboard plugged in */
+        for (i = 0; i < 100; i++) {
+                kb_wait();
+                udelay(50);
+                outb(0x60, 0x64);         /* write Controller Command Byte */
+                udelay(50);
+                kb_wait();
+                udelay(50);
+                outb(0x14, 0x60);         /* set "System flag" */
+                udelay(50);
+                kb_wait();
+                udelay(50);
+                outb(0xfe, 0x64);         /* pulse reset low */
+                udelay(50);
+        }
 }
 
 #endif /* !_MACH_REBOOT_H */
Comment 2 Anonymous Emailer 2007-05-13 05:14:17 UTC
Reply-To: trux@truxton.com

Andrew Morton wrote (at Sat, 12 May 2007 18:02:40 -0700) :
> 
> 
> On Sat, 12 May 2007 21:35:58 +0200 Lee Garrett <lee-in-berlin@web.de> wrote:
> 
>> Truxton Fulton wrote:
>> > Hi,
>> > 
>> > I verified on my IDEQ210M that performing the old reboot sequence
>> > followed by the new reboot sequence works for me, and I suspect that
>> > it will work for Lee also.  Like this :
>> > 
>> > 	/* old method, works on most machines */
>> >         for (i = 0; i < 100; i++) {
>> >                 kb_wait();
>> >                 udelay(50);
>> >                 outb(0xfe, 0x64);         /* pulse reset low */
>> >                 udelay(50);
>> >         }
>> > 
>> > 	/* new method, sets the "System flag" which when set,
>> > 	   indicates successful completion of the keyboard controller
>> > 	   self-test (Basic Assurance Test, BAT).  This is needed
>> > 	   for some machines with no keyboard plugged in */
>> >         for (i = 0; i < 100; i++) {
>> >                 kb_wait();
>> >                 udelay(50);
>> >                 outb(0x60, 0x64);         /* write Controller Command Byte */
>> >                 udelay(50);
>> >                 kb_wait();
>> >                 udelay(50);
>> >                 outb(0x14, 0x60);         /* set "System flag" */
>> >                 udelay(50);
>> >                 kb_wait();
>> >                 udelay(50);
>> >                 outb(0xfe, 0x64);         /* pulse reset low */
>> >                 udelay(50);
>> >         }
>> > 
>> > Thanks,
>> > 
>> > -Truxton
>> 
>> Hello everyone,
>> 
>> I compiled a 2.6.21.1 kernel with Truxton's suggestion mentioned 
>> above. My laptop reboots normally with it. For convenience I've 
>> diffed a patch, which is appended to this mail.
>> 
> 
> OK, thanks.
> 
> So that are we doing here?  We try the pre-Truxton code and if that didn't
> work we try the post-Truxton code?  Hard to see how that could go wrong.
> 
> Truxton, can you please test it for us?

Hi,

Segher suggested a better implementation that did a read-modify-write
sequence.  I tested a few different combinations of these rebooting
approaches, and found that each one individually correctly rebooted
my headless machine (Biostar iDEQ 210M with VIA PM800 + VT8237 chipset).

A = original "pulse reset low"
B = my patch that sets the system flag (with possibly bad assumptions about other flags)
C = Segher's read-modify-write to set only the system flag.

So, the bad news is that I no longer have a baseline test
(because A works for me now).  I updated the bios a while ago,
and this is a different physical machine than the others I
was testing last year (which are now in production and I
cannot use to test), although the model is the same.

So, if you want to revert my patch all together, that's fine.
I think a foolproof reboot sequence would be A followed by C.

So here is my recommendation, which I have verified works on
my current machine :

Thanks,

-Truxton


--- mach_reboot.h.orig  2007-05-13 05:04:43.000000000 -0700
+++ mach_reboot.h       2007-05-13 05:01:02.000000000 -0700
@@ -19,20 +19,42 @@
 static inline void mach_reboot(void)
 {
        int i;
-       for (i = 0; i < 100; i++) {
-               kb_wait();
-               udelay(50);
-               outb(0x60, 0x64);       /* write Controller Command Byte */
-               udelay(50);
-               kb_wait();
-               udelay(50);
-               outb(0x14, 0x60);       /* set "System flag" */
-               udelay(50);
-               kb_wait();
-               udelay(50);
-               outb(0xfe, 0x64);       /* pulse reset low */
-               udelay(50);
-       }
+       u8 cmd ;
+
+
+       /* old method, works on most machines */
+        for (i = 0; i < 100; i++) {
+         kb_wait();
+         udelay(50);
+         outb(0xfe, 0x64);         /* pulse reset low */
+         udelay(50);
+        }
+
+       /* new method, sets the "System flag" which when set,
+          indicates successful completion of the keyboard controller
+          self-test (Basic Assurance Test, BAT).  This is needed
+          for some machines with no keyboard plugged in.
+          This read-modify-write sequence sets only the system flag. */
+        for (i = 0; i < 100; i++) {
+         outb(0x20, 0x64);       /* read Controller Command Byte */
+         udelay(50);
+         kb_wait();
+         udelay(50);
+         cmd = inb(0x60);
+         udelay(50);
+         kb_wait();
+         udelay(50);
+         outb(0x60, 0x64);       /* write Controller Command Byte */
+         udelay(50);
+         kb_wait();
+         udelay(50);
+         outb(cmd | 0x04, 0x60); /* set "System flag" */
+         udelay(50);
+         kb_wait();
+         udelay(50);
+         outb(0xfe, 0x64);         /* pulse reset low */
+         udelay(50);
+        }
 }
 
 #endif /* !_MACH_REBOOT_H */

Comment 3 Natalie Protasevich 2007-06-04 12:01:32 UTC
Hi Truxton,
Are you planning to submit the patch?
Thanks,
--Natalie
Comment 4 Anonymous Emailer 2007-10-02 19:31:07 UTC
Reply-To: trux@truxton.com

Andrew Morton wrote (at Sat, 12 May 2007 18:02:40 -0700) :
> 
> OK, thanks.
> 
> So that are we doing here?  We try the pre-Truxton code and if that didn't
> work we try the post-Truxton code?  Hard to see how that could go wrong.
> 
> Truxton, can you please test it for us?

Hi,

Hiroto Shibuya wrote to tell me that he has a VIA EPIA-EK10000
which suffers from the reboot problem when no keyboard is attached.
My first patch works for him :

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59f4e7d572980a521b7bdba74ab71b21f5995538

But the latest patch does not work for him :

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8b93789808756bcc1e5c90c99f1b1ef52f839a51

We found that it was necessary to also set the "disable keyboard"
flag in the command byte, as the first patch was doing.  The
second patch tries to minimally modify the command byte, but
it is not enough.

Please consider this simple one-line patch to help people with
low end VIA motherboards reboot when no keyboard is attached.
Hiroto Shibuya has verified that this works for him (as I
no longer have an afflicted machine) :

This patch is against linux-2.6.23-rc9/include/asm-i386/mach-default/mach_reboot.h

--- mach_reboot.h       Mon Oct  1 20:24:52 2007
+++ mach_reboot.h.new   Tue Oct  2 19:22:13 2007
@@ -49,7 +49,7 @@
                udelay(50);
                kb_wait();
                udelay(50);
-               outb(cmd | 0x04, 0x60); /* set "System flag" */
+               outb(cmd | 0x14, 0x60); /* set "System flag" and "Keyboard Disabled" */
                udelay(50);
                kb_wait();
                udelay(50);


Thanks,

-Truxton
Comment 5 Anonymous Emailer 2007-11-01 08:50:48 UTC
Reply-To: aris@ruivo.org

Hi Andrew,
> > OK, thanks.
> > 
> > So that are we doing here?  We try the pre-Truxton code and if that didn't
> > work we try the post-Truxton code?  Hard to see how that could go wrong.
> > 
> > Truxton, can you please test it for us?
> 
> Hiroto Shibuya wrote to tell me that he has a VIA EPIA-EK10000
> which suffers from the reboot problem when no keyboard is attached.
> My first patch works for him :
> 
>  
>   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59f4e7d572980a521b7bdba74ab71b21f5995538
> 
> But the latest patch does not work for him :
> 
>  
>   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8b93789808756bcc1e5c90c99f1b1ef52f839a51
> 
> We found that it was necessary to also set the "disable keyboard"
> flag in the command byte, as the first patch was doing.  The
> second patch tries to minimally modify the command byte, but
> it is not enough.
> 
> Please consider this simple one-line patch to help people with
> low end VIA motherboards reboot when no keyboard is attached.
> Hiroto Shibuya has verified that this works for him (as I
> no longer have an afflicted machine) :
> 
> This patch is against
> linux-2.6.23-rc9/include/asm-i386/mach-default/mach_reboot.h
> 
> --- mach_reboot.h       Mon Oct  1 20:24:52 2007
> +++ mach_reboot.h.new   Tue Oct  2 19:22:13 2007
> @@ -49,7 +49,7 @@
>                 udelay(50);
>                 kb_wait();
>                 udelay(50);
> -               outb(cmd | 0x04, 0x60); /* set "System flag" */
> +               outb(cmd | 0x14, 0x60); /* set "System flag" and "Keyboard
> Disabled" */
>                 udelay(50);
>                 kb_wait();
>                 udelay(50);
> 
> 
any chance to get this into next -mm?
Comment 6 Anonymous Emailer 2007-11-01 10:53:10 UTC
Reply-To: akpm@linux-foundation.org

On Thu, 1 Nov 2007 11:50:31 -0400 Aristeu Rozanski <aris@ruivo.org> wrote:

> > --- mach_reboot.h       Mon Oct  1 20:24:52 2007
> > +++ mach_reboot.h.new   Tue Oct  2 19:22:13 2007
> > @@ -49,7 +49,7 @@
> >                 udelay(50);
> >                 kb_wait();
> >                 udelay(50);
> > -               outb(cmd | 0x04, 0x60); /* set "System flag" */
> > +               outb(cmd | 0x14, 0x60); /* set "System flag" and "Keyboard
> Disabled" */
> >                 udelay(50);
> >                 kb_wait();
> >                 udelay(50);
> > 
> > 
> any chance to get this into next -mm?

Is is, as i386-fix-reboot-with-no-keyboard-attached.patch
Comment 7 Anonymous Emailer 2007-11-01 11:06:31 UTC
Reply-To: aris@ruivo.org

> > any chance to get this into next -mm?
> 
> Is is, as i386-fix-reboot-with-no-keyboard-attached.patch
Thanks!
Comment 8 ykzhao 2009-02-11 21:48:48 UTC
HI, Lee
    How about the status of this bug? Will you please confirm whether this bug still exists on the latest kernel?
    If yes, will you please attach the output of acpidump, lspci -vxxx?
    Thanks.
Comment 9 Lee Garrett 2009-02-12 06:54:32 UTC
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8378
> 
> 
> 
> 
> 
> ------- Comment #8 from yakui.zhao@intel.com  2009-02-11 21:48 -------
> HI, Lee
>     How about the status of this bug? Will you please confirm whether this
>     bug
> still exists on the latest kernel?
>     If yes, will you please attach the output of acpidump, lspci -vxxx?
>     Thanks.
> 
> 

Hello there,

with current kernels this bug does not occur to me. I think it was fixed in
2.6.21.x or in 2.6.22. Sorry for keeping this bug open!

Regards,
Lee