Created attachment 421251 [details] /var/log/messages Description of problem: On rebooting, either kdm or X apparently crashes, leaving only a console login. Version-Release number of selected component (if applicable): kdm-4.4.3-1.fc13.1.x86_64 xorg-x11-drv-intel-2.11.0-4.fc13.x86_64 xorg-x11-server-Xorg-1.8.0-12.fc13.x86_64 How reproducible: Solid Steps to Reproduce: 1.Reboot system 2.X spinner appears 3.X terminates, leaving a console Actual results: No X session Expected results: KDE session Additional info: /var/log/messages contains: Jun 3 00:35:09 bree kdm: :0[27754]: Fatal X server IO error: Interrupted system call Video is Intel 82Q963/Q965.
Created attachment 421253 [details] dmesg output
Created attachment 421255 [details] lsmod output
This is a issue which needs to be reported upstream. Please file a report at http://bugs.kde.org Please add upstream report info to this report. We will monitor the upstream report for a resolution. Thanks for the report -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
By the accounts so far, this is looks to be an X server crash, so let's keep this here for now.
(In reply to comment #4) > By the accounts so far, this is looks to be an X server crash, so let's keep > this here for now. I concur, in fact I probably should have reported it against X, except that the bug doesn't happen with startx and does happen with kdm, so it looks like it's kdm that's tickling it. Let me know if there's any additional info I can collect, such as stack traces.
Oddly enough, the problem seems to have fixed itself. I ran "yum update" and now kdm starts without problems, even though no KDE or X rpms were affected. The only things that might be relevant were glibc and the deja-vu fonts.
And it's back. This time there's no error in /var/log/messages, but the KDM session simply doesn't start, leaving me looking at a console. Again, startx works fine.
I realized that the default init state was set to 3, so that explains the latest manifestation, i.e. not a bug. Note that the initial report (including the fatal X error) was correct, but hasn't reappeared in this form. Also, I've no idea how the state got set to 3 as I'm the only one with root access and /etc/inittab has a mod time of over 6 weeks ago. Go figure.
Since the original problem appears to be fixed and the new one isn't a bug, let's close this.
(In reply to comment #9) > Since the original problem appears to be fixed and the new one isn't a bug, > let's close this. Sure.