[4.6-rcX regression] closing and opening LID on thinkpad x200s freezes X
Jiri Kosina writes: > Hi, > > after updating to 4.6-rcX (where X is 1 or 2, doesn't really matter) on > thinkpad x200s notebook with > > 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series > Chipset Integrated Graphics Controller (rev 07) > > closing and opening the lid freezes the computer completely (after opening > the LID, I can see either the complete original contents of the screen, or > silouhette of xscreensaver window decorations, but the machine is dead by > then (neither ctrl-alt-backspace-backspace nor switching to text console > doesn't work). > > It definitely worked with older kernels, but I unfortunately don't have > all the data needed for bisection, as the old kernels have been wiped off > the machine in the meantime. > > Is this a known issue? Yup. Fix is queued: https://lkml.org/lkml/2016/3/30/151 Good to see that I'm not the only one running rc's on ancient laptops :) Bjørn
[PATCH] drm/i915: fix deadlock on lid open
commit e2c8b8701e2d moved modeset locking inside resume/suspend
functions, but missed a code path only executed on lid close/open
on older hardware. The result was a deadlock when closing and
opening the lid without suspending on such hardware:
=
[ INFO: possible recursive locking detected ]
4.6.0-rc1 #385 Not tainted
-
kworker/0:3/88 is trying to acquire lock:
(>mode_config.mutex){+.+.+.}, at: []
intel_display_resume+0x4a/0x12f [i915]
but task is already holding lock:
(>mode_config.mutex){+.+.+.}, at: []
drm_modeset_lock_all+0x3e/0xa6 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(>mode_config.mutex);
lock(>mode_config.mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
7 locks held by kworker/0:3/88:
#0: ("kacpi_notify"){.+}, at: []
process_one_work+0x14a/0x50b
#1: ((>work)#2){+.+.+.}, at: []
process_one_work+0x14a/0x50b
#2: ((acpi_lid_notifier).rwsem){.+}, at: []
__blocking_notifier_call_chain+0x34/0x65
#3: (_priv->modeset_restore_lock){+.+.+.}, at: []
intel_lid_notify+0x3c/0xd9 [i915]
#4: (>mode_config.mutex){+.+.+.}, at: []
drm_modeset_lock_all+0x3e/0xa6 [drm]
#5: (crtc_ww_class_acquire){+.+.+.}, at: []
drm_modeset_lock_all+0x48/0xa6 [drm]
#6: (crtc_ww_class_mutex){+.+.+.}, at: []
modeset_lock+0x13c/0x1cd [drm]
stack backtrace:
CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
Workqueue: kacpi_notify acpi_os_execute_deferred
88022fd5f990 8124af06 825b39c0
825b39c0 88022fd5fa60 8108f547 88022fd5fa70
8108e817 880230236cc0 825b39c0
Call Trace:
[] dump_stack+0x67/0x90
[] __lock_acquire+0xdb5/0xf71
[] ? look_up_lock_class+0xbe/0x10a
[] lock_acquire+0x137/0x1cb
[] ? lock_acquire+0x137/0x1cb
[] ? intel_display_resume+0x4a/0x12f [i915]
[] mutex_lock_nested+0x7e/0x3a4
[] ? intel_display_resume+0x4a/0x12f [i915]
[] ? intel_display_resume+0x4a/0x12f [i915]
[] ? modeset_lock+0x13c/0x1cd [drm]
[] intel_display_resume+0x4a/0x12f [i915]
[] ? intel_display_resume+0x4a/0x12f [i915]
[] ? modeset_lock+0x13c/0x1cd [drm]
[] ? modeset_lock+0x13c/0x1cd [drm]
[] ? drm_modeset_lock+0x17/0x24 [drm]
[] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm]
[] intel_lid_notify+0xb0/0xd9 [i915]
[] notifier_call_chain+0x4a/0x6c
[] __blocking_notifier_call_chain+0x4d/0x65
[] blocking_notifier_call_chain+0x14/0x16
[] acpi_lid_send_state+0x83/0xad [button]
[] acpi_button_notify+0x41/0x132 [button]
[] acpi_device_notify+0x19/0x1b
[] acpi_ev_notify_dispatch+0x49/0x64
[] acpi_os_execute_deferred+0x14/0x20
[] process_one_work+0x265/0x50b
[] worker_thread+0x1fc/0x2dd
[] ? rescuer_thread+0x309/0x309
[] ? rescuer_thread+0x309/0x309
[] kthread+0xe0/0xe8
[] ? local_clock+0x19/0x22
[] ret_from_fork+0x22/0x40
[] ? kthread_create_on_node+0x1b5/0x1b5
Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Cc: Maarten Lankhorst
Signed-off-by: Bjørn Mork
---
drivers/gpu/drm/i915/intel_lvds.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 30a8403a8f4f..cd9fe609aefb 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -478,11 +478,8 @@ static int intel_lid_notify(struct notifier_block *nb,
unsigned long val,
* and as part of the cleanup in the hw state restore we also redisable
* the vga plane.
*/
- if (!HAS_PCH_SPLIT(dev)) {
- drm_modeset_lock_all(dev);
+ if (!HAS_PCH_SPLIT(dev))
intel_display_resume(dev);
- drm_modeset_unlock_all(dev);
- }
dev_priv->modeset_restore = MODESET_DONE;
--
2.1.4
[PATCH] drm/i915: refine qemu south bridge detection
Jani Nikula writes:
> On Mon, 25 Jan 2016, Gerd Hoffmann wrote:
>> The test for the qemu q35 south bridge added by commit
>> "39bfcd52 drm/i915: more virtual south bridge detection"
>> also matches on real hardware. Having the check for
>> virtual systems last in the list is not enough to avoid
>> that ...
>>
>> Refine the check by additionally verifying the pci
>> subsystem id to see whenever it *really* is qemu.
>>
>> Reported-by: Bjørn Mork
>> Signed-off-by: Gerd Hoffmann
>
> Already sent the revert in [1], but I'm fine with this if it works for
> Bjørn.
Gerd's fix works fine for me (of course). Tested it now just to be 100%
sure, although it was pretty obvious from the code that it would have
the same effect as an revert on my system.
But I have a feeling Gerd might want to send you a v2 of it in any
case... I was curious about this QEMU subsystem vendor ID, so I went
grepping for it - and found nothing!
|> + pch->subsystem_vendor == 0x1a4f &&
|> + pch->subsystem_device == 0x1100)) {
Looks like a typo:
bjorn at nemi:/usr/local/src/git/qemu$ git grep
PCI_SUBVENDOR_ID_REDHAT_QUMRANET
hw/pci/pci.c:static uint16_t pci_default_sub_vendor_id =
PCI_SUBVENDOR_ID_REDHAT_QUMRANET;
include/hw/pci/pci.h:#define PCI_SUBVENDOR_ID_REDHAT_QUMRANET 0x1af4
0x1af4 != 0x1a4f
Thanks a lot both of you for a really fast fix. But it seems Gerd was a
little too fast :)
Bjørn
[PATCH v2] drm/i915: gen4: work around hang during hibernation
Jani Nikula writes: > On Mon, 02 Mar 2015, Imre Deak wrote: >> Bjørn reported that his machine hang during hibernation and eventually >> bisected the problem to the following commit: >> >> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d >> Author: Imre Deak >> Date: Thu Oct 23 19:23:26 2014 +0300 >> >> drm/i915: add poweroff_late handler >> >> The problem seems to be that after the kernel puts the device into D3 >> the BIOS still tries to access it, or otherwise assumes that it's in D0. >> This is clearly bogus, since ACPI mandates that devices are put into D3 >> by the OSPM if they are not wake-up sources. In the future we want to >> unify more of the driver's runtime and system suspend paths, for example >> by skipping all the system suspend/hibernation hooks if the device is >> runtime suspended already. Accordingly for all other platforms the goal >> is still to properly power down the device during hibernation. >> >> v2: >> - Another GEN4 Lenovo laptop had the same issue, while platforms from >> other vendors (including mobile and desktop, GEN4 and non-GEN4) seem >> to work fine. Based on this apply the workaround on all GEN4 Lenovo >> platforms. >> - add code comment about failing platforms (Ville) >> >> Reference: >> http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html >> Reported-and-bisected-by: Bjørn Mork >> Signed-off-by: Imre Deak > > Bjørn, I would really appreciate your Tested-by on this patch before I > queue it for v4.0 and cc: stable for v3.19. No problem. This version still works fine for me. Feel free to add Tested-by: Bjørn Mork Bjørn
[PATCH] drm/i915: fix failure to power off after hibernate
Ville Syrjälä writes:
>> @@ -651,7 +651,14 @@ static int i915_drm_suspend_late(struct drm_device
>> *drm_dev)
>> }
>>
>> pci_disable_device(drm_dev->pdev);
>> -pci_set_power_state(drm_dev->pdev, PCI_D3hot);
>> +/*
>> + * During hibernation on some GM45 platforms the BIOS may try to access
>> + * the device even though it's already in D3 and hang the machine. So
>> + * leave the device in D0 on those platforms and hope the BIOS will
>> + * power down the device properly.
>
> Please include the model of the known bad machine in this comment, to
> help future archaeologists.
Here are some details:
bjorn at nemi:~$ grep . /sys/class/dmi/id/{bios,product}* 2>/dev/null
/sys/class/dmi/id/bios_date:12/19/2011
/sys/class/dmi/id/bios_vendor:LENOVO
/sys/class/dmi/id/bios_version:6EET55WW (3.15 )
/sys/class/dmi/id/product_name:2776LEG
/sys/class/dmi/id/product_version:ThinkPad X301
Please let me know if you need some other data.
Bjørn
[PATCH] drm/i915: fix failure to power off after hibernate
Imre Deak writes: > Attached is the proposed fix for this issue. > > --Imre > > From 5c23657bc168db12a1ba100ab65fabd305c89c8a Mon Sep 17 00:00:00 2001 > From: Imre Deak > Date: Thu, 26 Feb 2015 18:38:53 +0200 > Subject: [PATCH] drm/i915: gm45: work around hang during hibernation I can confirm that this patch solves the problem for me. Thanks. Bjørn
[PATCH] drm/i915: fix failure to power off after hibernate
Imre Deak writes: >> That patch fixes the problem, with only pci_set_power_state commented >> out. Do you still want me to try with pci_disable_device() commented >> out as well? > > No, but it would help if you could still try the two attached patch > separately, without any of the previous workarounds. Based on the > result, we'll follow up with a fix that adds for your specific platform > either of the attached workarounds or simply avoids putting the device > into D3 (corresponding to the patch you already tried). None of those patches made any difference. The laptop still hangs at power-off. Not really surprising, is it? Previous testing shows that the hang occurs at the pci_set_power_state(drm_dev->pdev, PCI_D3hot) call in the poweroff_late hook. It is hard to see how replacing it by an attempt to set D3cold, or adding any call after this point, could possibly change anything. The system is stil hanging at the pci_set_power_state() call. The generic pci-driver code will put the i915 device into PCI_D3hot for you, won't it? Why do you need to duplicate that in the driver, *knowing* that doing so breaks (at least some) systems? I honestly don't think this "let's try some random code" is the proper way to fix this bug (or any other bug for that matter). You need to start understanding the code you write, and the first step is by actually explaining the changes you make. I also believe that you completely miss the fact that this bug has survived a full release cycle before you became aware of it, and the implications this has wrt other affected systems/users. I assume you understand that my system isn't one-of-a-kind, This means that there are other affected users with identical/similar systems. Now, if none of those users reported the bug to you (we all know why: Linux kernel development is currently limited by the available testing resources, NOT by the available developer resources), then how do you know that there aren't a number of other systems affected as well? Let me answer that for you: You don't. Which is why you must explain the mechanism triggering the bug, proving that it is a chipset/system specific issue. Because that's the only way you will *know* that you have solved the problem not only for me, but for all affected users. IMHO, the only safe and sane solution at the moment is the revert patch I posted. It's a simple fix, reverting back to the *known* working state before this regression was introduced. Then you can start over from there, trying to implement this properly. Thanks, Bjørn
[PATCH] drm/i915: fix failure to power off after hibernate
Imre Deak writes: > The poweroff handlers undo the actions of the thaw handlers. As the > original commit stated saving the registers is not needed there, but > it's also not a big overhead and there should be no problem doing it. We > are planning to optimize the hibernation sequence by for example not > shutting down the display between freeze and thaw, and also getting rid > of unnecessary steps at the power off phase. But before that we want to > actually unify things rather than having special cases, as maintaining > the special code paths caused already quite a lot of problems for us so > far. That sounds like a worthy goal. I don't understand what you hope to achieve by having a poweroff_late hook, since there aren't really anything useful left to do at the point it is called, but if you want a dummy callback there for code structure reasons then fine. But you cannot just run around breaking stuff while slowly moving towards this goal over multiple releases... v3.19 is currently broken and that seems totally unnecessary. In any case: You should have noticed this problem while testing your patches. The breakage is 100% reproducible. Unfortunately I had to do a bisect to realize what you had done to the i915 driver, something I unfortunately didn't find time to do before v3.19 was released. But I do find it unnecessary to release with such bugs. Any attempt to exercise the code path you modified would have revealed the bug. > Reverting the commit may hide some other issue, so before doing that > could you try the following patch: > http://lists.freedesktop.org/archives/intel-gfx/2015-February/060529.html Makes no difference. I assume that patch fixes an unrelated bug? The age and reported symptoms indicates so. Note that I am reporting a regression introduced after v3.18, while that seems to fix a bug introduced in v3.17. Both v3.17 and v3.18 (including v3.18.6), as well as earlier releases, work fine for me. > If with that you still get the hang could you try on top of that the > patch below, first having only pci_set_power_state uncommented, then > both pci_set_power_state and pci_disable_device uncommented? That patch fixes the problem, with only pci_set_power_state commented out. Do you still want me to try with pci_disable_device() commented out as well? Bjørn
[PATCH] drm/i915: fix failure to power off after hibernate
This fixes a bug where hibernation completes, but the system
fails to power off after the image has been saved.
Bisection lead to commit da2bc1b9db33 ("drm/i915: add poweroff_late
handler") which added a .poweroff_late hook pointing to the same
function as the .freeze_late hook, without any justification or
explanation why this would be correct, except "for consistency".
The assumption that this "makes the power off handling identical to
the S3 suspend and S4 freeze handling" is completely bogus. As clearly
documented in Documentation/power/devices.txt, the poweroff* hooks
are part of the hibernation API along with the freeze* hooks. The
phases involved in hibernation are:
prepare, freeze, freeze_late, freeze_noirq, thaw_noirq, thaw_early,
thaw, complete, prepare, poweroff, poweroff_late, poweroff_noirq
With the above sequence in mind, it should be fairly obvious that you
cannot save registers and disable the device in both the freeze_late
and poweroff_late phases. Or as Documentation/power/devices.txt
explains it:
The poweroff, poweroff_late and poweroff_noirq callbacks should do essentially
the same things as the suspend, suspend_late and suspend_noirq callbacks,
respectively. The only notable difference is that they need not store the
device register values, because the registers should already have been stored
during the freeze, freeze_late or freeze_noirq phases.
The "consistency" between suspend and hibernate was already in
place, with freeze_late pointing to the same function as suspend_late.
There is no need for any poweroff_late hook in this driver.
This reverts commit da2bc1b9db33.
Fixes: da2bc1b9db33 ("drm/i915: add poweroff_late handler")
Cc:
Cc: Imre Deak
Cc: Ville Syrjälä
Signed-off-by: Bjørn Mork
---
drivers/gpu/drm/i915/i915_drv.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8039cec71fc2..9cd695710f93 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1520,7 +1520,6 @@ static const struct dev_pm_ops i915_pm_ops = {
.thaw_early = i915_pm_resume_early,
.thaw = i915_pm_resume,
.poweroff = i915_pm_suspend,
- .poweroff_late = i915_pm_suspend_late,
.restore_early = i915_pm_resume_early,
.restore = i915_pm_resume,
--
1.7.10.4
[BISECTED REGRESSION v3.18->v3.19-rc1] drm/i915: failure to poweroff after hibernation
Hello, My Lenovo Thinkpad X301 has failed to power off after saving the hibernation image ever since v3.19-rc1. This is a regression since v3.18. The regression is still present i v4.0-rc1. The symptoms are: Hibernation proceeds as usual, writing a complete image. But instead of powering off the laptop stays on in a "dead" state, with fans running and the "sleep" LED blinking. The only way out of this state is by hard poweroff (pressing the power button for 4+ seconds). The system can successfully resume after this, proving that the hibernation was complete. I consider the bug somewhat critical as the system will continue to draw power until it is forcibly powered off, or the battery is completely dead. This causes unexpected battery usage and unnecessary battery wear if the power-off failure goes unnoticed. I finally took the time to bisect the problem, and ended up with this surprisingly obvious result: da2bc1b9db3351addd293e5b82757efe1f77ed1d is the first bad commit commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler The suspend_late handler saves some registers and powers off the device, so it doesn't have a big overhead. Calling it at S4 poweroff_late time makes the power off handling identical to the S3 suspend and S4 freeze handling, so do this for consistency. Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter :04 04 367eee899c6c2b2a669e2e46f68529dad0e1f7a3 78c7571e2b18dc0fb77161b8a3e32288bd4cbee8 M drivers The bisect log was: # bad: [97bf6af1f928216fd6c5a66e8a57bfa95a659672] Linux 3.19-rc1 # good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18 git bisect start 'v3.19-rc1' 'v3.18' # good: [70e71ca0af244f48a5dcf56dc435243792e3a495] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect good 70e71ca0af244f48a5dcf56dc435243792e3a495 # bad: [988adfdffdd43cfd841df734664727993076d7cb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad 988adfdffdd43cfd841df734664727993076d7cb # good: [e7cf773d431a63a2417902696fcc9e0ebdc83bbe] Merge tag 'usb-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb git bisect good e7cf773d431a63a2417902696fcc9e0ebdc83bbe # bad: [1a92b7a241dcf06a92d84219b4124dcf420ae315] Merge branch 'linux-3.19' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next git bisect bad 1a92b7a241dcf06a92d84219b4124dcf420ae315 # bad: [fd172d0c47fddff801d998e38c3efdd236ed082f] Merge tag 'drm-intel-next-2014-11-07-fixups' of git://anongit.freedesktop.org/drm-intel into drm-next git bisect bad fd172d0c47fddff801d998e38c3efdd236ed082f # bad: [820d2d77482810702758381808bdbb64595298e2] drm/i915/audio: pass intel_encoder on to platform specific ELD functions git bisect bad 820d2d77482810702758381808bdbb64595298e2 # good: [11c9b6c628c646894e6ef53f92cfd33a814ee553] drm/i915: Tighting frontbuffer tracking around flips git bisect good 11c9b6c628c646894e6ef53f92cfd33a814ee553 # good: [0b14cbd2f58199a024acbe2994bb27533c97d756] drm/i915: remove dead code from legacy suspend handler git bisect good 0b14cbd2f58199a024acbe2994bb27533c97d756 # good: [f4a12ead50580c17c3641ac1a453e68b5a5195dd] drm/i915: remove unused restore_gtt_mappings optimization during suspend git bisect good f4a12ead50580c17c3641ac1a453e68b5a5195dd # bad: [aff437667b93c3d65576b02628885687c72e1b3b] drm/i915: Move flags describing VMA mappings into the VMA git bisect bad aff437667b93c3d65576b02628885687c72e1b3b # bad: [da2bc1b9db3351addd293e5b82757efe1f77ed1d] drm/i915: add poweroff_late handler git bisect bad da2bc1b9db3351addd293e5b82757efe1f77ed1d # good: [f2476ae65e6159b41168bc41c630e9fbb1d72dde] drm/i915: disable/re-enable PCI device around S4 freeze/thaw git bisect good f2476ae65e6159b41168bc41c630e9fbb1d72dde # good: [5e365c391aeffe8b53d6952c28a68bd5fc856390] drm/i915: sanitize suspend/resume helper function names git bisect good 5e365c391aeffe8b53d6952c28a68bd5fc856390 My rather old system has a GM45 chip, but I would expect the bug to show up on most (all?) i915 systems: nemi:/tmp# lspci -vvvnns 2 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0100c Data: 41c2 Capabilities: [d0] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel
Stable kernel 3.8.3 appears to break displayport on intel gen4
Sergio Callegari writes:
> This is just a short note to let you know that after installing 3.8.3,
> display port stopped working on my laptop. Going back to 3.8.2 brought
> it back to life.
> This has been tested with the ubuntu mainline kernels that should be
> vanilla stable kernels. Hope this is not an incorrect report due to
> something wrong on their side. Laptop is a DELL E6500 with intel gen4
> integrated graphics (Intel Corporation Mobile 4 Series Chipset
> Integrated Graphics Controller (rev 07)).
> With 3.8.3, xrandr does not report anymore the external monitor when
> it is actually attached via displayport.
I can confirm seeing this bug on:
# lspci -nnvvvs 00:02.0
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Lenovo Device [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4152
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
Looking through the changes from v3.8.2 to v3.8.3, there weren't really
that many suspects. This partial (to avoid having to change any
following patches) revert of commit 2a98104 ("drm/i915: reorder setup
sequence to have irqs for output setup") fixes the problem for me. I
have no idea why, so I leave it to Daniel and the other wise men working
on this driver to explain and cleanup :)
---
drivers/gpu/drm/i915/i915_dma.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5206f24..b15b65d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device
*dev)
if (ret)
goto cleanup_vga_switcheroo;
- ret = drm_irq_install(dev);
- if (ret)
- goto cleanup_gem_stolen;
-
- /* Important: The output setup functions called by modeset_init need
-* working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
ret = i915_gem_init(dev);
if (ret)
- goto cleanup_irq;
+ goto cleanup_gem_stolen;
+
+ intel_modeset_gem_init(dev);
INIT_WORK(_priv->console_resume_work, intel_console_resume);
- intel_modeset_gem_init(dev);
+ ret = drm_irq_install(dev);
+ if (ret)
+ goto cleanup_gem;
/* Always safe in the mode setting case. */
/* FIXME: do pre/post-mode set stuff in core KMS code */
Re: Stable kernel 3.8.3 appears to break displayport on intel gen4
Sergio Callegari sergio.calleg...@gmail.com writes: This is just a short note to let you know that after installing 3.8.3, display port stopped working on my laptop. Going back to 3.8.2 brought it back to life. This has been tested with the ubuntu mainline kernels that should be vanilla stable kernels. Hope this is not an incorrect report due to something wrong on their side. Laptop is a DELL E6500 with intel gen4 integrated graphics (Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)). With 3.8.3, xrandr does not report anymore the external monitor when it is actually attached via displayport. I can confirm seeing this bug on: # lspci -nnvvvs 00:02.0 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 45 Region 0: Memory at f000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 1800 [size=8] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 4152 Capabilities: [d0] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: i915 Looking through the changes from v3.8.2 to v3.8.3, there weren't really that many suspects. This partial (to avoid having to change any following patches) revert of commit 2a98104 (drm/i915: reorder setup sequence to have irqs for output setup) fixes the problem for me. I have no idea why, so I leave it to Daniel and the other wise men working on this driver to explain and cleanup :) --- drivers/gpu/drm/i915/i915_dma.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 5206f24..b15b65d 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device *dev) if (ret) goto cleanup_vga_switcheroo; - ret = drm_irq_install(dev); - if (ret) - goto cleanup_gem_stolen; - - /* Important: The output setup functions called by modeset_init need -* working irqs for e.g. gmbus and dp aux transfers. */ intel_modeset_init(dev); ret = i915_gem_init(dev); if (ret) - goto cleanup_irq; + goto cleanup_gem_stolen; + + intel_modeset_gem_init(dev); INIT_WORK(dev_priv-console_resume_work, intel_console_resume); - intel_modeset_gem_init(dev); + ret = drm_irq_install(dev); + if (ret) + goto cleanup_gem; /* Always safe in the mode setting case. */ /* FIXME: do pre/post-mode set stuff in core KMS code */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
pipe B assertion failure (expected off, current on)
Daniel Vetter writes: > On Thu, Oct 11, 2012 at 4:13 PM, Bj?rn Mork wrote: >> Let me know if you want ot have more details about these warnings. >> Otherwise I'll just keep ignoring them ;-) > > The drm-intel-fixes branch from > http://cgit.freedesktop.org/~danvet/drm-intel has a patch to fix some > of the already reported WARNs. Note that the issue itself is really > old, it's just that the new i915.ko modeset code is really anal with > reporting even slight inconsistencies. And some of these WARNs even > brought some real bugs to the light. Yes, that was pretty much what I assumed. > If drm-intel-fixes doesn't get rid of them, please attach a complete > dmesg withd drm.debug=0xe added to your kernel cmdline. The dmesg > should include everything up to the first pile of WARNs. Thanks. Will try the fixes. Bj?rn
pipe B assertion failure (expected off, current on)
Hello, from time to time, I see the following warning on resume: [ 7022.245347] PM: Syncing filesystems ... done. [ 7022.271923] PM: Preparing system for mem sleep [ 7022.324107] [ cut here ] [ 7022.324154] WARNING: at drivers/gpu/drm/i915/intel_display.c:1225 intel_crtc_disable+0x52/0x86 [i915]() [ 7022.324155] Hardware name: 2776LEG [ 7022.324157] pipe B assertion failure (expected off, current on) [ 7022.324197] Modules linked in: cdc_mbim(O) cdc_ncm(O) usbnet(O) mii usb_storage uas cdc_acm usbhid hid cdc_wdm netconsole configfs xt_multiport iptable_filter ip_tables rfcomm bnep cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave xt_hl binfmt_misc ip6table_filter ip6_tables x_tables fuse nfsd nfs_acl nfs lockd fscache sunrpc 8021q garp stp llc tun ext2 loop btusb bluetooth crc16 iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4 snd_page_alloc iwldvm mac80211 snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_timer snd_seq_device uvcvideo videobuf2_vmalloc thinkpad_acpi psmouse iwlwifi acpi_cpufreq videobuf2_memops lpc_ich coretemp videobuf2_core nvram i2c_i801 qcserial usb_wwan kvm_intel usbserial kvm videodev evdev serio_raw cfg80211 mfd_core rfkill snd ac battery wmi i915 soundcore video drm_kms_helper mei mperf drm processor i2c_algo_bit i2c_core button ext3 mbcache jbd sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod nbd sg sd_mod sr_mod cdrom crc_t10dif microcode thermal thermal_sys ahci libahci uhci_hcd libata scsi_mod ehci_hcd e1000e usbcore usb_common [last unloaded: mii] [ 7022.324230] Pid: 5161, comm: Xorg Tainted: GW O 3.6.0 #36 [ 7022.324231] Call Trace: [ 7022.324240] [] ? warn_slowpath_common+0x78/0x8c [ 7022.324243] [] ? warn_slowpath_fmt+0x45/0x4a [ 7022.324262] [] ? intel_crtc_disable+0x52/0x86 [i915] [ 7022.324271] [] ? drm_helper_disable_unused_functions+0xf1/0x133 [drm_kms_helper] [ 7022.324277] [] ? drm_crtc_helper_set_config+0x185/0x919 [drm_kms_helper] [ 7022.324286] [] ? drm_fb_helper_set_par+0x64/0xac [drm_kms_helper] [ 7022.324294] [] ? journal_add_journal_head+0xa7/0x123 [jbd] [ 7022.324298] [] ? fb_set_var+0x274/0x36d [ 7022.324305] [] ? journal_stop+0x203/0x215 [jbd] [ 7022.324319] [] ? __ext3_journal_stop+0x1f/0x3d [ext3] [ 7022.324327] [] ? ext3_ordered_write_end+0x14b/0x172 [ext3] [ 7022.324331] [] ? fbcon_blank+0x6d/0x234 [ 7022.324335] [] ? do_unblank_screen+0xff/0x176 [ 7022.324338] [] ? complete_change_console+0x4b/0xc0 [ 7022.324341] [] ? vt_ioctl+0x936/0xfa6 [ 7022.324352] [] ? drm_ioctl+0x2ed/0x35c [drm] [ 7022.324355] [] ? tty_ioctl+0x98a/0x9f7 [ 7022.324358] [] ? fsnotify+0x231/0x25b [ 7022.324362] [] ? do_vfs_ioctl+0x44b/0x490 [ 7022.324364] [] ? sys_ioctl+0x4b/0x6f [ 7022.324368] [] ? sys_write+0x45/0x6e [ 7022.324371] [] ? system_call_fastpath+0x16/0x1b [ 7022.324373] ---[ end trace fcdef2bbc6ef4c9d ]--- [ 7022.329771] Freezing user space processes ... (elapsed 0.09 seconds) done. [ 7022.426570] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 7022.442715] PM: Entering mem sleep [ 7022.442803] Suspending console(s) (use no_console_suspend to debug) [ 7022.445364] uhci_hcd :00:1a.0: power state changed by ACPI to D0 It does not seem to harm, so I have been ignoring it so far. But then I thought you might want to know since you put the warning in there :-) Grepping through the backups of my kernel logs shows that this started happening around end of July, about the time when I switched from 3.5.0 release candidates to running kernels based on the to-be-v3.6 linux-next. The first time I saw it I was running next-20120726 from linux-next. But I had a similar warning earlier too: "panel assertion failure, pipe B regs locked" This showed up until mid-March when I switched to version 3.2.12-1 of Debians 3.2.0-2-amd64 kernel, which added stable releases v3.2.11 and v3.2.12. Full output of one of those warnings: Mar 13 09:18:34 nemi kernel: [47373.956730] [ cut here ] Mar 13 09:18:34 nemi kernel: [47373.956776] WARNING: at /build/buildd-linux-2.6_3.2.9-1-amd64-KTPapN/linux-2.6-3.2.9/debian/build/source_amd64_none/drivers/gpu/drm/i915/intel_display.c:915 i9xx_crtc_enable+0x7b/0x1 5a [i915]() Mar 13 09:18:34 nemi kernel: [47373.956780] Hardware name: 2776LEG Mar 13 09:18:34 nemi kernel: [47373.956783] panel assertion failure, pipe B regs locked Mar 13 09:18:34 nemi kernel: [47373.956785] Modules linked in: xt_state ipt_MASQUERADE qmi_wwan(O) bridge iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 nfnetlink_log nfnetlink option usb_wwan usbserial usb_storage uas acpi_cpufreq mperf cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave xt_hl ip6t_LOG xt_multiport ip6table_filter iptable_filter ip6_tables ip_tables x_tables parport_pc ppdev lp parport rfcomm bnep
pipe B assertion failure (expected off, current on)
Hello, from time to time, I see the following warning on resume: [ 7022.245347] PM: Syncing filesystems ... done. [ 7022.271923] PM: Preparing system for mem sleep [ 7022.324107] [ cut here ] [ 7022.324154] WARNING: at drivers/gpu/drm/i915/intel_display.c:1225 intel_crtc_disable+0x52/0x86 [i915]() [ 7022.324155] Hardware name: 2776LEG [ 7022.324157] pipe B assertion failure (expected off, current on) [ 7022.324197] Modules linked in: cdc_mbim(O) cdc_ncm(O) usbnet(O) mii usb_storage uas cdc_acm usbhid hid cdc_wdm netconsole configfs xt_multiport iptable_filter ip_tables rfcomm bnep cpufreq_userspace cpufreq_stats cpufreq_conservative cpufreq_powersave xt_hl binfmt_misc ip6table_filter ip6_tables x_tables fuse nfsd nfs_acl nfs lockd fscache sunrpc 8021q garp stp llc tun ext2 loop btusb bluetooth crc16 iTCO_wdt iTCO_vendor_support snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4 snd_page_alloc iwldvm mac80211 snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_timer snd_seq_device uvcvideo videobuf2_vmalloc thinkpad_acpi psmouse iwlwifi acpi_cpufreq videobuf2_memops lpc_ich coretemp videobuf2_core nvram i2c_i801 qcserial usb_wwan kvm_intel usbserial kvm videodev evdev serio_raw cfg80211 mfd_core rfkill snd ac battery wmi i915 soundcore video drm_kms_helper mei mperf drm processor i2c_algo_bit i2c_core button ext3 mbcache jbd sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod nbd sg sd_mod sr_mod cdrom crc_t10dif microcode thermal thermal_sys ahci libahci uhci_hcd libata scsi_mod ehci_hcd e1000e usbcore usb_common [last unloaded: mii] [ 7022.324230] Pid: 5161, comm: Xorg Tainted: GW O 3.6.0 #36 [ 7022.324231] Call Trace: [ 7022.324240] [8103e0ed] ? warn_slowpath_common+0x78/0x8c [ 7022.324243] [8103e19f] ? warn_slowpath_fmt+0x45/0x4a [ 7022.324262] [a029cce1] ? intel_crtc_disable+0x52/0x86 [i915] [ 7022.324271] [a01cbf0a] ? drm_helper_disable_unused_functions+0xf1/0x133 [drm_kms_helper] [ 7022.324277] [a01ccdd0] ? drm_crtc_helper_set_config+0x185/0x919 [drm_kms_helper] [ 7022.324286] [a01cb738] ? drm_fb_helper_set_par+0x64/0xac [drm_kms_helper] [ 7022.324294] [a00fc097] ? journal_add_journal_head+0xa7/0x123 [jbd] [ 7022.324298] [811f6819] ? fb_set_var+0x274/0x36d [ 7022.324305] [a00f5609] ? journal_stop+0x203/0x215 [jbd] [ 7022.324319] [a011aaca] ? __ext3_journal_stop+0x1f/0x3d [ext3] [ 7022.324327] [a010f5fa] ? ext3_ordered_write_end+0x14b/0x172 [ext3] [ 7022.324331] [811ff487] ? fbcon_blank+0x6d/0x234 [ 7022.324335] [8125653a] ? do_unblank_screen+0xff/0x176 [ 7022.324338] [8124d4d5] ? complete_change_console+0x4b/0xc0 [ 7022.324341] [8124df87] ? vt_ioctl+0x936/0xfa6 [ 7022.324352] [a01e66ed] ? drm_ioctl+0x2ed/0x35c [drm] [ 7022.324355] [81245f13] ? tty_ioctl+0x98a/0x9f7 [ 7022.324358] [81139430] ? fsnotify+0x231/0x25b [ 7022.324362] [81118bc0] ? do_vfs_ioctl+0x44b/0x490 [ 7022.324364] [81118c50] ? sys_ioctl+0x4b/0x6f [ 7022.324368] [8110b367] ? sys_write+0x45/0x6e [ 7022.324371] [8136f779] ? system_call_fastpath+0x16/0x1b [ 7022.324373] ---[ end trace fcdef2bbc6ef4c9d ]--- [ 7022.329771] Freezing user space processes ... (elapsed 0.09 seconds) done. [ 7022.426570] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 7022.442715] PM: Entering mem sleep [ 7022.442803] Suspending console(s) (use no_console_suspend to debug) [ 7022.445364] uhci_hcd :00:1a.0: power state changed by ACPI to D0 It does not seem to harm, so I have been ignoring it so far. But then I thought you might want to know since you put the warning in there :-) Grepping through the backups of my kernel logs shows that this started happening around end of July, about the time when I switched from 3.5.0 release candidates to running kernels based on the to-be-v3.6 linux-next. The first time I saw it I was running next-20120726 from linux-next. But I had a similar warning earlier too: panel assertion failure, pipe B regs locked This showed up until mid-March when I switched to version 3.2.12-1 of Debians 3.2.0-2-amd64 kernel, which added stable releases v3.2.11 and v3.2.12. Full output of one of those warnings: Mar 13 09:18:34 nemi kernel: [47373.956730] [ cut here ] Mar 13 09:18:34 nemi kernel: [47373.956776] WARNING: at /build/buildd-linux-2.6_3.2.9-1-amd64-KTPapN/linux-2.6-3.2.9/debian/build/source_amd64_none/drivers/gpu/drm/i915/intel_display.c:915 i9xx_crtc_enable+0x7b/0x1 5a [i915]() Mar 13 09:18:34 nemi kernel: [47373.956780] Hardware name: 2776LEG Mar 13 09:18:34 nemi kernel: [47373.956783] panel assertion failure, pipe B regs locked Mar 13 09:18:34 nemi kernel: [47373.956785] Modules linked in: xt_state ipt_MASQUERADE qmi_wwan(O) bridge
Re: pipe B assertion failure (expected off, current on)
Daniel Vetter daniel.vet...@ffwll.ch writes: On Thu, Oct 11, 2012 at 4:13 PM, Bjørn Mork bj...@mork.no wrote: Let me know if you want ot have more details about these warnings. Otherwise I'll just keep ignoring them ;-) The drm-intel-fixes branch from http://cgit.freedesktop.org/~danvet/drm-intel has a patch to fix some of the already reported WARNs. Note that the issue itself is really old, it's just that the new i915.ko modeset code is really anal with reporting even slight inconsistencies. And some of these WARNs even brought some real bugs to the light. Yes, that was pretty much what I assumed. If drm-intel-fixes doesn't get rid of them, please attach a complete dmesg withd drm.debug=0xe added to your kernel cmdline. The dmesg should include everything up to the first pile of WARNs. Thanks. Will try the fixes. Bjørn ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
