Bug 80332 - Lockup at screen after mouse probing
Lockup at screen after mouse probing
Status: CLOSED DUPLICATE of bug 80293
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
9
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks: 79578
  Show dependency treegraph
 
Reported: 2002-12-24 11:04 EST by Michael Schwendt
Modified: 2008-01-17 12:49 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:50:33 EST
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 Michael Schwendt 2002-12-24 11:04:21 EST
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 15:11:01 EST
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 16:40:17 EST
Does it work if you unplug the mouse, out of curiousity?
Comment 3 Michael Schwendt 2002-12-24 17:04:12 EST
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 17:18:34 EST
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-24 21:16:51 EST
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 00:05:33 EST
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 00:09:44 EST
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 07:33:53 EST
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 13:24:38 EST
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 12:57:52 EST

*** This bug has been marked as a duplicate of 80293 ***
Comment 11 Red Hat Bugzilla 2006-02-21 13:50:33 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.