Andrew Morton | 1 Mar 2005 10:52

Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown

Pavel Machek <pavel@...> wrote:
>
> In `subj` kernel, machine no longer powers down at the end of
>  swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk.

Binary searching indicates that this is due to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/acpi_power_off-bug-fix.patch.

I'll drop it.  That patch is pretty ugly-looking anyway (ACPI code in
drivers/base/power/?).

Perhaps someone who is hitting the problem which that patch addresses could
raise a bugzilla entry.

Oh.  It has one.  http://bugme.osdl.org/show_bug.cgi?id=4041

Anyway.  It needs more work.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Pavel Machek | 1 Mar 2005 11:54
Picon

Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown

Hi!

> > In `subj` kernel, machine no longer powers down at the end of
> >  swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk.
> 
> Binary searching indicates that this is due to
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/acpi_power_off-bug-fix.patch.
> 
> I'll drop it.  That patch is pretty ugly-looking anyway (ACPI code in
> drivers/base/power/?).
> 
> Perhaps someone who is hitting the problem which that patch addresses could
> raise a bugzilla entry.
> 
> Oh.  It has one.  http://bugme.osdl.org/show_bug.cgi?id=4041
> 
> Anyway.  It needs more work.

Yes, the patch is very ugly. If something like this needs to be done,
then perhaps acpi should properly register into driver model and do
the work there. This will also mean code will be called consistently.

								Pavel
--

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Luca Capello | 1 Mar 2005 12:05
Picon
Favicon

Re: Re: swsusp fails with "FATAL: cannot find swap device, try swapon -a!"

Hello!

On Mon 28 Feb 2005 01:04 +0100, Pavel Machek wrote:
> And you have resume= on command line, right? CONFIG_..._STD_PARTITION
> should not be required, but I have it set like this:

I don't have 'resume' on my command line, but I've
CONFIG_..._STD_PARTITION, it works great with 2.6.10 and 2.6.11-rc4:
=====
luca <at> gismo:~$ cat /proc/cmdline
root=/dev/hda2 ro acpi_sleep=s3_bios
luca <at> gismo:~$ grep STD_PARTITION /boot/config-2.6.10-mh4
CONFIG_PM_STD_PARTITION="/dev/hda5"
luca <at> gismo:~$
=====

Just my 0.02c...

Thx, bye,
Gismo / Luca
Eric W. Biederman | 1 Mar 2005 12:08
Favicon

Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown

Andrew Morton <akpm <at> osdl.org> writes:

> Pavel Machek <pavel <at> ucw.cz> wrote:
> >
> > In `subj` kernel, machine no longer powers down at the end of
> >  swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk.
> 
> Binary searching indicates that this is due to
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/acpi_power_off-bug-fix.patch.
> 
> 
> I'll drop it.  That patch is pretty ugly-looking anyway (ACPI code in
> drivers/base/power/?).
> 
> Perhaps someone who is hitting the problem which that patch addresses could
> raise a bugzilla entry.
> 
> Oh.  It has one.  http://bugme.osdl.org/show_bug.cgi?id=4041
> 
> Anyway.  It needs more work.

Agreed.

I threw it together to test a specific code path, and the fact it
fails in software suspend is actually almost confirmation that I am on
the right track.  This actually fixed the case I was testing.

In this case the failure is simply because system_state is
not set to SYSTEM_POWER_OFF before
kernel/power/disk.c:power_down() calls device_shutdown().
(Continue reading)

Eric W. Biederman | 1 Mar 2005 12:12
Favicon

Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown

Pavel Machek <pavel@...> writes:

> Yes, the patch is very ugly. If something like this needs to be done,
> then perhaps acpi should properly register into driver model and do
> the work there. This will also mean code will be called consistently.

I totally agree.  Do you have an example of how a non-device
can do this?

In particular something that gets as close to shutting down
the system devices as possible.  But gets called before that.

Or perhaps acpi should simply be setup to be the first system device?

Eric

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Pavel Machek | 1 Mar 2005 13:02
Picon

Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown

Hi!

> > Yes, the patch is very ugly. If something like this needs to be done,
> > then perhaps acpi should properly register into driver model and do
> > the work there. This will also mean code will be called consistently.
> 
> I totally agree.  Do you have an example of how a non-device
> can do this?
> 
> In particular something that gets as close to shutting down
> the system devices as possible.  But gets called before that.
> 
> Or perhaps acpi should simply be setup to be the first system device?

I believe that's the prefered solution.
								Pavel
--

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Pavel Machek | 1 Mar 2005 13:08
Picon

Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown

Hi!

> > > In `subj` kernel, machine no longer powers down at the end of
> > >  swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk.
> > 
> > Binary searching indicates that this is due to
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc5/2.6.11-rc5-mm1/broken-out/acpi_power_off-bug-fix.patch.
> > 
> > 
> > I'll drop it.  That patch is pretty ugly-looking anyway (ACPI code in
> > drivers/base/power/?).
> > 
> > Perhaps someone who is hitting the problem which that patch addresses could
> > raise a bugzilla entry.
> > 
> > Oh.  It has one.  http://bugme.osdl.org/show_bug.cgi?id=4041
> > 
> > Anyway.  It needs more work.
> 
> Agreed.
> 
> I threw it together to test a specific code path, and the fact it
> fails in software suspend is actually almost confirmation that I am on
> the right track.  This actually fixed the case I was testing.
> 
> In this case the failure is simply because system_state is
> not set to SYSTEM_POWER_OFF before
> kernel/power/disk.c:power_down() calls device_shutdown().
> The appropriate reboot notifier is also not called..

(Continue reading)

Tommy Ch. | 1 Mar 2005 13:48
Picon

Re: Req: debug dsdt of Toshiba M30


>>[...] erm, I think it was Bruno Ducrot. 

Bruno Ducrot wrote:
> Well, I don't remember if that's me.
> But I have an acpidmp for a toshiba M30-404.

Could be it was John Belmonte.

> After doing something like this:
> 
> ducrot <at> neptune:~/acpi_hack/toshiba-M30-404$ ../pmtools/acpidmp/acpixtract SSDT > ssdt < acpidmp
> ducrot <at> neptune:~/acpi_hack/toshiba-M30-404$ iasl-20041203 -d ssdt
> 
> and the resulting ssdt.dsl will contains the processor object.
> 
> So all you have to do is to add something like that:
> External (\_PR.CPU0)
> onto the dsdt.dsl in order to get rid of those errors.

>  DefinitionBlock ("DSDT.aml", "DSDT", 1, "TOSHIB", "A0007   ", 537069574)
>  {
> +    External (\_PR.CPU0)

OK, thanks. I read something like this somewhere but was really unsure 
where to place the External Definition.
So, is it worth correcting this and loading the new dsdt at boot? Will 
it help?

>>And perhaps: can anybody tell me why it isn't possible to switch CRT or 
(Continue reading)

Eric W. Biederman | 1 Mar 2005 18:33
Favicon

Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown

Pavel Machek <pavel <at> suse.cz> writes:

> > I threw it together to test a specific code path, and the fact it
> > fails in software suspend is actually almost confirmation that I am on
> > the right track.  This actually fixed the case I was testing.
> > 
> > In this case the failure is simply because system_state is
> > not set to SYSTEM_POWER_OFF before
> > kernel/power/disk.c:power_down() calls device_shutdown().
> > The appropriate reboot notifier is also not called..
> 
> Can you suggest patch to do it right? Or perhaps there should be
> just_plain_power_machine_down() that does all neccessary
> trickery?

I would call it kernel_power_down() and that
is what I am suggesting is the right fix.

We have it open coded in kernel/sys.c:sys_reboot()
in the switch case for: LINUX_REBOOT_CMD_POWER_OFF

So after the code gets factored out from there all
of the cases that call machine_power_off() and pm_power_off()
directly need to be updated.

There are similar cases for machine_restart() and machine_halt().
But the power off case seems to be the most acute.

My biggest problem with this is I get into the recursive code
cleanup problem.  Where I fix one piece and a bug is exposed somewhere
(Continue reading)

Sergio Monteiro Basto | 1 Mar 2005 21:37
Picon

Re: New insights about video module! Need help,please.

On Mon, 2005-02-28 at 19:17 +0100, Tommy Ch. wrote:

> Is this correct? If yes, a
> echo "tv_out:1" > /proc/acpi/toshiba/video
> had no effect.

To switch to tv-out I used keys Fn+F2 or Fn+F3 (don't remember exactly),
which just begging to work when I put ACPI on kernel.
The keys to switch to tv-out on Windows should work on Linux (with ACPI
enabled of course).

Regards,

--

-- 
Sérgio M.B.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Gmane