linux-kernel - Re: [Linux-fbdev-devel] Fwd: [Suspend-devel] resume not working on acer ferrari 4005 with radeonfb enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200611162344.41622.rjw@sisk.pl>
Date:	Thu, 16 Nov 2006 23:44:40 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Christian Hoffmann <chrmhoffmann@...il.com>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux-fbdev-devel@...ts.sourceforge.net,
	Christian Hoffmann <Christian.Hoffmann@...lstreetsystems.com>,
	Andrew Morton <akpm@...l.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Solomon Peachy <pizza@...ftnet.org>,
	Pavel Machek <pavel@....cz>
Subject: Re: [Linux-fbdev-devel] Fwd: [Suspend-devel] resume not working on acer ferrari 4005 with radeonfb enabled

On Thursday, 16 November 2006 23:17, Christian Hoffmann wrote:
> 
> > >
> > > Well, if you acquire the console sem you need to release it too :-)
> >
> > Or the console semaphore is acquired too many times.
> >
> > Christian, could you please add release_console_sem() before 'return 0'
> > and see if that makes the code work again?  If not, could you add a
> > printk() in kernel/printk.c/acquire_console_sem() to see how many times it
> > is called?
> 
> Ok, I did that and the machine resumes OK. Now I have the impression that 
> accessing the rinfo struct here:
> 
> if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
>                 /* Wakeup chip. Check from config space if we were powered off
>                  * (todo: additionally, check CLK_PIN_CNTL too)
>                  */
>                 if ((rinfo->pm_mode & radeon_pm_off) &&
>                         radeon_restore_pci_cfg(rinfo)) {

I think the call to radeon_restore_pci_cfg(rinfo) causes the problem to happen.

>                         if (rinfo->reinit_func != NULL) {
>                                 rinfo->reinit_func(rinfo);
>                                 }
>                         else {
>                                 goto bail;
>                         }
>                 }
>                 /* If we support D2, try to resume... we should check what was 
> our
>                  * state though... (were we really in D2 state ?). Right now, 
> this code
>                  * is only enable on Macs so it's fine.
>                  */
>                 else if (rinfo->pm_mode & radeon_pm_d2){
>                         radeon_set_suspend(rinfo, 0);
>                 }
>                 rinfo->asleep = 0; ////makes it crash
>         } else {
>                 radeon_engine_idle();
>         }
> 
> makes the resume fail. The machine locks up. I started xorg without drm/dri 
> and then it goes a little further and locks up in the next steps:        
> 
> /* Restore display & engine */
> radeon_write_mode (rinfo, &rinfo->state, 1);
> 
> But it starts to get too complicated for me :(

Unfortunately for me too.  Someone who knows the radeonfb code is needed.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/