Bug 467636 - (ctrlCkilledXstar) X restarted unexpectedly when Ctrl+C pressed
X restarted unexpectedly when Ctrl+C pressed
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
rawhide
i386 Linux
urgent Severity urgent
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Reopened
: 467539 467646 483820 (view as bug list)
Depends On:
Blocks: 409791 F10Blocker/F10FinalBlocker
  Show dependency treegraph
 
Reported: 2008-10-19 15:50 EDT by Yusuf Ma
Modified: 2009-02-10 20:19 EST (History)
14 users (show)

See Also:
Fixed In Version: 1.5.2-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-10 20:19:23 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)
/var/log/Xorg.0.log (81.54 KB, text/plain)
2008-10-19 17:52 EDT, Matěj Cepl
no flags Details
/var/log/dmesg (35.01 KB, text/plain)
2008-10-19 17:55 EDT, Matěj Cepl
no flags Details
Xorg.0.log - kasal (19.62 KB, text/plain)
2009-01-05 07:15 EST, Stepan Kasal
no flags Details
xorg.conf - kasal (469 bytes, text/plain)
2009-01-05 07:17 EST, Stepan Kasal
no flags Details

  None (edit)
Description Yusuf Ma 2008-10-19 15:50:28 EDT
Description of problem:

After logging in KDE, pressing Ctrl+C causes X server restarted and back to login interface, just like Ctrl+Alt+Backspace. After log in for a second time, Ctrl+C will not cause X restart, but key "2" will cause the same result. All other number keys are normal.


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

kdebase-workspace-4.1.2-6.fc10.i386


How reproducible:

Always


Steps to Reproduce:
1. boot the computer
2. log in KDE
3. press Ctrl+C
4. X restarted
5. log in KDE again
6. press number "2" key
7. X restarted
  

Actual results:

X restarted unexpectedly


Expected results:

Keys work normally. 


Additional info:

The related output in /var/log/messages are:
Oct 19 12:22:33 fedora pulseaudio[2651]: main.c: Called SUID root and real-time/high-priority scheduling was requested in the configuration. However, we lack the necessary priviliges:
Oct 19 12:22:33 fedora pulseaudio[2651]: main.c: We are not in group 'pulse-rt' and PolicyKit refuse to grant us priviliges. Dropping SUID again.
Oct 19 12:22:33 fedora pulseaudio[2651]: main.c: For enabling real-time scheduling please acquire the appropriate PolicyKit priviliges, or become a member of 'pulse-rt', or increase the RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user.
Oct 19 12:22:33 fedora pulseaudio[2651]: main.c: High-priority scheduling enabled in configuration but not allowed by policy.
Oct 19 12:22:33 fedora pulseaudio[2651]: core-util.c: setpriority(): Permission denied
Oct 19 12:22:34 fedora pulseaudio[2654]: alsa-util.c: Cannot find fallback mixer control "Mic".
Oct 19 12:22:35 fedora pulseaudio[2695]: pid.c: Daemon already running.
Oct 19 12:22:55 fedora kdm[2167]: X server for display :0 terminated unexpectedly
Oct 19 12:22:55 fedora acpid: client connected from 2767[0:0]
Oct 19 12:23:03 fedora kernel: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
Oct 19 12:23:04 fedora pulseaudio[2654]: module-alsa-source.c: Increasing wakeup watermark to 40.00 ms
Oct 19 12:23:04 fedora pulseaudio[2654]: module-alsa-sink.c: Increasing wakeup watermark to 40.00 ms
Oct 19 12:23:05 fedora pulseaudio[2654]: module-alsa-source.c: Increasing wakeup watermark to 80.00 ms
Oct 19 12:23:05 fedora pulseaudio[2654]: module-alsa-sink.c: Increasing wakeup watermark to 80.00 ms
Oct 19 12:23:05 fedora pulseaudio[2654]: module-alsa-source.c: Increasing wakeup watermark to 160.00 ms
Oct 19 12:23:05 fedora pulseaudio[2654]: module-alsa-sink.c: Increasing wakeup watermark to 160.00 ms
Oct 19 12:23:06 fedora pulseaudio[2654]: module-alsa-sink.c: Increasing wakeup watermark to 320.00 ms
Oct 19 12:23:10 fedora pulseaudio[3220]: pid.c: Daemon already running.
Oct 19 12:23:25 fedora kdm[2167]: X server for display :0 terminated unexpectedly
Oct 19 12:23:25 fedora acpid: client connected from 3303[0:0]
Oct 19 12:23:40 fedora pulseaudio[3764]: pid.c: Daemon already running.
Comment 1 Kevin Kofler 2008-10-19 15:55:05 EDT
This sounds like an X11 input bug to me, not a KDE bug.
Comment 2 Matěj Cepl 2008-10-19 17:52:12 EDT
Can fully reproduce with xorg-x11-server-Xorg-1.5.2-5.fc10.i386 and xorg-x11-drv-evdev-2.0.7-1.fc10.i386. Somehow it looks like some key combination "go through" X and are not captured -- i.e., Ctrl-C apparently kills something somewhere like it was producing SIGINT instead of copying text. Most likely relates to couple of similar bugs, which I will close as duplicates against this one.
Comment 3 Matěj Cepl 2008-10-19 17:52:54 EDT
Created attachment 320825 [details]
/var/log/Xorg.0.log
Comment 4 Matěj Cepl 2008-10-19 17:54:22 EDT
The previous attachment is from the running Xorg, so I am not sure how accurate it is (except there are plenty of (WW) and (EE) there). Unfortuantely /var/log/Xorg.0.log.old is zero-byte-long (which is remarkable in itself).
Comment 5 Matěj Cepl 2008-10-19 17:55:05 EDT
Created attachment 320826 [details]
/var/log/dmesg
Comment 6 Matěj Cepl 2008-10-19 18:02:44 EDT
possible duplicates -- bug 467539, and bug 467479?
Comment 7 Matěj Cepl 2008-10-19 18:10:30 EDT
*** Bug 467539 has been marked as a duplicate of this bug. ***
Comment 8 Matěj Cepl 2008-10-19 18:12:46 EDT
*** Bug 467573 has been marked as a duplicate of this bug. ***
Comment 9 Dominik 'Rathann' Mierzejewski 2008-10-19 18:46:04 EDT
Bit me, too. I would go as far as to say it's a release blocker.
Comment 10 Matěj Cepl 2008-10-19 18:54:35 EDT
*** Bug 467646 has been marked as a duplicate of this bug. ***
Comment 11 Kevin Kofler 2008-10-19 18:55:19 EDT
@Rathann (comment #9): +1
Comment 12 Peter Hutterer 2008-10-19 18:56:32 EDT
Fixed with xorg-x11-server-1.5.2-6.

The changes in 1.5.2-5 didn't trigger correctly if no xorg.conf was present, so a one-line fix was needed. See last hunk of http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.5.2-disable-kbd-mouse.patch?revision=1.2&view=markup
Comment 13 Dominik 'Rathann' Mierzejewski 2008-10-20 05:50:08 EDT
Confirmed fixed, thanks.
Comment 14 Edney Matias 2008-10-20 21:18:36 EDT
Hi there. Can confirm it's fixed on xorg-x11-server-Xorg-1.5.2-7. Thank you all!
Comment 15 Stepan Kasal 2009-01-05 07:09:42 EST
The bug seems to be back again.  My installation is a combination of randomly updated packages, but no dependencies are broken.
rpm -qa xorg*|sort:
xorg-x11-apps-7.3-5.fc10.i386
xorg-x11-drv-evdev-2.1.0-3.fc11.i386
xorg-x11-drv-fbdev-0.4.0-3.fc11.i386
xorg-x11-drv-vesa-2.1.0-1.fc11.i386
xorg-x11-drv-void-1.1.1-9.fc9.i386
xorg-x11-filesystem-7.3-2.fc10.noarch
xorg-x11-font-utils-7.2-6.fc10.i386
xorg-x11-fonts-100dpi-7.2-6.fc9.noarch
xorg-x11-fonts-75dpi-7.2-6.fc9.noarch
xorg-x11-fonts-ISO8859-1-100dpi-7.2-6.fc9.noarch
xorg-x11-fonts-ISO8859-1-75dpi-7.2-6.fc9.noarch
xorg-x11-fonts-Type1-7.2-6.fc9.noarch
xorg-x11-fonts-misc-7.2-6.fc9.noarch
xorg-x11-fonts-truetype-7.2-3.fc8.noarch
xorg-x11-proto-devel-7.4-12.fc11.noarch
xorg-x11-server-Xorg-1.5.99.3-5.fc11.i386
xorg-x11-server-Xvfb-1.5.99.3-5.fc11.i386
xorg-x11-server-common-1.5.99.3-5.fc11.i386
xorg-x11-server-utils-7.4-3.fc10.i386
xorg-x11-twm-1.0.3-3.fc10.i386
xorg-x11-util-macros-1.2.1-1.fc11.noarch
xorg-x11-utils-7.4-3.fc10.i386
xorg-x11-xauth-1.0.2-5.fc10.i386
xorg-x11-xinit-1.0.9-4.fc10.i386
xorg-x11-xkb-utils-7.2-7.fc10.i386
xorg-x11-xtrans-devel-1.2.2-1.fc11.noarch

(I have also observed that with xorg-x11-server-*-1.5.99.3-1.fc11.i386, before my "yum update xorg*".)

I'm attaching my xorg.conf and current Xorg.0.log.
Comment 16 Stepan Kasal 2009-01-05 07:15:40 EST
Created attachment 328188 [details]
Xorg.0.log - kasal
Comment 17 Stepan Kasal 2009-01-05 07:17:29 EST
Created attachment 328189 [details]
xorg.conf - kasal
Comment 18 Matěj Cepl 2009-01-05 07:25:19 EST
Cannot reproduce with fully upgraded Rawhide, but I still think it is worthy to check whether we haven't dropped the patch for this somewhere on the way.
Comment 19 Peter Hutterer 2009-01-05 17:27:53 EST
Remove the option AllowEmptyInput "false". With this setting, you're telling the X server to force the presence of mouse/kbd devices. You don't have either driver installed though, so your input devices are provided by evdev.
However, because of AEI "false", the console raw mode is not set and evdev can thus cancel the server.
Simply removing the option gives you the same input devices as now anyway.

Closing as CURRENTRELEASE, this bug is now fixed in F10 and rawhide.
Comment 20 Matěj Cepl 2009-02-08 10:20:03 EST
*** Bug 483820 has been marked as a duplicate of this bug. ***
Comment 21 Michal Jaegermann 2009-02-08 12:52:44 EST
I recently filed a bug 483820 reporting that with AEI set to "no" every keystroke shows up three times.  It was closed as a duplicate of this bug and here it says that this is a misconfiguration.  If this is really the case then I have the following questions:
  - If AEI set to "no" is a misconfiguration then why this flag exists at all?
  - As 'kbd', 'mouse' or 'vmmouse' drivers are disabled when AEI is "yes" then why these drivers do exist?
  - What are you supposed to do if you really need, say, 'vmmouse'?
  - Recently I had a situation when I had to set AEI to "no" or I had no input at all and that is why I had this flag set when after updates whenI was hit by this "triplicates" issue; am I supposed to play guessing games which will be a "misconfiguration" today?
Comment 22 Matěj Cepl 2009-02-08 13:26:14 EST
OK, taking back, passing to developers.
Comment 23 Peter Hutterer 2009-02-08 17:39:33 EST
(In reply to comment #21)
> I recently filed a bug 483820 reporting that with AEI set to "no" every
> keystroke shows up three times.  It was closed as a duplicate of this bug and
> here it says that this is a misconfiguration.  If this is really the case then
> I have the following questions:
>   - If AEI set to "no" is a misconfiguration then why this flag exists at all?
>   - As 'kbd', 'mouse' or 'vmmouse' drivers are disabled when AEI is "yes" then
> why these drivers do exist?
>   - What are you supposed to do if you really need, say, 'vmmouse'?
>   - Recently I had a situation when I had to set AEI to "no" or I had no input
> at all and that is why I had this flag set when after updates whenI was hit by
> this "triplicates" issue; am I supposed to play guessing games which will be a
> "misconfiguration" today?

From the xorg.conf man page:

Option "AllowEmptyInput" "boolean"
If enabled, don’t add the standard keyboard and mouse drivers, if there are no input devices in the config file.  Enabled by default if AutoAddDevices and AutoEnableDevices is enabled, otherwise  disabled.  If AllowEmptyInput is on, devices using the kbd or mouse driver are ignored.

Option "AutoAddDevices" "boolean"
If this option is disabled, then no devices will be added from HAL events.  Enabled by default.

Triplicate keystrokes are a sign that you add evdev and kbd devices, so you have AutoAddDevices on, and AEI on at the same time.
vmmouse in rawhide doesn't need any special configuration anymore, the matching bits should be added automatically. check the output of lshal in the VM, it should list input.x11_driver.vmmouse. Is this the case?

If you want to force vmmouse etc. through the configuration, disabling AutoAddDevices is the right approach.
Comment 24 Michal Jaegermann 2009-02-08 20:38:32 EST
> From the xorg.conf man page:

Yes, I know what manpage says.  AutoEnableDevices was not explicitely set.
In any case xorg.conf in use is attached as
https://bugzilla.redhat.com/attachment.cgi?id=330765
to a bug 483820.  That configuration file was required for a while as I needed some input devices working.  After recent rawhide updates I got that "tripple stutter" and had to do configuration change to restore sanity.

> vmmouse in rawhide doesn't need any special configuration anymore

This is what I see in logs with AEI on: "(WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled."  Do you mean that vmmouse is supported now through evdev as well?
Comment 25 Peter Hutterer 2009-02-09 17:38:56 EST
(In reply to comment #24)
> > vmmouse in rawhide doesn't need any special configuration anymore
> 
> This is what I see in logs with AEI on: "(WW) AllowEmptyInput is on, devices
> using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled."  Do you mean that
> vmmouse is supported now through evdev as well?

hmm, that's a bit ambiguous, you're right. What it is supposed to mean is that such devices from the xorg.conf file are ignored. vmmouse is now added through the HAL mechanism, just like the other devices.
Comment 26 Peter Hutterer 2009-02-10 20:19:23 EST
Closing the bug again, as stated in Comment #24, the configuration change fixed the problem.

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