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.
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 */
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 */
Hi Truxton, Are you planning to submit the patch? Thanks, --Natalie
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
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?
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
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!
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.
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