Bug 22126

Summary: [855GM KMS] freezes on suspend to RAM
Product: DRI Reporter: Ferenc Wágner <wferi>
Component: DRM/IntelAssignee: Jesse Barnes <jbarnes>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: medium CC: diegoe, jbarnes, shiningxc
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Generated after shutting down X, rmmod i915, modprobe i915 modeset=1
none
my 2.6.30-rc7 kernel config
none
restore the modeset for every activated crtc
none
Kernel log of a full KMS bootup (with messages of other modules elided)
none
try the debug patch which ignores the drm class for the connector device
none
acpidump output
none
never disable pipe a once enabled
none
dmidecode output
none
port old pipea force quirks to kernel
none
dmidecode output from another affected ThinkPad R50e
none
i915_drv.h.rej none

Description Ferenc Wágner 2009-06-06 13:32:35 UTC
Created attachment 26499 [details]
Generated after shutting down X, rmmod i915, modprobe i915 modeset=1

It's a pure kernel problem, present up to 2.6.30-rc8.  It's 100% reproducible on my ThinkPad R50e like the following:

 1. Boot with break=top, so initramfs gives a prompt without doing anything.
 2. modprobe intel_agp
 3. modprobe i915 modeset=1

Kernel messages this far:

Linux agpgart interface v0.103
agpgart-intel 0000:00:00.0: Intel 855GM Chipset
agpgart-intel 0000:00:00.0: detected 8060K stolen memory
agpgart-intel 0000:00:00.0: AGP aperture is 128M @ 0xe0000000
input: Video Bus as /class/input/input1
ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: power state changed by ACPI to D0
i915 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
i915 0000:00:02.0: setting latency timer to 64
i2c-adapter i2c-1: unable to read EDID block.
i915 0000:00:02.0: LVDS-1: no EDID data
i2c-adapter i2c-0: unable to read EDID block.
i915 0000:00:02.0: VGA-1: no EDID data
i2c-adapter i2c-1: unable to read EDID block.
i915 0000:00:02.0: LVDS-1: no EDID data
allocated 1024x768 fb: 0x007ff000, bo df31b840
Console: switching to colour frame buffer device 128x48
[drm] LVDS-8: set mode 1024x768 a
fb0: inteldrmfb frame buffer device
registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

 5. echo mem >/sys/power/state

Instead of powering off, the machine freezes hard with (I'm running with no_console_suspend to get some output):

Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
i915 0000:00:02.0: PCI INT A disabled

(A picture of such a freeze with more modules loaded is available from
http://apt.niif.hu/ram_2.6.30-rc7.jpg)

If i don't use the modeset=1 parameter, the system suspends and resumes all right, even from X.  Suspend to disk works equally well with or without KMS.
Comment 1 Ferenc Wágner 2009-06-06 13:38:18 UTC
Created attachment 26500 [details]
my 2.6.30-rc7 kernel config
Comment 2 ykzhao 2009-06-08 20:42:39 UTC
Hi, Ferenc
    Do you mean that the suspend/resume can work well with KMS disabled? But it can't work with KMS enabled. Right? Will you please double check it again?
    Will you please do the following test with KMS enabled?
    a. set the "CONFIG_PM_DEBUG" in kernel configuration
    b. echo cores > /sys/power/pm_test
    c. echo mem > /sys/power/state and see whether it can be resumed.(It is unnecessary to press the power button to wake up the system)
    d. please also echo processors/platform/devices/freezer to pm_test and re-do the test again.

    Thanks.
Comment 3 Ferenc Wágner 2009-06-09 07:44:22 UTC
> Do you mean that the suspend/resume can work well with KMS disabled? But it
> can't work with KMS enabled. Right? Will you please double check it again?

Yes, exactly, but for suspend to RAM only.  Suspend to disk works all right in
each case.  I rechecked it with current rc8 from git.

> Will you please do the following test with KMS enabled?
> a. set the "CONFIG_PM_DEBUG" in kernel configuration
> b. echo cores > /sys/power/pm_test
> c. echo mem > /sys/power/state and see whether it can be resumed.(It is
>    unnecessary to press the power button to wake up the system)
> d. please also echo processors/platform/devices/freezer to pm_test and
>    re-do the test again.

Sure.  It doesn't matter if I write cores, processors or platform into pm_test,
the machine just freezes hard all the same.  But if I write devices or freezer,
I get the prompt back in a couple of seconds.

I enabled PM_TRACE_RTC as well, but it didn't even manage to clobber my RTC.

To stress it again, the problem is not resume, but suspend. The machine freezes
on suspend, it does not manage to power down.

Thanks,
Feri.
Comment 4 ykzhao 2009-07-02 01:33:44 UTC
Created attachment 27324 [details] [review]
restore the modeset for every activated crtc

Will you please try the attached patch on the latest linus git tree and see whether the issue still exists?

Thanks.
Comment 5 Ferenc Wágner 2009-07-17 17:08:17 UTC
I was on holiday, and now I noticed that this patch is already present in the current Linus git tree.  modprobe i915 modeset=1 now gives some render errors as the attached annotated kernel logs show (first I loaded i915 without modeset=1, but it does not matter).

Even if I load i915 with modeset=1 for the first time, the freeze on suspend happens all the same as before.
Comment 6 Ferenc Wágner 2009-07-17 17:10:05 UTC
Created attachment 27806 [details]
Kernel log of a full KMS bootup (with messages of other modules elided)
Comment 7 ykzhao 2009-07-19 18:00:52 UTC
Created attachment 27836 [details] [review]
try the debug patch which ignores the drm class for the connector device

Will you please try the debug patch on the latest kernel and see whether this issue still exists?
Thanks.
Comment 8 Ferenc Wágner 2009-07-20 16:34:09 UTC
This debug patch on current git (actually the same as in the previous test) does not make any difference, unfortunately.
Comment 9 ykzhao 2009-07-30 17:58:40 UTC
(In reply to comment #8)
> This debug patch on current git (actually the same as in the previous test)
> does not make any difference, unfortunately.
Sorry for the late response.
Will you please do the following test and confirm whether the suspend/resume can work well under console mode? Of course the KMS should be enabled.
    1. echo mem > /sys/power/state; dmesg >dmesg_after; sync;
    2. press the power button and see whether it can be resumed.
    3. If it can't be resumed, please reboot the system and check whether the file of "dmesg_after" is created.

Thanks.
> 

Comment 10 Ferenc Wágner 2009-07-31 03:35:53 UTC
(In reply to comment #9)

> Will you please do the following test and confirm whether the suspend/resume
> can work well under console mode? Of course the KMS should be enabled.
>     1. echo mem > /sys/power/state; dmesg >dmesg_after; sync;
>     2. press the power button and see whether it can be resumed.
>     3. If it can't be resumed, please reboot the system and check whether the
> file of "dmesg_after" is created.

Hi Yakui,

I think you mixed up bug reports: this bug is about a failure to suspend from console mode. I've used the command you propose above from the very beginning, as you can read in the bug description. As such, I can't even attempt to resume, since the machine freezes before suspending itself. The issue can be reproduced from initramfs even, before X or any user space thing has a chance to mess with the system.

Regards,
Feri.
Comment 11 Ferenc Wágner 2009-08-03 10:45:02 UTC
2.6.31-rc5 still doesn't suspend on
echo mem >/sys/power/state
but freezes instead of powering down.
Comment 12 Ferenc Wágner 2009-09-02 11:24:03 UTC
Still the same under 2.6.31-rc8. :(
Comment 13 ykzhao 2009-09-15 23:38:36 UTC
Will you please try the following patch from Chris Wilson and see whether the
issue still exists?
  Patch: drm/i915: Check that the relocation points to within the target
   http://lists.freedesktop.org/archives/intel-gfx/2009-September/004243.html

thank
Comment 14 Ferenc Wágner 2009-09-16 11:44:01 UTC
Hi,

I tested Chris' patch on top of 2.6.31.  Unfortunately, no effect, the system freezes as usual.  I'm trying to find out how far it gets, whether it leaves i915_suspend() at all.  It it possible to get anything on screen after pci_disable_device(dev->pdev) and pci_set_power_state(dev->pdev, PCI_D3hot);?  Or should the screen only show whatever was on it right before invoking those functions?  Or should it turn blank if those were successful?  There's no serial port in this laptop, so I've got to find some other means to get feedback...
Comment 15 ykzhao 2009-09-16 18:17:20 UTC
(In reply to comment #14)
> Hi,
> 
> I tested Chris' patch on top of 2.6.31.  Unfortunately, no effect, the system
> freezes as usual.  I'm trying to find out how far it gets, whether it leaves
> i915_suspend() at all.  It it possible to get anything on screen after
> pci_disable_device(dev->pdev) and pci_set_power_state(dev->pdev, PCI_D3hot);? 
> Or should the screen only show whatever was on it right before invoking those
> functions?  Or should it turn blank if those were successful?  There's no
> serial port in this laptop, so I've got to find some other means to get
> feedback...
Sorry that I mix up this bug with other bugs. The issue on this box is that it can't be resumed from S3 when in KMS mode. Right?
Will you please do the following test under console mode?
    1. echo mem > /sys/power/state; dmesg >dmesg_after; sync;
    2. press the power button and see whether it can be resumed.
    3. If it can't be resumed, please reboot the system and check whether the
file of "dmesg_after" is created.

It is noted that the above test should be done on KMS/UMS mode.
    
> 


Comment 16 Ferenc Wágner 2009-09-17 03:51:30 UTC
(In reply to comment #15)
> Sorry that I mix up this bug with other bugs. The issue on this box is that it
> can't be resumed from S3 when in KMS mode. Right?

Actually, no, see my comment #10. This system freezes *during* S3 suspend when in KMS mode. That is, it does not enter S3, instead it freezes with

Shutting down device
i915 0000:00:02.0: PCI INT A disabled

on the screen, with i915_suspend() in drivers/gpu/drm/i915/i915_drv.c modified as

[...]
if (state.event == PM_EVENT_SUSPEND) {
  DRM_INFO("Shutting down device\n");
  pci_disable_device(dev->pdev);
  pci_set_power_state(dev->pdev, PCI_D3hot);
}
DRM_INFO("Leaving i915_suspend\n");
[...]

All this happens with 100% reproducibility right after booting, from the initramfs, with nothing else but the intel_agp and the i915 module loaded.  If I don't specify modeset=1 for the latter, suspend and resume works OK.

Feri.
Comment 17 Ferenc Wágner 2009-10-07 18:25:30 UTC
(In reply to comment #16)

After hooking up some LEDs to the parallel port, I was able to determine that under 2.6.31 the freeze happens in drivers/acpi/acpica/hwsleep.c, function acpi_enter_sleep_state_prep, line 176, that is

/* Run the _PTS method */
status = acpi_evaluate_object(NULL, METHOD_NAME__PTS, &arg_list, NULL);

does not return if I load i915 with modeset=1.  I compiled with CONFIG_ACPI_DEBUG=y, but the framebuffer console is already off by the time we get here, so I wasn't able to extract any info from that.  Not that I understand ACPI the least.

I wonder if NETCONSOLE or LP_CONSOLE could help here (this ThinkPad R50e has no serial port) or would those be suspended regardless of no_console_suspend before the suspend procedure got to the interesting part...

Thanks,
Feri.
Comment 18 ykzhao 2009-10-08 18:38:16 UTC
> I wonder if NETCONSOLE or LP_CONSOLE could help here (this ThinkPad R50e has no
> serial port) or would those be suspended regardless of no_console_suspend
> before the suspend procedure got to the interesting part...
Thanks for your finding.
Will you please attach the output of acpidump on your box?

The latest acpidump tool(pmtools-20071116) can be found in:
http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
> 
> Thanks,
> Feri.
> 

Comment 19 Ferenc Wágner 2009-10-09 14:02:58 UTC
Created attachment 30231 [details]
acpidump output

Compressed acpidump output attached, as requested by comment #18.
Comment 20 Ferenc Wágner 2009-11-10 17:42:26 UTC
This problem persists under 2.6.32-rc6 as well.
Comment 21 Xavier 2010-02-12 14:39:51 UTC
ping.

I am another unfortunate owner of a r50e.

The issue still exists on 2.6.32, and also drm-intel-next of today (based on 2.6.33-rc5).

@Ferenc:
Did you lose hope ? :)
And did you get to try netconsole ?
Comment 22 Ferenc Wágner 2010-02-13 14:08:32 UTC
> @Ferenc: Did you lose hope ? :)

Yes, pretty much.  Rafael Wysocki called this a "BIOS issue" in http://article.gmane.org/gmane.linux.acpi.devel/42754, but it looks like nobody is interested in fixing this. Nothing forces me to use KMS right now, so I can live with this, but I'm afraid this will change. :(

> And did you get to try netconsole?

I had no reason to do so. As things stand, I really don't know what I could do to get this issue fixed. Should I lobby IBM for a BIOS upgrade? Should I keep nagging the ACPI or the Intel folks?  Unfortunately, I know very little about ACPI, and haven't got the time to dive in either.

Too bad that such an easily reproducable bug gets no attention. My hibernation related phantom bug is much more popular, although totally unreproducible... I just don't get it.
Comment 23 Xavier 2010-02-13 15:06:36 UTC
(In reply to comment #22)
> > @Ferenc: Did you lose hope ? :)
> 
> Yes, pretty much.  Rafael Wysocki called this a "BIOS issue" in
> http://article.gmane.org/gmane.linux.acpi.devel/42754, but it looks like nobody
> is interested in fixing this. Nothing forces me to use KMS right now, so I can
> live with this, but I'm afraid this will change. :(
> 

Actually the last ddx release dropped UMS. And my distrib already uses that :
http://www.archlinux.org/news/484/

Upstream forces/wants us to use KMS by dropping UMS support.

> 
> Too bad that such an easily reproducable bug gets no attention. My hibernation
> related phantom bug is much more popular, although totally unreproducible... I
> just don't get it.
> 

So all the following discussion is about hibernation, not suspend to ram ?
I read a suggestion to follow up on suspend-devel. Did this happen ?
Comment 24 Ferenc Wágner 2010-02-14 05:03:22 UTC
(In reply to comment #23)
> (In reply to comment #22)
>>> @Ferenc: Did you lose hope ? :)
>> 
>> Yes, pretty much.  Rafael Wysocki called this a "BIOS issue" in
>> http://article.gmane.org/gmane.linux.acpi.devel/42754, but it looks like nobody
>> is interested in fixing this. Nothing forces me to use KMS right now, so I can
>> live with this, but I'm afraid this will change. :(
> 
> Actually the last ddx release dropped UMS. And my distrib already uses that :
> http://www.archlinux.org/news/484/
> 
> Upstream forces/wants us to use KMS by dropping UMS support.

Yes, that's what I expected. We're trapped.

>> Too bad that such an easily reproducable bug gets no attention. My hibernation
>> related phantom bug is much more popular, although totally unreproducible... I
>> just don't get it.
> 
> So all the following discussion is about hibernation, not suspend to ram ?

Yes, that thread is about kernel bug #14504, I just mentioned this problem there.

> I read a suggestion to follow up on suspend-devel. Did this happen ?

I'm not sure which one you mean, the thread was quite widely crossposted...  Suspend-devel was also involved on several occasions.
Comment 25 Xavier 2010-02-14 08:03:28 UTC
(In reply to comment #24)
> > I read a suggestion to follow up on suspend-devel. Did this happen ?
> 
> I'm not sure which one you mean, the thread was quite widely crossposted... 
> Suspend-devel was also involved on several occasions.
> 

Sorry, I just misread the mail, it was only about white-listing the r50e for s2ram in UMS mode.

So the only clue we have is Rafael Wysocki calling it a "BIOS issue", that's not much. How can we get more information and details about what that BIOS issue is ? Should we bug Rafael again or where are the experts in this domain ?
And why is this BIOS issue only triggered in KMS mode ? We don't know for a fact that getting KMS suspend to work with that BIOS is impossible, do we ?
Comment 26 Ferenc Wágner 2010-02-14 13:48:56 UTC
(In reply to comment #25)
> So the only clue we have is Rafael Wysocki calling it a "BIOS issue", that's
> not much. How can we get more information and details about what that BIOS
> issue is? Should we bug Rafael again or where are the experts in this domain?

Bugging Rafael is certainly an option, but I didn't want to hijack that thread too much and I also felt like I bugged him too much already. :)
I guess the Linux ACPI list would be the most appropriate place to ask about this, but they were crossposted if I remember correctly, and nobody spoke up. Maybe a direct question would result in some answer, it's definitely worth a try. I just didn't find the time for this yet.

> And why is this BIOS issue only triggered in KMS mode? We don't know for a
> fact that getting KMS suspend to work with that BIOS is impossible, do we?

Certainly not. KMS is not a machine state, it's rather an alternative path to get there (besides UMS), as I understand it. However, if you suspend from UMS, the screen is reset to the standard VGA text mode, while if you suspend from KMS it does not. This isn't the problem in itself, though: I'm almost sure that suspend with a framebuffer console worked for me. And that seemed at least visually equivalent to the KMS console. So your question about why the issue is triggered under KMS is very important, and the answer might well be the solution to this bug. But I'm mostly speculating here.
Comment 27 Diego Escalante Urrelo 2010-03-18 02:19:44 UTC
Hi,

I followed the bug report guide and got it to suspend/resume only on 'devices' and 'freezer' @pm_test. core, platform, processors, all failed and stuck.

Obviously I share the annoyance of completely broken suspend, it hangs in "suspending consoles..." when suspending.

Suspend/resume works ok without KMS in X (well, until they driver still had UMS support).
It works ok also without X when KMS is not enabled.

I got the dmesg after|before logs for all the cases of pm_test. Which ones should I include? Please let me help since I really miss suspend in my laptop :)

My system info:
-- chipset: 855GM
-- system architecture: 32-bit
-- xf86-video-intel: 3d4b3f257fbbb69c6f236d9803abe54a90d7d434 (master up to today march 18)
-- xserver: X.Org X Server 1.7.5.902 (1.7.6 RC 2)
-- mesa: 7.7.1-DEVEL (debian 7.7-4)
-- libdrm: 2.4.18 (debian 2.4.18-2)
-- kernel: 2.6.33-2-686
-- Linux distribution: Debian unstable+experimental
-- Machine or mobo model: Thinkpad R50e
-- Display connector: LVDS
Comment 28 Xavier 2010-03-21 16:04:00 UTC
By the way, Rafael asked me to open a bug on bugzilla.kernel.org so I did :
https://bugzilla.kernel.org/show_bug.cgi?id=15322

As the first line of the original report said, it's a pure kernel problem after all :)

I've just posted some fresh news to the kernel bug 2 minutes ago. This bug can be worked around with a custom DSDT.
Comment 29 Jesse Barnes 2010-07-15 10:53:06 UTC
Assuming this old bug is fixed now.
Comment 30 Jesse Barnes 2010-07-15 11:41:40 UTC
In case it's not fixed, I'll let Chris look at it. :)
Comment 31 Diego Escalante Urrelo 2010-07-15 11:49:59 UTC
(In reply to comment #30)
> In case it's not fixed, I'll let Chris look at it. :)

Hi Jesse,

unfortunately it is still broken :(. Last I checked the DSDT fix for the kernel helped but not really much, I got it to suspend a few times and then it broke again:
  https://bugzilla.kernel.org/show_bug.cgi?id=15322

I tested again with 2.6.34 (no dsdt fix) and intel master but no luck. I can't test *right now* but I bet it's still broken.

I'm up for helping to debug, although I know that doesn't help a lot.
Comment 32 Xavier 2010-07-15 14:07:18 UTC
I just upgraded to 35-rc5, the problem is still there, systematic hard freeze on every suspend to ram.

But the dsdt workaround still works perfectly for me, I just suspended 5 times in a row, it suspends and resumes very fast and reliably in my testing, better than other laptops.
Comment 33 Jesse Barnes 2010-07-16 09:37:47 UTC
Created attachment 37130 [details] [review]
never disable pipe a once enabled

This patch will leave pipe a enabled, which may prevent the hang.  The BIOS is probably touching something on the GPU that needs to be on; hopefully this will be sufficient.
Comment 34 Xavier 2010-07-16 13:28:50 UTC
Thanks a lot to Jesse Barnes, this pipea trick fixes the issue for me !
Ferenc or Diego, can you confirm ?
Comment 35 Xavier 2010-07-16 13:29:58 UTC
Created attachment 37132 [details]
dmidecode output

as required by jbarnes
Comment 36 Xavier 2010-07-16 13:38:16 UTC
jbarnes said : "dmidecode provides a bunch of machine specific info we can use to key the quirk from."

Diego and Ferenc : could you also attach your dmidecode output, so that we are sure the quirk will be applied on your systems ?
Comment 37 Jesse Barnes 2010-07-16 14:11:48 UTC
Created attachment 37136 [details] [review]
port old pipea force quirks to kernel

Does this patch also make things work for you?
Comment 38 Diego Escalante Urrelo 2010-07-17 16:08:11 UTC
(In reply to comment #37)
> Created an attachment (id=37136) [details]
> port old pipea force quirks to kernel
> 
> Does this patch also make things work for you?

Jesse. I'm running a patched kernel with this last patch and it seems to be working ok. I'll try a few more times before giving a full OK but if you say it's an old quirk, likely it's what was missing.

Xavier?
Comment 39 Xavier 2010-07-18 03:59:41 UTC
Ah right, I already tested that last patch yesterday and confirmed to Jesse it was still working, but I said that on irc, not here :)
Comment 40 Jesse Barnes 2010-07-19 13:40:19 UTC
Ok I'll clean up that patch and submit it upstream.  Thanks for testing.
Comment 41 Ferenc Wágner 2010-07-20 02:49:47 UTC
(In reply to comment #40)
> Ok I'll clean up that patch and submit it upstream.  Thanks for testing.

I tested the "port old pipea force quirks to kernel" on 2.6.35-rc5, and can also confirm that it fixes suspend to RAM. Thank you very much!  I'm attaching my dmidecode output as requested.  It would be fantastic if this fix could also be added to the long term supported stable version (2.6.32) of the Linux kernel if at all possible, so distros could benefit from it.
Comment 42 Ferenc Wágner 2010-07-20 02:51:38 UTC
Created attachment 37235 [details]
dmidecode output from another affected ThinkPad R50e
Comment 43 Ferenc Wágner 2010-07-20 02:55:36 UTC
Review of attachment 37136 [details] [review]:

You probably know, but your intel_quirks[] array is redundant: the last stanza shadows several previous entries.
Comment 44 M. Burger 2010-07-24 04:30:02 UTC
(In reply to comment #37)
> Created an attachment (id=37136) [details]
> port old pipea force quirks to kernel
> 
> Does this patch also make things work for you?

Well, at first thanks for your work guys! :)
I found this here with a comment in bug https://bugzilla.kernel.org/show_bug.cgi?id=14640.
I'm sorry, I feel really uncomfortable when asking this, but, how to apply this patch? Beeing in my Lucid-git-tree on my hd I tried to
$ /media/datenplatte/ubuntu-lucid$ patch -Np1 -i i915_suspend_fix.patch ,
and it works partly, but the first part of the patch fails, here's the terminal-output:
patching file drivers/gpu/drm/i915/i915_drv.h
Hunk #1 FAILED at 222.
Hunk #2 succeeded at 305 with fuzz 2 (offset -31 lines).
1 out of 2 hunks FAILED -- saving rejects to file drivers/gpu/drm/i915/i915_drv.h.rej
patching file drivers/gpu/drm/i915/intel_display.c
Hunk #1 succeeded at 2015 (offset -240 lines).
Hunk #2 succeeded at 2035 (offset -240 lines).
Hunk #3 succeeded at 4738 (offset -739 lines).
Hunk #4 succeeded at 4832 (offset -739 lines).

I'm sorry for my question, but please, could anybody explain what I'm doing wrong or what to do with that first section of the patch, so I could manually add it (it's just a few lines I think, but I don't really know where to put them in the original file).

Thanks in advantance,
really looking forward that this will fix the problem for me, too :)
Comment 45 M. Burger 2010-07-24 04:32:56 UTC
Created attachment 37348 [details]
i915_drv.h.rej

sorry, forgot to add the *.rej - file, maybe this helps :)
Comment 46 M. Burger 2010-07-25 14:03:04 UTC
(In reply to comment #45)
> Created an attachment (id=37348) [details]
> i915_drv.h.rej
> 
> sorry, forgot to add the *.rej - file, maybe this helps :)

Well, I maybe should add, obviously this patch is intend to be used with 2.6.35-rc6, but I'd like to know how to port it back to 2.6.33, because -I don't know exactly why- but with kernels newer than 2.6.33 my thinkpad-audio stopped working =/

And, 5 min. ago, I tested a kernel with your patch J. Barnes, and I'm happy I can confirm it's working, tested with an IBM thinkpad R51-2888 with an Intel 855GM-GPU.

Thanks a lot for your work and I'm looking forward this patch will made it's way to the kernel :)
Comment 47 Jesse Barnes 2010-07-26 12:17:41 UTC
author	Jesse Barnes <jbarnes@virtuousgeek.org>	
	Mon, 19 Jul 2010 20:53:12 +0000 (13:53 -0700)
committer	Eric Anholt <eric@anholt.net>	
	Mon, 26 Jul 2010 19:00:43 +0000 (12:00 -0700)
commit	b690e96cf9e6a6cde6f0393de47bdd6317ddb5de
tree	8438bf5540d4f71d0fcc8b6acb8bf472780e4579	tree | snapshot
parent	0cc4d4300c28d5c3fc73e5ec91bfd4b0c2c744af	commit | diff
drm/i915: add pipe A force quirks to i915 driver

Ported over from the old UMS list.  Unfortunately they're still
necessary especially on older laptop platforms.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=22126.

Tested-by: Xavier <shiningxc@gmail.com>
Tested-by: Diego Escalante Urrelo <diegoe@gnome.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Comment 48 M. Burger 2010-09-13 02:38:16 UTC
(In reply to comment #47)
> author    Jesse Barnes <jbarnes@virtuousgeek.org>    
>     Mon, 19 Jul 2010 20:53:12 +0000 (13:53 -0700)
> committer    Eric Anholt <eric@anholt.net>    
>     Mon, 26 Jul 2010 19:00:43 +0000 (12:00 -0700)
> commit    b690e96cf9e6a6cde6f0393de47bdd6317ddb5de
> tree    8438bf5540d4f71d0fcc8b6acb8bf472780e4579    tree | snapshot
> parent    0cc4d4300c28d5c3fc73e5ec91bfd4b0c2c744af    commit | diff
> drm/i915: add pipe A force quirks to i915 driver
> 
> Ported over from the old UMS list.  Unfortunately they're still
> necessary especially on older laptop platforms.
> 
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=22126.
> 
> Tested-by: Xavier <shiningxc@gmail.com>
> Tested-by: Diego Escalante Urrelo <diegoe@gnome.org>
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> Signed-off-by: Eric Anholt <eric@anholt.net>

Well, after a short time with a kernel with this patch included in use, I'm facing a new problem: My Thinkpad is crashing suddendly while playing espacially flash videos (e.g. youtube, zshare and similar). I can't really say that the patch causes this issue, because I switched for the patch directly from the ubuntu-stable-kernel 2.6.32 up to 2.6.35.
A kind of annoying, the only thing left is a hard-reboot with ALT+MAGICSYSRECOVERY,  I'd like to know if anyone here is facing the same issue?
But in fact, the patch works, standby works again flawlessly,thanks James :)
Comment 49 Ronny Standtke 2012-01-23 07:05:49 UTC
Just a short info:

This patch breaks external monitor support on certain notebooks (including mine, unfortunately). For more details please have a look at the following bug report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796030

Should I reopen this bug?

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.