Similar to bug #2991 but on i810 driver, rather than MGA In runlevel 5, X working OK; press Ctrl+Alt+F[1-6]: the screen is blank (entirely black). Press Ctrl+Alt+F7 gets back to X OK This is on Fedora rawhide; xorg-x11-6.8.2-20
When I ctrl-alt-f1 on a Dell running FC4T2, I get a black screen also. Hardware is detected as: (--) PCI:*(0:2:0) Intel Corp. 82865G Integrated Graphics Device rev 2, Mem @ 0xe8000000/27, 0xfeb80000/19, I/O @ 0xed98/3 (II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G Package version is: xorg-x11-6.8.2-1
Created attachment 2499 [details] Xorg0.log for i810
Cut and paste error. I meant Package version is: xorg-x11-6.8.2-19
Created attachment 2500 [details] Log file for FC4T2 Here is the log file from my machine.
Can you try the binary driver available at http://www.fairlite.demon.co.uk/intel.html and re-report?
Same problem on IBM NetVista, FC4-test2 Hardware: (--) PCI:*(0:2:0) Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device rev 1, Mem @ 0x88000000/27, 0x80000000/19 Kernel: OS Kernel: Linux version 2.6.11-1.1253_FC4 (bhcompile@decompose.build.redhat.com) (gcc version 4.0.0 20050412 (Red Hat 4.0.0-0.42)) #1 Wed Apr 20 04:11:32 EDT 2005 Driver: (II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G package: xorg-x11-6.8.2-26
Using an Intel 815 videocard, starting in runlevel 3 allows normal terminal to be displayed. After using startx w/ 1280x1024 resolution X starts fine. If I either switch to a virtual terminal or log out of X, I get a blue border around the terminals in all screens. Within the area where information is put to screen, the text starts on the far right portion of the screen with about a tenth of the ascii character. The rest of the text and about the other 9/10 of the first ascii character start on the line below the 1/10 portion of the first character outputted. This may not be a defect specifically related to this driver. There are reports related to other video cards with green borders, no text displayed and other pecularities. The latest available version of xorg-x11 available from Fedore Core development was used.
An added note regarding this bug. I experience the border, wrapped around text with no DRI enabled. Some state regarding the mga driver in bug 2991 that the text is visible, but has a border w/ DRI disabled. With DRI Enabled, the text is either not visible or is scrambled. For reference when testing the problem causes, the below comment for degugging was suggested for supplying useful information to help resolve the problem.
Guidlines for debugging. https://bugs.freedesktop.org/show_bug.cgi?id=2991#c4
I tried the new driver, but still get a black screen when typing ctl-alt-f1. Note: I cannot switch back to graphics mode with ctl-alt-f7, so it appears that the keyboard is dead also. I'll post a new log.
Created attachment 2539 [details] testing new driver Same issue
As per the debugging guidelines, I tried the following: rpm -e rhgb - no effect comment out dri - no effect set norenderaccel - no effect set noaccel - no effect I am still curious as to why ctl-alt-f7 doesn't switch me back to graphical mode. Are other folks seeing the same behavior? I'll attach my xorg.conf. I've already posted my server log.
Created attachment 2542 [details] config file
Created attachment 2546 [details] Config file for Intel 815 No options were changed from default settings.
Created attachment 2547 [details] Xorg.0.log w/ xorg-x11-6.8.2-26 I use alt-F7 to change backto the GUI after ctl-alt-Fn to 1-5 virtual terminal. This test was done regarding the next released version that I have not downloaded yet. CTL-ALT-F7 does work to change back to the GUI w/ no problem in this earlier version.
Created attachment 2548 [details] dmesg after various switching from console to GUI
Created attachment 2549 [details] after system-config-display --reconfig I believe the xorg.conf submitted earlier was customized to my preferences. I ran s-c-display --reconfig to check out any differences. I did not obtain any DRI with the previously submitted config file. I have DRI now. Since I am stuck with the blue border until rebooting, I will say that the border is there with or without DRI and text is visible in the terminal. resolution 1024x768@16 with this xorg.conf file.
Created attachment 2550 [details] xorg log w/ dri, lower depth and resolution Installing latest, will reboot with these xorg.conf settings.
Created attachment 2551 [details] glxinfo and gears Though I recall that this info does not do much good, I ran glxgears and glxinfo and pasted both outputs into a file. The gears were running quick, then started pausing and resuming at different speeds. It appeared that the cycle was consistent with up and down speed for the gears.
Created attachment 2552 [details] log with xorg-x11-6.8.2-27 No difference with how the blue border surrounds the screen or how the text is wrapped w/ the first character partially put at the far right and the rest of the text on the next line. ctl-alt-F7 or ALT-F7 both take me back to the GUI. There is no noticable problems with the GUI itself. The problem is only present in the virtual terminals. Runlevel 3, with or without X running.
Created attachment 2553 [details] running two servers, no problem Both server on F7 and the server on F8 work. There appears no difference in the VT terminals, same problem. Log from startx -- :1 & ran from terminal on F3
Created attachment 2554 [details] startx -- :8 & I had trouble launching applications using :1. Changing the command to -- :8 allows applications to work on VT 7 and VT 8. This log with a more working X server on two VTs. I'm out of here! For the Intel 865, I have not tried this unit. With the screenshot submitted on the first bug, it looks like the 865 video card was broken again and the Intel 815 work pretty decent (Except for the console VT problem) Serious consideration to devising seperate drivers for the 810/815 and at least another driver for the 830 through the 865 should be an easier way to have both server chips working. The 865 works great with the latest FC3 version of xorg-x11. The smearing demonstrated by the screenshot in bug 2991 looks pretty bad on the 865 card type. https://bugs.freedesktop.org/attachment.cgi?id=2476
Correction! The screenshot was from the MGA, not the 865.
With xorg-x11-6.8.2-28 installed, I still get the border. I was in screen 3 and was not logged in yet to this VT. I recieved text to screen where the login screen stopped which said the following: [drm:i810_wait_ring] *ERROR* space 65520 wanted 65528 cutoff character to the far right resembling an up and down line. Then the wrapped around text with two small dots up and down from each other followed by this line: (ah! this was a bracket "[" ) [drm:i810_wait_ring] *ERROR* lockup The server is up and running. I am not sure if this error means anything. I changed to the VT before the server fully initiated on screen 7
Created attachment 2567 [details] var log messages - exit stage left I believe I'm just adding noise to the report. Here is /var/log/messages for my departing comment.
(In reply to comment #5) > Can you try the binary driver available at > http://www.fairlite.demon.co.uk/intel.html > and re-report? I just tried one I downloaded last Friday and it didn't make any difference.
Created attachment 2574 [details] Xorg.0.log diff from bad to good
Created attachment 2575 [details] my xorg.conf showing no dri
I've attached my xorg.conf and Xorg.0.log diff from bad to good. How did I fix this? I went from fedora rawhide xorg to fedora 3 updates xorg. For xorg-x11/libs/xfs packages only. I don't use DRI (I might if it were stable). The VBERestore option had a lot of effect in this. If "on", you could go back to a text console, and it wouldn't be blank, but if you went back to X11, it would be blank (or if X11 restarted it would be blank). If off, you couldn't get to a text console without it being blank. One thing to note, is that when either X11 or text are blank, they still work, as I can login, pop up xterms, reboot blindly now. I've tried a healthy matrix of DRI on/off, VideoRam sizes, AGP aperture sizes, accel on/off. I'm stable on Fc3 at the moment. I know the driver got significant rev (true 845++ support), so I wouldn't know where to begin a binary search of the driver, and given the nature of changes if that would be helpful.
I just installed FC4 (Kernel 2.6.11-1.1369_FC4) on G40 with an intel 82852/855GM card. Xorg version 6.8.2-31 I'm seeing the same VT behaviour. I read previous bug reports about issues with xkb if X is started when root file system is read only, so I've tried starting on runlevel 3 with RHGB disabled and still get the issue. Booting to : Run level 5 ctrl/alt/F1.2,3,4 gives a blank screen Booting to : Run level 3 Alt f1/2/3/4 works fine. After starting xwindows with startx ctrl/alt/f1,2,3,4 gives a blank screen. If I close down x (either cleanly with a logout or using ctrl/alt/backspace then I go back to a blank screen. note: when I have a blank screen it's still *usable* I can't see anything but anything I type is accepted. I've tried X with and without DRI.
This bug is also caused by /usr/X11R6/lib/modules/libvgahw.a in the newer xorg-x11 which are compiled with GCC4 vs. 3.x series compilers. Although failures seem to be different with varying video cards, MGA all distorted in many modes GUI and VT. Intel 815 with blue border, Intel 865G shows no screen in terminal. It appears to be stuch in Graphics mode vs. Text mode. White screens with other video types. IMO, it is fair to say that the drivers are a bit itchy from /usr/X11R6/lib/modules/libvgahw.a but both the driver and the static lib can be improved from the observed failure. Can the assorted bugs be grouped to at least take into account the common failure influence?
Just a note regarding libvgahw.a. By replacing this file with one from a version of X that worked in the past will allow visible text in the VT. The system must be rebooted to correct errors caused post launching X from startx or runlevel 5 /usr/X11R6/lib/modules/libvgahw.a There is also a bug that I submitted that links the library with the MGA and the Intel bug, bug 3557 above. The comments made there seem to be rational regarding overscan workarounds and lingering tricks used to make the drivers be more desirable visually to the user. The blue screen was said to be a result from another library (xf86Mode.c imposing old VGA blanking length restrictions.) comment from Luc Verhaegen in ()
Thanks Jim for the pointer. It appears that Mike Harris at RedHat has opened up a bug in their database to find what broke things in FC4 over FC3 for libvgahw.a. I'm marking this as NOTOURBUG, and pasting the RedHat bug report here for people's use. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242 If things transpire to be something else, then re-open this bug.
The lib seems to be the main trigger for the x server crashes. I think that the effects regarding the blue border and wrapped text might be investigated while using libvgahw.a frim FC4 compiled with GCC4. I don't think the driver is busted trying w/ 865G and Intel 815 video.
*** Bug 3848 has been marked as a duplicate of this bug. ***
I have an Intel 855 card, using the i810 driver and I had the problem described here concerning blank VC screens. Adding this option to the Device section fixed it: Option "VBERestore" "true" I hope this help someone!
The problem seemed to be related to how GCC4 compiled optimized code regarding type volatile. The latest xorg-x11 using a revised GCC4 version compiles xorg-x11 fine now.
For people who stumble upon this... The gcc 4.0.0 bug that causes this problem to occur is fixed in newer versions of gcc, although I'm not sure what specific upstream gcc version has it. Fedora Core 4 and Fedora development both have a gcc that this bug has been fixed in now, and Red Hat has released updated Xorg builds for FC4 which resolve this issue. Any users who experienced this problem in FC4 should update to the latest xorg-x11 packages. Users of other distributions who experience this problem should check to make sure their distribution has updated gcc4 to fix the issue as well. Hope this helps.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.