Hide Forgot
Description of problem: DG41TY is a relatively new motherboard from Intel and the x-driver till now is not functioning properly. In fact, in Fedora 10 installer one has to tab and insert 'xdriver=vesa' or the installation crashes. And even then the X is more than bad in F10, and so I went to this F11 rawhide. But the X server is giving quite a few problems: 1. I cannot go to any virtual terminal by hitting 'Ctrl + F*', the moment I do it, system automatically logs me out, and goes to the X-log-in screen. 2. The problem is same even if I boot with 'init 3' as the default in '/etc/inittab'. The very first moment I go into X by 'startx' all the virtual terminals go away. 3. Even the grub splash screen is garbled, though after I deleted 'rhgb' portion in menu.lst in /boot/grub, the booting messages are coming clearly in vga=0x317. Version-Release number of selected component (if applicable): uname -r: 2.6.29.1-85.fc11.i686.PAE arch: i686 I cannot tell you the driver it is using because there is no 'xorg.conf' in /etc/X11 How reproducible: -- Steps to Reproduce: -- Actual results: -- Expected results: -- Additional info: --
(In reply to comment #0) > I cannot tell you the driver it is using because there is no 'xorg.conf' in > /etc/X11 That's OK, can we get at least /var/log/Xorg.0.log (and /var/log/anaconda.xlog if available) attached to this bug as uncompressed separate attachment(s), please? Thank you in advance
Created attachment 340387 [details] bzip2 of Xorg log This is the Xorg.0.log
Created attachment 340388 [details] anaconda.xlog in bzip2 Attaching the /var/log/anaconda.xlog in bzip2
Thank you for responding. I have attached the two files as you said.
Sorry, I just missed your word 'uncompressed': so stupid of me. I am attaching the original ones.
Created attachment 340393 [details] Xorg.0.log Uncompressed Xorg.0.log
Created attachment 340394 [details] anaconda.xlog Uncompressed anaconda.xlog
Just an hour back had one yum update, which included one xorg-x11-driver-intel. So, expected something to happen, which did not. The same problem continues. Now I am within Xfce, on one Epiphany window, if I press Ctrl+Alt+f<*>, it will log me out and I will have to log-in into Xfce.
From the time I reported this bug, many updates did take place. But, till now, X is always restarting showing the login-window whenever I try to go to some other virtual terminal, and once X starts, there is no console any more.
2.6.29.3-140.fc11.i686.PAE kernel is making the system hang when trying to load X. I have to boot with the earlier 2.6.29.2-126.fc11.i686.PAE kernel. Will you people need any additional material?
And though there were many xorg updates by this time, there is no change in the init front: till now Ctrl+f* causes logout.
Thank you Høgsberg and other people from Fedora. After the latest kernel update, 2.6.29.3-155.fc11.i686.PAE, all the problems that I reported here have gone away.
Maybe it was too soon to react. The moment I start playing a movie and go to full-screen mode, in both Mplayer and VLC, system hangs. Though they are running fine in the older 126 kernel.
This is a new chip, relatively uncommon, and it's no worse than F10. This is not a blocker for F11.
This is a curious situation. Thanks to a suggestion by Rahul Sundaram of increasing the variable 'installonly' in yum.conf, I can work. These are the four kernels in /boot: vmlinuz-2.6.29.2-126.fc11.i686.PAE vmlinuz-2.6.29.3-140.fc11.i686.PAE vmlinuz-2.6.29.3-155.fc11.i686.PAE vmlinuz-2.6.29.4-167.fc11.i686.PAE From this only the 126 one works, none of the later three. In fact the 167 kernel, or the latest one has gone even one step back. Again I am getting logged off and returned to init 5 GUI login prompt when I want to go to any of the Ctrl+F*. And of course VLC/Mplayer full-screen mode is hanging the machine. Also some problems with the X when I am working with virt-manager (Kubuntu 8.04 or MSW-XP), but I cannot reproduce the exact steps. But it is not working properly and it is related someway to going full-screen or trying to change the screen resolution while operating some guest OS in virt-manager.
If you need anything please ask, today I have no class in the college, and till around 10 PM IST I will be here working on this desktop.
Just now in yum update list there was a xorg-drv-intel, I updated it, but that did not change the situation, the same log-off and the same hang. Working with 126 kernel.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Till now, so many times the machine just hangs whenever by mistake I hit 'f' during playing mplayer. This happens with VLC too. Four and half months have gone by. Change of distro version too. But the problem persists. This is quite sad. And this happened even after Intel published all the HW details of the motherboard more than two months back. I don't know what is happening.
The newest kernel, 2.6.30.5-43.fc11.i686.PAE, is not loading at all. The whole thing is getting stuck at something like 'Registering Windows binaries ... '. So, I had to boot with the 2.6.29.6-217.2.16.fc11.i686.PAE. Which is working, but with the problem of full-screen for any video application.
I tried init 3 boot with 2.6.30.5-43.fc11.i686.PAE. Booting Ok, and bringing in Login Prompt. But, startx from there is causing a hang. If you people need any details for the diagnosis, please ask.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
See, after a long time I faced the problem, I did something that one of my friends suggested: adding 'nomodeset' to kernel line in the grub.conf. After that the problem went, but obviously with inhumanly big characters on virtual consoles, which I hardly use. I had actually three problems: 1. Hanging when going to Ctrl+F*: that thing has gone away after 'nomodeset'. I can go at my will. 2. The videos are going to full-screen after 'nomodeset'. 3. The machine does not shut-down, I have to make the power off manually. Shut-down makes a restart. Both from the switch in GUI or 'poweroff' from command prompt, both as user and root. This is still there after 'nomodeset'. You have requested a feed-back after enabling the update-testing repo. Frankly speaking I am feeling a bit nervous. Anyway, I will give you a feedback, but please give me some time. Most probably I will not be able to do it today. I will try to do it as soon as I can.
After I removed 'nomodeset' the experiences are: 1. Playing Video in full-screen making the system hang just like before. 2. Shutdown is making restart just like before. 3. Virtual consoles are working. I am now going to try your 'enable repo'. Let us pray to God, I mean, Source, that it works.
After I did your 'enable repo udates-testing' what happened are these: 1. Playing video full-screen making it hang. 2. Shutdown is making restart. 3. Virtual consoles/init 3 login/startx are working. Now what would be prudent: to uninstall the new kernel by updates-testing, or just adding 'nomodeset' to the new kernel line? And from now on, are the update-testing repo automatically enabled? If I want to uninstall the update-testing kernel, how to do it? Please give me the suggestions: I am not a technical person at all.
Please reply as soon as you can: I am waiting.
The problem is continuing exactly the same way as before. uname -r: 2.6.30.9-102.fc11.i686.PAE Without 'nomodeset' in kernel line: init 5 hangs init 3 hangs after giving this message (I did write it down): [drm: intelfb_panic] *ERROR* panic occurred, switching back to text console But the console never appeared and it hanged With 'nomodeset': Everything working, even init 5 too. Though obviously those big fonts on virtual console.
After a long time I was extremely busy in my works, yesterday I installed F 12, with the expectation that all problems will go away. But, unfortunately, the problem became bigger in F 12. Even with nomodeset X was not almost not functioning at all: that is extremely slow in rendering, even switching desktops taking tens of seconds. That too with 4 GB RAM. I tried everything that came to my mind, like installing system-config-display and then changing the driver from 'vesa' to 'intel' in xorg.conf, adding acceleration option 'XAA' or 'EXA'. Nothing worked. So today I went back to F 11. Once again working with kernel option 'nomodeset'.
Sorry, for missing this bug ... the original assignee stopped maintaining the package and it slipped form our radar screen. Sorry, fixing the assignments. If we are switching to F12 (which I applaud), could we get please updated versions of /var/log/Xorg.0.log, /var/log/messages, and output of the program dmesg after the crash happens? Thank you very much and I am sorry again for the delay.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
I cannot report anything more about the HW, because I don't have that machine any more for a long time.