Bug 132042 - Xorg core pointer not loaded (causing unrecoverable X crash) when booting with kernel 2.6.8-1.541
Xorg core pointer not loaded (causing unrecoverable X crash) when booting wit...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-08 01:21 EDT by Michael Wiktowy
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-09 03:49:38 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)
X server log when failing while booting kernel 2.6.8-1.541 (46.27 KB, text/plain)
2004-09-08 01:24 EDT, Michael Wiktowy
no flags Details
X server log when sucessfully running with same config but while booting kernel 2.6.8-1.524 (46.04 KB, text/plain)
2004-09-08 01:27 EDT, Michael Wiktowy
no flags Details
xorg.conf before fix (3.69 KB, text/plain)
2004-09-08 18:49 EDT, John Ellson
no flags Details
Here is my xorg.conf ... (3.12 KB, text/plain)
2004-09-08 19:44 EDT, Michael Wiktowy
no flags Details

  None (edit)
Description Michael Wiktowy 2004-09-08 01:21:44 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
The system mouse is not being found when the Xorg server is loaded
when booting from kernel 2.6.8-1.541. Booting from 2.6.8-1.524 runs
the X server fine with no other changes.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. boot with kernel 2.6.8-1.541 into a rhgb
2.
3.
    

Actual Results:  Screen goes blank after initializing hardware
message. Cannot switch to a console using alt+crtl+F*. Login does not
fall back to non-graphical mode.

Expected Results:  Expect to see rhgb start normally or, if there are
problems, fail gracefully to a text login prompt or be able to switch
to a console.

Additional info:
ATI 8500 AIW video card
I have a KVM switch
Comment 1 Michael Wiktowy 2004-09-08 01:24:56 EDT
Created attachment 103574 [details]
X server log when failing while booting kernel 2.6.8-1.541
Comment 2 Michael Wiktowy 2004-09-08 01:27:03 EDT
Created attachment 103575 [details]
X server log when sucessfully running with same config but while booting kernel 2.6.8-1.524
Comment 3 Bill Nottingham 2004-09-08 15:42:08 EDT
What's your xorg.conf?

What happens if you change the device from /dev/mouse to /dev/input/mice?
Comment 4 John Ellson 2004-09-08 18:48:22 EDT
I'm not the original poster, but that fixed it for me.

The incompatibilty is present in all kernels after 2.6.8-1.533

Why does X care if it has an pointer device?   It certainly shouldn't
crash the system just because it can't find one.

I'll attach my xorg.conf as it was *before* changing /dev/mouse to
/dev/input/mice

I verified that I can still use both the USB and the PS2 mouse after
the change.
Comment 5 John Ellson 2004-09-08 18:49:23 EDT
Created attachment 103612 [details]
xorg.conf before fix
Comment 6 Michael Wiktowy 2004-09-08 19:44:05 EDT
Created attachment 103619 [details]
Here is my xorg.conf ... 

it already had the /dev/input/mice in from manually editing it long ago when I
got by that problem before
Comment 7 Michael Wiktowy 2004-09-08 19:51:14 EDT
Oops ... sorry ... it actually has two sections with /dev/input/mice
and /dev/mouse in it ... So does John's in attachment 103612 [details] by the
looks of it. I am not sure if this is proper by I am pretty sure I
didn't add a whole other section manually. I would have just changed
the device name earlier. I will check if changing both instances to
/dev/input/mice fixes things.
Comment 8 John Ellson 2004-09-08 19:53:12 EDT
Try changing the /dev/mouse in your *first* InputDevice to
/dev/input/mice.

Worked for me.
Comment 9 Michael Wiktowy 2004-09-08 20:04:11 EDT
Changing the first one to /dev/input/mice worked for me also. Thanks!

The fail safe drop back to text login didn't work though ... I thought
that it used to do that. At least it did when I had X issues in the past.

Regardless, I am back on track.
Comment 10 Mike A. Harris 2004-09-09 03:44:52 EDT
>Why does X care if it has an pointer device?

Because the X server must have at least one configured pointer device
as per X11 specification.  The pointer device needs to be able to
be successfully opened.  If the device open fails, then the pointer
can't be opened, and the X server will refuse to start.  If you run
pointerless kiosks or similar, the X server manpages describe an
option you can use to force the server to start without a pointer
device, however that is not the default behaviour (and shouldn't be).

>It certainly shouldn't crash the system just because it can't find >one.

It doesn't.  If the X server can't open the pointer device that is
specified in the config file, it will simply display a fatal error
to the console and log file indicating the configured pointer device
could not be opened, and then exit.  This does not and should not
crash the system.  You should end up in a text mode console, with
a running system.

Hope this helps.
Comment 11 Mike A. Harris 2004-09-09 03:49:38 EDT
As mentioned above, the X server requires a single pointer to be
configured correctly, and that device must be able to be opened,
or you must configure the server to start pointerless manually if
you wish to use the X server without any pointer.  If the server
works with one kernel, and a kernel upgrade causes the server to
no longer be able to start, it is either a kernel bug that broke
the input driver, or as is the case between 2.4 and 2.6 kernels,
you need to use /dev/input/mice.  In the latter case, this isn't
a bug, but rather a misconfiguration of your X server under a 2.6
kernel, since /dev/psaux no longer exists.

Our installer handles this gracefully.  Manual upgrades may require
manual reconfiguration.

Setting status to "NOTABUG".
Comment 12 Michael Wiktowy 2004-09-09 10:10:49 EDT
Would it be worth opening up another bug specifically spelling out the
behaviour of the X Server crash recovery never going back to text mode
nor letting you switch with the F-keys to a text console? Is failure
to cleanly fail when misconfigured a bug that will be fixed? I would
guess that this is a problem with the scripts that detect an X Server
failure and retry not giving up rather than the X Server itself ...
but I don't know where that occurs.

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