Re: [Bugme-new] [Bug 8378] New: Averatec 3156X laptop doesn't reboot with kernels > 2.6.13.5 (responsible commit found)

[Truxton Fulton <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 */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/