From: Christian Hoffmann <hidden> Date: 2006-11-13 22:08:45
-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
Sent: Monday, November 13, 2006 3:06 PM
To: Christian Hoffmann
Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
Solomon Peachy; linux-fbdev-devel@lists.sourceforge.net; LKML
Subject: Re: Fwd: [Suspend-devel] resume not working on acer
ferrari 4005 with radeonfb enabled
On Monday, 13 November 2006 11:51, Christian Hoffmann wrote:
quoted
quoted
-----Original Message-----
From: Pavel Machek [mailto:pavel@ucw.cz]
Sent: Sunday, November 12, 2006 1:14 PM
To: Benjamin Herrenschmidt
Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
Wysocki; linux-fbdev-devel@lists.sourceforge.net; LKML;
Christian@ogre.sisk.pl; Hoffmann@albercik.sisk.pl
Subject: Re: Fwd: [Suspend-devel] resume not working on
acer ferrari
quoted
quoted
4005 with radeonfb enabled
Hi!
quoted
quoted
Then the radeonfb doesn't kick in at all (guess some
pci ids are
quoted
quoted
quoted
quoted
added in that patch).
BTW: resume/suspend works ok if I have the vesa fb enabled.
In that case (vesafb), when does the screen come back
precisely ? Do
quoted
you get console mode back and then X ? Or it only comes
back when
quoted
quoted
quoted
going back to X ? Do you have some userland-type vbetool
thingy that
quoted
bring it back ?
He's using s3_bios+s3_mode, so kernel does some BIOS
calls to reinit
quoted
quoted
the video. It should come out in text mode, too.
Christian, can you unload radeonfb before suspend/reload it after
resume?
Will it work if radeonfb is compiled as module? I think I
had problems
quoted
with that, but I'll try again.
quoted
Next possibility is setting up serial console and adding some
printks to radeon...
Unfortunatly, the laptop doesn't have serial port. I tried to get a
USB device (pocketpc) read the USB serial, but I only partially
succeeded. I can pass console=ttyUSB0 to the kernel and
load the ipaq
quoted
serial console driver as it oopses. I am able to echo strings to
/dev/ttyUSB0 and read them on the ipaq, but I am not able to
"deviate" the kernel messages to that port. Any hints on how to do
that would be very appreciated, I didn't find anything
usefull on the
quoted
web. (I tried with setconsole /dev/ttyUSB0 but it gives error msg
about device busy or something)
Would it be practicable to use netconsole on your box? If
so, it should work.
I tried netconsole, and it somehow works, but when suspending it says in
an "infinite" loop:
unregister_netdevice: waiting for eth2 to become free. Usage count = 1
And then it never goes to sleep.
BTW: same if I use radeonfb as a module and try to blacklist this
module. It complains that radeonfb is still in use.
Arghhh :)
Chris
Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Wall Street Systems does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Wall Street Systems does not accept liability for any damage sustained as a result of viruses. Statements in this message or attachments that do not relate to the business of Wall Street Systems are neither given nor endorsed by the company or its Directors.
From: Rafael J. Wysocki <hidden> Date: 2006-11-13 23:11:42
On Monday, 13 November 2006 23:08, Christian Hoffmann wrote:
quoted
-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
Sent: Monday, November 13, 2006 3:06 PM
To: Christian Hoffmann
Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
Solomon Peachy; linux-fbdev-devel@lists.sourceforge.net; LKML
Subject: Re: Fwd: [Suspend-devel] resume not working on acer
ferrari 4005 with radeonfb enabled
On Monday, 13 November 2006 11:51, Christian Hoffmann wrote:
quoted
quoted
-----Original Message-----
From: Pavel Machek [mailto:pavel@ucw.cz]
Sent: Sunday, November 12, 2006 1:14 PM
To: Benjamin Herrenschmidt
Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
Wysocki; linux-fbdev-devel@lists.sourceforge.net; LKML;
Christian@ogre.sisk.pl; Hoffmann@albercik.sisk.pl
Subject: Re: Fwd: [Suspend-devel] resume not working on
acer ferrari
quoted
quoted
4005 with radeonfb enabled
Hi!
quoted
quoted
Then the radeonfb doesn't kick in at all (guess some
pci ids are
quoted
quoted
quoted
quoted
added in that patch).
BTW: resume/suspend works ok if I have the vesa fb enabled.
In that case (vesafb), when does the screen come back
precisely ? Do
quoted
you get console mode back and then X ? Or it only comes
back when
quoted
quoted
quoted
going back to X ? Do you have some userland-type vbetool
thingy that
quoted
bring it back ?
He's using s3_bios+s3_mode, so kernel does some BIOS
calls to reinit
quoted
quoted
the video. It should come out in text mode, too.
Christian, can you unload radeonfb before suspend/reload it after
resume?
Will it work if radeonfb is compiled as module? I think I
had problems
quoted
with that, but I'll try again.
quoted
Next possibility is setting up serial console and adding some
printks to radeon...
Unfortunatly, the laptop doesn't have serial port. I tried to get a
USB device (pocketpc) read the USB serial, but I only partially
succeeded. I can pass console=ttyUSB0 to the kernel and
load the ipaq
quoted
serial console driver as it oopses. I am able to echo strings to
/dev/ttyUSB0 and read them on the ipaq, but I am not able to
"deviate" the kernel messages to that port. Any hints on how to do
that would be very appreciated, I didn't find anything
usefull on the
quoted
web. (I tried with setconsole /dev/ttyUSB0 but it gives error msg
about device busy or something)
Would it be practicable to use netconsole on your box? If
so, it should work.
I tried netconsole, and it somehow works, but when suspending it says in
an "infinite" loop:
unregister_netdevice: waiting for eth2 to become free. Usage count = 1
Hm. Is your kernel compiled with CONFIG_DISABLE_CONSOLE_SUSPEND set?
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
From: Christian Hoffmann <hidden> Date: 2006-11-14 18:51:50
On Tuesday 14 November 2006 00:08, Rafael J. Wysocki wrote:
On Monday, 13 November 2006 23:08, Christian Hoffmann wrote:
quoted
quoted
-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
Sent: Monday, November 13, 2006 3:06 PM
To: Christian Hoffmann
Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
Solomon Peachy; linux-fbdev-devel@lists.sourceforge.net; LKML
Subject: Re: Fwd: [Suspend-devel] resume not working on acer
ferrari 4005 with radeonfb enabled
On Monday, 13 November 2006 11:51, Christian Hoffmann wrote:
quoted
quoted
-----Original Message-----
From: Pavel Machek [mailto:pavel@ucw.cz]
Sent: Sunday, November 12, 2006 1:14 PM
To: Benjamin Herrenschmidt
Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
Wysocki; linux-fbdev-devel@lists.sourceforge.net; LKML;
Christian@ogre.sisk.pl; Hoffmann@albercik.sisk.pl
Subject: Re: Fwd: [Suspend-devel] resume not working on
acer ferrari
quoted
quoted
4005 with radeonfb enabled
Hi!
quoted
quoted
Then the radeonfb doesn't kick in at all (guess some
pci ids are
quoted
quoted
quoted
quoted
added in that patch).
BTW: resume/suspend works ok if I have the vesa fb enabled.
In that case (vesafb), when does the screen come back
precisely ? Do
quoted
you get console mode back and then X ? Or it only comes
back when
quoted
quoted
quoted
going back to X ? Do you have some userland-type vbetool
thingy that
quoted
bring it back ?
He's using s3_bios+s3_mode, so kernel does some BIOS
calls to reinit
quoted
quoted
the video. It should come out in text mode, too.
Christian, can you unload radeonfb before suspend/reload it after
resume?
Will it work if radeonfb is compiled as module? I think I
had problems
quoted
with that, but I'll try again.
quoted
Next possibility is setting up serial console and adding some
printks to radeon...
Unfortunatly, the laptop doesn't have serial port. I tried to get a
USB device (pocketpc) read the USB serial, but I only partially
succeeded. I can pass console=ttyUSB0 to the kernel and
load the ipaq
quoted
serial console driver as it oopses. I am able to echo strings to
/dev/ttyUSB0 and read them on the ipaq, but I am not able to
"deviate" the kernel messages to that port. Any hints on how to do
that would be very appreciated, I didn't find anything
usefull on the
quoted
web. (I tried with setconsole /dev/ttyUSB0 but it gives error msg
about device busy or something)
Would it be practicable to use netconsole on your box? If
so, it should work.
I tried netconsole, and it somehow works, but when suspending it says in
an "infinite" loop:
unregister_netdevice: waiting for eth2 to become free. Usage count = 1
Hm. Is your kernel compiled with CONFIG_DISABLE_CONSOLE_SUSPEND set?
Rafael
No, I don't even have your patch installed that gives that option.
Chris
From: Christian Hoffmann <hidden> Date: 2006-11-14 21:48:11
On Tuesday 14 November 2006 00:08, Rafael J. Wysocki wrote:
On Monday, 13 November 2006 23:08, Christian Hoffmann wrote:
quoted
quoted
-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
Sent: Monday, November 13, 2006 3:06 PM
To: Christian Hoffmann
Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
Solomon Peachy; linux-fbdev-devel@lists.sourceforge.net; LKML
Subject: Re: Fwd: [Suspend-devel] resume not working on acer
ferrari 4005 with radeonfb enabled
On Monday, 13 November 2006 11:51, Christian Hoffmann wrote:
quoted
quoted
-----Original Message-----
From: Pavel Machek [mailto:pavel@ucw.cz]
Sent: Sunday, November 12, 2006 1:14 PM
To: Benjamin Herrenschmidt
Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
Wysocki; linux-fbdev-devel@lists.sourceforge.net; LKML;
Christian@ogre.sisk.pl; Hoffmann@albercik.sisk.pl
Subject: Re: Fwd: [Suspend-devel] resume not working on
acer ferrari
quoted
quoted
4005 with radeonfb enabled
Hi!
quoted
quoted
Then the radeonfb doesn't kick in at all (guess some
pci ids are
quoted
quoted
quoted
quoted
added in that patch).
BTW: resume/suspend works ok if I have the vesa fb enabled.
In that case (vesafb), when does the screen come back
precisely ? Do
quoted
you get console mode back and then X ? Or it only comes
back when
quoted
quoted
quoted
going back to X ? Do you have some userland-type vbetool
thingy that
quoted
bring it back ?
He's using s3_bios+s3_mode, so kernel does some BIOS
calls to reinit
quoted
quoted
the video. It should come out in text mode, too.
Christian, can you unload radeonfb before suspend/reload it after
resume?
Will it work if radeonfb is compiled as module? I think I
had problems
quoted
with that, but I'll try again.
quoted
Next possibility is setting up serial console and adding some
printks to radeon...
Unfortunatly, the laptop doesn't have serial port. I tried to get a
USB device (pocketpc) read the USB serial, but I only partially
succeeded. I can pass console=ttyUSB0 to the kernel and
load the ipaq
quoted
serial console driver as it oopses. I am able to echo strings to
/dev/ttyUSB0 and read them on the ipaq, but I am not able to
"deviate" the kernel messages to that port. Any hints on how to do
that would be very appreciated, I didn't find anything
usefull on the
quoted
web. (I tried with setconsole /dev/ttyUSB0 but it gives error msg
about device busy or something)
Would it be practicable to use netconsole on your box? If
so, it should work.
I tried netconsole, and it somehow works, but when suspending it says in
an "infinite" loop:
unregister_netdevice: waiting for eth2 to become free. Usage count = 1
Hm. Is your kernel compiled with CONFIG_DISABLE_CONSOLE_SUSPEND set?
Rafael
I tried that patch, but the last message I see over netconsole (using tg3) is:
Suspending console(s)
and then nothing. Nothing on resume at all :(
Adding some printks in the radeonfb_pci_suspend and radeonfb_pci_resume
(radeon_pm.c) didn't help: I don't see them. But I am not a kernel programmer
at all, so I might do something wrong or in the wrong place.
Chris
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-11-14 22:07:55
I tried that patch, but the last message I see over netconsole (using tg3) is:
Suspending console(s)
and then nothing. Nothing on resume at all :(
Adding some printks in the radeonfb_pci_suspend and radeonfb_pci_resume
(radeon_pm.c) didn't help: I don't see them. But I am not a kernel programmer
at all, so I might do something wrong or in the wrong place.
Does it resume if you make radeon_pci_resume() a nop ?
Of course, the fbdev will not come back, but will the machine overall
resume ?
Ben.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: Rafael J. Wysocki <hidden> Date: 2006-11-14 22:39:47
On Tuesday, 14 November 2006 22:47, Christian Hoffmann wrote:
On Tuesday 14 November 2006 00:08, Rafael J. Wysocki wrote:
quoted
On Monday, 13 November 2006 23:08, Christian Hoffmann wrote:
quoted
quoted
-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
Sent: Monday, November 13, 2006 3:06 PM
To: Christian Hoffmann
Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
Solomon Peachy; linux-fbdev-devel@lists.sourceforge.net; LKML
Subject: Re: Fwd: [Suspend-devel] resume not working on acer
ferrari 4005 with radeonfb enabled
On Monday, 13 November 2006 11:51, Christian Hoffmann wrote:
quoted
quoted
-----Original Message-----
From: Pavel Machek [mailto:pavel@ucw.cz]
Sent: Sunday, November 12, 2006 1:14 PM
To: Benjamin Herrenschmidt
Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
Wysocki; linux-fbdev-devel@lists.sourceforge.net; LKML;
Christian@ogre.sisk.pl; Hoffmann@albercik.sisk.pl
Subject: Re: Fwd: [Suspend-devel] resume not working on
acer ferrari
quoted
quoted
4005 with radeonfb enabled
Hi!
quoted
quoted
Then the radeonfb doesn't kick in at all (guess some
pci ids are
quoted
quoted
quoted
quoted
added in that patch).
BTW: resume/suspend works ok if I have the vesa fb enabled.
In that case (vesafb), when does the screen come back
precisely ? Do
quoted
you get console mode back and then X ? Or it only comes
back when
quoted
quoted
quoted
going back to X ? Do you have some userland-type vbetool
thingy that
quoted
bring it back ?
He's using s3_bios+s3_mode, so kernel does some BIOS
calls to reinit
quoted
quoted
the video. It should come out in text mode, too.
Christian, can you unload radeonfb before suspend/reload it after
resume?
Will it work if radeonfb is compiled as module? I think I
had problems
quoted
with that, but I'll try again.
quoted
Next possibility is setting up serial console and adding some
printks to radeon...
Unfortunatly, the laptop doesn't have serial port. I tried to get a
USB device (pocketpc) read the USB serial, but I only partially
succeeded. I can pass console=ttyUSB0 to the kernel and
load the ipaq
quoted
serial console driver as it oopses. I am able to echo strings to
/dev/ttyUSB0 and read them on the ipaq, but I am not able to
"deviate" the kernel messages to that port. Any hints on how to do
that would be very appreciated, I didn't find anything
usefull on the
quoted
web. (I tried with setconsole /dev/ttyUSB0 but it gives error msg
about device busy or something)
Would it be practicable to use netconsole on your box? If
so, it should work.
I tried netconsole, and it somehow works, but when suspending it says in
an "infinite" loop:
unregister_netdevice: waiting for eth2 to become free. Usage count = 1
Hm. Is your kernel compiled with CONFIG_DISABLE_CONSOLE_SUSPEND set?
Rafael
I tried that patch, but the last message I see over netconsole (using tg3) is:
Suspending console(s)
and then nothing. Nothing on resume at all :(
The patch prevents messages from being sent to the console(s) while the
devices that handle the console(s) are being suspended/resumed.
What you observe means that the box probably crashes somewhere during
the resuming of devices, so netconsole won't help.
BTW, could you please remind me which kernel you are using?
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
From: Pavel Machek <hidden> Date: 2006-11-14 22:56:49
Hi!
quoted
quoted
I tried netconsole, and it somehow works, but when suspending it says in
an "infinite" loop:
unregister_netdevice: waiting for eth2 to become free. Usage count = 1
Hm. Is your kernel compiled with CONFIG_DISABLE_CONSOLE_SUSPEND set?
Rafael
I tried that patch, but the last message I see over netconsole (using tg3) is:
Suspending console(s)
and then nothing. Nothing on resume at all :(
Adding some printks in the radeonfb_pci_suspend and radeonfb_pci_resume
(radeon_pm.c) didn't help: I don't see them. But I am not a kernel programmer
at all, so I might do something wrong or in the wrong place.
From: Rafael J. Wysocki <hidden> Date: 2006-11-14 23:00:54
On Tuesday, 14 November 2006 23:56, Pavel Machek wrote:
Hi!
quoted
quoted
quoted
I tried netconsole, and it somehow works, but when suspending it says in
an "infinite" loop:
unregister_netdevice: waiting for eth2 to become free. Usage count = 1
Hm. Is your kernel compiled with CONFIG_DISABLE_CONSOLE_SUSPEND set?
Rafael
I tried that patch, but the last message I see over netconsole (using tg3) is:
Suspending console(s)
and then nothing. Nothing on resume at all :(
Adding some printks in the radeonfb_pci_suspend and radeonfb_pci_resume
(radeon_pm.c) didn't help: I don't see them. But I am not a kernel programmer
at all, so I might do something wrong or in the wrong place.
Linus has crazy "write some info to CMOS" hack... which should be
usable here.
No, it's i386-only.
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
From: Pavel Machek <hidden> Date: 2006-11-14 23:13:14
On Tue 2006-11-14 23:57:59, Rafael J. Wysocki wrote:
On Tuesday, 14 November 2006 23:56, Pavel Machek wrote:
quoted
Hi!
quoted
quoted
quoted
I tried netconsole, and it somehow works, but when suspending it says in
an "infinite" loop:
unregister_netdevice: waiting for eth2 to become free. Usage count = 1
Hm. Is your kernel compiled with CONFIG_DISABLE_CONSOLE_SUSPEND set?
Rafael
I tried that patch, but the last message I see over netconsole (using tg3) is:
Suspending console(s)
and then nothing. Nothing on resume at all :(
Adding some printks in the radeonfb_pci_suspend and radeonfb_pci_resume
(radeon_pm.c) didn't help: I don't see them. But I am not a kernel programmer
at all, so I might do something wrong or in the wrong place.
Linus has crazy "write some info to CMOS" hack... which should be
usable here.
From: Christian Hoffmann <hidden> Date: 2006-11-15 00:54:54
On Tuesday 14 November 2006 23:07, Benjamin Herrenschmidt wrote:
quoted
I tried that patch, but the last message I see over netconsole (using
tg3) is: Suspending console(s)
and then nothing. Nothing on resume at all :(
Adding some printks in the radeonfb_pci_suspend and radeonfb_pci_resume
(radeon_pm.c) didn't help: I don't see them. But I am not a kernel
programmer at all, so I might do something wrong or in the wrong place.
Does it resume if you make radeon_pci_resume() a nop ?
Of course, the fbdev will not come back, but will the machine overall
resume ?
Ben.
Yes, if i make radeon_pci_resume a nop, the machine resumes if i do a return 0
immediately.
I think I tracked it down to the call to acquire_console_sem() as the
following code makes the machine hang again:
int radeonfb_pci_resume(struct pci_dev *pdev)
{
struct fb_info *info = pci_get_drvdata(pdev);
struct radeonfb_info *rinfo = info->par;
int rc = 0;
if (pdev->dev.power.power_state.event == PM_EVENT_ON)
return 0;
if (rinfo->no_schedule) {
/* if (try_acquire_console_sem())*/
return 0;
} else
acquire_console_sem();
return 0;
...
Chris
NB: kernel 2.6.18.1, amd64
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-11-15 01:48:58
On Wed, 2006-11-15 at 01:54 +0100, Christian Hoffmann wrote:
On Tuesday 14 November 2006 23:07, Benjamin Herrenschmidt wrote:
quoted
quoted
I tried that patch, but the last message I see over netconsole (using
tg3) is: Suspending console(s)
and then nothing. Nothing on resume at all :(
Adding some printks in the radeonfb_pci_suspend and radeonfb_pci_resume
(radeon_pm.c) didn't help: I don't see them. But I am not a kernel
programmer at all, so I might do something wrong or in the wrong place.
Does it resume if you make radeon_pci_resume() a nop ?
Of course, the fbdev will not come back, but will the machine overall
resume ?
Ben.
Yes, if i make radeon_pci_resume a nop, the machine resumes if i do a return 0
immediately.
I think I tracked it down to the call to acquire_console_sem() as the
following code makes the machine hang again:
int radeonfb_pci_resume(struct pci_dev *pdev)
{
struct fb_info *info = pci_get_drvdata(pdev);
struct radeonfb_info *rinfo = info->par;
int rc = 0;
if (pdev->dev.power.power_state.event == PM_EVENT_ON)
return 0;
if (rinfo->no_schedule) {
/* if (try_acquire_console_sem())*/
return 0;
} else
acquire_console_sem();
return 0;
...
Well, if you acquire the console sem you need to release it too :-)
Ben.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: Rafael J. Wysocki <hidden> Date: 2006-11-15 10:12:04
On Wednesday, 15 November 2006 02:48, Benjamin Herrenschmidt wrote:
On Wed, 2006-11-15 at 01:54 +0100, Christian Hoffmann wrote:
quoted
On Tuesday 14 November 2006 23:07, Benjamin Herrenschmidt wrote:
quoted
quoted
I tried that patch, but the last message I see over netconsole (using
tg3) is: Suspending console(s)
and then nothing. Nothing on resume at all :(
Adding some printks in the radeonfb_pci_suspend and radeonfb_pci_resume
(radeon_pm.c) didn't help: I don't see them. But I am not a kernel
programmer at all, so I might do something wrong or in the wrong place.
Does it resume if you make radeon_pci_resume() a nop ?
Of course, the fbdev will not come back, but will the machine overall
resume ?
Ben.
Yes, if i make radeon_pci_resume a nop, the machine resumes if i do a return 0
immediately.
I think I tracked it down to the call to acquire_console_sem() as the
following code makes the machine hang again:
int radeonfb_pci_resume(struct pci_dev *pdev)
{
struct fb_info *info = pci_get_drvdata(pdev);
struct radeonfb_info *rinfo = info->par;
int rc = 0;
if (pdev->dev.power.power_state.event == PM_EVENT_ON)
return 0;
if (rinfo->no_schedule) {
/* if (try_acquire_console_sem())*/
return 0;
} else
acquire_console_sem();
return 0;
...
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?
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: Christian Hoffmann <hidden> Date: 2006-11-16 22:17:48
quoted
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)) {
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 :(
Chris
From: Rafael J. Wysocki <hidden> Date: 2006-11-16 22:47:59
On Thursday, 16 November 2006 23:17, Christian Hoffmann wrote:
quoted
quoted
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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Thu, Nov 16, 2006 at 11:44:40PM +0100, Rafael J. Wysocki wrote:
I think the call to radeon_restore_pci_cfg(rinfo) causes the problem to happen.
radeonfb is still using its own code for saving and restoring PCI
registers; I'm in the process of fixing it up to use proper PCI
subsystem calls. That will hopefully work better.
It's possible there's a good reason (other than "nobody's ported it over
yet") that the radeonfb driver is doing it manually, but I don't know
why that would be the case.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur. ICQ: 1318344
On Thu, Nov 16, 2006 at 11:17:26PM +0100, Christian Hoffmann wrote:
Ok, I did that and the machine resumes OK. Now I have the impression that
accessing the rinfo struct here:
Can you try this updated patch?
http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.19-v7-WIP1.diff
Changes from v6b (which you were using)
* A few PPC-related fixes and other cleanups from BenH
* Rewrote the suspend/resume code to use standard
pci_save_state/pci_restore_state/pci_set_power_state calls instead
of the manual saving and twiddling of PCI registers.
This power management code change is very much of an experiment -- it's
certianly possible there's a good reason to do it manually, but I
suspect it's just because that code is old.
Let me know if this is an improvement.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur. ICQ: 1318344
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-11-17 06:17:36
On Fri, 2006-11-17 at 00:27 -0500, Stuffed Crust wrote:
On Thu, Nov 16, 2006 at 11:44:40PM +0100, Rafael J. Wysocki wrote:
quoted
I think the call to radeon_restore_pci_cfg(rinfo) causes the problem to happen.
radeonfb is still using its own code for saving and restoring PCI
registers; I'm in the process of fixing it up to use proper PCI
subsystem calls. That will hopefully work better.
It's possible there's a good reason (other than "nobody's ported it over
yet") that the radeonfb driver is doing it manually, but I don't know
why that would be the case.
Well, radeonfb has code to bring back some cards from D2 or D3 cold (or
hard reset). It differenciates those states by checking if the config
space has been trashed. We should try to find out some better way.
Cheers,
Ben.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
On Fri, Nov 17, 2006 at 05:17:00PM +1100, Benjamin Herrenschmidt wrote:
quoted
radeonfb is still using its own code for saving and restoring PCI
registers; I'm in the process of fixing it up to use proper PCI
subsystem calls. That will hopefully work better.
It's possible there's a good reason (other than "nobody's ported it over
yet") that the radeonfb driver is doing it manually, but I don't know
why that would be the case.
Well, radeonfb has code to bring back some cards from D2 or D3 cold (or
hard reset). It differenciates those states by checking if the config
space has been trashed. We should try to find out some better way.
The d2 vs d3 is determined by chipset in advance -- powermacs and some
thinkpads use d2, and everyone else uses d3.
On resume, we check that same flag, and restore differently. We only
checked the config space on D3 resume, and restored everything if the
first byte was trashed..
If I understand what you're saying correctly, if we re-write a valid set
of pci registers, we'll trash the radeon state? Why _wouldn't_ a D3
resume be trashed?
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur. ICQ: 1318344
http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.19-v7-WIP2.diff
This incorporates the latest round of BenH's fixes and changes, but
backs out the PCI suspend changes, which need independent review and testing.
(BenH has promised a little more work before he's ready to sign off,
hence the -WIP2 designation)
The following patch contains a rewrite of radeonfb's suspend/resume code
to use standard PCI subsystem calls. It applies to 2.6.19-rc6 and also
on top of the v7-WIP2 patch.
http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.19-suspend.diff
Christian, if you could see if the latter patch (on top of the -v6b or
-WIP2 patches) makes a difference for your suspend/resume problems..
And with these patches, I'm going to drop offline for a camping trip
over the weekend. I'll pick this stuff back up on Monday.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur. ICQ: 1318344
http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.19-v7-WIP2.diff
This incorporates the latest round of BenH's fixes and changes, but
backs out the PCI suspend changes, which need independent review and
testing.
(BenH has promised a little more work before he's ready to sign off,
hence the -WIP2 designation)
The following patch contains a rewrite of radeonfb's suspend/resume code
to use standard PCI subsystem calls. It applies to 2.6.19-rc6 and also
on top of the v7-WIP2 patch.
http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.19-suspend.diff
Christian, if you could see if the latter patch (on top of the -v6b or
-WIP2 patches) makes a difference for your suspend/resume problems..
And with these patches, I'm going to drop offline for a camping trip
over the weekend. I'll pick this stuff back up on Monday.
- Solomon
Hlo,
it still locks up.
...
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
if (pci_enable_device(pdev)) {
rc = -ENODEV;
printk(KERN_ERR "radeonfb (%s): can't enable PCI device !\n",
pci_name(pdev));
goto bail;
}
pci_set_master(pdev);
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) {
if (rinfo->reinit_func != NULL)
rinfo->reinit_func(rinfo);
else {
printk(KERN_ERR "radeonfb (%s): can't resume
radeon from"
" D3 cold, need softboot !",
pci_name(pdev));
rc = -EIO;
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;
} else
radeon_engine_idle();
goto bail;
When I comment out the rinfo->asleep = 0; line, the machine comes back. So it
seems that rinfo struct is still corrupted somehow.
Chris
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-11-17 21:58:20
If I understand what you're saying correctly, if we re-write a valid set
of pci registers, we'll trash the radeon state? Why _wouldn't_ a D3
resume be trashed?
No, we determine in advance what we support. On resume, we don't want to
do a full reset of the chip if it was not powered down. (Among others,
this isn't tested and we might not be doing it properly from a non
poweron-reset state).
Ben.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-11-17 21:59:54
When I comment out the rinfo->asleep = 0; line, the machine comes back. So it
seems that rinfo struct is still corrupted somehow.
No, I don't think the rinfo is corrupted, I think the chip is in a state
the driver can't cope with. Possibly related to some PCI-Express
specific bits or to the memory map.
At this point, we'll need to do register dumps.
Ben.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: Christian Hoffmann <hidden> Date: 2006-11-17 22:03:00
-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
Sent: Friday, November 17, 2006 10:59 PM
To: Christian Hoffmann
Cc: Stuffed Crust; Rafael J. Wysocki;
linux-fbdev-devel@lists.sourceforge.net; Christian Hoffmann;
Andrew Morton; LKML; Pavel Machek
Subject: Re: [Linux-fbdev-devel] Fwd: [Suspend-devel] resume
not working onacer ferrari 4005 with radeonfb enabled
quoted
When I comment out the rinfo->asleep = 0; line, the machine comes
back. So it seems that rinfo struct is still corrupted somehow.
No, I don't think the rinfo is corrupted, I think the chip is
in a state the driver can't cope with. Possibly related to
some PCI-Express specific bits or to the memory map.
At this point, we'll need to do register dumps.
Sorry, but how do I do that?
Chris
BTW: yes, it's a PCI-express card.
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.430 / Virus Database: 268.14.6/536 - Release Date: 11/16/2006
3:51 PM
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2006-11-17 22:35:20
Sorry, but how do I do that?
Chris
BTW: yes, it's a PCI-express card.
You need to wit a bit for me to check wether we have added the PCI-E
specific registers to radeontool dump :-)
Ben.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV