Bug 170188 - Machine hanging on (remote) reboot: psmouse.c: bad data from KBC - timeout
Machine hanging on (remote) reboot: psmouse.c: bad data from KBC - timeout
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-08 10:35 EDT by Chris Chabot
Modified: 2012-06-20 09:19 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:19:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Chabot 2005-10-08 10:35:08 EDT
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 13:06:45 EDT
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 13:23:05 EDT
Thanks Suzanne, i'll file one of those too :-)
Comment 8 Jiri Pallich 2012-06-20 09:19:45 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.