>Number: 153851 >Category: misc >Synopsis: keyboard issues on new Intel Mother boards. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jan 10 16:10:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Spencer Minear >Release: Seen in our 6.x and 7.x based systems >Organization: McAfee >Environment: NA >Description: We have been working with two new Intel Mother boards, S3420GP and S5520HC. Both of these boards have no AT controller hardware and limited emulation of the 60/64 ports.
At system boot there is a long delay between the point when control is given to the loaded kernel and the first of the boot messages. The delay is due to the fact that the ports look alive, but the emulation does not support at least the controller diagnose self test or the keyboard port test functions. In both cases the command is accepted but no response is ever set and the existing driver code ends up doing long timeouts waiting for the response to the tests. We do not have a general solution for this as yet and simply bypass these tests when are on this hardware as detected by the symbios.planar information. Another problem is that the systems shutdown -h operation turns results in a hung system. This happens because the only path for keyboard input via the USB controllers. During the shutdown processing, before we reach the shutdown_halt function that spins waiting for keyboard input, the module shutdown is done. This results in calls to the uhci_shutdown and ehci_shutdown functions which send commands to the controller to stop in the uchi case and to reset in the ehci case. For reasons I do not know the stop of the uhci does not block keyboard input but the reset in the ehci does. Non the less when we need keyboard input and that data is via usb controllers, it is not good to do anything to the hardware. Our initial solution is to expose the shutdown howto value and detect that state in the USB drivers and if RB_HALT is set, we do not change the hardware state. >How-To-Repeat: Watch a boot and run a shudown -h. >Fix: Our initial actions are outlined in the problem description >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
