On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
such as Fn-F4 and lid open/close, prints them in /var/log/acpid
and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
This no longer happens in 2.6.25-rc3: I see nothing in /var/log/acpid
after power on:
[Mon Feb 25 20:47:28 2008] completed event "button/power PWRF 00000080 00000001"
[Mon Feb 25 20:48:44 2008] starting up
[Mon Feb 25 20:48:44 2008] 57 rules loaded
[Mon Feb 25 20:48:48 2008] client connected from 5927[0:0]
[Mon Feb 25 20:48:48 2008] 1 client rule loaded
and pressing buttons or closing lid produces no output in
/var/log/acpid and seems to have no effect.
git bisect pointed at commit 208c70a45624400fafd7511b96bc426bf01f8f5e :
ACPI: EC: Use proper handle for boot EC
If I do git revert 208c70a45624400fafd7511b96bc426bf01f8f5e on top
of 2.6.25-rc3, I start getting keyboard acpi events, again.
Thanks,
MST
PS: I see a different problem on resume, it seems to be unrelated to ACPI
and I will bisect and report separately.
PPS: Pls Cc me directly, I am not on the list.
Michael S. Tsirkin wrote:
> On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
> such as Fn-F4 and lid open/close, prints them in /var/log/acpid
> and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
>
> This no longer happens in 2.6.25-rc3: I see nothing in /var/log/acpid
> after power on:
> [Mon Feb 25 20:47:28 2008] completed event "button/power PWRF 00000080 00000001"
> [Mon Feb 25 20:48:44 2008] starting up
> [Mon Feb 25 20:48:44 2008] 57 rules loaded
> [Mon Feb 25 20:48:48 2008] client connected from 5927[0:0]
> [Mon Feb 25 20:48:48 2008] 1 client rule loaded
>
> and pressing buttons or closing lid produces no output in
> /var/log/acpid and seems to have no effect.
>
> git bisect pointed at commit 208c70a45624400fafd7511b96bc426bf01f8f5e :
> ACPI: EC: Use proper handle for boot EC
>
> If I do git revert 208c70a45624400fafd7511b96bc426bf01f8f5e on top
> of 2.6.25-rc3, I start getting keyboard acpi events, again.
Could you please create a bug report and attach acpidump?
Thanks,
Alex.
>
>
> Thanks,
> MST
>
> PS: I see a different problem on resume, it seems to be unrelated to ACPI
> and I will bisect and report separately.
>
> PPS: Pls Cc me directly, I am not on the list.
On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
> On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
> such as Fn-F4 and lid open/close, prints them in /var/log/acpid
> and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
You mean suspend-to-ram works correctly on your t61p?
Mine suspends, then five seconds later magically resumes itself and the
screen is all black.
On Mon, Feb 25, 2008 at 9:42 PM, Alexey Starikovskiy
<[email protected]> wrote:
> Michael S. Tsirkin wrote:
> > On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
> > such as Fn-F4 and lid open/close, prints them in /var/log/acpid
> > and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
> >
> > This no longer happens in 2.6.25-rc3: I see nothing in /var/log/acpid
> > after power on:
> > [Mon Feb 25 20:47:28 2008] completed event "button/power PWRF 00000080 00000001"
> > [Mon Feb 25 20:48:44 2008] starting up
> > [Mon Feb 25 20:48:44 2008] 57 rules loaded
> > [Mon Feb 25 20:48:48 2008] client connected from 5927[0:0]
> > [Mon Feb 25 20:48:48 2008] 1 client rule loaded
> >
> > and pressing buttons or closing lid produces no output in
> > /var/log/acpid and seems to have no effect.
> >
> > git bisect pointed at commit 208c70a45624400fafd7511b96bc426bf01f8f5e :
> > ACPI: EC: Use proper handle for boot EC
> >
> > If I do git revert 208c70a45624400fafd7511b96bc426bf01f8f5e on top
> > of 2.6.25-rc3, I start getting keyboard acpi events, again.
> Could you please create a bug report
Did you guys stop accepting reports by mail?
I hope not.
> and attach acpidump?
I'll see if I can get acpidump output - in which state do you want it?
Right after boot on the broken kernel?
> Thanks,
> Alex.
>
>
> >
> >
> > Thanks,
> > MST
> >
> > PS: I see a different problem on resume, it seems to be unrelated to ACPI
> > and I will bisect and report separately.
> >
> > PPS: Pls Cc me directly, I am not on the list.
>
>
On Mon, Feb 25, 2008 at 9:46 PM, Andrew Morton
<[email protected]> wrote:
> On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
>
> > On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
> > such as Fn-F4 and lid open/close, prints them in /var/log/acpid
> > and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
>
> You mean suspend-to-ram works correctly on your t61p?
>
> Mine suspends, then five seconds later magically resumes itself and the
> screen is all black.
>
>
I see the resume problems too, but they do not seem to be acpi-related
(IOW, there are 2 issues). I just finished bisecting and intend to
report shortly.
On Mon, Feb 25, 2008 at 9:46 PM, Andrew Morton
<[email protected]> wrote:
> On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
>
> > On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
> > such as Fn-F4 and lid open/close, prints them in /var/log/acpid
> > and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
>
> You mean suspend-to-ram works correctly on your t61p?
>
> Mine suspends, then five seconds later magically resumes itself and the
> screen is all black.
Sorry, have not noticed what you were asking about.
Yes, rc2 seems to suspend/resume fine.
And after reverting
revert commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2.
revert commit 208c70a45624400fafd7511b96bc426bf01f8f5e.
r3 does, too.
I just waited a couple of minutes after suspend to ram and it stays suspended.
On Monday, 25 of February 2008, Michael S. Tsirkin wrote:
> On Mon, Feb 25, 2008 at 9:46 PM, Andrew Morton
> <[email protected]> wrote:
> > On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
> >
> > > On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
> > > such as Fn-F4 and lid open/close, prints them in /var/log/acpid
> > > and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
> >
> > You mean suspend-to-ram works correctly on your t61p?
> >
> > Mine suspends, then five seconds later magically resumes itself and the
> > screen is all black.
>
> Sorry, have not noticed what you were asking about.
> Yes, rc2 seems to suspend/resume fine.
>
> And after reverting
>
> revert commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2.
commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
Author: Pavel Machek <[email protected]>
Date: Thu Feb 21 13:56:55 2008 +0100
power_state: get rid of write-only variable in SATA
> revert commit 208c70a45624400fafd7511b96bc426bf01f8f5e.
commit 208c70a45624400fafd7511b96bc426bf01f8f5e
Author: Alexey Starikovskiy <[email protected]>
Date: Thu Feb 14 15:58:47 2008 -0500
ACPI: EC: Use proper handle for boot EC
> r3 does, too.
Please, _please_ always add commit subjects to your reports. Also, please
include the names of the authors of the commits that turn out to break things
and send CCs to them.
It won't hurt to send CCs to the people who signed those commits off, too.
Thanks,
Rafael
On Mon, Feb 25, 2008 at 10:50 PM, Alexey Starikovskiy
<[email protected]> wrote:
> Michael S. Tsirkin wrote:
> > Did you guys stop accepting reports by mail?
> > I hope not.
> It is easier to track bug information in bugzilla.
> If you for some reason do not wish to create a bug report,
> I can do it for you. You only need to provide acpidump.
Great.
> >
> >> and attach acpidump?
> >
> > I'll see if I can get acpidump output - in which state do you want it?
> > Right after boot on the broken kernel?
> acpidump output does not change over time, you could get it even with some other kernel.
>
>
Attached is the acpidump output run under 2.6.23-rc3 + with reverted
37f9b4c7c612fcbeb8fb6faddaef4ccdb5350145
(IOW - this is a working configuration).
HTH,
MST
Michael S. Tsirkin wrote:
> Did you guys stop accepting reports by mail?
> I hope not.
It is easier to track bug information in bugzilla.
If you for some reason do not wish to create a bug report,
I can do it for you. You only need to provide acpidump.
>
>> and attach acpidump?
>
> I'll see if I can get acpidump output - in which state do you want it?
> Right after boot on the broken kernel?
acpidump output does not change over time, you could get it even with some other kernel.
Hi!
> On Monday, 25 of February 2008, Michael S. Tsirkin wrote:
> > On Mon, Feb 25, 2008 at 9:46 PM, Andrew Morton
> > <[email protected]> wrote:
> > > On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
> > >
> > > > On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
> > > > such as Fn-F4 and lid open/close, prints them in /var/log/acpid
> > > > and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
> > >
> > > You mean suspend-to-ram works correctly on your t61p?
> > >
> > > Mine suspends, then five seconds later magically resumes itself and the
> > > screen is all black.
> >
> > Sorry, have not noticed what you were asking about.
> > Yes, rc2 seems to suspend/resume fine.
> >
> > And after reverting
> >
> > revert commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2.
>
> commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
> Author: Pavel Machek <[email protected]>
> Date: Thu Feb 21 13:56:55 2008 +0100
>
> power_state: get rid of write-only variable in SATA
This is pretty unlikely to be it. Can you double check that this patch
really breaks something?
> > revert commit 208c70a45624400fafd7511b96bc426bf01f8f5e.
>
> commit 208c70a45624400fafd7511b96bc426bf01f8f5e
> Author: Alexey Starikovskiy <[email protected]>
> Date: Thu Feb 14 15:58:47 2008 -0500
>
> ACPI: EC: Use proper handle for boot EC
>
> > r3 does, too.
>
> Please, _please_ always add commit subjects to your reports. Also, please
> include the names of the authors of the commits that turn out to break things
> and send CCs to them.
>
> It won't hurt to send CCs to the people who signed those commits off, too.
Hmm, as EC is the piece of hw that does the wakeups, yes, EC might be
responsible for autowaking.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Feb 25, 2008 at 11:26 PM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>
> > On Monday, 25 of February 2008, Michael S. Tsirkin wrote:
> > > On Mon, Feb 25, 2008 at 9:46 PM, Andrew Morton
> > > <[email protected]> wrote:
> > > > On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
> > > >
> > > > > On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
> > > > > such as Fn-F4 and lid open/close, prints them in /var/log/acpid
> > > > > and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
> > > >
> > > > You mean suspend-to-ram works correctly on your t61p?
> > > >
> > > > Mine suspends, then five seconds later magically resumes itself and the
> > > > screen is all black.
> > >
> > > Sorry, have not noticed what you were asking about.
> > > Yes, rc2 seems to suspend/resume fine.
> > >
> > > And after reverting
> > >
> > > revert commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2.
> >
> > commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
> > Author: Pavel Machek <[email protected]>
> > Date: Thu Feb 21 13:56:55 2008 +0100
> >
> > power_state: get rid of write-only variable in SATA
>
> This is pretty unlikely to be it. Can you double check that this patch
> really breaks something?
I did and it seems to: just reverting
559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 fixes resume for me.
635adc28087ced0c843d2ecb6d4ae474d0e611cd which is
559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2~1
also resumes fine.
>
> > > revert commit 208c70a45624400fafd7511b96bc426bf01f8f5e.
> >
> > commit 208c70a45624400fafd7511b96bc426bf01f8f5e
> > Author: Alexey Starikovskiy <[email protected]>
> > Date: Thu Feb 14 15:58:47 2008 -0500
> >
> > ACPI: EC: Use proper handle for boot EC
> >
> > > r3 does, too.
> >
> > Please, _please_ always add commit subjects to your reports. Also, please
> > include the names of the authors of the commits that turn out to break things
> > and send CCs to them.
> >
> > It won't hurt to send CCs to the people who signed those commits off, too.
>
> Hmm, as EC is the piece of hw that does the wakeups, yes, EC might be
> responsible for autowaking.
> Pavel
As far as I can tell, nope, reverting
208c70a45624400fafd7511b96bc426bf01f8f5e fixes acpi
keyboard/lid events but does fix resume from suspend to ram for me.
Pavel Machek wrote:
>> commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
>> Author: Pavel Machek <[email protected]>
>> Date: Thu Feb 21 13:56:55 2008 +0100
>>
>> power_state: get rid of write-only variable in SATA
>
> This is pretty unlikely to be it. Can you double check that this patch
> really breaks something?
Quote...
After reverting 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
on top of 2.6.25-rc3 the kernel again resumes from suspend to
ram.
Seems pretty clear to me.
Jeff
Hi!
> > > commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
> > > Author: Pavel Machek <[email protected]>
> > > Date: Thu Feb 21 13:56:55 2008 +0100
> > >
> > > power_state: get rid of write-only variable in SATA
> >
> > This is pretty unlikely to be it. Can you double check that this patch
> > really breaks something?
>
> I did and it seems to: just reverting
> 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 fixes resume for me.
> 635adc28087ced0c843d2ecb6d4ae474d0e611cd which is
> 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2~1
> also resumes fine.
Hmm, I guess that should teach me about "simple cleanups".
Do you use any of:
ata/sata_inic162x.c
ata/sata_nv.c
ata/sata_sil24.c
by chance?
(Ok, the patch is very safe to revert, it was "cleanup", it fixes
nothing).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Feb 25, 2008 at 11:50 PM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>
> > > > commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
> > > > Author: Pavel Machek <[email protected]>
> > > > Date: Thu Feb 21 13:56:55 2008 +0100
> > > >
> > > > power_state: get rid of write-only variable in SATA
> > >
> > > This is pretty unlikely to be it. Can you double check that this patch
> > > really breaks something?
> >
> > I did and it seems to: just reverting
> > 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 fixes resume for me.
> > 635adc28087ced0c843d2ecb6d4ae474d0e611cd which is
> > 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2~1
> > also resumes fine.
>
> Hmm, I guess that should teach me about "simple cleanups".
>
> Do you use any of:
>
> ata/sata_inic162x.c
> ata/sata_nv.c
> ata/sata_sil24.c
>
> by chance?
I don't think so.
Here are the only 3 ata modules I have built:
drivers/ata/ahci.ko
drivers/ata/ata_piix.ko
drivers/ata/libata.ko
ahci.c seems to look at power_state.
static int ahci_pci_device_resume(struct pci_dev *pdev)
{
struct ata_host *host = dev_get_drvdata(&pdev->dev);
int rc;
rc = ata_pci_device_do_resume(pdev);
if (rc)
return rc;
if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
rc = ahci_reset_controller(host);
if (rc)
return rc;
ahci_init_controller(host);
}
ata_host_resume(host);
return 0;
}
Right?
> (Ok, the patch is very safe to revert, it was "cleanup", it fixes
> nothing).
>
>
> Pavel
Hi!
> > > > > commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
> > > > > Author: Pavel Machek <[email protected]>
> > > > > Date: Thu Feb 21 13:56:55 2008 +0100
> > > > >
> > > > > power_state: get rid of write-only variable in SATA
> > > >
> > > > This is pretty unlikely to be it. Can you double check that this patch
> > > > really breaks something?
> > >
> > > I did and it seems to: just reverting
> > > 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 fixes resume for me.
> > > 635adc28087ced0c843d2ecb6d4ae474d0e611cd which is
> > > 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2~1
> > > also resumes fine.
> >
> > Hmm, I guess that should teach me about "simple cleanups".
> >
> > Do you use any of:
> >
> > ata/sata_inic162x.c
> > ata/sata_nv.c
> > ata/sata_sil24.c
> >
> > by chance?
>
> I don't think so.
> Here are the only 3 ata modules I have built:
> drivers/ata/ahci.ko
> drivers/ata/ata_piix.ko
> drivers/ata/libata.ko
>
>
> ahci.c seems to look at power_state.
>
> static int ahci_pci_device_resume(struct pci_dev *pdev)
> {
> struct ata_host *host = dev_get_drvdata(&pdev->dev);
> int rc;
>
> rc = ata_pci_device_do_resume(pdev);
> if (rc)
> return rc;
>
> if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
> rc = ahci_reset_controller(host);
> if (rc)
> return rc;
>
> ahci_init_controller(host);
> }
> Right?
Hmm, mystery partly solved... as you guessed it, this piece of code
was not in my tree.
(still, how can this cause autoresume after 5 seconds is a mystery to
me).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon 2008-02-25 16:32:38, Jeff Garzik wrote:
> Pavel Machek wrote:
>>> commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
>>> Author: Pavel Machek <[email protected]>
>>> Date: Thu Feb 21 13:56:55 2008 +0100
>>>
>>> power_state: get rid of write-only variable in SATA
>>
>> This is pretty unlikely to be it. Can you double check that this patch
>> really breaks something?
>
> Quote...
>
> After reverting 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
> on top of 2.6.25-rc3 the kernel again resumes from suspend to
> ram.
>
> Seems pretty clear to me.
Yep, that patch was crappy. I developed it on machine with SCSI
powersave patches applied, and did not realize this code
changed. Sorry.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Michael S. Tsirkin wrote:
> On Mon, Feb 25, 2008 at 10:50 PM, Alexey Starikovskiy
> <[email protected]> wrote:
>> Michael S. Tsirkin wrote:
>> > Did you guys stop accepting reports by mail?
>> > I hope not.
>> It is easier to track bug information in bugzilla.
>> If you for some reason do not wish to create a bug report,
>> I can do it for you. You only need to provide acpidump.
>
> Great.
>
>> >> and attach acpidump?
>> >
>> > I'll see if I can get acpidump output - in which state do you want it?
>> > Right after boot on the broken kernel?
>> acpidump output does not change over time, you could get it even with some other kernel.
>>
>>
>
> Attached is the acpidump output run under 2.6.23-rc3 + with reverted
> 37f9b4c7c612fcbeb8fb6faddaef4ccdb5350145
> (IOW - this is a working configuration).
Thanks, you've got round 10100 bug number.
Please check if the following patch on top of Linus git tree helps.
Regards,
Alex
>
> HTH,
> MST
>
On Tue, Feb 26, 2008 at 12:20 AM, Pavel Machek <[email protected]> wrote:
>
> Hi!
>
> > > > > > commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
> > > > > > Author: Pavel Machek <[email protected]>
> > > > > > Date: Thu Feb 21 13:56:55 2008 +0100
> > > > > >
> > > > > > power_state: get rid of write-only variable in SATA
> > > > >
> > > > > This is pretty unlikely to be it. Can you double check that this patch
> > > > > really breaks something?
> > > >
> > > > I did and it seems to: just reverting
> > > > 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 fixes resume for me.
> > > > 635adc28087ced0c843d2ecb6d4ae474d0e611cd which is
> > > > 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2~1
> > > > also resumes fine.
> > >
> > > Hmm, I guess that should teach me about "simple cleanups".
> > >
> > > Do you use any of:
> > >
> > > ata/sata_inic162x.c
> > > ata/sata_nv.c
> > > ata/sata_sil24.c
> > >
> > > by chance?
> >
> > I don't think so.
> > Here are the only 3 ata modules I have built:
> > drivers/ata/ahci.ko
> > drivers/ata/ata_piix.ko
> > drivers/ata/libata.ko
> >
> >
> > ahci.c seems to look at power_state.
> >
> > static int ahci_pci_device_resume(struct pci_dev *pdev)
> > {
> > struct ata_host *host = dev_get_drvdata(&pdev->dev);
> > int rc;
> >
> > rc = ata_pci_device_do_resume(pdev);
> > if (rc)
> > return rc;
> >
> > if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
> > rc = ahci_reset_controller(host);
> > if (rc)
> > return rc;
> >
> > ahci_init_controller(host);
> > }
>
> > Right?
>
> Hmm, mystery partly solved... as you guessed it, this piece of code
> was not in my tree.
>
> (still, how can this cause autoresume after 5 seconds is a mystery to
> me).
>
>
> Pavel
Maybe it doesn't. Andrew saw the autoresume on -rc[2,3], I didn't.
For me, it causes resume to fail.
On Tue, 26 Feb 2008 00:36:54 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
> > Hmm, mystery partly solved... as you guessed it, this piece of code
> > was not in my tree.
> >
> > (still, how can this cause autoresume after 5 seconds is a mystery to
> > me).
> >
> >
> > Pavel
>
> Maybe it doesn't. Andrew saw the autoresume on -rc[2,3]
And earlier - I think 2.6.23 does it as well.
On Tue, Feb 26, 2008 at 12:39 AM, Andrew Morton
<[email protected]> wrote:
> On Tue, 26 Feb 2008 00:36:54 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
>
> > > Hmm, mystery partly solved... as you guessed it, this piece of code
> > > was not in my tree.
> > >
> > > (still, how can this cause autoresume after 5 seconds is a mystery to
> > > me).
> > >
> > >
> > > Pavel
> >
> > Maybe it doesn't. Andrew saw the autoresume on -rc[2,3]
>
> And earlier - I think 2.6.23 does it as well.
But that one at least resumes fine, does it not?
On Tue, 26 Feb 2008 00:48:12 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
> On Tue, Feb 26, 2008 at 12:39 AM, Andrew Morton
> <[email protected]> wrote:
> > On Tue, 26 Feb 2008 00:36:54 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
> >
> > > > Hmm, mystery partly solved... as you guessed it, this piece of code
> > > > was not in my tree.
> > > >
> > > > (still, how can this cause autoresume after 5 seconds is a mystery to
> > > > me).
> > > >
> > > >
> > > > Pavel
> > >
> > > Maybe it doesn't. Andrew saw the autoresume on -rc[2,3]
> >
> > And earlier - I think 2.6.23 does it as well.
>
> But that one at least resumes fine, does it not?
Nope, the resume-after-five-seconds and black-screen-after-resume have
always been there (I've only had the thing a few months).
I thought the restoring of the screen after resume is handled by the X
server? I'm using the nv.o driver. Perhaps nvidia's driver handles it
right, dunno.
Hi!
> > > > Maybe it doesn't. Andrew saw the autoresume on -rc[2,3]
> > >
> > > And earlier - I think 2.6.23 does it as well.
> >
> > But that one at least resumes fine, does it not?
>
> Nope, the resume-after-five-seconds and black-screen-after-resume have
> always been there (I've only had the thing a few months).
>
> I thought the restoring of the screen after resume is handled by the X
> server? I'm using the nv.o driver. Perhaps nvidia's driver handles it
> right, dunno.
Aha, so you do not have s2ram from suspend.sf.net installed, do you?
Restoring the screen is done by either
a) kernel/bios (acpi_sleep=..., or better s2ram -f -a X )
b) vbetool
c) X
. s2ram should detect your machine, and automatically set acpi_sleep
and/or perform vbetool magic.
Please try s2ram, there's good chance it will just work.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Feb 26, 2008 at 12:53 AM, Andrew Morton
<[email protected]> wrote:
>
> On Tue, 26 Feb 2008 00:48:12 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
>
> > On Tue, Feb 26, 2008 at 12:39 AM, Andrew Morton
> > <[email protected]> wrote:
> > > On Tue, 26 Feb 2008 00:36:54 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
> > >
> > > > > Hmm, mystery partly solved... as you guessed it, this piece of code
> > > > > was not in my tree.
> > > > >
> > > > > (still, how can this cause autoresume after 5 seconds is a mystery to
> > > > > me).
> > > > >
> > > > >
> > > > > Pavel
> > > >
> > > > Maybe it doesn't. Andrew saw the autoresume on -rc[2,3]
> > >
> > > And earlier - I think 2.6.23 does it as well.
> >
> > But that one at least resumes fine, does it not?
>
> Nope, the resume-after-five-seconds and black-screen-after-resume have
> always been there (I've only had the thing a few months).
>
> I thought the restoring of the screen after resume is handled by the X
> server? I'm using the nv.o driver. Perhaps nvidia's driver handles it
> right, dunno.
>
>
Oh, I have the ATI thingy.
On Tue, Feb 26, 2008 at 12:33 AM, Alexey Starikovskiy
<[email protected]> wrote:
> > Attached is the acpidump output run under 2.6.23-rc3 + with reverted
> > 37f9b4c7c612fcbeb8fb6faddaef4ccdb5350145
> > (IOW - this is a working configuration).
> Thanks, you've got round 10100 bug number.
>
> Please check if the following patch on top of Linus git tree helps.
>
> Regards,
> Alex
I did some light testing, but yes, this seems to help.
With this patch applied on top of 2.6.25-rc3, I get keyboard acpi events again,
so that I can suspend by clicking Fn+F4.
--
MST
On Mon, Feb 25, 2008 at 11:46:11 -0800, Andrew Morton wrote:
> On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin" <[email protected]> wrote:
>
> > On my T61p, 2.6.25-rc2 seems to get acpi events from keypresses
> > such as Fn-F4 and lid open/close, prints them in /var/log/acpid
> > and reacts accordingly (my acpi scripts suspend on lid close and Fn-F4).
>
> You mean suspend-to-ram works correctly on your t61p?
>
> Mine suspends, then five seconds later magically resumes itself and the
> screen is all black.
I also have a T61p, on which STR works. I haven't tried 2.6.25, but it
works with 2.6.24. Both using the suspend scripts included in Ubuntu
7.10, and with s2ram 0.8 (although I need to use --acpi_sleep 2
(s3_mode) as an option, instead of 1 (s3_bios), which is used by default
on my model).
But I'm using the NVidia module, so that most likely changes a lot of
things. I'll see if I can find time tonight to test 2.6.25-rc3 + nv,
and report back.
--
Kind regards
Klaus S. Madsen
Hi!
Andrew is trying to get s2ram to work on Fedora:
> > > Please try s2ram, there's good chance it will just work.
> >
> > configure: error: Required libx86 was not found
>
> apt-get install libx86-dev?
>
> Alternatively, can you post dmidecode? Thinkpads usually work with
> acpi_sleep=s3_bios,s3_mode ; and I can look up whitelist manually.
...unfortunately, it does not ship s2ram by default, and does not even
carry its dependencies.
Is there some custom mechanism to get suspend-to-ram to work on
Fedora? If not, would it be possible to start shipping s2ram from
suspend.sf.net?
(Unlike s2disk, this will not eat filesystems, I promise :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Feb 26, 2008 at 11:11:17AM +0100, Pavel Machek wrote:
> Hi!
>
> Andrew is trying to get s2ram to work on Fedora:
>
> > > > Please try s2ram, there's good chance it will just work.
> > >
> > > configure: error: Required libx86 was not found
> >
> > apt-get install libx86-dev?
> >
> > Alternatively, can you post dmidecode? Thinkpads usually work with
> > acpi_sleep=s3_bios,s3_mode ; and I can look up whitelist manually.
>
> ...unfortunately, it does not ship s2ram by default, and does not even
> carry its dependencies.
>
> Is there some custom mechanism to get suspend-to-ram to work on
> Fedora?
if by 'custom' you mean the solution everyone agreed to work
toward at the power management summit several years ago
(hal/pm-utils) then, yes.
Dave
--
http://www.codemonkey.org.uk
On Tue 2008-02-26 12:46:13, Dave Jones wrote:
> On Tue, Feb 26, 2008 at 11:11:17AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > Andrew is trying to get s2ram to work on Fedora:
> >
> > > > > Please try s2ram, there's good chance it will just work.
> > > >
> > > > configure: error: Required libx86 was not found
> > >
> > > apt-get install libx86-dev?
> > >
> > > Alternatively, can you post dmidecode? Thinkpads usually work with
> > > acpi_sleep=s3_bios,s3_mode ; and I can look up whitelist manually.
> >
> > ...unfortunately, it does not ship s2ram by default, and does not even
> > carry its dependencies.
> >
> > Is there some custom mechanism to get suspend-to-ram to work on
> > Fedora?
>
> if by 'custom' you mean the solution everyone agreed to work
> toward at the power management summit several years ago
> (hal/pm-utils) then, yes.
I must have been on different summit... I believe it is bad to tie
s2ram to hal, because it makes testing on minimal system hard.
Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps
Fedora already has his machine whitelisted...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote:
> > if by 'custom' you mean the solution everyone agreed to work
> > toward at the power management summit several years ago
> > (hal/pm-utils) then, yes.
>
> I must have been on different summit... I believe it is bad to tie
> s2ram to hal, because it makes testing on minimal system hard.
>
> Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps
> Fedora already has his machine whitelisted...
There is no s2ram. pm-suspend uses the white/black-lists in pm-utils.
Remember that? The cross-distro package everyone agreed was a good idea
so that every distro didn't have their own magic utility ?
sigh, I give up.
Dave
--
http://www.codemonkey.org.uk
On Tue 2008-02-26 13:10:01, Dave Jones wrote:
> On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote:
>
> > > if by 'custom' you mean the solution everyone agreed to work
> > > toward at the power management summit several years ago
> > > (hal/pm-utils) then, yes.
> >
> > I must have been on different summit... I believe it is bad to tie
> > s2ram to hal, because it makes testing on minimal system hard.
> >
> > Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps
> > Fedora already has his machine whitelisted...
>
> There is no s2ram. pm-suspend uses the white/black-lists in pm-utils.
> Remember that? The cross-distro package everyone agreed was a good idea
> so that every distro didn't have their own magic utility ?
Well, we have cross-distro package, it is at suspend.sf.net , and it
can bring up video - which is kind of important. (It is single binary,
so it can be pagelocked -- which is important for s2disk).
Plus it does not depend on HAL.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Feb 26, 2008 at 07:16:11PM +0100, Pavel Machek wrote:
> On Tue 2008-02-26 13:10:01, Dave Jones wrote:
> > On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote:
> >
> > > > if by 'custom' you mean the solution everyone agreed to work
> > > > toward at the power management summit several years ago
> > > > (hal/pm-utils) then, yes.
> > >
> > > I must have been on different summit... I believe it is bad to tie
> > > s2ram to hal, because it makes testing on minimal system hard.
> > >
> > > Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps
> > > Fedora already has his machine whitelisted...
> >
> > There is no s2ram. pm-suspend uses the white/black-lists in pm-utils.
> > Remember that? The cross-distro package everyone agreed was a good idea
> > so that every distro didn't have their own magic utility ?
>
> Well, we have cross-distro package, it is at suspend.sf.net , and it
> can bring up video - which is kind of important. (It is single binary,
> so it can be pagelocked -- which is important for s2disk).
>
> Plus it does not depend on HAL.
Neither does pm-utils. Once again for the hard of thinking..
The mechanism belongs in pm-utils. HAL is just a fancy wrapper around that.
Don't want/like hal? fine, a smaller wrapper around pm-suspend and friends
is trivial (or even unnecessary if you're happy with running pm-suspend by hand)
Dave
--
http://www.codemonkey.org.uk
On Tue, 26 Feb 2008 19:16:11 +0100 Pavel Machek <[email protected]> wrote:
> On Tue 2008-02-26 13:10:01, Dave Jones wrote:
> > On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote:
> >
> > > > if by 'custom' you mean the solution everyone agreed to work
> > > > toward at the power management summit several years ago
> > > > (hal/pm-utils) then, yes.
> > >
> > > I must have been on different summit... I believe it is bad to tie
> > > s2ram to hal, because it makes testing on minimal system hard.
> > >
> > > Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps
> > > Fedora already has his machine whitelisted...
> >
> > There is no s2ram. pm-suspend uses the white/black-lists in pm-utils.
> > Remember that? The cross-distro package everyone agreed was a good idea
> > so that every distro didn't have their own magic utility ?
>
> Well, we have cross-distro package, it is at suspend.sf.net , and it
> can bring up video - which is kind of important. (It is single binary,
> so it can be pagelocked -- which is important for s2disk).
>
> Plus it does not depend on HAL.
Meanwhile, my computer continues to not work.
First thing we need to do is to work out why it won't stay suspended?
2.6.25 suspends correctly on my T61 using
# echo mem >/sys/power/state
(though the patch that started this thread broke it, it works again when reverted)
I use the attached .config -- perhaps you can send me your .config
and I can try it on this end in case there is some config issue?
(The T61 happens to be the only machine I have with me on this trip)
My T61 has intel video, which X restores when in graphics mode.
However, in older kernels I needed to manually switch virtual consoles
on resume to coax X to do this)
With 2.6.25's i915 driver, video restores even w/o X running.
The T61p has add-in graphics, so Documentation/power/video.txt
workarounds may be necessary -- depending on what grahics device,
bios and graphics driver are running.
-Len
> I also have a T61p, on which STR works. I haven't tried 2.6.25, but it
> works with 2.6.24. Both using the suspend scripts included in Ubuntu
> 7.10, and with s2ram 0.8 (although I need to use --acpi_sleep 2
> (s3_mode) as an option, instead of 1 (s3_bios), which is used by default
> on my model).
>
> But I'm using the NVidia module, so that most likely changes a lot of
> things. I'll see if I can find time tonight to test 2.6.25-rc3 + nv,
> and report back.
Ok. I've spent some time testing this. The good news is that with the nv
driver, s2ram as available from suspend.sf.net works, when run without
parameters on a 32-bit 2.6.24.3.
The bad news, however, is that it segfaults reliably after "Calling
get_mode" when I run it on 2.6.25-rc3. GDB shows that the segmentation
fault happens in the libx86 library, but as the version I use doesn't
have debug symbols, I don't have a complete backtrace. I'll try to
compile a version of libx86 tomorrow evening with debug symbols, and
return with a proper backtrace.
I have also tried to bisect the problem (its somewhere between 2.6.24
and 2.6.25rc1, quite a large span). However reverting the resulting
commit didn't solve the problem, I suspect I took a wrong turn
somewhere. I'll try to redo the bisection also tomorrow evening.
So I'll return with a proper bug report tomorrow (in its own thread). I
just wanted to give a heads up, if the above makes sense to anyone ;-)
--
Kind regards
Klaus S. Madsen
On Tue, 26 Feb 2008, Klaus S. Madsen wrote:
> The bad news, however, is that it segfaults reliably after "Calling
> get_mode" when I run it on 2.6.25-rc3. GDB shows that the segmentation
> fault happens in the libx86 library, but as the version I use doesn't
> have debug symbols, I don't have a complete backtrace. I'll try to
> compile a version of libx86 tomorrow evening with debug symbols, and
> return with a proper backtrace.
Hmm, just a random shot (shouldn't be the case, but just to be on the safe
side) -- could you please try
echo 0 > /proc/sys/kernel/randomize_va_space
to see whether it removes the segfault by any chance?
I don't know how exactly execution of real-mode code through libx86 works,
but this might be worth trying before starting the next round of
bisection.
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue 2008-02-26 13:22:41, Dave Jones wrote:
> On Tue, Feb 26, 2008 at 07:16:11PM +0100, Pavel Machek wrote:
> > On Tue 2008-02-26 13:10:01, Dave Jones wrote:
> > > On Tue, Feb 26, 2008 at 06:59:54PM +0100, Pavel Machek wrote:
> > >
> > > > > if by 'custom' you mean the solution everyone agreed to work
> > > > > toward at the power management summit several years ago
> > > > > (hal/pm-utils) then, yes.
> > > >
> > > > I must have been on different summit... I believe it is bad to tie
> > > > s2ram to hal, because it makes testing on minimal system hard.
> > > >
> > > > Anyway, what is the "default" way to trigger s2ram for Andrew? Perhaps
> > > > Fedora already has his machine whitelisted...
> > >
> > > There is no s2ram. pm-suspend uses the white/black-lists in pm-utils.
> > > Remember that? The cross-distro package everyone agreed was a good idea
> > > so that every distro didn't have their own magic utility ?
> >
> > Well, we have cross-distro package, it is at suspend.sf.net , and it
> > can bring up video - which is kind of important. (It is single binary,
> > so it can be pagelocked -- which is important for s2disk).
> >
> > Plus it does not depend on HAL.
>
> Neither does pm-utils. Once again for the hard of thinking..
>
> The mechanism belongs in pm-utils. HAL is just a fancy wrapper around that.
> Don't want/like hal? fine, a smaller wrapper around pm-suspend and friends
> is trivial (or even unnecessary if you're happy with running pm-suspend by hand)
Seems like pm-utils is just a thin wrapper around s2ram, at least in
version debian ships. It does not seem to have its own whitelist.
Now, take a look at
/usr/lib/pm-utils/functions
...
if [ -x /usr/sbin/s2ram ]; then
if [ -n "$S2RAM_OPTS" ]; then
# Trust HAL or the user to pass the correct
options
/usr/sbin/s2ram $S2RAM_OPTS
elif /usr/sbin/s2ram --test > /dev/null ; then
# Trust s2ram's internal whitelist
/usr/sbin/s2ram
else
# Unknown machine
echo "This machine is unkown, please try to
find out how to suspend this machine. See s2ram(8)."
fi
else
echo -n "mem" > /sys/power/state
fi
...so it is ready to use s2ram, but will fall back to
echo. Unfortunately, that will mean no video resume on _many_
machines.
To give some numbers: according to s2ram whitelist, we can restore
video on 410 machines. On 74 of them, s2ram is not needed. So
approximately 80% of machines need s2ram (at least in configuration
without X running)....
Pretty please, can we get s2ram for Fedora, so that video is restored
there?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Feb 26, 2008 at 10:56:41PM +0100, Pavel Machek wrote:
> Seems like pm-utils is just a thin wrapper around s2ram, at least in
> version debian ships. It does not seem to have its own whitelist.
The actual whitelists still live in hal (or specifically hal-data),
rather than pm-utils. /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-*
for example. This gets passed down to pm-utils by hal.
> /usr/lib/pm-utils/functions
>
> ...
>
> if [ -x /usr/sbin/s2ram ]; then
> if [ -n "$S2RAM_OPTS" ]; then
> # Trust HAL or the user to pass the correct
> options
> /usr/sbin/s2ram $S2RAM_OPTS
> elif /usr/sbin/s2ram --test > /dev/null ; then
> # Trust s2ram's internal whitelist
> /usr/sbin/s2ram
> else
> # Unknown machine
> echo "This machine is unkown, please try to
> find out how to suspend this machine. See s2ram(8)."
> fi
> else
> echo -n "mem" > /sys/power/state
> fi
Seems to be a debian specific change, the variant in Fedora, nor upstream
pm-utils doesn't have any of that. Possibly because it's a dumb idea
to have two separate sources of the same information.
> ...so it is ready to use s2ram, but will fall back to
> echo. Unfortunately, that will mean no video resume on _many_
> machines.
>
> To give some numbers: according to s2ram whitelist, we can restore
> video on 410 machines. On 74 of them, s2ram is not needed. So
> approximately 80% of machines need s2ram (at least in configuration
> without X running)....
>
> Pretty please, can we get s2ram for Fedora, so that video is restored
> there?
I'm not the gatekeeper of what goes into Fedora userspace, but I'm pretty
certain the path forward has already been decided. Running a modern
Fedora desktop installation without hal just isn't feasible.
Dave
--
http://www.codemonkey.org.uk
On Tuesday, 26 of February 2008, Dave Jones wrote:
> On Tue, Feb 26, 2008 at 10:56:41PM +0100, Pavel Machek wrote:
>
> > Seems like pm-utils is just a thin wrapper around s2ram, at least in
> > version debian ships. It does not seem to have its own whitelist.
>
> The actual whitelists still live in hal (or specifically hal-data),
> rather than pm-utils. /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-*
> for example. This gets passed down to pm-utils by hal.
>
> > /usr/lib/pm-utils/functions
> >
> > ...
> >
> > if [ -x /usr/sbin/s2ram ]; then
> > if [ -n "$S2RAM_OPTS" ]; then
> > # Trust HAL or the user to pass the correct
> > options
> > /usr/sbin/s2ram $S2RAM_OPTS
> > elif /usr/sbin/s2ram --test > /dev/null ; then
> > # Trust s2ram's internal whitelist
> > /usr/sbin/s2ram
> > else
> > # Unknown machine
> > echo "This machine is unkown, please try to
> > find out how to suspend this machine. See s2ram(8)."
> > fi
> > else
> > echo -n "mem" > /sys/power/state
> > fi
>
> Seems to be a debian specific change, the variant in Fedora, nor upstream
> pm-utils doesn't have any of that. Possibly because it's a dumb idea
> to have two separate sources of the same information.
>
> > ...so it is ready to use s2ram, but will fall back to
> > echo. Unfortunately, that will mean no video resume on _many_
> > machines.
> >
> > To give some numbers: according to s2ram whitelist, we can restore
> > video on 410 machines. On 74 of them, s2ram is not needed. So
> > approximately 80% of machines need s2ram (at least in configuration
> > without X running)....
> >
> > Pretty please, can we get s2ram for Fedora, so that video is restored
> > there?
>
> I'm not the gatekeeper of what goes into Fedora userspace, but I'm pretty
> certain the path forward has already been decided. Running a modern
> Fedora desktop installation without hal just isn't feasible.
Well, pm-utils seems to be a bunch of shell scripts that run some addtional
utilities, such as vbetool, to actually do the quirks. In s2ram we have all
these additional utilities put together in one package and you need not
use the whiltelist it contains. You can just very well make pm-utils use
s2ram for doing the low-level work, just build the appropriate command line
for it on the basis of the HAL whitelist.
Frankly, I don't see any conflict between pm-utils and s2ram at a technical
level.
Thanks,
Rafael
On Tue 2008-02-26 17:23:37, Dave Jones wrote:
> On Tue, Feb 26, 2008 at 10:56:41PM +0100, Pavel Machek wrote:
>
> > Seems like pm-utils is just a thin wrapper around s2ram, at least in
> > version debian ships. It does not seem to have its own whitelist.
>
> The actual whitelists still live in hal (or specifically hal-data),
> rather than pm-utils. /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-*
> for example. This gets passed down to pm-utils by hal.
Well... you can keep the whitelist where you prefer it -- it may make
sense for support of desktops...
> > /usr/lib/pm-utils/functions
> >
> > ...
> >
> > if [ -x /usr/sbin/s2ram ]; then
> > if [ -n "$S2RAM_OPTS" ]; then
> > # Trust HAL or the user to pass the correct
> > options
> > /usr/sbin/s2ram $S2RAM_OPTS
> > elif /usr/sbin/s2ram --test > /dev/null ; then
> > # Trust s2ram's internal whitelist
> > /usr/sbin/s2ram
> > else
> > # Unknown machine
> > echo "This machine is unkown, please try to
> > find out how to suspend this machine. See s2ram(8)."
> > fi
> > else
> > echo -n "mem" > /sys/power/state
> > fi
>
> Seems to be a debian specific change, the variant in Fedora, nor upstream
> pm-utils doesn't have any of that. Possibly because it's a dumb idea
> to have two separate sources of the same information.
>
> > ...so it is ready to use s2ram, but will fall back to
> > echo. Unfortunately, that will mean no video resume on _many_
> > machines.
> >
> > To give some numbers: according to s2ram whitelist, we can restore
> > video on 410 machines. On 74 of them, s2ram is not needed. So
> > approximately 80% of machines need s2ram (at least in configuration
> > without X running)....
> >
> > Pretty please, can we get s2ram for Fedora, so that video is restored
> > there?
>
> I'm not the gatekeeper of what goes into Fedora userspace, but I'm pretty
> certain the path forward has already been decided. Running a modern
> Fedora desktop installation without hal just isn't feasible.
Unfortunately, your decision means few things:
1) we can't debug it easily: I can no longer tell Andrew to boot into
init=/bin/bash , and run s2ram. For debugging, trying with minimal
system is very important.
2) you use bunch of shellscripts. If your SATA does not wake up, you
get no video, and probably no chance to pull debug info out of that
box. s2ram is pagelocked for that reason.
...plus, you could easily keep your whitelist in HAL and just call
s2ram, unless user is running it manually.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Feb 26, 2008 at 10:56 AM, Andrew Morton
<[email protected]> wrote:
> First thing we need to do is to work out why it won't stay suspended?
Forgive me the stupid question, but you don't happen to have Wake On
LAN or somesuch enabled in your BIOS, do you? (Given yours stays down
for five seconds then resumes, and other T61 owners aren't seeing that
behavior... <shrug>)
For Pavel and Rafael: Is there some sort of event that gets handed
back on resume to let the kernel know why the system woke up? One
would think that the Wake On LAN (keyboard, timer, etc.) would hand a
notification over to the OS. One is often wrong though.
On Wednesday, 27 of February 2008, Ray Lee wrote:
> On Tue, Feb 26, 2008 at 10:56 AM, Andrew Morton
> <[email protected]> wrote:
> > First thing we need to do is to work out why it won't stay suspended?
>
> Forgive me the stupid question, but you don't happen to have Wake On
> LAN or somesuch enabled in your BIOS, do you? (Given yours stays down
> for five seconds then resumes, and other T61 owners aren't seeing that
> behavior... <shrug>)
>
> For Pavel and Rafael: Is there some sort of event that gets handed
> back on resume to let the kernel know why the system woke up? One
> would think that the Wake On LAN (keyboard, timer, etc.) would hand a
> notification over to the OS. One is often wrong though.
In theory we should be able to get this kind of information from ACPI, but I've
never seriously looked at that. I'm not sure if anyone has ...
Thanks,
Rafael
On Tue, Feb 26, 2008 at 10:56:41PM +0100, Pavel Machek wrote:
> Seems like pm-utils is just a thin wrapper around s2ram, at least in
> version debian ships. It does not seem to have its own whitelist.
That's a Debian patch.
> ...so it is ready to use s2ram, but will fall back to
> echo. Unfortunately, that will mean no video resume on _many_
> machines.
See /usr/lib/pm-utils/sleep.d/99video .
> Pretty please, can we get s2ram for Fedora, so that video is restored
> there?
Stefan told us at FOSDEM that s2ram was being deprecated in OpenSuse, so
I don't think this is the way to go.
--
Matthew Garrett | [email protected]
On Wednesday, 27 of February 2008, Matthew Garrett wrote:
> On Tue, Feb 26, 2008 at 10:56:41PM +0100, Pavel Machek wrote:
>
> > Seems like pm-utils is just a thin wrapper around s2ram, at least in
> > version debian ships. It does not seem to have its own whitelist.
>
> That's a Debian patch.
>
> > ...so it is ready to use s2ram, but will fall back to
> > echo. Unfortunately, that will mean no video resume on _many_
> > machines.
>
> See /usr/lib/pm-utils/sleep.d/99video .
>
> > Pretty please, can we get s2ram for Fedora, so that video is restored
> > there?
>
> Stefan told us at FOSDEM that s2ram was being deprecated in OpenSuse, so
> I don't think this is the way to go.
Well, is that really correct? Stefan??
He probably meant that the s2ram _whitelist_ is going to be deprecated, which
didn't mean s2ram altogether.
s2ram is pretty useful anyway, as it combines many mechanisms that allow us to
bring the video back to life from the user land, so you can use one binary
instead of a bunch of different programs with different command lines etc.
Thanks,
Rafael
Rafael J. Wysocki wrote:
> On Wednesday, 27 of February 2008, Matthew Garrett wrote:
>> On Tue, Feb 26, 2008 at 10:56:41PM +0100, Pavel Machek wrote:
>>
>>> Seems like pm-utils is just a thin wrapper around s2ram, at least in
>>> version debian ships. It does not seem to have its own whitelist.
>> That's a Debian patch.
Yes, the current openSUSE basically uses the same setup, but this will change
in the future.
>>> ...so it is ready to use s2ram, but will fall back to
>>> echo. Unfortunately, that will mean no video resume on _many_
>>> machines.
>> See /usr/lib/pm-utils/sleep.d/99video .
>>
>>> Pretty please, can we get s2ram for Fedora, so that video is restored
>>> there?
>> Stefan told us at FOSDEM that s2ram was being deprecated in OpenSuse, so
>> I don't think this is the way to go.
>
> Well, is that really correct? Stefan??
Not quite :-)
> He probably meant that the s2ram _whitelist_ is going to be deprecated, which
> didn't mean s2ram altogether.
Exactly.
> s2ram is pretty useful anyway, as it combines many mechanisms that allow us to
> bring the video back to life from the user land, so you can use one binary
> instead of a bunch of different programs with different command lines etc.
That's what i like about it and the part i want to keep: do all the
workarounds in one place, ideally with locked VTs and maybe mlock()ed, but get
the workaround options from HAL.
I also had the impression that i had said this quite clearly, but the talk was
short, so the "data compression" of the information might not have been
lossless :-)
Hope this helps to clear up the confusion.
--
Stefan Seyfried
R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG N?rnberg)
On Wed, Feb 27, 2008 at 04:51:13PM +0100, Stefan Seyfried wrote:
> Rafael J. Wysocki wrote:
> > He probably meant that the s2ram _whitelist_ is going to be deprecated, which
> > didn't mean s2ram altogether.
>
> Exactly.
Ah! My apologies, I managed to misunderstand that.
--
Matthew Garrett | [email protected]
On Tue, Feb 26, 2008 at 22:44:13 +0100, Jiri Kosina wrote:
> Hmm, just a random shot (shouldn't be the case, but just to be on the safe
> side) -- could you please try
>
> echo 0 > /proc/sys/kernel/randomize_va_space
>
> to see whether it removes the segfault by any chance?
Unfortunately this does not remove the segfault. I got a proper
bisection result (82bc03fc158e28c90d7ed9919410776039cb4e14: x86: add PWT
to NOCACHE flags), which I've reported in a new thread, as it really
doesn't have anything to do with the original subject anymore. The
subject of the new thread is:
Regression in 2.6.25-rc3: s2ram segfaults before suspending
--
Kind regards
Klaus S. Madsen
On Wed, 27 Feb 2008, Klaus S. Madsen wrote:
> On Tue, Feb 26, 2008 at 22:44:13 +0100, Jiri Kosina wrote:
> > Hmm, just a random shot (shouldn't be the case, but just to be on the safe
> > side) -- could you please try
> >
> > echo 0 > /proc/sys/kernel/randomize_va_space
> >
> > to see whether it removes the segfault by any chance?
> Unfortunately this does not remove the segfault. I got a proper
> bisection result (82bc03fc158e28c90d7ed9919410776039cb4e14: x86: add PWT
> to NOCACHE flags), which I've reported in a new thread, as it really
> doesn't have anything to do with the original subject anymore. The
> subject of the new thread is:
> Regression in 2.6.25-rc3: s2ram segfaults before suspending
Thanks for bisecting this.
Please, don't forget to CC the author of the commit, whenever you finish
your bisection (this time it is Ingo). Added to CC.
--
Jiri Kosina
SUSE Labs