Bug 35812

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