Questions about vbestate

Questions about vbestate

[Stefan Dösinger]

Hello,
I am still investigating the suspend-to-ram issues with the radeon graphic 
cards. I am trying to get s3 working with the proprietary  fglrx driver from 
ati.

There is no problem with the kernel module, but switching back to the X server 
after resuming and post-ing the card the driver hangs. Bad so far. I 
investigated a little bit more:

*switching to the console(no framebuffer), posting the card with one of the 
c000:3 callers and switching back to X causes a crash

*If I save the card's state with vbesate before calling the post-routine and 
restoring the state afterwards makes switching back to X work again.

*BUT: If I switch to the console, save the state, go to suspend, wake up the 
system and restore the vbestate fglrx crashes again.

So my question is: Are there some settings which might get lost during and S3 
which are NOT restored by vbestate?

I am using fglrx V.8.8.25 with X.Org 6.8.1. I will also write a mail to ATI to 
help them fix their driver. They say that they are aware of this problem and 
haven't found a solution yet.

Note: S3 works fine for me with the gpl "radeon" driver from X.Org. I am 
trying to get fglrx working because I need it for gaming and I don't want to 
switch the konfiguration permanently. It would also help users with a radeon 
>=9200 card.

Cheers,
Stefan


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Questions about vbestate

[Matthew Garrett]

On Tue, 2005-01-18 at 19:12 +0100, Stefan Dösinger wrote:

> *If I save the card's state with vbesate before calling the post-routine and 
> restoring the state afterwards makes switching back to X work again.

I'd recommend saving the vbe state on boot, and not on every suspend.
I'm not sure why, but there certainly seems to be some amount of
information that's lost otherwise. Saving on suspend seems to make a
large amount of hardware unhappy - I've only found one machine that
complains about it on boot.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Questions about vbestate

[Stefan Dösinger]

Am Mittwoch, 19. Januar 2005 01:55 schrieb Matthew Garrett:
> On Tue, 2005-01-18 at 19:12 +0100, Stefan Dösinger wrote:
> > *If I save the card's state with vbesate before calling the post-routine
> > and restoring the state afterwards makes switching back to X work again.
>
> I'd recommend saving the vbe state on boot, and not on every suspend.
> I'm not sure why, but there certainly seems to be some amount of
> information that's lost otherwise. Saving on suspend seems to make a
> large amount of hardware unhappy - I've only found one machine that
> complains about it on boot.
I tried this and it didn't work. I've also found out why. It's because the dri 
part of fglrx crashes after resume.

fglrx and suspend works fine if I disable DRI in xorg.conf. With dri enabled 
I've found no way to resume a started X session :-(

I suppose that vbestate doesn't touch the radeon specific settings set by 
fglrx and fglrx doesn't restore them carefully enought. If I start a secound 
X server after S3 I can't revive the original session too because the 2nd 
server doesn't initialize dri.

I've written a bug report to ATI yesterday and I'm waiting for a reply.

Stefan


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: Questions about vbestate

[Stefan Dösinger]

Am Mittwoch, 19. Januar 2005 01:55 schrieb Matthew Garrett:
> On Tue, 2005-01-18 at 19:12 +0100, Stefan Dösinger wrote:
> > *If I save the card's state with vbesate before calling the post-routine
> > and restoring the state afterwards makes switching back to X work again.
>
> I'd recommend saving the vbe state on boot, and not on every suspend.
> I'm not sure why, but there certainly seems to be some amount of
> information that's lost otherwise. Saving on suspend seems to make a
> large amount of hardware unhappy - I've only found one machine that
> complains about it on boot.

Is it possible to reset the whole video memory with vbetool? I mean, if we 
reset the graphics processor when posting the card, we should also clean up 
the garbage in the video memory. The content in my card's memory survives a 
card reboot, a suspend-to-ram cycle and even a system reboot. Under certain 
circumstances this crashes both fglrx and the open source radeon driver.

Stefan


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Questions about vbestate

[Matthew Garrett]

On Sat, 2005-01-22 at 12:05 +0100, Stefan Dösinger wrote:

> Is it possible to reset the whole video memory with vbetool? I mean, if we 
> reset the graphics processor when posting the card, we should also clean up 
> the garbage in the video memory. The content in my card's memory survives a 
> card reboot, a suspend-to-ram cycle and even a system reboot. Under certain 
> circumstances this crashes both fglrx and the open source radeon driver.

That's likely to be caused by held-over internal chip state, rather than
video memory. Whether or not vbetool can do anything about that depends
on the video BIOS, really - the state saving/restore /ought/ to deal
with that, but there's no guarantee.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Questions about vbestate

[Stefan Dösinger]

Am Samstag, 22. Januar 2005 14:10 schrieb Matthew Garrett:
> On Sat, 2005-01-22 at 12:05 +0100, Stefan Dösinger wrote:
> > Is it possible to reset the whole video memory with vbetool? I mean, if
> > we reset the graphics processor when posting the card, we should also
> > clean up the garbage in the video memory. The content in my card's memory
> > survives a card reboot, a suspend-to-ram cycle and even a system reboot.
> > Under certain circumstances this crashes both fglrx and the open source
> > radeon driver.
>
> That's likely to be caused by held-over internal chip state, rather than
> video memory. Whether or not vbetool can do anything about that depends
> on the video BIOS, really - the state saving/restore /ought/ to deal
> with that, but there's no guarantee.
If I switch between the 2 drivers, the X server crashes on load after a system 
reboot(at least it happened with older versions of the drivers). A part of my 
old desktop image appears when I attempt to start the server. That's why I 
think that some content in the video memory survives a reboot.

I'll need the help of ATI with the fglrx driver. I contacted ATI but didn't 
get a reply so far. :-(

What's the state of Nvidia cards here? Do they work with suspend-to-ram?

Stefan


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl