Created attachment 35714 [details] dmesg Archlinux Fresh install and full system upgrade Kernel 2.26.33 xf86-video-intel 2.10.0-1 xorg-server 1.7.6-3 With KMS (default menu.lst), xorg runs fine but I can't read the output of any framebuffer applications (TTY's). Instead of the usual login prompt in consoles, I got some pixel noise moving from right to left where there where supposed to be some text. This happen when the boot sequence start to load the kernel module, as I can read the boot process until the "loading module" line. It happened since KMS was incorporated in the linux kernels (2.26.3X I think). Without KMS (added "nomodeset" in menu.lst bootline), I can't start X as it is with the new intel driver. However, with the "nomodeset" line I don't have the problems below. I put dmesg output in the attachment
The following bug is on an intel D945GCLF motherboard and can be reproduced every time I boot.
Jesse any clues about this warning? Appears harmless though. agpgart-intel 0000:00:00.0: Intel 945G Chipset resource map sanity check conflict: 0x88280000 0x882bffff 0x88280000 0x8829ffff 0000:00:02.0 ------------[ cut here ]------------ WARNING: at arch/x86/mm/ioremap.c:135 __ioremap_caller+0x2a7/0x2f0() Hardware name: Info: mapping multiple BARs. Your kernel is fine. Call Trace: [<f804d5a9>] intel_i915_create_gatt_table+0x79/0x120 [intel_agp] [<f80332a4>] agp_add_bridge+0x124/0x520 [agpgart] Sebastien, it sounds like you have modesetting issue. Can you please attach a dmesg with drm.debug=4, and if possible intel_reg_dumper output for a successful ums load and the failing kms boot along with the xrandr and Xorg.logs.
Created attachment 38039 [details] [review] Fix wm calculation. The pixel noise on the fbcon and not in X is reminiscent of a FIFO issue and should be fixed with the attached patch. It also implies that there is a modeswitch between the console and X, which should be fixed in xserver-1.9.
Hi all, I have the same or similiar issue on a HP 5320m labtop: 1. Starting with KMS enabled gets me heavy flicker and massive display distortions right after start from GRUB. These distortions are present in Console and later in X11/KDE environment. 2. If I disabled KMS by using "nomodeset", I get a clear screen using either X11 auto-configuration (which is using fbdev) or manual cX11 configuration using VESA driver. I (try to) attach to arichives: - "hp320m_flicker_videos.zip" containing 2 short videos of the console and X11 screens - "hp5320m_flicker_logs.tar.gz" containing dmesg,X11 log and lscpi. If anything more is needed, please tell me. Thomas
Created attachment 43086 [details] Contains short videos X11 flicker screen
Created attachment 43087 [details] Contains system logs (dmesg,X11,lspci)
(In reply to comment #4) > Hi all, > I have the same or similiar issue on a HP 5320m labtop: > 1. Starting with KMS enabled gets me heavy flicker and massive display > distortions right after start from GRUB. These distortions are present in > Console and later in X11/KDE environment. > 2. If I disabled KMS by using "nomodeset", I get a clear screen using either > X11 auto-configuration (which is using fbdev) or manual cX11 configuration > using VESA driver. > > I (try to) attach to arichives: > - "hp320m_flicker_videos.zip" containing 2 short videos of the console and X11 > screens > - "hp5320m_flicker_logs.tar.gz" containing dmesg,X11 log and lscpi. > > If anything more is needed, please tell me. > Thomas Replying to myself: - OS is standard openSUSE 11.3, except I am using an openSuSE-provided kernel 2.6.37.6
Thoman, you have your own bug based on the massive difference in chipset generations. Please file separately and attach the text files individually (not as a tar ball), that makes reviewing the information much easier. Appending drm.debug=0xe to your boot parameters would be useful, as is testing drm-intel-next for the eDP fixes.
(In reply to comment #8) > Thoman, you have your own bug based on the massive difference in chipset > generations. Please file separately and attach the text files individually (not > as a tar ball), that makes reviewing the information much easier. > Appending drm.debug=0xe to your boot parameters would be useful, as is testing > drm-intel-next for the eDP fixes. Thanks for the tip, I have now done that (bug# 34165) Thomas
(In reply to comment #8) > Thoman, you have your own bug based on the massive difference in chipset > generations. Please file separately and attach the text files individually (not > as a tar ball), that makes reviewing the information much easier. > Appending drm.debug=0xe to your boot parameters would be useful, as is testing > drm-intel-next for the eDP fixes. I have removed my attachments as they are not applicable to this specific bug. Sorry about that, Thomas
Comment on attachment 38039 [details] [review] Fix wm calculation. The patch is wrong; please ignore.
(In reply to comment #2) > Sebastien, it sounds like you have modesetting issue. Can you please attach a > dmesg with drm.debug=4, and if possible intel_reg_dumper output for a > successful ums load and the failing kms boot along with the xrandr and > Xorg.logs. Sebastian, can you please provide this information? This is the basic info-dump we need to diagnose modesetting issues.
Original reporter hasn't replied on this one, but we think it's fixed. Sebastien, please re-open if not with your testing results on drm-intel-next-queued. Thanks.
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.