Bug 479344 - Intel 810 video hangs on IBM Netvista
Intel 810 video hangs on IBM Netvista
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
All Linux
low Severity urgent
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-01-08 18:32 EST by Neal Rhodes
Modified: 2009-11-02 10:42 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-01 07:42:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
config file (607 bytes, text/plain)
2009-01-11 13:22 EST, Neal Rhodes
no flags Details
Log when we tried to use xorg.conf with XAA parameter. (1.20 KB, text/plain)
2009-01-11 13:37 EST, Neal Rhodes
no flags Details
I think this is the log of system-config-display when it hangs. (224.32 KB, text/plain)
2009-01-11 13:52 EST, Neal Rhodes
no flags Details
Log fiile when I tried to get it to use i810 driver on 82815 video chip. (4.89 KB, text/plain)
2009-01-11 15:49 EST, Neal Rhodes
no flags Details
config with XAA option on Netvista with 82815 video (922 bytes, text/plain)
2009-01-12 11:21 EST, Neal Rhodes
no flags Details
X startup log with XAA option, 82815 video. (28.03 KB, text/plain)
2009-01-12 11:23 EST, Neal Rhodes
no flags Details
Screen picture when running system-config-display with exciting background (1.91 MB, image/jpeg)
2009-01-12 11:26 EST, Neal Rhodes
no flags Details
Exciting background during X startup (1.87 MB, image/jpeg)
2009-01-12 11:28 EST, Neal Rhodes
no flags Details

  None (edit)
Description Neal Rhodes 2009-01-08 18:32:47 EST
Description of problem: Stock X driver hangs IBM Netvista with Intel 82845 Video

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

How reproducible:

Steps to Reproduce:
1.  Install FC10 on IBM Netvista 8305-53U
2.  Reboot
3.  It fries immediately
4.  Reboot
5.  Take out the "rhgb quiet" out of boot spec, futz with it to make it boot to single user.
6.  Login and telinit 5.
7.  It spits out garbled login screen and then hangs. 
8.  Reboot as above.
9.  Try running system-config-display.
10. It puts up an initial screen and then garbles it and IT hangs the whole machine. 
Actual results:

Expected results:

Additional info:  I can pull the drives out and stick them in an older IBM Netvista 6578, which has some flavor of 810 chip, and it works essentially fine.
Comment 1 Matěj Cepl 2009-01-10 20:19:32 EST
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf (if you have one) whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 Neal Rhodes 2009-01-11 13:21:24 EST
A couple of notes, and then I'll get on to answering those questions in the last comment. 

A. I don't think this is one specific hardware failure - I've got two NetVista desktops, and it hangs on both of them when I stuff this drive pair in.  

B. I went through a cautious approach to getting here.  I started with making a Ghost4Linux image of my RAID pair of IDE drives with Fedora Core 6, then restoring that to new disk drives, stuffing them in another old Netvista with an 810 video, upgrading via YUM to Fedora Core 7, hitting a roadblock with dependencies on going farther, then doing an update via install CD's to FC9, then an update via install CD's to FC10.   All when OK regarding video.   Then I pull the drives and stuck them in the newer NetVista with the later Intel video and it all when to ... well, you know.  So, is it possible that some file got left around from this sequence of events that normally wouldn't be present on a fresh install?  Maybe?   Probably not the cause, but I didn't want to withhold that piece of information.  

C. Without trying to me a wise donkey my gut reaction after 30 years in this business is that there's something different about this specific video chip in the Netvista 8305-58U that the FC10 driver isn't accounting for, which is NOT a problem with the chip in the Netvista 6578.   So unless someone has tested with that chip, they may NEVER find this problem.  

Now, to your requests for info...

xorg.conf files:  When I first started wrassling with this problem, there was NO xorg.conf file.    I tried to run system-display-config, and when this was run normally IT MANAGED to hang the box completely.   When I say hang I mean no CTRL-ALT-DEL, no CTRL-ALT-Backspace, no CTRL-ALT-F1, only option was they power button.   My recollection was that the mouse still moved, but I'm not sure.  If it would help, I can shoot a picture of the garbled screen and attach that. 

SO, I ran it system-display-config --noui, and it created something for xorg.conf, and based on reading various postings on the Fedora Forum I tried adding 
       Option 'AccelMethod' 'XAA'
to the DEvice section.  It promptly barfed up some error messages and refused to start X.   And I took that out, and it promptly barfed up some other error messages and refused to start X.  But at least it didn't hang.   So, if you tell me which way you want to go on that, with or without xorg.conf, then we can focus on those startup errors more. 

Log files:  I'll attached a couple of them.   Remember that without xorg.conf this thing dies rather quickly, so those log files are pretty short.  I suppose if I could get it to recognize the ethernet chips and pick up an IP address I could see if it's still pingable and if I can retain an ssh connection.  My gut reaction is it's plain dead. 

Please do recall that EVERY attempt of Fedora Core 10 to access the video on these Netvista desktops has been an abject failure, whether it's Grub, or system-display-config, or X11. 

Thanks for the review.
Comment 3 Neal Rhodes 2009-01-11 13:22:54 EST
Created attachment 328670 [details]
config file

generated by system-display-config
Comment 4 Neal Rhodes 2009-01-11 13:37:10 EST
Created attachment 328671 [details]
Log when we tried to use xorg.conf with XAA parameter.
Comment 5 Neal Rhodes 2009-01-11 13:52:09 EST
Created attachment 328673 [details]
I think this is the log of system-config-display when it hangs.
Comment 6 Neal Rhodes 2009-01-11 14:06:42 EST
Ok, I lied.  I said I was going to attach various log files.  It seems like there weren't any log files from when I had no xorg.conf.    I'm a little fuzzy on the details, but it just looks like there was no log file saved - like it hung before it flushed the buffer, or synced the filesystem. 

Remember that I cannot actually run X or system-config-display on the target chassis - it hangs.   I have to drag the drives out and stick them back into an older Netvista with an 82815 video chip.  Then everything works.   NOW, here's the interesting thing - if on the old Netvista, I remove xorg.conf, then run system-config-display it says I've got an 82815 chip.  Then when I hit the config button, it says it's going to use the "intel" driver, which is described as "Experimental Modesetting Driver".   It's not selecting the i810 driver, which seems to have had lots of bug fixes recently.   And indeed, that's what is in the attached file.   

So, maybe the way out of this swamp is to run system-config-display on the old box, pick the i810 driver, and let it save the xorg.conf.    Perhaps maybe even then the Option 'AccelMethod' 'XAA' will make sense?    And maybe the system-config-display should pick the most conservative driver, not the kamakase one? 

What is the update path on the intel driver?  If this box is current with FC10 updates would it be current with that? 

Note my goal here is just a working server with 1600x1200 screen for average desktop usage, not amazing graphics for video games.
Comment 7 Neal Rhodes 2009-01-11 15:44:25 EST
OK, doing a little poking around on my hypothesis...

Run system-config-display on the old Netvista with 82815, no xorg.conf, and force it to use the 810 driver.   Then I remove ALL of the Xorg*log from /var/log, and do a telinit 5. 

It barfs up a whole pile of messages about prefdm something, that scroll off the screen, and leaves me with a big pile of log files. 
[root@localhost log]# ls -lt X*
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.1.log
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.2.log
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.3.log
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.4.log
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.5.log
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.0.log
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.4.log.old
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.5.log.old
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.0.log.old
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.1.log.old
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.2.log.old
-rw-r--r-- 1 root root 5007 2009-01-11 15:26 Xorg.3.log.old
-rw-r--r-- 1 root root  919 2009-01-11 15:25 Xorg.setup.log

They are all pretty much the same, and I'll attach one as Xorg.1.log-trying-i810-driver.

Then it gets more interesting.  I run system-config-display again, and it spits out a message roughly "can't start with existing xorg.conf because .... and that scrolls off the screen too quickly, and we're back to the "intel" driver again. 

SO, I never got to the point of stuffing these drives into the newer Netvista; can't get X to startup with the i810 driver on the old 82815 chip.
Comment 8 Neal Rhodes 2009-01-11 15:49:46 EST
Created attachment 328676 [details]
Log fiile when I tried to get it to use i810 driver on 82815 video chip.
Comment 9 Matěj Cepl 2009-01-12 07:35:07 EST
I think this is a good explanation why the driver in the default mode doesn't work for you (from comment 5):

0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x812bc5b]
1: /usr/bin/Xorg(mieqEnqueue+0x289) [0x810b379]
2: /usr/bin/Xorg(xf86PostMotionEventP+0xc2) [0x80d4262]
3: /usr/bin/Xorg(xf86PostMotionEvent+0x68) [0x80d43c8]
4: /usr/lib/xorg/modules/input//evdev_drv.so [0x2f5d05]
5: /usr/bin/Xorg [0x80bcdb7]
6: /usr/bin/Xorg [0x80ac91e]
7: [0x110400]
8: [0x110416]
9: /lib/libc.so.6(ioctl+0x19) [0xc71979]
10: /usr/lib/libdrm.so.2 [0x48106cf]
11: /usr/lib/libdrm.so.2(drmCommandWrite+0x34) [0x4810984]
12: /usr/lib/xorg/modules/drivers//intel_drv.so(I830Sync+0x135) [0x1c6ca5]
13: /usr/lib/xorg/modules/drivers//intel_drv.so [0x1f097a]
14: /usr/lib/xorg/modules//libexa.so(exaWaitSync+0x65) [0x278095]
15: /usr/lib/xorg/modules//libexa.so(ExaDoPrepareAccess+0x7e) [0x2793ae]
16: /usr/lib/xorg/modules//libexa.so [0x27e3b2]
17: /usr/lib/xorg/modules//libexa.so [0x27e905]
18: /usr/lib/xorg/modules//libexa.so(exaDoMigration+0x652) [0x27f0c2]
19: /usr/lib/xorg/modules//libexa.so [0x28074b]
20: /usr/lib/xorg/modules//libexa.so(exaComposite+0xd5a) [0x28192a]
21: /usr/bin/Xorg [0x816f6fa]
22: /usr/bin/Xorg(CompositePicture+0x19a) [0x815818a]
23: /usr/lib/xorg/modules//libexa.so(exaTrapezoids+0x3ea) [0x2803da]
24: /usr/bin/Xorg(CompositeTrapezoids+0x9b) [0x8157f5b]
25: /usr/bin/Xorg [0x816053d]
26: /usr/bin/Xorg [0x815ad75]
27: /usr/bin/Xorg(Dispatch+0x34f) [0x8085e9f]
28: /usr/bin/Xorg(main+0x47d) [0x806b71d]
29: /lib/libc.so.6(__libc_start_main+0xe5) [0xbac6e5]
30: /usr/bin/Xorg [0x806ab01]

Yes, forcing XAA as an acceleration method might help. However, you have to use double quotes not single quotes -- your log in the comment XXX says:

Parse error on line 21 of section Device in file /etc/X11/xorg.conf
	The Option keyword requires 1 or 2 quoted strings to follow it.
Parse error on line 21 of section Device in file /etc/X11/xorg.conf
	"'XAA'" is not a valid keyword in this section.

With this X didn't even try to start up.

And concerning your theory about difference between intel and i810 driver. Sorry to crush your theory, but they are actually the same:

[root@viklef ~]# ls -l /usr/lib/xorg/modules/drivers/{intel,i810}*
-rwxr-xr-x 1 root root 523364  2. pro 06.46 /usr/lib/xorg/modules/drivers/intel_drv.so
lrwxrwxrwx 1 root root     12  7. pro 20.31 /usr/lib/xorg/modules/drivers/i810_drv.so -> intel_drv.so
[root@viklef ~]# 

So, please try to start with

Option "AccelMethod" "XAA"

in the graphics driver section, and please let us know how it went (together with /var/log/Xorg.0.log attached), please.
Comment 10 Neal Rhodes 2009-01-12 11:21:57 EST
Created attachment 328753 [details]
config with XAA option on Netvista with 82815 video
Comment 11 Neal Rhodes 2009-01-12 11:23:04 EST
Created attachment 328754 [details]
X startup log with XAA option, 82815 video.
Comment 12 Neal Rhodes 2009-01-12 11:26:17 EST
Created attachment 328756 [details]
Screen picture when running system-config-display with exciting background
Comment 13 Neal Rhodes 2009-01-12 11:28:34 EST
Created attachment 328759 [details]
Exciting background during X startup
Comment 14 Neal Rhodes 2009-01-12 11:43:01 EST
Ok, I've verified that the symbolic link does exist as you mentioned on this system.  Fair enough. 

I've done as you suggested on the older Netvista and attached the results.  I notice that it didn't seem to put in the screen resolution options I requested in the setup, although once I convinced it the monitor was 1280x1024 it seemed to start up that way.  

I also checked the bios setup on this box:
Shared video: 1MB
Active Video: Was PCI, I changed it to Integrated.
Palette Snooping: Was Disabled, I changed it to Enabled. 

I'm puzzled on the Active Video - it's only got the embedded controller on board; don't see what that changed.  

Afterwards, I noticed a couple of things: 

A. running system-config-display AND starting X results in some exiting moments on the screen, which eventually get settled down.  I didn't know how to describe so I  took some pictures and attached them. 

B. Once the smoke cleared, the display seemed to look better - I distinctly recall having faint red vertical dashed lines about 2" apart on the screen, and now they are gone. 

So, next step when I get to it is to take these drives out and stick them in the newer Netvista with the 82845 video and more RAM and see what it does. 

BTW, What revision of the intel driver should I have?  I don't see where it lives.
[root@localhost log]# rpm -q -a | fgrep x11-drv-i
Comment 15 Neal Rhodes 2009-01-12 17:18:31 EST
OK, taking the drives out and sticking them in the Netvista with the 82845 chip results in....... perfect behavior from X. No funky psychedelic colors on startup, everything looks normal. 

Running system-config-display from inside X results in normal behavior.  Setting it to millions of colors from thousands, and then stopping and starting X via telinit 3; telinit 5 results in ok display. 

I do have to modify the boot sequence to take out the "rhgb" and "quiet" options, or it will hang on boot, but that's not any big deal. 

I could remove the xorg.conf file and go looking for trouble running system-config-display, but unless y'all want me to, I don't need that trouble in my life.  It seems the only challenge I've got left is getting it to recognise the network chip. 

So, what we seem to be left with is that system-config-display, without any xorg.conf, will barf and hang the box, and if run with the -noui option will create an xorg.conf that will make system-config-display unable to start, and make it hang the box.    But if you happen to add that XAA option, then it will work.
Comment 16 Vedran Miletić 2009-09-21 10:30:44 EDT
Reporter, does this still occur in Fedora 11?
Comment 17 Vedran Miletić 2009-11-01 07:42:02 EST
Reporter doesn't reply for a long time. Closing as we don't have sufficent data to debug this further, and it's possible that it was fixed in the meantime.
Comment 18 Neal Rhodes 2009-11-02 10:42:03 EST
Sorry I either didn't notice this, or wasn't motivated to go through the pain of another Fedora upgrade again. 

This morning I boot from a FC11 live media CD and can verify that it started up and went completely through X startup and graphical login without incident on the above hardware.

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