Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 90014
Summary: | gdm failure and automatic restart | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Simon Perreault <nomis80> | ||||||||||
Component: | XFree86 | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> | ||||||||||
Severity: | high | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 9 | CC: | mharris | ||||||||||
Target Milestone: | --- | Keywords: | Triaged | ||||||||||
Target Release: | --- | ||||||||||||
Hardware: | i686 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2004-09-29 22:31:07 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: | 100644 | ||||||||||||
Attachments: |
|
Description
Simon Perreault
2003-05-01 02:52:55 UTC
It could well be an X server bug, just one that only happens the second time you start the server or something. What video hardware do you have? Attach your X server log file and config file as bugzilla file attachments, as well as /var/log/messages. Created attachment 91437 [details]
/var/log/messages
As you may see in the log, I did not have to login/logout. The display manager
came up fine, and then I logged in as root in a text console. I did init 3 ;
init 5 and the problem reappeared.
Created attachment 91438 [details]
/etc/X11/XF86Config
Created attachment 91439 [details]
/var/log/XFree86.0.log
Sorry, I forgot to mention that I'm running RH9 on a ThinkPad R32, which has an
ATI Radeon Mobility M6.
I also tried with the ati driver, which doesn't use dri, and that didn't fix
it.
I want to stress that this is *not* an X bug. When I use startx, KDE loads fine and everything works. I have tried with rawhide (4.3.0-6) X rpms but gdm still doens't work. Also, the problem has gotten worse (but better from a debugging standpoint): gdm wont let me login once. It always restarts the X server once the animated hourglass has been seen. Understood that startx works, it is very possible to have X bugs that only happen in certain contexts or hardware states, though. mharris: didn't gafton say M6 was messed up? Ok, I feel stupid now. I must be in the majority of bug reporters here eh? In /etc/fonts/fonts.conf, I had uncommented the part labeled "Enable sub-pixel rendering" so that it would do sub-pixel antialiasing on my LCD. When I recommented that part, gdm worked fine again. There are a few strange things though: 1) Why did that setting affect gdm and not the rest of X? Why did it work with startx? 2) Why was that setting problematic at all? If it comes commented by default, one would expect it to work if it got unocmmented. 3) If X was at fault, why wasn't anything logged? 4) And strangest of all, why do I still get sub-pixel antialiasing after I recommented that part of fonts.conf? Anyway, thanks for your time, keep up the good work! The fonts.conf subpixel setting probably gets overwritten by gnome/kde GUI-managed settings once you log in, but conceivably it changes how gdm does the subpixel. If it caused this problem, I have no idea how. ;-) Perhaps it triggers a different alpha blending codepath in the X server. What likely happened is that the X server crashed and left its lockfile around. It is concievable that the pid from the lock file exists or some such thing. X would then think that its running on that display already. Fix would be to add the following code into gdm_server_wipe_cookies in server.c: g_snprintf (buf, sizeof (buf), "/tmp/.X%d-lock", disp->dispnum); unlink (buf); g_snprintf (buf, sizeof (buf), "/tmp/.X11-unix/X%d", disp->dispnum); unlink (buf); Just to clarify my comment on the above. That wouldn't fix it if X was crashing constantly of course, then gdm would just tell you that your X is crashing constantly rather then the confusing message about display being busy. It would "fix" the problem where the X server crashes on SIGTERM, to allow a second login. The best way to fix it is how it's "fixed" in the CVS, which is to turn AlwaysRestartServer back to false, however that has security implications for the current stable release unless you reset rlimits in the code somewhere. If I would get a nickel for everytime pam or X are broken in some respect I'd be rich. (Of course if I had a penny for every time gdm is broken, I'd be even richer:) We upgraded to the new stable from CVS now, so this should be "fixed" for gdm then. Still, XFree86 shouldn't crash like that. (II) RADEON(0): Video RAM override, using 16384 kB instead of 16384 kB Don't ever use the VideoRAM setting in your config file. The driver will autodetect RAM automatically properly. Using this setting unless it is absolutely required, will cause serious side effects and driver instability. May 1 09:57:07 localhost kernel: PCI: Found IRQ 11 for device 01:00.0 May 1 09:57:07 localhost kernel: PCI: Sharing IRQ 11 with 00:1d.0 Can you please provide the complete output of the following command in a text file and attach it: lspci -vvn Created attachment 94209 [details]
lspci -vvn
Here is `lspci -vvn`.
Your kernel log above shows the video card using IRQ11 however your lspci shows it using IRQ10. What is worse, is that the majority of hardware in your entire system is all sharing IRQ 10, including the video card. Very scary. ;o) If there is a problem with shared IRQ's with _any_ of the hardware in your system which has registered an interrupt handler in its driver, that hardware can cause instability across the system in any other device driver which has hooked the same shared IRQ. One common example of this problem, is a sound card and video card sharing the same IRQ, and starting X generating startup sounds. If the sound driver is instable or has any issues, it can cause a complete system lockup similar to what is described in this report. One suggestion, is thus to disable all non-essential hardware including sound card, network card, etc. and see if X will start up ok in this state. If it does start, it is likely that shared IRQ contention is occuring between your device drivers. One thing I should have mentioned is that I recently upgraded to linux-2.6.0-test4. So this could explain things like IRQ numbers moving around. What could explain all devices having the same IRQ number could be that lspci needs to be recompiled to take the new kernel into account. This is a stock Thinkpad R32, so it can't be an unstable system. The only IRQ- related problems I've been having is the keyboard generating duplicated signals or forgetting to send a "release" signal, but this has been fixed by enabling ACPI in the kernel. BTW, see the message I posted on 2003-05-01 10:57. gdm works fine now, even though I use kdm. There were still some open questions, but as a user my problem is fixed. I can still help you get information to help you answer the remaining open questions if you want to. I don't have ATI Radeon Mobility hardware, so I can't personally investigate this issue on real hardware to troubleshoot the problem. We do not support the 2.6.x kernel being ran on our OS products as it is not officially released yet, and not supported by us. Are you still able to reproduce this problem using a stock RHL 9 system plus official errata updates, including the latest official Red Hat kernel erratum? Since this bugzilla report was filed, there have been several major updates to the X Window System, which may resolve this issue. We encourage you to upgrade to the latest version of Fedora Core (http://fedora.redhat.com). If this issue turns out to still be reproduceable in the latest version of Fedora Core, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates. |