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
On Sat, 12 May 2007 21:35:58 +0200 Lee Garrett <[email protected]> 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?
Andrew Morton wrote (at Sat, 12 May 2007 18:02:40 -0700) :
>
>
> On Sat, 12 May 2007 21:35:58 +0200 Lee Garrett <[email protected]> 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 */
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
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?
--
Aristeu
On Thu, 1 Nov 2007 11:50:31 -0400 Aristeu Rozanski <[email protected]> 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
> > any chance to get this into next -mm?
>
> Is is, as i386-fix-reboot-with-no-keyboard-attached.patch
Thanks!
--
Aristeu