Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 80332

Summary:	Lockup at screen after mouse probing
Product:	[Retired] Red Hat Linux	Reporter:	Michael Schwendt <bugs.michael>
Component:	anaconda	Assignee:	Jeremy Katz <katzj>
Status:	CLOSED DUPLICATE	QA Contact:	Mike McLean <mikem>
Severity:	high	Docs Contact:
Priority:	medium
Version:	9	CC:	notting, redhat-bugzilla, wtogami
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:	2006-02-21 18:50:33 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:
Bug Depends On:
Bug Blocks:	79578

Description Michael Schwendt 2002-12-24 16:04:21 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203

Description of problem:
Probing of hardware finds graphics adapter and monitor, but "no mouse". The
installer prints a dialog box with the title "Mouse not detected" and a summary
of what has happened and that I must install via text mode. At the bottom of the
dialog are two buttons "OK" and "Use text mode". Unfortunately, at that point
the system is locked up and does not accept any input. No key presses possible,
neither TAB nor switching to the virtual consoles.

Suffice to say, mouse detection worked flawlessly with older versions of Red Hat
Linux, including the Limbo and (null) betas. My mouse is a classic 3-button
serial mouse from Logitech on /dev/ttyS1. Kernel info from Valhalla:

02f8-02ff : serial(auto)
03f8-03ff : serial(auto)

Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ
SERIAL_PCI ISAPNP enabled
ttyS0 at 0x03f8 (irq = 4) is a 16550A
ttyS1 at 0x02f8 (irq = 3) is a 16550A

I'm going to post the kernel info from the installer later. Maybe it gives a clue.


How reproducible:
Always

Comment 1 Michael Schwendt 2002-12-24 20:11:01 UTC

Booting with "linux text" and "linux text noprobe" locks up at the "Welcome to
Red Hat Linux" screen.

Booting with "linux acpi=off" fails, too.

Comment 2 Bill Nottingham 2002-12-24 21:40:17 UTC

Does it work if you unplug the mouse, out of curiousity?

Comment 3 Michael Schwendt 2002-12-24 22:04:12 UTC

No. Same symptoms.

To make it more clear. "Probing for mouse: No - mouse" most likely is not
causing the crash. That it doesn't find my mouse is just a minor detail which
differs from previous versions and betas of Red Hat Linux.

It's the next screen where the installer locks up.

Comment 4 Bill Nottingham 2002-12-24 22:18:34 UTC

Yeah, but I'm guessing something odd in the PS/2 mouse probe is locking up the
keyboard.

Comment 5 Nathan G. Grennan 2002-12-25 02:16:51 UTC

I think this bug is duplicate of #80293, unless you want to redefine it has the
mouse isn't detect properly. The mouse isn't detected and so he is forced to do
a text install, but then he runs into the problem with the keyboard not working
at all after a certain point. I don't think it is related to the ps/2 mouse
since I have a usb mouse and the keyboard stops working.

Comment 6 Nathan G. Grennan 2002-12-25 05:05:33 UTC

This bug is a duplicate of #80293.

Here is what I discovered:

Did more testing and figured out why my second computer worked and my main
computer didn't. On both computers if there was no mouse you got no keyboard in
the text installer. On both computers if you used a USB mouse you got no
keyboard in the GUI and text installer. On both computers if you used a PS/2
mouse or USB mouse with PS/2 adapter the keyboard worked in the text and GUI
installer. So now we have a workaround.

Comment 7 Nathan G. Grennan 2002-12-25 05:09:44 UTC

To clarify this is with a PS/2 keyboard and I tried two different PS/2 keyboard.
One with straight PS/2 and one AT with PS/2 adapter.

Comment 8 Michael Schwendt 2002-12-25 12:33:53 UTC

Yes, bug #80293 looks like it deals with a similar problem. But only at this
later stage when Bill mentioned it could be keyboard-related. Since I had run CD
#1 through the media-check just fine (although I have had checked the CD with
md5sum before) and skipping the media-check had not killed my keyboard either, I
have assumed the deadlock might be something else.

Comment 9 Nathan G. Grennan 2002-12-25 18:24:38 UTC

I have successfully run through a media check also. I just said skip cd check to
get right to the problem isn't of taking the time to check the media.

Comment 10 Michael Schwendt 2002-12-27 17:57:52 UTC


*** This bug has been marked as a duplicate of 80293 ***

Comment 11 Red Hat Bugzilla 2006-02-21 18:50:33 UTC

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.