Bug 13512

Does 2.6.30-rc1 also fail?

Yes, it is the same as 2.6.30. I will try 2.6.29.4.
Dan

I'm afraid this is not going to help a lot.  Please check the kernel where the commit:

commit 2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Mon Mar 16 22:34:06 2009 +0100

    PM: Rework handling of interrupts during suspend-resume

is the head.

Sorry I don't know how do it.

Please read http://linux.yyz.us/git-howto.html#download_first_time to learn how to clone the Linus' kernel repository.  When you have the repository cloned, go to the directory containing it, do

$ git checkout -b test 2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7

build the kernel and install it as usual.

Thanks for advice. I start working on it.

I build kernel as you recommend me. And when I try suspend comp freeze.
Situation is the same as in 2.6.30.

Dan

Thanks.

Now, can you please do the same as in comment #5, but for commit 0a0c5168df270a50e3518e4f12bddb31f8f5f38f (one commit before the one you have tested)?

can you tell us more about what "D43" is?
eg. lspci and dmidecode
in case there is some common issue here with similar machines?

bugzilla-daemon@bugzilla.kernel.org napsal(a):
> http://bugzilla.kernel.org/show_bug.cgi?id=13512
> 
> 
> Len Brown <len.brown@intel.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |acpi-bugzilla@lists.sourcef
>                    |                            |orge.net,
>                    |                            |len.brown@intel.com
> 
> 
> 
> 
> --- Comment #9 from Len Brown <len.brown@intel.com>  2009-06-16 01:26:58 ---
> can you tell us more about what "D43" is?
> eg. lspci and dmidecode
> in case there is some common issue here with similar machines?
> 
Yes this is Dell notebook D43 I late send lspci and dmidecode.

There is dmidecode output and lspci -vvv output.

Created attachment 21944 [details]
lspci -vvv output

Created attachment 21945 [details]
dmidecode output

Seeing what looks like the same as this bug on Dell Latitude D810 running 2.6.29.4-167.fc11.i586.  Suspend works.  Upon resume (opening cover), screen is blank.  Keyboard is mostly non-responsive. FN-F2 (turn on/off wifi&blutooth radio does cause the bluetooth indicator to toggle).  This used to work on a much older kernel (2.2.26?? on FC9).

lspci and dmidecode will follow.

Created attachment 21974 [details]
lspci -vvv on D810

Created attachment 21975 [details]
dmidecode on D810

it would be great if you can run git bisect to find out which commit introduces this bug.

Rafael I do this:

git checkout -b test_pokus 0a0c5168df270a50e3518e4f12bddb31f8f5f38f
But use previous colned tree. I only execute this command is it right ?
If yes, comp still freezes as before.

Now I clone fresh git tree and
git checkout -b test 0a0c5168df270a50e3518e4f12bddb31f8f5f38f compile kernel and situation is the same kernel freeze.

(In reply to comment #14)
> Seeing what looks like the same as this bug on Dell Latitude D810 running
> 2.6.29.4-167.fc11.i586.  Suspend works.  Upon resume (opening cover), screen
> is
> blank.  Keyboard is mostly non-responsive. FN-F2 (turn on/off wifi&blutooth
> radio does cause the bluetooth indicator to toggle).  This used to work on a
> much older kernel (2.2.26?? on FC9).
> 
> lspci and dmidecode will follow.

I had a brain fart.  The older kernel version was kernel-2.6.27.24-78.2.53.fc9.i686

2.6.31-rc1 still buggy.

I have a similar problem with an HP dv5z; up to 2.6.29.4 it suspended OK, but on 2.6.30 and 2.6.31-rc1 it hangs during suspend - all I see is a blank screen with a blinking text cursor in the top left corner. One of the times this happened, pressing the power button caused it to finish suspending, and then the power button blinked like it usually does. But upon resume, while the power light came on steady, nothing else happened. I haven't been able to duplicate that situation; every other time it has just hung with the blinking cursor.

I also still have i8042.reset in my boot command line. On 2.6.29 and previous kernels this was needed otherwise my keyboard wouldn't come back. Should this still be required on newer kernels?

Created attachment 22133 [details]
lspci -vvv HP dv5z

Created attachment 22134 [details]
dmidecode HP dv5z

On Monday 29 June 2009, Daniel Smolik wrote:
> Rafael J. affected napsal(a):
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=13512
> > Subject             : D43 on 2.6.30 doesn't suspend anymore
> > Submitter   : Daniel Smolik <marvin@mydatex.cz>
> > Date                : 2009-06-11 20:12 (18 days old)
> >
> >
> >   
> Yes problem still exists. I now bitsecting and I am near to find 
> affected patch.

e70049b9e74267dd47e1ffa62302073487afcb48 is first bad commit

Bisecting show me this commit. But I mean that I do something wrong. Bug is in i915 driver. Because when I unload i915.ko notebook suspend OK. But this commit doesn't affect i915 I mean,.

Suspend is working for me again on 2.6.31-rc2.

Hi, Daniel 
    Will you please also try the latest kernel(2.6.31-rc2) and see whether it also works for you?
    thanks.

Still the same. Unloading i915 solve problem. May be I don't use framebuffer cosole only text. 

Dan

On Tuesday 07 July 2009, Daniel Smolik wrote:
> Rafael J. Wysocki napsal(a):
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=13512
> > Subject             : D43 on 2.6.30 doesn't suspend anymore
> > Submitter   : Daniel Smolik <marvin@mydatex.cz>
> > Date                : 2009-06-11 20:12 (26 days old)
> >
> >
> >   
> 
> Bug still exists. Latest which I test is 2.6.31-rc2.

HI, Daniel
    Will you please do the following test to see whether the box can't be resumed or there is no display after resume?
    a. kill the process using /proc/acpi/event
    b. echo mem > /sys/power/state; dmesg >dmesg_after; sync; 
    c. press the power button and see whether the box can be resumed.
    d. if the box can't be resumed, please reboot the box and see whether there exists the file of dmesg_after.
    
    If there exists the file of dmesg_after, please try the latest linus git tree and see whether it can be resumed correctly.

BTW: It will be better that the test is done in KMS mode. The CONFIG_DRM_I915_KMS should be enabled in kernel configuration. In such case the framebuffer console should also be enabled.

    Thanks.

Yes I can, but I mean that notebook doesn't sleep. I test this with Xserver stopped and sleep/resume works. I will try it with KMS + framebuffer enabled.
I try what you recommend with 2.6.31-rc2 OK ?

Dan

If you try the 2.6.31-rc2 kernel, it will be better that you can apply the patch in https://bugs.freedesktop.org/show_bug.cgi?id=21576#C16.

thanks.

Created attachment 22332 [details]
dmesg before sleep

Created attachment 22333 [details]
dmesg after sleep

I do all as you want. But without framebuffer console situation is the same.
Comp freeze and in dmesg is nothing.But if I enable framebuffer console suspend start working. I attach new dmesg_before and dmesg_after. But another problem is that when I enable  fb console I don't see any output before Xserver starts.

Hi, Daniel
    It seems that the incorrect driver is used. From the dmesg log it seems that the intel fb driver is used. But in fact the drm i915 driver had better be used. At the same time the fb console had better be enabled if the system is booted with KMS enabled. (BTW: please boot the system with KMS enabled.)
    Thanks.

Please enable the following in kernel configuration.
   >CONFIG_FRAMEBUFFER_CONSOLE
   >CONFIG_DRM_I915_KMS

At the same time the CONFIG_FB_INTEL should be cleared in kernel configuration.
Thanks.

I do all as you recommend me. And situation is now little different.
If I don't start Xserver suspend/resume work. But If I start it and stop suspend freeze after suspending console. I mean that my version of Xserver can't handle KMS properly. I will continue with investigation.

If in log I see this:
[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
[drm:i915_initialize] *ERROR* Client tried to initialize ringbuffer in GEM mode

and try suspend system freeze.

New information. I have found oops in sleep preparation. Tomorrow I will connect serial console and post a OOPS.

Created attachment 22364 [details]
OOPS during suspend

Created attachment 22365 [details]
OOPS decoded by ksymoops

Created attachment 22369 [details]
Don't register the connector device under the drm_class

Will you please try the debug patch on the latest kernel and see whether the oops still exists?
In this debug patch it won't register the connector device under the drm_class. In such case it won't call the drm_sysfs_suspend/resume for the connector device.

Thanks.

Yes, do you want latest git or 31-rc3 ?
Dan

The 31-rc3 is ok.
Thanks.

I compile 2.6.31-rc3 with the same config as rc2 and situation is worse then before. System still oops and I didn't see your debug message. But when I use serial console system freeze and didn't OOPS :-(.

Hi, Daniel
    Sorry that I don't pay attention to the info in comment #39 that your xserver can't handle the KMS correctly.
    From the info in comment #39 it seems that the suspend/resume can work well if the X is not started. Right? Will you please double check it again? Please also confirm whether the OOPS still exists on the 2.6.31-rc3 when KMS is enabled.
    If it still exists, please try the patch in comment #44 and see whether the OOPS still exists?
    Thanks.

(In reply to comment #48)
> Hi, Daniel
>     Sorry that I don't pay attention to the info in comment #39 that your
> xserver can't handle the KMS correctly.
>     From the info in comment #39 it seems that the suspend/resume can work
>     well
> if the X is not started. Right? Will you please double check it again? Please
> also confirm whether the OOPS still exists on the 2.6.31-rc3 when KMS is
> enabled.
>     If it still exists, please try the patch in comment #44 and see whether
>     the
> OOPS still exists?
>     Thanks.

On 2.6.31-rc3 suspend stop working. OOPS still exists in 2.6.31-rc3 I use patch that you recommend me. If I connect serial console system freeze and didn't OOPS.
I will check if suspend work without Xserver and let you know.

Dan

Hi, Daniel
    Will you please attach the output of dmesg when the OOPS happens?
    It will be great if you can attach the output of dmesg after doing suspend/resume without Xserver.
    
Thanks.

Created attachment 22485 [details]
dmesg with 2.6.31rc3 before sleep

Created attachment 22486 [details]
dmesg with 2.6.31rc3 after resume

Created attachment 22487 [details]
dmesg with 2.6.31rc3 before second sleep, but after X server start/stop

I add some dmesg output before/after suspend resume without X. After running and stopping Xserver in dmesg is displayed error message about drm.
If I try suspend after this system OOPS. But I can't catch this OOPS because if I attach serial console system freeze not OOPS. I can do only screenshot. Is it suitable for you ?

Dan

Hi, Daniel
    From the log in comment #52 it seems that the box can be suspend/resumed correctly on the 2.6.31-rc3. And there is no OOPS.
    Will you please double check what is the issue on the D43 box?
    Thanks.

Yes but Xserver is not running. Please look to comment #53 and #54. After I run Xserver system doesn't sleep anymore but OOPS. I test it many times and after running Xserver system always OOPS. Is enough start and stop Xsserver and after this system always OOPS.

On Monday 03 August 2009, Daniel Smolik wrote:
> Rafael J. Wysocki napsal(a):
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=13512
> > Subject             : D43 on 2.6.30 doesn't suspend anymore
> > Submitter   : Daniel Smolik <marvin@mydatex.cz>
> > Date                : 2009-06-11 20:12 (53 days old)
> > 
> > 
> Yes still exists.

As of the most recent FC rawhide distro (sorry, kernel version not immediately available) suspend/resume with X works for me on a Dell Latitude D810.

It is possible, but if your Xserver use some old interface kernel OOPS or freeze.

On Monday 10 August 2009, Daniel Smolik wrote:
> Rafael J. Wysocki napsal(a):
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> > 
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=13512
> > Subject             : D43 on 2.6.30 doesn't suspend anymore
> > Submitter   : Daniel Smolik <marvin@mydatex.cz>
> > Date                : 2009-06-11 20:12 (60 days old)
> > 
> > 
> I will try 2.6.31-rc5 a let you know. But problem still exists.

2.6.31-rc6 oops still the same.

2.6.31-rc8 still OOPS in i915_gem_idle

Now in squeeze was upgraded Xserver and with 2.6.31 suspend/resume start working again. But with old Xserver still OOPS.

So I don't think this is a LInux kernel problem.
please file a new bug at bugs.freedesktop.org.

Sorry, If userspace call kernel with wrong way and kernel OOPS it is userspace problem not kernel problem ? Thanks for reply.

Thanks for so quick response.
    Now it seems that it is not a linux kernel problem.
   If the OOPS still exists, please open the bug in bugs.freedesktop.org.

Thanks.