SUMMARY: SparcII Keyboard HANGS (Long)

From: Steven Venema (steve@uw-isdl.ee.washington.edu)
Date: Fri Aug 28 1992 - 08:07:19 CDT


REVIEW:

> From steve
> To: sun-managers
> Subject: SparcII Keyboard HANGS
> Date: Tue Jul 21 14:41:08 1992
>
> PROBLEM-SUMMARY:
> SparcII KEYBOARD HANGS at login prompt after exiting X-windows.
>
> CONFIG: Sun SparcII, SunOS 4.1.1, MIT X11R5 + Fixes 1-8, no xdm
>
> BACKGROUND:
> As the X-server shuts down, the 4 keyboard LED's flash twice
> before the screen clears and the shell or login prompt is
> displayed.
>
> PROBLEM:
> About 10% of the time, after the keyboard lights flash the second
> time, the "Num-Lock" light stays on and the KEYBOARD IS COMPLETELY
> HUNG. The only way found to correct the problem is to reboot via
> remote login (the "L1-A" sequence doesn't work since the keyboard
> and/or the kbd driver is dead).
>
> CORRELATIONS:
> This problem *ONLY* happens on our SparcII's, not on our IPC's,
> 4/330 or 4/110. The kbd-lockup and 'Num-Lock' LED always occur
> together.
>
> What I've tried so far:
>
> The kb(4) streams module supports a "KBD_CMD_RESET" command
> which is supposed to "Reset keyboard as if power-up". I wrote
> a program to do this...no effect.

RESPONSES:

        I received several responses indicating that others were having
        this problem with their SparcII's too. A couple of people suggested
        using the "kbdmode -a" command...I forgot to mention in my original
        message that this was the first thing that I tried--it never worked.

        One person indicated that this problem has also happened on Sun IPX's.
        Another person indicated that this problem has also occurred with
        Sun Openwindows 3.0.

        One person indicated that remote login and starting openwindows
        when the keyboard is hung will fail, but it will diddle the
        keyboard enough to "bring it back from the dead". I haven't tried
        this; I changed the Xsun sources instead.

WORK-AROUND:

        Comments in the MIT/Sun X11R5 server code indicate that there is a
          problem with SparcI kbd driver ($MITX/src/server/ddx/sun/sunKbd.c)
        which requires that a minimum of 750 milliseconds must elapse between
        successive KIOCTRANS ioctl() calls to the keyboard driver.

        I added code to this routine to increase the time from 750ms to
        2000ms and also printed out a message indicating how much time
        actually elapsed.

        The combination of these changes has completely fixed the problem
        (no keyboard hangs in more than 4 weeks, as opposed to one or more
        occurrences every day before the changes were made). However, my
        delay-time checking code occasionally detected wait times less than
        what was requested. Therefore there are two possible explanations
        for this problem:

        1. The select() call used to implement the delay between
           successive KIOCTRANS ioctl() calls was/is not working
           consistently. Since my added code which prints out the true
           delay-time takes a *long* time to actually print out on the
           console, it is possible that the act of printing is masking
           a problem with the select() delay returning prematurely.

        2. The SparcII simply requires more than the 750ms required by the
           SparcI (as indicated by the comments in Sun's sunKbd.c file).

        I don't have the time to further track the source of this
        problem--my changes to the sunKbd.c routine have made the
        keyboard hangs disappear so I'm happy. I'm going to leave it
        to the folks at MIT and/or Sun to find out what is happening
        here (I've sent a bug-report on to MIT).

        In the meantime, if this problem is plaguing you, I'll be happy
        to email you a context-diff of the changes that I made to the
        Xsun server sources and/or a copy of the full bug-report that I
        sent to MIT. Hopefully, MIT or Sun will release an "official"
        fix soon...

        Of-course, if you choose to use my modifications, the maxim,
        "Caveat Emptor" ("Let the buyer beware") will apply...especially
        since the price is free ;-)

                                        -steve

                                        Steven Venema
                                        Dept. of Electrical Engineering
                                        University of Washington
                                        Seattle, Washington
                                        email: venema@ee.washington.edu

PS: Thanks to the following people for responding to my original plea
    to the sun-managers distribution:

        jimbo@crseo.ucsb.edu
        russ@MATH.ORST.EDU
        datri@lovecraft.convex.com
        ross@dseg.ti.com
        danny@ews7.dseg.ti.com
        jumper@spf.trw.com
        cook@stout.atd.ucar.EDU
        leg@inel.gov
        Perry_Hutchison.Portland@xerox.com



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:48 CDT