Bug 924002 - kernel-3.8.3-101.fc17.x86_64 breaks my display resolution
Summary: kernel-3.8.3-101.fc17.x86_64 breaks my display resolution
Keywords:
Status: CLOSED DUPLICATE of bug 922304
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 17
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-20 22:06 UTC by Krzysztof Pawlik
Modified: 2013-03-20 23:02 UTC (History)
28 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 922304
Environment:
Last Closed: 2013-03-20 23:01:40 UTC


Attachments (Terms of Use)

Description Krzysztof Pawlik 2013-03-20 22:06:05 UTC
This bug affects F17 also. Can we have new kernel built (>3.8.3-101.fc17)?



+++ This bug was initially created as a clone of Bug #922304 +++

Created attachment 710973 [details]
dmesg

Description of problem: I upgraded to 3.8.3-201.fc18 kernel to test it, and it started booting fine, resolution seemed ok/native, but just little before startig X, or when X was starting I'm not really sure it changes the resoltuion to 1024x768 instead of 1280x720 which is native display resolution. This is on laptop with GM45 graphics.


Version-Release number of selected component (if applicable):
kernel-3.8.3-201.fc18.x86_64

How reproducible:


Steps to Reproduce:
1. install kernel-3.8.3-201.fc18.x86_64
2. reboot
3.
  
Actual results:
wrong screen resolution

Expected results:
using native screen resolution

Additional info:

--- Additional comment from branko on 2013-03-16 02:47:05 EDT ---

Created attachment 710974 [details]
xorg log

--- Additional comment from branko on 2013-03-16 02:47:27 EDT ---

Created attachment 710975 [details]
xrandr output

--- Additional comment from branko on 2013-03-16 02:54:31 EDT ---

Sorry I was wrong about native display resolution it is 1280x800 not, 1280x720 which is detected right in xrandr output for LVDS1

--- Additional comment from Arkadiusz Miskiewicz on 2013-03-16 03:23:15 EDT ---

https://lkml.org/lkml/2013/3/14/540

no solution beside reverting 

2a9810441fcc26cf3f006f015f8a62094fe57a90 is the first bad commit
commit 2a9810441fcc26cf3f006f015f8a62094fe57a90
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Dec 1 21:03:22 2012 +0100

    drm/i915: reorder setup sequence to have irqs for output setup

--- Additional comment from Anthony Messina on 2013-03-16 10:21:42 EDT ---

I confirm this same issue on a Thinkpad X200s.

--- Additional comment from  on 2013-03-17 05:24:14 EDT ---

I have the same problem after updating to 3.8.3-201.fc18.

Instead of defaulting to the native display resolution of 1280x800 it now goes to 1024x768. This is on an HP laptop with Intel Chipset Series 4 Integrated Graphics.

I am using a work around for this problem for now by adding the following line to /etc/gdm/Init/Default
xrandr --output LVDS1 --mode 1280x800

--- Additional comment from techouse on 2013-03-17 07:33:10 EDT ---

Same thing here. After installing and booting into kernel-3.8.3-201.fc18.x86_64 my 1280x800 resolution went to 1024x768 and there was no option like 1280x800 to chose from the resolutions menu in Gnome settings. There was only 1024x768 and 800x600, so everything 4:3. Booting back to 3.8.2 fixed it.

SPECS:
From dmesg:
[    0.934394] agpgart-intel 0000:00:00.0: Intel GM45 Chipset

From lspci:
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

--- Additional comment from Iosif Bancioiu on 2013-03-17 16:04:54 EDT ---

the same on Dell Vostro 1015 1024x768 instate of 1366x768 -> kernel-3.8.3-206.fc18.i686

--- Additional comment from Kamil Páral on 2013-03-17 16:18:06 EDT ---

The same problem here on Thinkpad T500. xrandr says I have LVDS1 with 1680x1050 resolution (that is correct, that is my notebook display) and VGA1 with 1024x768 connected (that is incorrect, I don't have any external display connected). GNOME clones the displays, so I get 1024x768 resolution. Didn't happen with kernel-3.8.2-206.fc18.x86_64.

Two more people (bitlord and amessina) confirmed the problem here:
https://admin.fedoraproject.org/updates/FEDORA-2013-3893/kernel-3.8.3-201.fc18

--- Additional comment from Tomas Dolezal on 2013-03-17 16:26:27 EDT ---

same for me on lenovo T400
Display starts in cloning mode, VGA1 is detected as connected, which is not true. That is probably the cause of problem. Primary display is on LVDS1 with 1024x768; native resolution is 1440x900.

kernel-3.8.2-206.fc18.x86_64

$ lspci -nns 00:02
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)

--- Additional comment from Tomas Dolezal on 2013-03-17 16:30:51 EDT ---

sorry for bad kernel specified in comment above, it's same as for the others
kernel-3.8.3-201.fc18.x86_64

--- Additional comment from Jim Haynes on 2013-03-17 21:04:19 EDT ---

Same problem for me on a Dell i1545 laptop
I looked in system tools->system settings->display and it says it is a
mirrored display.

--- Additional comment from Steven Michael Williams on 2013-03-18 00:19:35 EDT ---

I have the same issue using a Lenovo G530. Tried to redetect the display and it won't go any higher than 1024x768. Previous kernel works fine.

--- Additional comment from Roman Kagan on 2013-03-18 07:02:45 EDT ---

Me too on Lenovo ThinkPad T500.

The relevant log part (with drm.debug=255)


3.8.3-201.fc18:

[    2.539349] [drm:intel_crt_detect], CRT detected via hotplug


3.8.2-206.fc18:

[    2.703031] [drm:intel_crt_detect], CRT not detected via hotplug


In both cases nothing is connected to the VGA output.

My suspect is

commit 2a9810441fcc26cf3f006f015f8a62094fe57a90
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Dec 1 21:03:22 2012 +0100

    drm/i915: reorder setup sequence to have irqs for output setup
    
    commit 52d7ecedac3f96fb562cb482c139015372728638 upstream.
    
    Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that
    well. Noticed since the dp aux code doesn't have an automatic fallback
    with a timeout (since the hw provides for that already).
    
    v2: Simple move drm_irq_install before intel_modeset_gem_init, as
    suggested by Ben Widawsky.
    
    v3: Now that interrupts are enabled before all connectors are fully
    set up, we might fall over serving a HPD interrupt while things are
    still being set up. Instead of jumping through massive hoops and
    complicating the code with a separate hpd irq enable step, simply
    block out the hotplug work item from doing anything until things are
    in place.
    
    v4: Actually, we can enable hotplug processing only after the fbdev is
    fully set up, since we call down into the fbdev from the hotplug work
    functions. So stick the hpd enabling right next to the poll helper
    initialization.
    
    v5: We need to enable irqs before intel_modeset_init, since that
    function sets up the outputs.
    
    v6: Fixup cleanup sequence, too.
    
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


but I don't have the time to dig deeper ATM.

--- Additional comment from  on 2013-03-18 08:02:36 EDT ---

Same here on my T500.
The X-Server actually crashes with the new kernel if I don't add radeon.modeset=0 to kernel options. But if I add it I get a wrong resolution and a non existing VGA monitor. And as a bonus vgaswitcheroo isn't working any more so I have a boiling notebook.
Reverting to 3.8.2 solves the issus for now. I really hope for a quick fix.

Xorg.0.log: http://paste.fedoraproject.org/5300/36072581
dmesg: http://paste.fedoraproject.org/5301/13636072
xrandr: http://paste.fedoraproject.org/5302/13636073

--- Additional comment from Dave Airlie on 2013-03-18 08:17:39 EDT ---

backporting 20afbda209d from linus tree has been suggested, maybe someone can do that, I'm zzzz.

--- Additional comment from Fedora Update System on 2013-03-18 11:16:54 EDT ---

kernel-3.8.3-203.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.8.3-203.fc18

--- Additional comment from Fedora Update System on 2013-03-18 16:05:04 EDT ---

kernel-3.8.3-103.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/FEDORA-2013-3909/kernel-3.8.3-103.fc17

--- Additional comment from Axel Sommerfeldt on 2013-03-19 04:34:54 EDT ---

Same problem here with kernel-3.8.3-201.fc18:

[    0.637622] agpgart-intel 0000:00:00.0: Intel GM45 Chipset

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)

kdm (and razor-qt) starts in 1024x768 while the correct screen resolution would be 1280x800. The old kernel-3.8.2-206 works fine.

--- Additional comment from  on 2013-03-19 04:51:38 EDT ---

I just installed kernel-3.8.3-203.fc18.x86_64 and the problem is gone, thanks for the quick fix.

--- Additional comment from Josh Boyer on 2013-03-19 09:20:07 EDT ---

*** Bug 922665 has been marked as a duplicate of this bug. ***

--- Additional comment from Jim Haynes on 2013-03-19 15:50:35 EDT ---

kernel-3.8.3-203.fc18.x86_64 fixes it for me too, Dell i1545 laptop.

--- Additional comment from Fedora Update System on 2013-03-19 16:06:06 EDT ---

kernel-3.8.3-203.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from Jaroslav Škarvada on 2013-03-20 05:10:35 EDT ---

*** Bug 923348 has been marked as a duplicate of this bug. ***

--- Additional comment from Justin M. Forbes on 2013-03-20 11:04:00 EDT ---

*** Bug 922500 has been marked as a duplicate of this bug. ***

Comment 1 Josh Boyer 2013-03-20 23:01:40 UTC
(In reply to comment #0)
> This bug affects F17 also. Can we have new kernel built (>3.8.3-101.fc17)?

You mean like the one that is already in updates-testing and on it's way to stable and is marked as fixing the original bug and is mentioned in comment #18 of the bug you cloned?  Like this one?

https://admin.fedoraproject.org/updates/FEDORA-2013-3909/kernel-3.8.3-103.fc17

Yes!  Of course we can have that. :)

*** This bug has been marked as a duplicate of bug 922304 ***

Comment 2 Josh Boyer 2013-03-20 23:02:49 UTC
fwiw, 3.8.4 is being built shortly too, and that has the reverts upstream.


Note You need to log in before you can comment on or make changes to this bug.