Hi,
We've just got the appended report. Could you please have a look at this?
Greetings,
Rafael
---------- Forwarded Message ----------
Subject: [Suspend-devel] resume not working on acer ferrari 4005 with radeonfb enabled
Date: Friday, 10 November 2006 20:44
From: "Christian Hoffmann" <[email protected]>
To: [email protected]
Hello,
when I have radeonfb enabled, my laptop (X700 ati mobility) doesnt resume
anymore. Screen stays black and nothing works anymore, no capslock light, no
ctrl alt sysreq b etc. I tried all kind of things vbetool, passing
acpi_sleep=s3_bios,s3_mode to the kernel. Nothing seems to work.
You can see dmesg output and lspci -vv output here
http://christianhoffmann.de/temp/radeon.log
http://christianhoffmann.de/temp/lspci.log
Thanks a lot for any input.
Chris
PS: I use kernel 2.18.1 + patch for radeonfb from
http://bugzilla.kernel.org/attachment.cgi?id=9408&action=view
On Sat, 2006-11-11 at 00:31 +0100, Rafael J. Wysocki wrote:
> Hi,
>
> We've just got the appended report. Could you please have a look at this?
There are many possible reasons for that. The most likely is that the
BIOS isn't bringing the chip back on resume, causing radeonfb to
crash when trying to access it.
Ben.
> Greetings,
> Rafael
>
>
> ---------- Forwarded Message ----------
>
> Subject: [Suspend-devel] resume not working on acer ferrari 4005 with radeonfb enabled
> Date: Friday, 10 November 2006 20:44
> From: "Christian Hoffmann" <[email protected]>
> To: [email protected]
>
> Hello,
>
> when I have radeonfb enabled, my laptop (X700 ati mobility) doesnt resume
> anymore. Screen stays black and nothing works anymore, no capslock light, no
> ctrl alt sysreq b etc. I tried all kind of things vbetool, passing
> acpi_sleep=s3_bios,s3_mode to the kernel. Nothing seems to work.
>
> You can see dmesg output and lspci -vv output here
> http://christianhoffmann.de/temp/radeon.log
> http://christianhoffmann.de/temp/lspci.log
>
> Thanks a lot for any input.
>
> Chris
>
> PS: I use kernel 2.18.1 + patch for radeonfb from
> http://bugzilla.kernel.org/attachment.cgi?id=9408&action=view
On Sat, 11 Nov 2006 12:49:06 +1100
Benjamin Herrenschmidt <[email protected]> wrote:
> On Sat, 2006-11-11 at 00:31 +0100, Rafael J. Wysocki wrote:
> > Hi,
> >
> > We've just got the appended report. Could you please have a look at this?
>
> There are many possible reasons for that. The most likely is that the
> BIOS isn't bringing the chip back on resume, causing radeonfb to
> crash when trying to access it.
>
I assume from this:
> > Greetings,
> > Rafael
> >
> >
> > ---------- Forwarded Message ----------
> >
> > Subject: [Suspend-devel] resume not working on acer ferrari 4005 with radeonfb enabled
> > Date: Friday, 10 November 2006 20:44
> > From: "Christian Hoffmann" <[email protected]>
> > To: [email protected]
> >
> > Hello,
> >
> > when I have radeonfb enabled, my laptop (X700 ati mobility) doesnt resume
> > anymore. Screen stays black and nothing works anymore, no capslock light, no
^^^^^^^
that it's a regression, from some unknown-previous-kernel-version.
> > ctrl alt sysreq b etc. I tried all kind of things vbetool, passing
> > acpi_sleep=s3_bios,s3_mode to the kernel. Nothing seems to work.
> >
> > You can see dmesg output and lspci -vv output here
> > http://christianhoffmann.de/temp/radeon.log
> > http://christianhoffmann.de/temp/lspci.log
> >
> > Thanks a lot for any input.
> >
> > Chris
> >
> > PS: I use kernel 2.18.1 + patch for radeonfb from
> > http://bugzilla.kernel.org/attachment.cgi?id=9408&action=view
That's http://www.shaftnet.org/~pizza/radeonfb-atom-2.6.18-v6a.diff.
What happens when that patch isn't applied?
>There are many possible reasons for that. The most likely is that the
>BIOS isn't bringing the chip back on resume, causing radeonfb to
>crash when trying to access it.
>Ben.
Is there any possible workaround for this, or some tracing possible so
we can prove the hypothesis?
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.
-----Original Message-----
From: Andrew Morton [mailto:[email protected]]
Sent: Saturday, November 11, 2006 3:03 AM
To: Benjamin Herrenschmidt; Solomon Peachy
Cc: Rafael J. Wysocki; [email protected]; LKML;
[email protected]; [email protected]; Christian Hoffmann
Subject: Re: Fwd: [Suspend-devel] resume not working on acer ferrari
4005 with radeonfb enabled
On Sat, 11 Nov 2006 12:49:06 +1100
Benjamin Herrenschmidt <[email protected]> wrote:
> On Sat, 2006-11-11 at 00:31 +0100, Rafael J. Wysocki wrote:
> > Hi,
> >
> > We've just got the appended report. Could you please have a look at
this?
>
> There are many possible reasons for that. The most likely is that the
> BIOS isn't bringing the chip back on resume, causing radeonfb to
> crash when trying to access it.
>
I assume from this:
> > Greetings,
> > Rafael
> >
> >
> > ---------- Forwarded Message ----------
> >
> > Subject: [Suspend-devel] resume not working on acer ferrari 4005
with radeonfb enabled
> > Date: Friday, 10 November 2006 20:44
> > From: "Christian Hoffmann"
<[email protected]>
> > To: [email protected]
> >
> > Hello,
> >
> > when I have radeonfb enabled, my laptop (X700 ati mobility) doesnt
resume
> > anymore. Screen stays black and nothing works anymore, no capslock
light, no
^^^^^^^
>that it's a regression, from some unknown-previous-kernel-version.
> > ctrl alt sysreq b etc. I tried all kind of things vbetool, passing
> > acpi_sleep=s3_bios,s3_mode to the kernel. Nothing seems to work.
> >
> > You can see dmesg output and lspci -vv output here
> > http://christianhoffmann.de/temp/radeon.log
> > http://christianhoffmann.de/temp/lspci.log
> >
> > Thanks a lot for any input.
> >
> > Chris
> >
> > PS: I use kernel 2.18.1 + patch for radeonfb from
> > http://bugzilla.kernel.org/attachment.cgi?id=9408&action=view
>That's http://www.shaftnet.org/~pizza/radeonfb-atom-2.6.18-v6a.diff.
>What happens when that patch isn't applied?
Then the radeonfb doesn't kick in at all (guess some pci ids are added
in that patch).
BTW: resume/suspend works ok if I have the vesa fb enabled.
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.
On Sat, Nov 11, 2006 at 12:49:06PM +1100, Benjamin Herrenschmidt wrote:
> There are many possible reasons for that. The most likely is that the
> BIOS isn't bringing the chip back on resume, causing radeonfb to
> crash when trying to access it.
I have the same laptop, and it also crashes for me on resume when
radeonfb is loaded. However, it also crashes on a resume when radeonfb
*isn't* loaded, so I hardly considered that a regression. :)
> On Thu, Nov 09, 2006 at 07:50:17PM +0100, Christian Hoffmann wrote:
> > when I have radeonfb enabled, my laptop (X700 ati mobility) doesnt resume
> > anymore. Screen stays black and nothing works anymore, no capslock light, no
> > ctrl alt sysreq b etc. I tried all kind of things vbetool, passing
> > acpi_sleep=s3_bios,s3_mode to the kernel. Nothing seems to work.
...but it used to work? Now that's interesting; this is the first
report I've heard of a suspend-to-RAM (and subsequent resumes) working
on that machine.
> > You can see dmesg output and lspci -vv output here
> > http://christianhoffmann.de/temp/radeon.log
> > http://christianhoffmann.de/temp/lspci.log
Can you send the *full* bootup log, including the command lines you
used?
I noticed that you have the 'radeon' drm module loading too; that may be
causing problems. Are you running X when you try to suspend/resume?
Also, since you're using a Ferarri 4000, are you using the stock 3A23
BIOS/DSDT, or are you using the patched DSDT from http://acpi.sf.net?
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Melbourne, FL ^^ (mail/jabber/gtalk) ^^
Quidquid latine dictum sit, altum viditur. ICQ: 1318344
> Then the radeonfb doesn't kick in at all (guess some pci ids are 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 you
get console mode back and then X ? Or it only comes back when going back
to X ? Do you have some userland-type vbetool thingy that bring it
back ?
Ben.
Hi!
> > Then the radeonfb doesn't kick in at all (guess some pci ids are 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 you
> get console mode back and then X ? Or it only comes back when going back
> to X ? Do you have some userland-type vbetool thingy that bring it
> back ?
He's using s3_bios+s3_mode, so kernel does some BIOS calls to reinit
the video. It should come out in text mode, too.
Christian, can you unload radeonfb before suspend/reload it after
resume?
Next possibility is setting up serial console and adding some printks
to radeon...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sunday, 12 November 2006 13:13, Pavel Machek wrote:
> Hi!
>
> > > Then the radeonfb doesn't kick in at all (guess some pci ids are 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 you
> > get console mode back and then X ? Or it only comes back when going back
> > to X ? Do you have some userland-type vbetool thingy that bring it
> > back ?
>
> He's using s3_bios+s3_mode, so kernel does some BIOS calls to reinit
> the video. It should come out in text mode, too.
>
> Christian, can you unload radeonfb before suspend/reload it after
> resume?
>
> Next possibility is setting up serial console and adding some printks
> to radeon...
I guess this box has no serial ports, but netconsole should do (provided
there's another box nearby on which netcat can be run).
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
On Monday, 13 November 2006 11:51, Christian Hoffmann wrote:
>
> > -----Original Message-----
> > From: Pavel Machek [mailto:[email protected]]
> > Sent: Sunday, November 12, 2006 1:14 PM
> > To: Benjamin Herrenschmidt
> > Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael
> > J. Wysocki; [email protected]; LKML;
> > [email protected]; [email protected]
> > Subject: Re: Fwd: [Suspend-devel] resume not working on acer
> > ferrari 4005 with radeonfb enabled
> >
> > Hi!
> >
> > > > Then the radeonfb doesn't kick in at all (guess some pci ids are
> > > > 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
> > > you get console mode back and then X ? Or it only comes back when
> > > going back to X ? Do you have some userland-type vbetool
> > thingy that
> > > bring it back ?
> >
> > He's using s3_bios+s3_mode, so kernel does some BIOS calls to
> > reinit 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
> with that, but I'll try again.
>
> >
> > 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 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 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.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
> -----Original Message-----
> From: Pavel Machek [mailto:[email protected]]
> Sent: Sunday, November 12, 2006 1:14 PM
> To: Benjamin Herrenschmidt
> Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael
> J. Wysocki; [email protected]; LKML;
> [email protected]; [email protected]
> Subject: Re: Fwd: [Suspend-devel] resume not working on acer
> ferrari 4005 with radeonfb enabled
>
> Hi!
>
> > > Then the radeonfb doesn't kick in at all (guess some pci ids are
> > > 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
> > you get console mode back and then X ? Or it only comes back when
> > going back to X ? Do you have some userland-type vbetool
> thingy that
> > bring it back ?
>
> He's using s3_bios+s3_mode, so kernel does some BIOS calls to
> reinit 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
with that, but I'll try again.
>
> 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 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 web. (I tried with setconsole
/dev/ttyUSB0 but it gives error msg about device busy or something)
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.
Hi!
> > > > Then the radeonfb doesn't kick in at all (guess some pci ids are
> > > > 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
> > > you get console mode back and then X ? Or it only comes back when
> > > going back to X ? Do you have some userland-type vbetool
> > thingy that
> > > bring it back ?
> >
> > He's using s3_bios+s3_mode, so kernel does some BIOS calls to
> > reinit 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
> with that, but I'll try again.
I think it could. Be sure to compile vga text-mode support into
kernel.
--
Thanks, Sharp!
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:[email protected]]
> Sent: Monday, November 13, 2006 3:06 PM
> To: Christian Hoffmann
> Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
> Solomon Peachy; [email protected]; 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:
> >
> > > -----Original Message-----
> > > From: Pavel Machek [mailto:[email protected]]
> > > Sent: Sunday, November 12, 2006 1:14 PM
> > > To: Benjamin Herrenschmidt
> > > Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
> > > Wysocki; [email protected]; LKML;
> > > [email protected]; [email protected]
> > > Subject: Re: Fwd: [Suspend-devel] resume not working on
> acer ferrari
> > > 4005 with radeonfb enabled
> > >
> > > Hi!
> > >
> > > > > Then the radeonfb doesn't kick in at all (guess some
> pci ids are
> > > > > 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
> > > > you get console mode back and then X ? Or it only comes
> back when
> > > > going back to X ? Do you have some userland-type vbetool
> > > thingy that
> > > > bring it back ?
> > >
> > > He's using s3_bios+s3_mode, so kernel does some BIOS
> calls to reinit
> > > 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
> > with that, but I'll try again.
> >
> > >
> > > 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
> > 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
> > 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.
On Monday, 13 November 2006 23:08, Christian Hoffmann wrote:
>
> > -----Original Message-----
> > From: Rafael J. Wysocki [mailto:[email protected]]
> > Sent: Monday, November 13, 2006 3:06 PM
> > To: Christian Hoffmann
> > Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
> > Solomon Peachy; [email protected]; 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:
> > >
> > > > -----Original Message-----
> > > > From: Pavel Machek [mailto:[email protected]]
> > > > Sent: Sunday, November 12, 2006 1:14 PM
> > > > To: Benjamin Herrenschmidt
> > > > Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
> > > > Wysocki; [email protected]; LKML;
> > > > [email protected]; [email protected]
> > > > Subject: Re: Fwd: [Suspend-devel] resume not working on
> > acer ferrari
> > > > 4005 with radeonfb enabled
> > > >
> > > > Hi!
> > > >
> > > > > > Then the radeonfb doesn't kick in at all (guess some
> > pci ids are
> > > > > > 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
> > > > > you get console mode back and then X ? Or it only comes
> > back when
> > > > > going back to X ? Do you have some userland-type vbetool
> > > > thingy that
> > > > > bring it back ?
> > > >
> > > > He's using s3_bios+s3_mode, so kernel does some BIOS
> > calls to reinit
> > > > 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
> > > with that, but I'll try again.
> > >
> > > >
> > > > 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
> > > 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
> > > 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
On Tuesday 14 November 2006 00:08, Rafael J. Wysocki wrote:
> On Monday, 13 November 2006 23:08, Christian Hoffmann wrote:
> > > -----Original Message-----
> > > From: Rafael J. Wysocki [mailto:[email protected]]
> > > Sent: Monday, November 13, 2006 3:06 PM
> > > To: Christian Hoffmann
> > > Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
> > > Solomon Peachy; [email protected]; 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:
> > > > > -----Original Message-----
> > > > > From: Pavel Machek [mailto:[email protected]]
> > > > > Sent: Sunday, November 12, 2006 1:14 PM
> > > > > To: Benjamin Herrenschmidt
> > > > > Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
> > > > > Wysocki; [email protected]; LKML;
> > > > > [email protected]; [email protected]
> > > > > Subject: Re: Fwd: [Suspend-devel] resume not working on
> > >
> > > acer ferrari
> > >
> > > > > 4005 with radeonfb enabled
> > > > >
> > > > > Hi!
> > > > >
> > > > > > > Then the radeonfb doesn't kick in at all (guess some
> > >
> > > pci ids are
> > >
> > > > > > > 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
> > > > >
> > > > > > you get console mode back and then X ? Or it only comes
> > >
> > > back when
> > >
> > > > > > going back to X ? Do you have some userland-type vbetool
> > > > >
> > > > > thingy that
> > > > >
> > > > > > bring it back ?
> > > > >
> > > > > He's using s3_bios+s3_mode, so kernel does some BIOS
> > >
> > > calls to reinit
> > >
> > > > > 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
> > >
> > > > with that, but I'll try again.
> > > >
> > > > > 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
> > >
> > > > 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
> > >
> > > > 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
On Tuesday 14 November 2006 00:08, Rafael J. Wysocki wrote:
> On Monday, 13 November 2006 23:08, Christian Hoffmann wrote:
> > > -----Original Message-----
> > > From: Rafael J. Wysocki [mailto:[email protected]]
> > > Sent: Monday, November 13, 2006 3:06 PM
> > > To: Christian Hoffmann
> > > Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
> > > Solomon Peachy; [email protected]; 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:
> > > > > -----Original Message-----
> > > > > From: Pavel Machek [mailto:[email protected]]
> > > > > Sent: Sunday, November 12, 2006 1:14 PM
> > > > > To: Benjamin Herrenschmidt
> > > > > Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
> > > > > Wysocki; [email protected]; LKML;
> > > > > [email protected]; [email protected]
> > > > > Subject: Re: Fwd: [Suspend-devel] resume not working on
> > >
> > > acer ferrari
> > >
> > > > > 4005 with radeonfb enabled
> > > > >
> > > > > Hi!
> > > > >
> > > > > > > Then the radeonfb doesn't kick in at all (guess some
> > >
> > > pci ids are
> > >
> > > > > > > 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
> > > > >
> > > > > > you get console mode back and then X ? Or it only comes
> > >
> > > back when
> > >
> > > > > > going back to X ? Do you have some userland-type vbetool
> > > > >
> > > > > thingy that
> > > > >
> > > > > > bring it back ?
> > > > >
> > > > > He's using s3_bios+s3_mode, so kernel does some BIOS
> > >
> > > calls to reinit
> > >
> > > > > 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
> > >
> > > > with that, but I'll try again.
> > > >
> > > > > 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
> > >
> > > > 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
> > >
> > > > 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
>
> 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.
On Tuesday, 14 November 2006 22:47, Christian Hoffmann wrote:
> On Tuesday 14 November 2006 00:08, Rafael J. Wysocki wrote:
> > On Monday, 13 November 2006 23:08, Christian Hoffmann wrote:
> > > > -----Original Message-----
> > > > From: Rafael J. Wysocki [mailto:[email protected]]
> > > > Sent: Monday, November 13, 2006 3:06 PM
> > > > To: Christian Hoffmann
> > > > Cc: Pavel Machek; Benjamin Herrenschmidt; Andrew Morton;
> > > > Solomon Peachy; [email protected]; 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:
> > > > > > -----Original Message-----
> > > > > > From: Pavel Machek [mailto:[email protected]]
> > > > > > Sent: Sunday, November 12, 2006 1:14 PM
> > > > > > To: Benjamin Herrenschmidt
> > > > > > Cc: Christian Hoffmann; Andrew Morton; Solomon Peachy; Rafael J.
> > > > > > Wysocki; [email protected]; LKML;
> > > > > > [email protected]; [email protected]
> > > > > > Subject: Re: Fwd: [Suspend-devel] resume not working on
> > > >
> > > > acer ferrari
> > > >
> > > > > > 4005 with radeonfb enabled
> > > > > >
> > > > > > Hi!
> > > > > >
> > > > > > > > Then the radeonfb doesn't kick in at all (guess some
> > > >
> > > > pci ids are
> > > >
> > > > > > > > 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
> > > > > >
> > > > > > > you get console mode back and then X ? Or it only comes
> > > >
> > > > back when
> > > >
> > > > > > > going back to X ? Do you have some userland-type vbetool
> > > > > >
> > > > > > thingy that
> > > > > >
> > > > > > > bring it back ?
> > > > > >
> > > > > > He's using s3_bios+s3_mode, so kernel does some BIOS
> > > >
> > > > calls to reinit
> > > >
> > > > > > 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
> > > >
> > > > > with that, but I'll try again.
> > > > >
> > > > > > 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
> > > >
> > > > > 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
> > > >
> > > > > 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
Hi!
> > > 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.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tuesday, 14 November 2006 23:56, Pavel Machek wrote:
> Hi!
>
> > > > 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
On Tue 2006-11-14 23:57:59, Rafael J. Wysocki wrote:
> On Tuesday, 14 November 2006 23:56, Pavel Machek wrote:
> > Hi!
> >
> > > > > 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.
Ok, so you could debug it on i386 kernel :-). Actually trying if s2ram
works in 32-bit mode _would_ be interesting.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tuesday 14 November 2006 23:07, Benjamin Herrenschmidt wrote:
> > 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
On Wed, 2006-11-15 at 01:54 +0100, Christian Hoffmann wrote:
> On Tuesday 14 November 2006 23:07, Benjamin Herrenschmidt wrote:
> > > 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.
On Wednesday, 15 November 2006 02:48, Benjamin Herrenschmidt wrote:
> On Wed, 2006-11-15 at 01:54 +0100, Christian Hoffmann wrote:
> > On Tuesday 14 November 2006 23:07, Benjamin Herrenschmidt wrote:
> > > > 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
> >
> > 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
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
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
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:
> > 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.
On Fri, Nov 17, 2006 at 05:17:00PM +1100, Benjamin Herrenschmidt wrote:
> > 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
On Fri, Nov 17, 2006 at 01:07:58AM -0500, Stuffed Crust wrote:
> http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.19-v7-WIP1.diff
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
On Friday 17 November 2006 16:41, Stuffed Crust wrote:
> On Fri, Nov 17, 2006 at 01:07:58AM -0500, Stuffed Crust wrote:
> > http://www.shaftnet.org/users/pizza/radeonfb-atom-2.6.19-v7-WIP1.diff
>
> 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
> 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.
> 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.
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:[email protected]]
> Sent: Friday, November 17, 2006 10:59 PM
> To: Christian Hoffmann
> Cc: Stuffed Crust; Rafael J. Wysocki;
> [email protected]; Christian Hoffmann;
> Andrew Morton; LKML; Pavel Machek
> Subject: Re: [Linux-fbdev-devel] Fwd: [Suspend-devel] resume
> not working onacer ferrari 4005 with radeonfb enabled
>
>
> > 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
> 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.