Re: [BUG] nvidia vga card is missed after S3

On Friday, 28 of March 2008, Shaohua Li wrote:
> Still in ASUS A6VC laptop (linux is quite broken in the system). If
> 'pm_restore_console()' is called the video card (03:00.0, Nevidia Go
> 6200/6400, it hasn't a driver) pci config space read is messy (some are
> 0xffffffff, others are 0). If I comment pm_restore_console(), then
> everything is fine. Anything I can provide to debug the issue?

Hmm.  Do you suspend the box from under X or crom the console?

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] nvidia vga card is missed after S3

On Tue, 2008-04-01 at 01:02 +0200, Rafael J. Wysocki wrote:
> On Friday, 28 of March 2008, Shaohua Li wrote:
> > Still in ASUS A6VC laptop (linux is quite broken in the system). If
> > 'pm_restore_console()' is called the video card (03:00.0, Nevidia Go
> > 6200/6400, it hasn't a driver) pci config space read is messy (some are
> > 0xffffffff, others are 0). If I comment pm_restore_console(), then
> > everything is fine. Anything I can provide to debug the issue?
> 
> Hmm.  Do you suspend the box from under X or crom the console?
from console.

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 6)

Hi Rafael.

Please excuse me, but I'm going to ask the questions you get from
someone who hasn't followed development to date, and is thus reading the
explanation without prior knowledge. Hopefully that will be helpful when
you come to finalising the commit message.

On Mon, 2008-03-31 at 23:29 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rjw <at> sisk.pl>
> 
> Introduce 'struct pm_ops' and 'struct pm_ext_ops' representing
> suspend and hibernation operations for bus types, device classes and
> device types.

Does ..._ext_... mean extended? (external?) If 'extended' (or if not),
does that imply that they're mutually exclusive alternatives for drivers
to use?

> Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
> objects, if defined, instead of the ->suspend() and ->resume() or,
> respectively, ->suspend_late() and ->resume_early() callbacks that
> will be considered as legacy and gradually phased out.

'Respectively' doesn't look like the right word to use, but I'm not sure
I understand correctly what you're trying to say. The way it's written
at the moment, it sounds to me like you're saying that suspend_late()
and resume_early are deprecated, but you're modifying the PM core to use
them.

> Change the behavior of the PM core wrt the error codes returned by

Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 6)

On Tue, 2008-04-01 at 19:15 +1100, Nigel Cunningham wrote:
> > + *   However, drivers may NOT assume anything about the availability of the
> > + *   user space at that time and it is not correct to request firmware from
> > + *   within  <at> prepare() (it's too late to do that).
> 
> That doesn't sound good. It would be good to be able to get drivers to
> request firmware early in the process.

Agreed. Prepare() should still allow request_firmware and full userspace
communication / helper usage.

> > + *  <at> complete: Undo the changes made by  <at> prepare().  This method is executed for
> > + *   all kinds of resume transitions, following one of the resume callbacks:
> > + *    <at> resume(),  <at> thaw(),  <at> restore().  Also called if the state transition
> > + *   fails before the driver's suspend callback ( <at> suspend(),  <at> freeze(),
> > + *    <at> poweroff()) can be executed (e.g. if the suspend callback fails for one
> > + *   of the other devices that the PM core has unsucessfully attempted to

Ben.

Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 6)

> On Sunday, 30 of March 2008, Rafael J. Wysocki wrote:
> > On Saturday, 29 of March 2008, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rjw <at> sisk.pl>
> > > 
> > > Introduce 'struct pm_ops' and 'struct pm_ext_ops' representing
> > > suspend and hibernation operations for bus types, device classes and
> > > device types.
> > > 
> > > Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
> > > objects, if defined, instead of the ->suspend() and ->resume() or,
> > > respectively, ->suspend_late() and ->resume_early() callbacks that
> > > will be considered as legacy and gradually phased out.
> > 
> > Unfortunately I forgot to set dev->power.status to DPM_PREPARING before
> > calling ->prepare(), as documented.  Also, dpm_prepare() could cleaned up
> > a bit.
> > 
> > Fixed patch follows.
> 
> My testing shows that some drivers tend to return error codes from their
> ->resume() callbacks, even though the devices in question appear to work
> correctly after the seemingly failing suspend.

The drivers should be fixed not to do that, no?

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in

Re: [PATCH] ACPI PM: Restore the 2.6.24 suspend ordering

Hi!

> > > > > For the reasons outlined above, the change of the suspend ordering
> > > > > should be reverted, which is done by the patch below.
> > > > 
> > > > But this will break those few nvidia-based systems, no?
> > > > 
> > > > this may have been a good idea in -rc1 days, but we are in -rc7
> > > > now... and the patch is slightly big.
> > > 
> > > It's quite obvious, though.
> > 
> > Yes, but breaking systems between -rc7 and final is _very_ unnice.
> 
> Breaking systems between 2.6.24 and 2.6.25 is even worse, which is why
> I've posted this patch.
> 
> IOW, we tried to fix systems that were broken with 2.6.24, but it didn't work,
> because our "fix" broke systems that were OK with 2.6.24.  Solution: revert
> the "fix" and go back to the design board.  That's all we can do so late in
> the release cycle, IMO.

Well, I agree that regression from 2.6.24 is worse, but it is
_slightly_ worse... -rcs are really expected to improve...

...plus it no longer looks like macbook regression is caused by _PTS
ordering?

> > > I think we _can_ do something about the failing NVidia systems in the 2.6.26
> > > time frame, but that will require some more consideration.

Re: [patch 00/37] PNP resource_table cleanups

On 31-03-08 23:38, Rene Herman wrote:
> On 31-03-08 22:51, Bjorn Helgaas wrote:
> 
>> Ah, right.  Thanks for tracking that down.  I forgot to factor out
>> isapnp_to_pnpid() and pnpid32_to_pnpid() (and acpi_ex_eisa_id_to_string()
>> for that matter, though that's buried in the ACPI CA)-- they're really
>> doing the same thing and we should only need one copy (plus the CA
>> one).
> 
> I'll wait for another round then, before reviewing this further.

There's actually a hex_asc() helper in kernel.h, so before you overlook it 
as well, this is a somewhat nicer ID fix.

Rene.

commit cfed76bc2a76f2094338bc43dae55aa814017b5f
Author: Rene Herman <rene.herman <at> gmail.com>
Date:   Tue Apr 1 12:03:15 2008 +0200

    [ISAPNP] fix isapnp_to_pnpid

diff --git a/drivers/pnp/isapnp/core.c b/drivers/pnp/isapnp/core.c
index c4b95b5..9727050 100644
--- a/drivers/pnp/isapnp/core.c
+++ b/drivers/pnp/isapnp/core.c
 <at>  <at>  -406,11 +406,11  <at>  <at>  static void isapnp_to_pnpid(unsigned short vendor, unsigned short device,
 	id[0] = 'A' + ((vendor >> 2) & 0x3f) - 1;
 	id[1] = 'A' + (((vendor & 3) << 3) | ((vendor >> 13) & 7)) - 1;

Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 6)

On Tue, 1 Apr 2008, Benjamin Herrenschmidt wrote:

> On Tue, 2008-04-01 at 19:15 +1100, Nigel Cunningham wrote:
> > > + *   However, drivers may NOT assume anything about the availability of the
> > > + *   user space at that time and it is not correct to request firmware from
> > > + *   within  <at> prepare() (it's too late to do that).
> > 
> > That doesn't sound good. It would be good to be able to get drivers to
> > request firmware early in the process.
> 
> Agreed. Prepare() should still allow request_firmware and full userspace
> communication / helper usage.

Pepare() is called after userspace has been frozen.  (Of course, once 
the freezer goes away this won't matter any more.)

There is a separate notifier chain which drivers can subscribe to;
notifications about impending sleeps are sent out while userspace is
still alive.  Drivers can use that for request_firmware, memory
allocation, and other things.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ACPI PM: Restore the 2.6.24 suspend ordering

Hi,
>>>>>> For the reasons outlined above, the change of the suspend ordering
>>>>>> should be reverted, which is done by the patch below.
>>>>> But this will break those few nvidia-based systems, no?
>>>>>
>>>>> this may have been a good idea in -rc1 days, but we are in -rc7
>>>>> now... and the patch is slightly big.
>>>> It's quite obvious, though.
>>> Yes, but breaking systems between -rc7 and final is _very_ unnice.
>> Breaking systems between 2.6.24 and 2.6.25 is even worse, which is why
>> I've posted this patch.
>>
>> IOW, we tried to fix systems that were broken with 2.6.24, but it didn't work,
>> because our "fix" broke systems that were OK with 2.6.24.  Solution: revert
>> the "fix" and go back to the design board.  That's all we can do so late in
>> the release cycle, IMO.
> 
> Well, I agree that regression from 2.6.24 is worse, but it is
> _slightly_ worse... -rcs are really expected to improve...
> 
> ...plus it no longer looks like macbook regression is caused by _PTS
> ordering?
I am the reporter from the original Novell Bug: 
https://bugzilla.novell.com/show_bug.cgi?id=374217

I just tried current git head (two hours ago) with the patch (the one 
from the beginning of this thread) from Rafael and without it. With the 
patch my MacBook does suspend without it does not.

HTH

Re: [patch 00/37] PNP resource_table cleanups

On Tuesday 01 April 2008 04:16:10 am Rene Herman wrote:
> On 31-03-08 23:38, Rene Herman wrote:
> > On 31-03-08 22:51, Bjorn Helgaas wrote:
> > 
> >> Ah, right.  Thanks for tracking that down.  I forgot to factor out
> >> isapnp_to_pnpid() and pnpid32_to_pnpid() (and acpi_ex_eisa_id_to_string()
> >> for that matter, though that's buried in the ACPI CA)-- they're really
> >> doing the same thing and we should only need one copy (plus the CA
> >> one).
> > 
> > I'll wait for another round then, before reviewing this further.
> 
> There's actually a hex_asc() helper in kernel.h, so before you overlook it 
> as well, this is a somewhat nicer ID fix.

Thanks, I didn't know about hex_asc()!  I'll post v2 of the series today.
And thanks a lot for finding those typos in resource.c.  I never would
have found those...

Bjorn