Bug 16581 - 2.6.35 regression bisected : System hang when starting X with VGA/DVI monitor connected.
Summary: 2.6.35 regression bisected : System hang when starting X with VGA/DVI monitor...
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-13 14:19 UTC by Roel Teuwen
Modified: 2012-08-13 15:48 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.35
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
kernel .config file (74.21 KB, application/octet-stream)
2010-08-13 14:19 UTC, Roel Teuwen
Details
Xorg log of a working session (47.90 KB, application/octet-stream)
2010-08-13 14:20 UTC, Roel Teuwen
Details
Xorg log of a hanging session (27.15 KB, application/octet-stream)
2010-08-13 14:21 UTC, Roel Teuwen
Details
possible fix (1.20 KB, patch)
2010-08-13 14:45 UTC, Alex Deucher
Details | Diff

Description Roel Teuwen 2010-08-13 14:19:07 UTC
Created attachment 27432 [details]
kernel .config file

After upgrading from 2.6.34 to 2.6.35.1 on my laptop, I'm seeing a hang and blank screen when X is started if a VGA or DVI monitor is connected to the docking station before boot. If I boot without the VGA or DVI monitor connected, and hotplug them after X is started, all is fine. Interestingly, there is no problem when both the VGA and DVI monitors are connected.
Console on radeondrmfb works all the time.

Attached you can find the kernel .config, dmesg with and without the panel attached on boot and the Xorg log on success and failure.

I've bisected the problem to the following change :

ce8f53709bf440100cb9d31b1303291551cf517f is the first bad commit
commit ce8f53709bf440100cb9d31b1303291551cf517f
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Fri May 7 15:10:16 2010 -0400

    drm/radeon/kms/pm: rework power management
    
    - Separate dynpm and profile based power management methods.  You can select the pm method
      by echoing the selected method ("dynpm" or "profile") to power_method in sysfs.
    - Expose basic 4 profile in profile method
      "default" - default clocks
      "auto" - select between low and high based on ac/dc state
      "low" - DC, low power mode
      "high" - AC, performance mode
      The current base profile is "default", but it should switched to "auto" once we've tested
      on more systems.  Switching the state is a matter of echoing the requested profile to
      power_profile in sysfs.  The lowest power states are selected automatically when dpms turns
      the monitors off in all states but default.
    - Remove dynamic fence-based reclocking for the moment.  We can revisit this later once we
      have basic pm in.
    - Move pm init/fini to modesetting path.  pm is tightly coupled with display state.  Make sure
      display side is initialized before pm.
    - Add pm suspend/resume functions to make sure pm state is properly reinitialized on resume.
    - Remove dynpm module option.  It's now selectable via sysfs.
    
    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 fa3acba12b9886453c2de619577ae633abfc97bc faf940f2c2791f1382ed1abbfa54e22df7e1c936 M	drivers
Comment 1 Roel Teuwen 2010-08-13 14:20:37 UTC
Created attachment 27433 [details]
Xorg log of a working session
Comment 2 Roel Teuwen 2010-08-13 14:21:37 UTC
Created attachment 27434 [details]
Xorg log of a hanging session
Comment 3 Alex Deucher 2010-08-13 14:45:18 UTC
Created attachment 27435 [details]
possible fix

Does this patch fix the issue?
Comment 4 Roel Teuwen 2010-08-16 08:36:42 UTC
This patch fixed the issue, thank you.

Tested-by: Roel Teuwen <Roel.Teuwen@gmail.com>

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