Description of problem: Stock X driver hangs IBM Netvista with Intel 82845 Video Version-Release number of selected component (if applicable): xorg-x11-drv-i810-2.5.0-4.fc10, 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.
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.
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.
Created attachment 328670 [details] config file generated by system-display-config
Created attachment 328671 [details] Log when we tried to use xorg.conf with XAA parameter.
Created attachment 328673 [details] I think this is the log of system-config-display when it hangs.
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.
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.
Created attachment 328676 [details] Log fiile when I tried to get it to use i810 driver on 82815 video chip.
I think this is a good explanation why the driver in the default mode doesn't work for you (from comment 5): Backtrace: 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.
Created attachment 328753 [details] config with XAA option on Netvista with 82815 video
Created attachment 328754 [details] X startup log with XAA option, 82815 video.
Created attachment 328756 [details] Screen picture when running system-config-display with exciting background
Created attachment 328759 [details] Exciting background during X startup
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 xorg-x11-drv-i740-1.2.0-1.fc9.i386 xorg-x11-drv-i128-1.3.0-1.fc9.i386 xorg-x11-drv-i810-2.5.0-4.fc10.i386
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.
Reporter, does this still occur in Fedora 11?
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.
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.