Bug 170188

Summary:	Machine hanging on (remote) reboot: psmouse.c: bad data from KBC - timeout
Product:	Red Hat Enterprise Linux 4	Reporter:	Chris Chabot <chabotc>
Component:	kernel	Assignee:	Pete Zaitcev <zaitcev>
Status:	CLOSED WONTFIX	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	4.0	CC:	benl, jbaron, lwang
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-20 13:19:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Chabot 2005-10-08 14:35:08 UTC

When we upgraded one of our servers to redhat enterprise server 4 update 4 it
refused to come back online.

After sending someone to the datacenter, he found that the error printed on
screen: "psmouse.c: bad data from KBC - timeout", and stopped booting there

This is after it was booted to the 2.6.9-22.EL (smp) kernel

After the machine was brought back online, dmesg is still slowly filling up with
errors:

psmouse.c: Mouse at isa0060/serio0/input0 lost synchronization, throwing 1 bytes
away.
psmouse.c: Mouse at isa0060/serio0/input0 lost synchronization, throwing 2 bytes
away.

Now the machine has had problems before, during 'firstboot' initialization the
last command that it tried to run was a set keymap command, which zombied and
restarted a lot of times, we finished rhn-register etc remotely so we could keep
using the machine. 

Oddly enough during install it all worked perfectly, it was after reboot that
this problem happened. It was initialy installed with RHEL 4 Update 1, wich had
kernel 2.6.9-11.EL

Now the fact that it doesn't have a working mouse isn't such a huge deal, its a
quad xeon servermanaged thru ssh so it can live without one, but that it stops
it from successfully rebooting is a big deal, next time we have to upgrade +
reboot it, or have a power crisis, it will mean traveling to the datacenter again.

We have about 14 rh el licences/servers of the same kind of configuration, but
without this behaviour, so i expect its a faulty bit of hardware for the mouse?
(speculation) but still thats no reason to keep the server from rebooting :-)

Comment 1 Suzanne Hillman 2005-10-11 17:06:45 UTC

This looks like something for which you would be best off going through support,
as Bugzilla is not an official support channel, has no response guarantees, and
may not route your issue to the correct area to assist you. In order to file a
support issue, please either contact Red Hat's Technical Support line at
888-GO-REDHAT or file a web ticket at http://www.redhat.com/apps/support/. 
Using the official support channels above will guarantee that your issue is
handled appropriately and routed to the individual or group which can best
assist you with this issue and will also allow Red Hat to track the issue,
ensuring that any applicable bug fix is included in all releases and is not
dropped from a future update or major release.

Comment 2 Chris Chabot 2005-10-11 17:23:05 UTC

Thanks Suzanne, i'll file one of those too :-)

Comment 8 Jiri Pallich 2012-06-20 13:19:45 UTC

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.