Bug 35812

Summary: [SNB] Kernel Mode-Settings problems (Dell Latitude e6420)
Product: xorg Reporter: Georg Grabler <georg>
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: brot+bfdo
Version: 7.6 (2010.12)   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Picture of the problem
none
dmesg output
none
intel reg dump
none
vbios dump
none
xorg log
none
xorg conf
none
xrandr verbose output
none
intel_reg_dump after disable end enable (screen working)
none
dmesg with kernel boot param drm.debug=0xe
none
xrandr_verbose for danvet none

Description Georg Grabler 2011-03-30 11:44:23 UTC
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 :-)
Comment 1 Georg Grabler 2011-03-30 11:45:46 UTC
Created attachment 45069 [details]
Picture of the problem
Comment 2 Georg Grabler 2011-03-30 12:27:01 UTC
Created attachment 45071 [details]
dmesg output
Comment 3 Georg Grabler 2011-03-30 12:27:41 UTC
Created attachment 45072 [details]
intel reg dump
Comment 4 Georg Grabler 2011-03-30 12:28:12 UTC
Created attachment 45073 [details]
vbios dump
Comment 5 Georg Grabler 2011-03-30 12:28:51 UTC
Created attachment 45074 [details]
xorg log
Comment 6 Georg Grabler 2011-03-30 12:29:50 UTC
Created attachment 45075 [details]
xorg conf
Comment 7 Georg Grabler 2011-03-30 12:30:14 UTC
Created attachment 45076 [details]
xrandr verbose output
Comment 8 Chris Wilson 2011-04-01 00:06:35 UTC
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?
Comment 9 Georg Grabler 2011-04-02 03:37:09 UTC
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.
Comment 10 Chris Wilson 2011-04-02 03:41:57 UTC
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)?
Comment 11 Georg Grabler 2011-04-02 04:39:04 UTC
Created attachment 45157 [details]
intel_reg_dump after disable end enable (screen working)
Comment 12 Chris Wilson 2011-04-03 01:34:16 UTC
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?
Comment 13 Georg Grabler 2011-04-03 04:59:06 UTC
Created attachment 45177 [details]
dmesg with kernel boot param drm.debug=0xe
Comment 14 Georg Grabler 2011-05-13 08:02:00 UTC
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.
Comment 15 Georg Grabler 2011-05-25 10:57:40 UTC
With 2.6.39 this problem completely disappeared, tested for a week now. Time to close the bug.
Comment 16 Georg Grabler 2012-06-14 01:45:42 UTC
Hello,

The problem re-appeared for me with kernel 3.4.2, where rc6 is enabled by default again.
Comment 17 Chris Wilson 2012-06-14 02:03:50 UTC
Can you please check with i915.i915_enable_rc6=0 to rule out that possiblity?
Comment 18 Georg Grabler 2012-06-14 02:04:14 UTC
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).
Comment 19 Georg Grabler 2012-06-14 02:08:44 UTC
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?
Comment 20 Georg Grabler 2012-06-24 12:05:43 UTC
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.
Comment 21 Georg Grabler 2012-06-24 12:06:05 UTC
(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
Comment 22 Georg Grabler 2012-06-24 12:29:40 UTC
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?
Comment 23 Georg Grabler 2012-06-26 13:38:35 UTC
Created attachment 63496 [details]
xrandr_verbose for danvet

xrandr_verbose output of the working mode.
Comment 24 Georg Grabler 2012-06-30 08:45:33 UTC
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.