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