Hello, I experience a problem with booting, when the kernel mod setting is done, my LVDS display goes black with white stripes to the right side (picture attached). I was asked by ickle to create a seperate bug report for this (where the other one is used for KDE display glitches). So I do, but I will try to attach the dumps when the LVDS display actually was "out of order". Chipset I don't know, but lspci shows "00:02.0 VGA compatible controller: Intel Corporation Device 0126 (rev 09)", maybe it helps System Architecture x86_64 Driver / Lib Versions All built by Chakra-Linux guys (chakra testing repository) xf86-video-intel 2.14.0 xorg-server 1.9.5 mesa 7.10 libdrm 2.4.23 Kernel Version kernel26 2.6.38.2 Linux Distribution Chakra Linux: [testing] repository (don't worry, stable doesn't work too, nor does openSuSE) Machine or mobo model: I just know it's a Dell Latitude e6420 Display Connector: External Monitor: VGA Laptop Monitor: LVDS Steps to reproduce: Just boot :-)
Created attachment 45069 [details] Picture of the problem
Created attachment 45071 [details] dmesg output
Created attachment 45072 [details] intel reg dump
Created attachment 45073 [details] vbios dump
Created attachment 45074 [details] xorg log
Created attachment 45075 [details] xorg conf
Created attachment 45076 [details] xrandr verbose output
So what should be happening is that the panel should be set to 1600x900 and scaling up the 1024x768 fb to fit: PIPEACONF: 0xc0000054 (enabled, active, 6bpc) HTOTAL_A: 0x07fb063f (1600 active, 2044 total) HBLANK_A: 0x07fb063f (1600 start, 2044 end) HSYNC_A: 0x068f066f (1648 start, 1680 end) VTOTAL_A: 0x03a10383 (900 active, 930 total) VBLANK_A: 0x03a10383 (900 start, 930 end) VSYNC_A: 0x038a0385 (902 start, 907 end) VSYNCSHIFT_A: 0x00000000 PIPEASRC: 0x063f0383 (1600, 900) PIPEA_DATA_M1: 0x7e1f53d8 (TU 64, val 0x1f53d8 2053080) PIPEA_DATA_N1: 0x0020f580 (val 0x20f580 2160000) PIPEA_DATA_M2: 0x00000000 (TU 1, val 0x0 0) PIPEA_DATA_N2: 0x00000000 (val 0x0 0) PIPEA_LINK_M1: 0x0001bd8c (val 0x1bd8c 114060) PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 270000) PIPEA_LINK_M2: 0x00000000 (val 0x0 0) PIPEA_LINK_N2: 0x00000000 (val 0x0 0) DSPACNTR: 0xd8004000 (enabled) DSPABASE: 0x00000000 DSPASTRIDE: 0x00001e00 (120) DSPASURF: 0x00063000 DSPATILEOFF: 0x00000000 (0, 0) which looks valid, but would need some detailed inspection of the hardware to confirm the value. But... PFA_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1) PFA_CTL_2: 0x00007e3e (vscale 0.986267) PFA_CTL_3: 0x00003f1f (vscale initial phase 0.493134) PFA_CTL_4: 0x00007ce0 (hscale 0.975586) PFA_WIN_POS: 0x00c80000 (200, 0) PFA_WIN_SIZE: 0x00000000 (0, 0) Ho hum. Does "xrandr --output LVDS1 --preferred" restore the laptop display?
Hi Chris, The command does not change anything, also I'm not sure what it should change, since the problem is when switching to fb mode, not when X starts. What I did notice, disabling and enabling the screen in KDE removes the KMS-Problem.
Well since the problem existed in X as well, I was trying to test a hypothesis that we failed to setup the panel-fitter correctly for a non-native mode. Can you attach a reg dump for the working state (after switching the display off/on)?
Created attachment 45157 [details] intel_reg_dump after disable end enable (screen working)
Hmm, missed one discrepancy in the original dump:- xrandr: LVDS1 connected 1024x768+0+0 regdump: PIPEASRC: 0x063f0383 (1600, 900) which explains the lack of panel fitting (since it thinks it is the native mode), but xrandr thinks it is running with a reduced fb. Clearing the state by turning the output off and then back on seems to be the workaround. Georg, can you add drm.debug=0xe to your grub kernel parameters and attach the dmesg for the boot through to X starting and applying the workaround?
Created attachment 45177 [details] dmesg with kernel boot param drm.debug=0xe
Just a short question: Did you notice the update on the bug? I'm sorry if I'm annoying, but I'm used that you respond quite fast on everything, and it has been some time already :-). Let me know if you need any other logs.
With 2.6.39 this problem completely disappeared, tested for a week now. Time to close the bug.
Hello, The problem re-appeared for me with kernel 3.4.2, where rc6 is enabled by default again.
Can you please check with i915.i915_enable_rc6=0 to rule out that possiblity?
Just added i915.i915_enable_rc6=0 to the kernel boot line - same problem continues to exist. But this time at the KDE-Login when the resolution gets changed switching from KDM to KDE (kde adjusts the screen resolution to the users settings at login).
Again, not a "always" existing problem. Last kernel I had (which worked) was 3.2.8 . As it seems chakra skipped the 3.3 kernel series completely. Should I build a specific kernel version before 3.4.2 to check if the problems still exist, so there are less commits to track?
Just some more details: This happens either at KMD or at X-Login. The thing they have in common: They change the resolution of the screen.
(In reply to comment #20) > Just some more details: > > This happens either at KMD or at X-Login. > The thing they have in common: They change the resolution of the screen. at kms or x-login :-( .. typo
Just checked back with Thiago Macieira, who has the same model as I do. He does not seem to suffer this issue with 3.4.0. Could this be some weired half-bricked hardware? And if so, why was this not there in 3.2?
Created attachment 63496 [details] xrandr_verbose for danvet xrandr_verbose output of the working mode.
Okay, as we agreed on IRC, I tested this with 3.5-rc4. Closing the bug since it seems as if it disappeared (tested yesterday + today, have not had the problem once since I switched to 3.5-rc4). Thanks, Georg
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.