Bug 496545 (DG41TY) - X-related Init not functioning at all in DG41TY Intel Motherboard
Summary: X-related Init not functioning at all in DG41TY Intel Motherboard
Keywords:
Status: CLOSED WONTFIX
Alias: DG41TY
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: 11
Hardware: i686
OS: Linux
low
urgent
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: card_G41
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-20 02:03 UTC by das
Modified: 2018-04-11 11:40 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-06-28 12:06:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
bzip2 of Xorg log (8.53 KB, application/x-bzip)
2009-04-20 17:20 UTC, das
no flags Details
anaconda.xlog in bzip2 (7.01 KB, application/x-bzip)
2009-04-20 17:22 UTC, das
no flags Details
Xorg.0.log (156.53 KB, text/plain)
2009-04-20 17:30 UTC, das
no flags Details
anaconda.xlog (34.74 KB, text/plain)
2009-04-20 17:31 UTC, das
no flags Details

Description das 2009-04-20 02:03:32 UTC
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:
--

Comment 1 Matěj Cepl 2009-04-20 16:41:54 UTC
(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

Comment 2 das 2009-04-20 17:20:47 UTC
Created attachment 340387 [details]
bzip2 of Xorg log

This is the Xorg.0.log

Comment 3 das 2009-04-20 17:22:15 UTC
Created attachment 340388 [details]
anaconda.xlog in bzip2

Attaching the /var/log/anaconda.xlog in bzip2

Comment 4 das 2009-04-20 17:25:52 UTC
Thank you for responding. I have attached the two files as you said.

Comment 5 das 2009-04-20 17:27:50 UTC
Sorry, I just missed your word 'uncompressed': so stupid of me. I am attaching the original ones.

Comment 6 das 2009-04-20 17:30:16 UTC
Created attachment 340393 [details]
Xorg.0.log

Uncompressed Xorg.0.log

Comment 7 das 2009-04-20 17:31:20 UTC
Created attachment 340394 [details]
anaconda.xlog

Uncompressed anaconda.xlog

Comment 8 das 2009-04-25 03:26:05 UTC
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.

Comment 9 das 2009-05-01 14:45:39 UTC
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.

Comment 10 das 2009-05-16 03:12:09 UTC
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?

Comment 11 das 2009-05-20 13:21:43 UTC
And though there were many xorg updates by this time, there is no change in the init front: till now Ctrl+f* causes logout.

Comment 12 das 2009-05-22 13:59:30 UTC
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.

Comment 13 das 2009-05-22 15:33:21 UTC
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.

Comment 14 Jesse Keating 2009-05-25 20:14:37 UTC
This is a new chip, relatively uncommon, and it's no worse than F10.  This is not a blocker for F11.

Comment 15 das 2009-05-30 07:05:08 UTC
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.

Comment 16 das 2009-05-30 07:06:42 UTC
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.

Comment 17 das 2009-05-30 14:30:16 UTC
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.

Comment 18 Bug Zapper 2009-06-09 14:10:12 UTC
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

Comment 19 das 2009-09-01 05:21:22 UTC
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.

Comment 20 das 2009-09-09 14:24:38 UTC
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.

Comment 21 das 2009-09-10 22:27:31 UTC
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.

Comment 23 Matěj Cepl 2009-11-05 18:27:00 UTC
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.]

Comment 24 das 2009-11-06 07:42:22 UTC
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.

Comment 25 das 2009-11-06 07:54:15 UTC
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.

Comment 26 das 2009-11-06 08:16:37 UTC
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.

Comment 27 das 2009-11-06 08:17:39 UTC
Please reply as soon as you can: I am waiting.

Comment 28 das 2009-12-20 15:40:51 UTC
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.

Comment 29 das 2010-02-21 13:51:08 UTC
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'.

Comment 30 Matěj Cepl 2010-02-22 10:40:16 UTC
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.

Comment 31 Bug Zapper 2010-04-27 13:47:52 UTC
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

Comment 32 Bug Zapper 2010-06-28 12:06:30 UTC
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.

Comment 33 das 2014-09-29 14:46:16 UTC
I cannot report anything more about the HW, because I don't have that machine any more for a long time.


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