swsusp in test8 fails with intel-agp and i830

swsusp in test8 fails with intel-agp and i830

[Aviram Jenik]

Hi Pavel,

On Thursday 16 October 2003 22:21, Pavel Machek wrote:
> Hi!
>
> > Suspend to disk (I'm using echo -n "disk" > /sys/power/state) works about
> > one in ten attempts. When it works, it is _usually_ capable of
> > hibernating a few consecutive times, but then it stops working (reboots
> > on resume).
>
> can you try echo 4 > /proc/acpi/sleep?
>

In 2.6.0-test8 hibernation via "echo 4 > /proc/acpi/sleep" works incredibly 
well from the console. Great work! I tested it many times and it seems quite 
stable.

However, it fails when X is running (even if doing chvt before suspension). 
I followed your advice and removed the video card modules (intel-agp and 
i830). Indeed, when booting without those modules, suspend to disk 
miraculously works from X; I was even able to hibernate from within a KDE 
session and restore to that point exactly.

I am not sure which of the two modules causes the problem, I can only load 
them both. Unfortunately, without those modules the vaio laptop can only give 
640x480, so this is not much of a workaround...

To summarize:
If the intel-agp and i830 modules are not loaded during startup, suspend via 
echo 4 > /proc/acpi/sleep and restore work beautifully. If those modules 
_are_ loaded, and X is running, resume reboots.

- Aviram

Re: swsusp in test8 fails with intel-agp and i830

[Pavel Machek]

Hi!

> I am not sure which of the two modules causes the problem, I can only load 
> them both. Unfortunately, without those modules the vaio laptop can only give 
> 640x480, so this is not much of a workaround...

With vesafb, you should be able to get any resultion you want at
60Hz. Which is okay, because you have LCD.

> To summarize:
> If the intel-agp and i830 modules are not loaded during startup, suspend via 
> echo 4 > /proc/acpi/sleep and restore work beautifully. If those modules 
> _are_ loaded, and X is running, resume reboots.

Okay, 

static int agp_intel_resume(struct pci_dev *pdev)
{
        struct agp_bridge_data *bridge = pci_get_drvdata(pdev);

        if (bridge->driver == &intel_generic_driver)
                intel_configure();
        else if (bridge->driver == &intel_845_driver)
                intel_845_configure();

        return 0;
}

intel_agp tries to implement resume, try to put printk("something");
mdelay(1000); in it and debug it this way.

drivers/char/drm/i830_drv driver is apparently using DMA _and_  has no
suspend/resume support. That looks dangerous to me, perhaps you'll
need to implement those, too.
									Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

re: swsusp in test8 fails with intel-agp and i830

[John Mock]

   > I am not sure which of the two modules causes the problem, I can only load
   > them both. Unfortunately, without those modules the vaio laptop can only give
   > 640x480, so this is not much of a workaround...

   With vesafb, you should be able to get any resultion you want at
   60Hz. Which is okay, because you have LCD.

Not necessarily, at least not on a VAIO R505EL  This is due to the well-
known (to some X hackers at least) 'stolen memory' problem.  Yes, you can 
have 1024x768x8 with 'vesafb' (0x305), but if i use 'vga=ask', then i 
can't get it to accept anything of the form 0x31x (e.g., nothing more 
than 256 colors).  And netscape/mozilla grabs everything in sight, so if 
you want a color that 'netscape' doesn't use after 'netscape' has been
started, you're out of luck.

   drivers/char/drm/i830_drv driver is apparently using DMA _and_ has no
   suspend/resume support. That looks dangerous to me, perhaps you'll
   need to implement those, too.

Yeah, i looked at that driver and couldn't figure out how it was supposed
to hand suspend/resume, but didn't have anything to compare it with.  So
thank you for remark, as i was wondering if that were the case.  Basically
what i think it comes to is that whatever initialization that X does to
a display when it starts up needs to be done again after software suspend.
Given that i doubt X knows anything about software suspend, the underlying
kernel code is going to have to remember whatever X wanted and repeat that.

I did look very briefly at 'drivers/video/i810/' (i810/i815 framebuffer
driver), but no free lunch there.  Someone who knows just how the i830m
differs might have a chance at that, but that's too much work for me
to think about right now (e.g. i've got too much else to learn right
now).

So i think your workaround is to use VESA (XF86Config-4 available upon
request), probably only 256 colors, until this problem can be resolved 
with the DRM driver.
				-- JM

P.S.  Uh, do any of the DRM drivers work properly with software suspend
on other machines?

Re: swsusp in test8 fails with intel-agp and i830

[Aviram Jenik]

On Sunday 19 October 2003 00:18, John Mock wrote:
>
>    With vesafb, you should be able to get any resultion you want at
>    60Hz. Which is okay, because you have LCD.
>
> Not necessarily, at least not on a VAIO R505EL  This is due to the well-
> known (to some X hackers at least) 'stolen memory' problem.  

Indeed, the same with my R505DL. I imagine vesafb is not much of a workaround 
for most vaio R505 users :-(

Pavel - I looked in intel_agp and placed printk+mdelay all over 
agp_intel_resume(struct pci_dev *pdev), but something strange happened: I saw 
those print outs during _suspend_ and not during resume - does that make any 
sense?

-- 
Aviram Jenik
Beyond Security Ltd.
http://www.BeyondSecurity.com
http://www.SecuriTeam.com

Know that you're safe:
http://www.AutomatedScanning.com

Re: swsusp in test8 fails with intel-agp and i830

[John Mock]

I took a naive look at 'intel-agp.c' to see if i could learn anything.  Not 
much luck.  I think it has a better chance of winning if 'intel-agp' and 
friends aren't compiled as modules, but even then, i'm rather skeptical...

   Pavel - I looked in intel_agp and placed printk+mdelay all over
   agp_intel_resume(struct pci_dev *pdev), but something strange happened: I saw
   those print outs during _suspend_ and not during resume - does that make any
   sense?
							-- Aviram Jenik

I also tried putting in prink's at agp_intel_suspend(), agp_intel_resume(),
and a couple of other places.  ...suspend() was called, and ...resume() did 
appear to be called during the power down sequence [even if the DRM code is
not loaded], and after as well, i think, albeit the timing isn't completely 
clear to me from 'kern.log'.  (Similarly, e100 reported 'Link is Up' during 
the power-down sequence, and also happened after it was powered back up.)

So it looks like it's trying at least, and the problem may be elsewhere.
For example, if 'i810fb' wins with software suspend, then 'intel-agp' may 
not be the issue here, as it is worth noting that the i810 frame buffer
code ('drivers/video/i810/i810_main.c'), which uses it, makes some effort 
to make sure things are suspended and resumed properly.

   drivers/char/drm/i830_drv driver is apparently using DMA _and_ has no
   suspend/resume support. That looks dangerous to me, perhaps you'll
   need to implement those, too.
							-- Pavel Machek

I wasn't able to find anything that looked like suspend/resume support in
'drivers/char/drm/*', and i'm starting to wonder if DRI in general has any
chance of working with software suspend.  After all, i think the X server 
reaches in and hacks the hardware, so i don't understand how the DRM code 
can manage to restore that state after being powered down, 'cause i don't 
think it has any way of remembering what the user level code has been doing.  
No dbout, someone else has a MUCH better understanding of this than i do! 
*-sigh-*

I did go back to 2.4.21 to try out the older i830 frame buffer code (which
was formerly called 'intelfb'). It indeed seemed to work, but alas, for my 
machine, like 'vesafb', it seemed to be stuck with whatever frame buffer 
configuration 'arch/i386/boot/video.S' set up.  So again, the best i could
do seems to be 1024x768x8 (as it seemed to look like maybe the BIOS was 
rejecting anything larger than that in memory size).

				-- JM

Re: swsusp in test8 fails with intel-agp and i830

[Pavel Machek]

Hi!

>    Pavel - I looked in intel_agp and placed printk+mdelay all over
>    agp_intel_resume(struct pci_dev *pdev), but something strange happened: I saw
>    those print outs during _suspend_ and not during resume - does that make any
>    sense?

They should be called both during suspend and during
resume. If they are not called during resume... Trace that
it looks like problem.

> I wasn't able to find anything that looked like suspend/resume support in
> 'drivers/char/drm/*', and i'm starting to wonder if DRI in general has any
> chance of working with software suspend.  After all, i think the X server 
> reaches in and hacks the hardware, so i don't understand how the DRM code 
> can manage to restore that state after being powered down, 'cause i don't 

Well, X should only hit hw when it owns the console,
that's why -test8 swsusp is doing console switch.
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...