Bug 153851 - [keyboard] keyboard issues on new Intel Mother boards.
Summary: [keyboard] keyboard issues on new Intel Mother boards.
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: i386 (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-i386 mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-10 16:10 UTC by Spencer Minear
Modified: 2017-12-31 22:32 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Spencer Minear 2011-01-10 16:10:09 UTC
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.

Fix: 

Our initial actions are outlined in the problem description
How-To-Repeat: Watch a boot and run a shudown -h.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2011-01-11 01:47:12 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-i386

reclassify.
Comment 2 Remko Lodder freebsd_committer 2011-03-30 06:36:39 UTC
Responsible Changed
From-To: freebsd-i386->freebsd-usb

There are reports that this might be USB related, can you have a look 
and confirm please?
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:42 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped