Created attachment 344318 [details] Xorg log file Description of problem: Tried to run rawhide and fedora 11 preview on my old Dell Inspiron 500m laptop. It has an internal display showing 1280x1024. With rawhide and Fedora 11 preview the modeline is set to 1400x1050, and the screen is naturally garbled. Version-Release number of selected component (if applicable): How reproducible: Boot Steps to Reproduce: 1. Boot the machine 2. The corruption occurs before the GDM kicks in, and stays that way 3. Actual results: A non-working resolution Expected results: A working resolution of 1280x1024 Additional info: I attach xorg log file and output from dmesg
Created attachment 344319 [details] output from dmesg
Maybe this should be filed against the xorg intel driver component?
Seems to be a flaw in the KMS handling. If I add i915.modeset=0 to the kernel boot line, the system starts with a somewhat better resolution (1 cm black bars to the right and left of the screen.)
My bad. The native resolution on the LCD is actually 1400x1050, and with i915.modeset=0 at the boot line, I'm able to set the resolution to 1400x1050 wich looks fine. So the bug boils down to that KMS doesn't work as it should.
Versions of the components used. xorg-x11-drv-intel-2.7.0-4.fc11.i586 xorg-x11-server-Xorg-1.6.1-11.fc11.i586 xorg-x11-server-common-1.6.1-11.fc11.i586 xorg-x11-server-utils-7.4-7.fc11.i586 kernel-firmware-2.6.29.3-140.fc11.noarch kernel-2.6.29.3-140.fc11.i586
When using the default kernel boot line, the following message is shown: IO APIC resources could be not be allocated. And the screen is in a garbled state. This happens right after the GRUB menu. The distortion continues into X, showing about 1/4 of the screen (top-left corner). This means that allowing KMS as a default option at this time really destroys the Fedora experience for users of this chipset.
Just tested with kernel-2.6.29.3-155.fc11.i586 and the problem persists.
The problem persists with kernel-2.6.29.4-167.fc11.i586 xorg-x11-drv-intel-2.7.0-7.fc11.i586 I think this is a showstopper for this chipset, since even with nomodeset X crashes when playing a video file.
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
Yep, and I can confirm that the bug is still here in F11 final (same version of kernel and intel driver as in comment #8, so I'm not surprised). This renders the laptop unusable with and without nomodeset as described above.
Can you provide the /var/log/Xorg.0.log from the 'nomodeset' case too? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 347112 [details] Xorg log with nomodeset and the release F11 kernel After trying to play one video file in totem
Created attachment 347113 [details] Xorg log after trying to open the video file a second time Here X crashes
The two additional log files were created as follows: clean boot with nomodeset set as boot parameter double click a video file -> first log file (totem closes) double click the same file -> second log file (X crashes)
I don't really care about the video playback failure at this point, I just wanted it to compare the mode detection stuff. We would rather fix the modesetting case than the no modesetting case. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The log claims that the resolution is 1400x1050 even in the nomodeset case: (II) intel(0): Printing probed modes for output LVDS (II) intel(0): Modeline "1400x1050"x60.0 108.00 1400 1448 1560 1688 1050 1051 1055 1066 -hsync -vsync (64.0 kHz) ... (II) intel(0): Output LVDS using initial mode 1400x1050 are you sure 1400x1050 isn't the right resolution? I'm not sure the problem is accurately described here. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I think that the screen has a native resolution of 1400x1050 as stated in comment #4, so the initial post was wrong about the resolution. However, the rest is accurately described, i.e. without nomodeset the screen is garbled, showing about 1/4th of the screen, and with nomodeset the screen is displaying 1400x1050 without problems, but has the video playback crashing issues.
Created attachment 347164 [details] Xorg log without nomodeset and release F11 Here is the Xorg log file with the release version of Fedora 11 without nomodeset
Created attachment 347167 [details] Screen photo showing the boot before X kicks in This is an example of teh garbled state I've tried to describe
Created attachment 347168 [details] Screen photo showing how X looks when corrupted As you can see about 1/4 of the screen is shown and it looks kind of interlaced
OK, thanks. One last thing, then - in the corrupted state, can you manage to log in, open a console, run 'xrandr' and paste the results of that, or is it too garbled? If you can, that might also be helpful. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 347261 [details] Output from xrandr when booting normally without nomodeset xrandr output when the screen is garbled.
Created attachment 347262 [details] xrandr output when nomodeset given on the boot line xrandr output when nomodeset has been passed to the kernel. In this state the desktop looks OK.
OK, so it's not a mode difference. The phantom VGA1 is a common problem, _probably_ isn't what's causing the corruption, but useful to note. ok, over to Kristian, I think... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 347468 [details] Screen image when playing a video with kms Without nomodeset, i.e. when the display is corrupted - video can be played. See attached image for an example of the video corruptions visible when playing video.
Managed to create a smolt profile: http://www.smolts.org/client/show/pub_df7ce2df-1372-463f-b30d-5d63c2b477ae
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.]
Fully updated Fedora 11 xorg-x11-server-utils-7.4-7.1.fc11.i586 xorg-x11-server-Xorg-1.6.4-0.1.fc11.i586 xorg-x11-server-common-1.6.4-0.1.fc11.i586 xorg-x11-drv-intel-2.7.0-7.fc11.i586 kernel-2.6.30.9-96.fc11.i586 kernel-firmware-2.6.30.9-96.fc11.noarch The exact same problem persists.
Upgraded the rig to F12 today, and here is the funny part: By default the upgrade kept my nomodeset parameter. In this mode the computer hangs at starting smartd. When removing nomodeset from the boot line everything works as expected. So: Fedora 11 still broken, but Fedora 12 seems to work OK, with regards to modesetting during boot. I'll just regard Fedora 11 as a sad part in history for this rig.
Thank you for letting us know.