This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 231768 - [RHEL4] VIA EPIA-EK10000 does not reboot without PS/2 keyboard attached
[RHEL4] VIA EPIA-EK10000 does not reboot without PS/2 keyboard attached
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.5
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Aristeu Rozanski
Martin Jenner
http://git.kernel.org/?p=linux/kernel...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-11 09:09 EDT by Hiroto Shibuya
Modified: 2012-06-20 09:24 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 09:24:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch to pull in the fix from 2.6.15 kernel (652 bytes, patch)
2007-03-11 09:09 EDT, Hiroto Shibuya
no flags Details | Diff
test patch (1.42 KB, patch)
2007-10-02 12:53 EDT, Aristeu Rozanski
no flags Details | Diff

  None (edit)
Description Hiroto Shibuya 2007-03-11 09:09:42 EDT
Description of problem:

VIA EPIA-EK10000 motherboard does not reboot if PS/2 keyboard is not attached.

http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=420


Version-Release number of selected component (if applicable):


How reproducible:

100% on all the system I have with this motherboard.

Steps to Reproduce:
1. Boot system without PS/2 keyboard attached
2. remote login to the system (either serial console, ssh)
3. # reboot
  
Actual results:

After the last printk message "Restarting system.", system does not reboot
and hang.

Expected results:

System reboots.

Additional info:

Fedore Core 4 with 2.6.11 kernel exhibit the same problem but Fedora Core 5 with 2.6.15 kernel
reboot fine on those motherboards.  Comparing the differences around the reboot code, 
pulling in the single change to a inline function mach_reboot from 2.6.15 (or somewhere 
between .11 and .15) into 2.6.9 resolved the reboot problem on those particular motherboard. 
(please refer to the attached patch).   

This may resolve the following bug too:

Reboot failure on AMD64 when no keyboard attached
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227808
Comment 1 Hiroto Shibuya 2007-03-11 09:09:42 EDT
Created attachment 149791 [details]
patch to pull in the fix from 2.6.15 kernel
Comment 2 Hiroto Shibuya 2007-06-15 11:45:25 EDT
Still issue with 2.6.9-55 in 4.6.  My assumption is that this affect more than this particular 
class of motherboard.  Since it is such a safe and straight forward back merge from 
the future version of kernel, I would appreciate if this is considered for 4.6 update.
Comment 3 Hiroto Shibuya 2007-09-27 21:06:47 EDT
To add credibility, I attached a reference to the original commit in 2.6.16 stable tree.
Comment 4 Aristeu Rozanski 2007-10-02 12:53:33 EDT
Created attachment 213701 [details]
test patch

patch based on commits
59f4e7d572980a521b7bdba74ab71b21f5995538
8b93789808756bcc1e5c90c99f1b1ef52f839a51
Comment 5 Aristeu Rozanski 2007-10-02 12:58:38 EDT
Hiroto, please test the kernel available in
    http://people.redhat.com/arozansk/reboot/
or just apply the patch I've attached here and let me know the results.
I don't have any machine VIA based available. I suspect the new box I got at
home is VIA based. I'll check at night.
Comment 6 Hiroto Shibuya 2007-10-02 14:08:33 EDT
Thanks Aristeu.  Unfortunately, that kernel didn't reboot.  

I see that you pulled in the latest patch from 2.6.23-rc which 
has some added logic about reading command control byte. That seems to 
be not working out with my VIA MB for some reason. 

Is it too much to ask to exclude the lastest change and just 
apply the one in between?

Or I should figure out how to make this new code with VIA
and send in patch again 2.6.23-rc.

Do you know of any documentation in this area I can refer to.  
Comment 7 Hiroto Shibuya 2007-10-02 14:32:48 EDT
I mailed Truxton Fulton, the original author of those patches for information. 
Comment 8 Hiroto Shibuya 2007-10-02 22:27:32 EDT
Got response back from Mr. Fulton.  After making the change he suggested, it rebooted 
fine on my MB.

----
Hello Hiroto-san,

Do you mean that my original patch (59f4e7d572980a521b7bdba74ab71b21f5995538)
fixes your reboot problem, but the new patch (8b93789808756bcc1e5c90c99f1b1ef52f839a51)
does not work?

When I debugged this problem, I found that the keyboard controller
would refuse to pulse the reset low if there was no keyboard attached.
Forcing the system flag to 1 seemed to satisfy the VIA chip,
and the reboot could proceed.

I used google to find documentation for the AT keyboard controller.
Here are some links :
 http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-8.html
 http://www.computer-engineering.org/ps2keyboard/

Unfortunately, I no longer have access to a machine with the
rebooting problem, so I was unable to verify that my second patch
worked for machines that could not reboot normally.

Perhaps the controller command byte need to have
_EN (Disable keyboard) also set (which is what the first patch did).
Can you please try changing this line :

                outb(cmd | 0x04, 0x60); /* set "System flag" */

to this :

                outb(cmd | 0x14, 0x60); /* set "System flag" and "Disable Keyboard" */

To see if that works for you?

Thanks,

-Truxton
Comment 9 Hiroto Shibuya 2007-10-02 23:24:52 EDT
Related kernel bugzilla entry.  Mr. Fulton posted additional patch with above change
against 2.6.23-rc9 at the bottom.

http://bugzilla.kernel.org/show_bug.cgi?id=8378
Comment 10 Aristeu Rozanski 2007-10-03 09:11:35 EDT
Hiroto,
I saw Truxton message on lkml. Before including the fix, I have to wait for it
to be included into Linus' tree. I've just checked for the fix and it's not
included yet. Do you need a new test kernel with this patch included?
Comment 11 Hiroto Shibuya 2007-10-03 09:29:06 EDT
I have tested it myself so I'm confident the patch itself is ok.  

If you have to wait for commit in main tree anyway, and for me to test right now
will not speed up the process, I can wait.
Comment 12 Aristeu Rozanski 2007-11-12 09:40:06 EST
It's on -mm but not pulled into Linus' tree yet.
Comment 13 Aristeu Rozanski 2007-11-20 11:03:45 EST
The patch is upstream:
05dfa35e84331c6921ab394463069e9376f0bd76
Comment 14 Aristeu Rozanski 2007-11-21 14:27:52 EST
Hiroto,
the test kernels are on:
http://people.redhat.com/arozansk/kernel-2.6.9-60.EL.reboot.i686.rpm
http://people.redhat.com/arozansk/kernel-smp-2.6.9-60.EL.reboot.i686.rpm

please test and let me know how it goes.

Thanks
Comment 15 Hiroto Shibuya 2007-11-21 15:29:10 EST
Hmm, sorry to say that it didn't work, although commit 05dfa35e84331c6921ab394463069e9376f0bd76
looks good.  Could you upload the source RPM so I can take a look?
Comment 16 Aristeu Rozanski 2007-11-21 15:37:16 EST
It's on
http://people.redhat.com/arozansk/kernel-2.6.9-60.EL.reboot.src.rpm
the patch is linux-kernel-test.patch

It seems there's something else missing
Comment 17 Hiroto Shibuya 2007-11-21 16:28:48 EST
Aristeu, you added the variable "cmd" as "int" while on the main line 
it is "u8". 

Since this is an include file with only two short inline functions defined, 
and all we are doing is to patch it up to be identical to the latest, 
isn't it easier to simply grab the copy of the latest and drop it in, 
rather than hand edit the source?  
Comment 18 Aristeu Rozanski 2007-11-21 16:49:28 EST
Nope, upstream cmd is int.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/asm-x86/mach-default/mach_reboot.h;hb=HEAD

Did you tried the last upstream version?
Comment 20 Jiri Pallich 2012-06-20 09:24:27 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

Note You need to log in before you can comment on or make changes to this bug.