Bug 14236

Created attachment 13911 [details]
Post hibernate and vt switch

Created attachment 13912 [details]
xorg.conf

This is when using the ubuntu hardy 2.6.24-rc8 kernel and without any framebuffer driver.

Does it matter if you are in X or VT just before the hibernation?

The system fails to resume when hibernated from the console, this holds for suspend to ram too.

I just fixed this last week.  Please try the latest DRM bits and reopen if you still have problems.

I tried the latest tip of the drm, it did _not_ resolve the issue for me. 

Can you reproduce this problem from a VT in text mode?  If so, please use the intel_reg_dumper tool to get a register dump from before your hibernate call and one from afterwards.  E.g.
  $ intel_reg_dumper > pre-hibernate.out
  $ echo disk > /sys/power/state
  $ intel_reg_dumper > post-resume.out
or similar, all from text mode.

(In reply to comment #8)
> Can you reproduce this problem from a VT in text mode?  If so, please use the
> intel_reg_dumper tool to get a register dump from before your hibernate call
> and one from afterwards.  E.g.
>   $ intel_reg_dumper > pre-hibernate.out
>   $ echo disk > /sys/power/state
>   $ intel_reg_dumper > post-resume.out
> or similar, all from text mode.
> 

Thanks for spending your time trying to debug this issue.
As I stated in #5, the machine never successfully resumes when initiated in text mode; regardless of doing a suspend-to-disk or suspend-to-ram.
Would some logs with ModeDebug activated be useful?

Oh I missed that comment, sorry.  Maybe the patch in #14249 will help with that, assuming it resumes w/o video enabled rather than crashing anyway...

(In reply to comment #5)
> The system fails to resume when hibernated from the console, this holds for
> suspend to ram too.
> 

Erik, would you please explain more about the failure? I mean:

1) Is the machine totally hang? can you switch to X? Can you access it from a ssh?
2) What if you didn't start X at all and then do a suspend/resume cycle from a text console?

Also could you attach your dmesg too? thanks.

(In reply to comment #11)
> (In reply to comment #5)
> > The system fails to resume when hibernated from the console, this holds for
> > suspend to ram too.
> > 
> 
> Erik, would you please explain more about the failure? I mean:
> 
> 1) Is the machine totally hang? can you switch to X? Can you access it from a
> ssh?
> 2) What if you didn't start X at all and then do a suspend/resume cycle from a
> text console?
> 
> Also could you attach your dmesg too? thanks.
> 

Ok, I've investigated this a bit more.
My current platform is Ubuntu Hardy current using a 2.6.24 kernel

If I hibernate from the console the system fails to resume during the splash screen, even if I boot with vga=normal (which I usually do).
If I explicitly remove the splash screen from the grub command line the kernel resumes properly (to a console).

If I hibernate from X and resume normally (with a splash screen) the terminal becomes corrupt. This holds if I resume with vga=normal too.

So, It seems like the splash screen is the villain in the drama.

Ah yeah, the Ubuntu splash screen uses the fb drivers, which are known to be incompatible with the 2D X driver...

Then why doesn't it work when I disable the framebuffer using the vga=normal command on the kernel command line?

I don't think vga=normal totally disables the framebuffer layer.  In other reports, people have had to totally disable CONFIG_FB in their kernel before things worked right.

(In reply to comment #15)
> I don't think vga=normal totally disables the framebuffer layer.  In other
> reports, people have had to totally disable CONFIG_FB in their kernel before
> things worked right.
> 

I'll build a test kernel and report back. Not today, though.

(In reply to comment #13)
> Ah yeah, the Ubuntu splash screen uses the fb drivers, [...]

Actually, it doesn't - at least not (always) in current versions of Ubuntu.

(In reply to comment #16)
> (In reply to comment #15)
> > I don't think vga=normal totally disables the framebuffer layer.  In other
> > reports, people have had to totally disable CONFIG_FB in their kernel before
> > things worked right.
> > 
> 
> I'll build a test kernel and report back. Not today, though.
> 

Erik, any update for the test?

(In reply to comment #18)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > I don't think vga=normal totally disables the framebuffer layer.  In other
> > > reports, people have had to totally disable CONFIG_FB in their kernel before
> > > things worked right.
> > > 
> > 
> > I'll build a test kernel and report back. Not today, though.
> > 
> 
> Erik, any update for the test?
> 

There's currently a bug in Ubuntu hardy hindering custom kernel upgrades.
I booted a 2.6.24.2 kernel with CONFIG_FB not set and it still showed the graphics corruption in the terminal upon resuming. 

Any ideas on how to take this forward?

Sorry for neglecting this Erik, I'm travelling right now so I haven't been looking at bugs much.

It does sound like there's something going on with the splash screen, given that you can correctly resume w/o it.  Can you get more details on how that works in Ubuntu (if not using fb, then what?)?

Thanks,
Jesse

> 
> There's currently a bug in Ubuntu hardy hindering custom kernel upgrades.
> I booted a 2.6.24.2 kernel with CONFIG_FB not set and it still showed the
> graphics corruption in the terminal upon resuming. 
> 

Erik, could you please attach your dmesg and xorg.log ( with modedebug option turns on ) here? thanks.

Created attachment 14793 [details]
dmesg before hibernate

Created attachment 14794 [details]
dmesg after hibernate

Created attachment 14795 [details]
xorg log with modedebug before hibernate

Created attachment 14796 [details]
xorg log with modedebug after hibernate

(In reply to comment #21)
> Sorry for neglecting this Erik, I'm travelling right now so I haven't been
> looking at bugs much.
> 
> It does sound like there's something going on with the splash screen, given
> that you can correctly resume w/o it.  Can you get more details on how that
> works in Ubuntu (if not using fb, then what?)?
> 
> Thanks,
> Jesse
> 

I remember someone said it calls bios service directly... Jesse, any hint from the last several attachment?

Erik, when you said you tested the tip of DRM, did you mean just the library?  If you built the kernel modules, did you make sure to remove the old ones from your system first (both rmmod drm, rmmod i915, then removing the files themselves) before installing the new ones?

(In reply to comment #28)
> Erik, when you said you tested the tip of DRM, did you mean just the library? 
> If you built the kernel modules, did you make sure to remove the old ones from
> your system first (both rmmod drm, rmmod i915, then removing the files
> themselves) before installing the new ones?
> 

You are correct, I must have failed last time on how to properly modprobe the new drm modules. With git current, terminals are properly restored; even after hibernation.

The machine still fails to resume after suspending via the terminal. This is a minor issue though. Close?

As long as the i915 driver is loaded, it should suspend/resume from the console correctly as well.  Which kernel are you running?  What happens exactly?  Does it just hang on resume?

Ok, I guess we can close, I'll assume the other suspend/resume problem you had is another bug (please open another bug if you can reproduce the problem and have some more details).  Thanks a lot for testing.