acpi-devel — defunct list, use http://vger.kernel.org/vger-lists.html#linux-acpi

Re: [ACPI] Toshiba Satellite P10

[Pavel M. <pa...@su...>]

Hi!

> Damn.  I just thought I solved it.  I disabled the APIC and tried again.
>  This time round I managed to re-enable APIC in the kernel source
> (without IO-APIC) and _recompile_ it entirely.  Only upon issueing "make
> install modules_install" did it pop.
> 
> Sequence was something like:
> 
> echo mem > /sys/power/state
> cd /usr/src/linux
> make menuconfig
> make menuconfig
> echo mem > /sys/power/state
> make menuconfig
> --> re-enable APIC but not IO-APIC
> make
> make install modules_install
> ->> pop.  When copying the image from the source directory to /boot.
> 
> This is beginning to sound more and more like some obscure
> race-condition if you ask me.

I would be surprised if that was the case. Are you sure it is not just
"disk does not work after resume", and depending of stuff in cache, it
fails at random places?
								Pavel
-- 
Thanks, Sharp!

[ACPI] Need some help with Toshiba L20-101 DSDT table

[<cth...@sp...>]

I'm geting this four errors which I suppose are caused by that objects bein=
g=0D
defined before (never heard about the "ACPI language" 'till today).=0D
----------------=0D
# ./iasl -tc dsdt.dsl=0D
=0D
Intel ACPI Component Architecture=0D
ASL Optimizing Compiler / AML Disassembler version 20030228 [Feb 28 2003]=
=0D
Copyright (C) 2000 - 2003 Intel Corporation=0D
Supports ACPI Specification Revision 2.0b=0D
=0D
dsdt.dsl   370:             If (LEqual (And (PDC0, 0x0A), 0x0A))=0D
Error    1022 -           Object does not exist ^  (PDC0)=0D
=0D
dsdt.dsl   375:             If (LEqual (And (PDC1, 0x0A), 0x0A))=0D
Error    1022 -           Object does not exist ^  (PDC1)=0D
=0D
dsdt.dsl  3936:                 Z003,=0D
Error    1022 -                    ^ Object does not exist (Z003)=0D
=0D
dsdt.dsl  3937:                 Z003,=0D
Error    1022 -                    ^ Object does not exist (Z003)=0D
=0D
ASL Input:  dsdt.dsl - 4240 lines, 137275 bytes, 1880 keywords=0D
Compilation complete. 4 Errors, 0 Warnings, 0 Remarks, 546 Optimizations=0D
------------------=0D
=0D
I fixed the Z003 deleting that two entries, which I think is tricky. Couldn=
't fix=0D
the PDCs after researching on Google for almost an hour. This are the fragm=
ents=0D
of code:=0D
=0D
-------------------=0D
    Method (PNOT, 0, Serialized)=0D
    {=0D
        If (HTTE)=0D
        {=0D
            If (LEqual (And (PDC0, 0x0A), 0x0A))=0D
            {=0D
                Notify (\_PR.CPU0, 0x80)=0D
            }=0D
=0D
            If (LEqual (And (PDC1, 0x0A), 0x0A))=0D
            {=0D
                Notify (\_PR.CPU1, 0x80)=0D
            }=0D
        }=0D
        Else=0D
        {=0D
            Notify (\_PR.CPU0, 0x80)=0D
            Sleep (0x64)=0D
            Notify (\_PR.CPU0, 0x81)=0D
        }=0D
    }=0D
---------------------=0D
=0D
And:=0D
=0D
---------------------=0D
        Device (BAT1)=0D
        {=0D
            Name (_HID, EisaId ("PNP0C0A"))=0D
            Name (_UID, 0x01)=0D
            Name (CBTI, 0x00)=0D
            Name (PBTI, 0x00)=0D
            Name (BTIN, 0x00)=0D
            Name (BTCH, 0x00)=0D
            Name (BIFI, 0x00)=0D
            Name (SEL0, 0x00)=0D
            Name (BCRI, 0x00)=0D
            Name (PBIF, Package (0x0D)=0D
            {=0D
                0x01,=0D
                0x1130,=0D
                0x1130,=0D
                0x01,=0D
                0x2B5C,=0D
                0x012C,=0D
                0x84,=0D
                0x20,=0D
                0x20,=0D
                "PA34200-1BRS",=0D
                "11        ",=0D
                "11        ",=0D
                "TOSHIBA   "=0D
            })=0D
            Name (PBST, Package (0x04)=0D
            {=0D
                0x00,=0D
                Z003,=0D
                Z003,=0D
                0x2710=0D
            })=0D
            Name (ERRC, 0x00)=0D
            Name (_PCL, Package (0x01)=0D
            {=0D
                \_SB=0D
            })=0D
--------------------=0D
=0D
I'm not sure about I'm giving enough info, and didn't think posting the who=
le=0D
archive was very polite.=0D
=0D
Has anyone a idea on how to fix it? If you need the full *dsl to give me so=
me=0D
advice, tell me and I'll send it off the list. I'm starting to learn C, so =
please=0D
don't blame me for not knowing how to programm in such a low level thingy. =
I=0D
would appreciate it if you could give me some links to an introduction to "=
ACPI=0D
programming", too.=0D
=0D
Thank you very much!=0D

Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

Jaco Kroon wrote:
> Stefan Seyfried wrote:
>>>Same problem.  SysRq+T reveals that the newly spawned process is getting
>>>stuck in:
>>>
>>>ide_do_request+0x18a/0x3c5
>>>io_schedule+0xe/0x16

[--snip--]

>>To my untrained eye this looks like an IDE suspend / resume problem.
>>Maybe another machine that needs those ACPI methods for the IDE drives
>>badly :-(
> 
> 
> To mine as well.  _WAK?  Some other methods?  I'm posting my DSDT at
> http://www.kroon.co.za/downloads/toshiba_p10-792/ now.  If somebody else
> can take a look it just might reveal something I'm missing.

Damn.  I just thought I solved it.  I disabled the APIC and tried again.
 This time round I managed to re-enable APIC in the kernel source
(without IO-APIC) and _recompile_ it entirely.  Only upon issueing "make
install modules_install" did it pop.

Sequence was something like:

echo mem > /sys/power/state
cd /usr/src/linux
make menuconfig
make menuconfig
echo mem > /sys/power/state
make menuconfig
--> re-enable APIC but not IO-APIC
make
make install modules_install
->> pop.  When copying the image from the source directory to /boot.

This is beginning to sound more and more like some obscure
race-condition if you ask me.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

Re: [ACPI] Toshiba Satellite P10

[Pavel M. <pa...@su...>]

Hi!

> > I have a Vaio which has the same ide problem (at least I think so):
> > after resume, all processes wishing to access the disk hang,
> > dmesg shows lots of "hda: lost interrupt" messages.
> > However, doing a "hdparm -w /dev/hda" after resume makes everything
> > work again.
> > 
> 
> >From the man page:
> 
>        -w     Perform a device reset (DANGEROUS).  Do NOT use this
> option.  It
>               exists for unlikely situations where a reboot might
> otherwise be
>               required to get a confused drive back into a useable state.
> 
> Ok.  I don't have really important data on the notebook atm (all backed
> up for obvious reasons).  So I gave this a try.  It causes the kernel to
> crash entirely.  No more SysRq.  No OOPS.  Nothing.  It outputs a single
> string namely "/dev/hda:" and then dies.

Try verifying that your interrupts work after resume. (I assume we are
still talking suspend-to-RAM here, and that you got suspend-to-disk to
more or less work?) Do cat /proc/interrupts; sleep 10; cat
/proc/interrupts both before and after suspend.

								Pavel


-- 
Thanks, Sharp!

Re: [ACPI] Toshiba Satellite P10

[Pavel M. <pa...@su...>]

Hi!

> >>>Okay, what *other* patches do you have installed? What kernel are you
> >>>running? 2.6.15-rc6?
> >>
> >>I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can
> >>always get the VI patch to rc6).  Was intending to run the acpi_include
> >>patch, but since that is a standard option in 2.6.14.x I never actually
> >>pulled in that patch, so no other patches and I've backed out suspend2
> >>now.  Will also give 15rc6 a go in the morning.
> > 
> > rc5 should be good enough.
> 
> Same problem.  SysRq+T reveals that the newly spawned process is getting
> stuck in:
> 
> ide_do_request+0x18a/0x3c5
> io_schedule+0xe/0x16
> sync_page+0x3e/0x4b
> __wait_on_bit_lock+0x41/0x61
> sync_page+0x0/0x4b
> __lock_page+0x9d/0xb1
> wake_bit_function+0x0/0x55
> wake_bit_function+0x0/0x55
> do_generic_mapping_read+0x335/0x7fd
> __generic_file_aio_read+0x19d/0x203
> file_read_actor+0x0/0xfa
> generic_file_read+0xba/0xd8
> autoremove_wake_function+0x0/0x57
> vfs_read+0x1a5/0x1aa
> kernel_read+0x50/0x5f
> prepare_binprm+0xd8/0x103
> do_execve+0xfe/0x203
> sys_execve+0x3c/0x6f
> sysenter_past_esp+0x54/0x75
> 
> Second run round the first command I issued worked fine, as did cd to
> /usr/src/linux, but running make menuconfig failed.  This time the stack
> trace was considerably longer (I'm not going to type that over).  The
> top two calls are the same, but it comes in from sync_buffer,
> __wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit,
> wake_bit_function, wakebit_function, and so forth.  A quick scan of the
> VI between rc5  and rc6 doesn't reveal any changes that could possibly
> affect this (I'm going to patch to rc6 in any case).
> 
> Could it be a bug in reiserfs?  I have run a fsck but no errors were
> found, so I presume the fs is still in tact.

Seife is right, this looks like an ide problem. And the fact that
autorepeat does not work for you may mean something bad with
interrupts. Can you try "noapic"?

> >>Will do if I get it working.  more-or-less is simply not good enough (or
> >>should I just make a note there?).
> > 
> > It is good enough for video.txt. It describes how to get _video_
> > working, and video works just ok for you.
> 
> You should have received the patch.

I don't see it here. Can you just attach it to this discussion? It
should be small enough...
								Pavel

-- 
Thanks, Sharp!

Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

Manuel Lauss wrote:
> Jaco Kroon wrote:
> 
> 
>>ide_do_request+0x18a/0x3c5
>>io_schedule+0xe/0x16
>>sync_page+0x3e/0x4b
>>__wait_on_bit_lock+0x41/0x61
>>sync_page+0x0/0x4b
>>__lock_page+0x9d/0xb1
>>wake_bit_function+0x0/0x55
>>wake_bit_function+0x0/0x55
>>do_generic_mapping_read+0x335/0x7fd
>>__generic_file_aio_read+0x19d/0x203
>>file_read_actor+0x0/0xfa
>>generic_file_read+0xba/0xd8
>>autoremove_wake_function+0x0/0x57
>>vfs_read+0x1a5/0x1aa
>>kernel_read+0x50/0x5f
>>prepare_binprm+0xd8/0x103
>>do_execve+0xfe/0x203
>>sys_execve+0x3c/0x6f
>>sysenter_past_esp+0x54/0x75
>>
>>Second run round the first command I issued worked fine, as did cd to
>>/usr/src/linux, but running make menuconfig failed.  This time the stack
>>trace was considerably longer (I'm not going to type that over).  The
>>top two calls are the same, but it comes in from sync_buffer,
>>__wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit,
>>wake_bit_function, wakebit_function, and so forth.  A quick scan of the
>>VI between rc5  and rc6 doesn't reveal any changes that could possibly
>>affect this (I'm going to patch to rc6 in any case).
> 
> 
> I have a Vaio which has the same ide problem (at least I think so):
> after resume, all processes wishing to access the disk hang,
> dmesg shows lots of "hda: lost interrupt" messages.
> However, doing a "hdparm -w /dev/hda" after resume makes everything
> work again.
> 

>From the man page:

       -w     Perform a device reset (DANGEROUS).  Do NOT use this
option.  It
              exists for unlikely situations where a reboot might
otherwise be
              required to get a confused drive back into a useable state.

Ok.  I don't have really important data on the notebook atm (all backed
up for obvious reasons).  So I gave this a try.  It causes the kernel to
crash entirely.  No more SysRq.  No OOPS.  Nothing.  It outputs a single
string namely "/dev/hda:" and then dies.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

Re: [ACPI] Toshiba Satellite P10

[Manuel L. <ma...@ro...>]

Jaco Kroon wrote:

> ide_do_request+0x18a/0x3c5
> io_schedule+0xe/0x16
> sync_page+0x3e/0x4b
> __wait_on_bit_lock+0x41/0x61
> sync_page+0x0/0x4b
> __lock_page+0x9d/0xb1
> wake_bit_function+0x0/0x55
> wake_bit_function+0x0/0x55
> do_generic_mapping_read+0x335/0x7fd
> __generic_file_aio_read+0x19d/0x203
> file_read_actor+0x0/0xfa
> generic_file_read+0xba/0xd8
> autoremove_wake_function+0x0/0x57
> vfs_read+0x1a5/0x1aa
> kernel_read+0x50/0x5f
> prepare_binprm+0xd8/0x103
> do_execve+0xfe/0x203
> sys_execve+0x3c/0x6f
> sysenter_past_esp+0x54/0x75
> 
> Second run round the first command I issued worked fine, as did cd to
> /usr/src/linux, but running make menuconfig failed.  This time the stack
> trace was considerably longer (I'm not going to type that over).  The
> top two calls are the same, but it comes in from sync_buffer,
> __wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit,
> wake_bit_function, wakebit_function, and so forth.  A quick scan of the
> VI between rc5  and rc6 doesn't reveal any changes that could possibly
> affect this (I'm going to patch to rc6 in any case).

I have a Vaio which has the same ide problem (at least I think so):
after resume, all processes wishing to access the disk hang,
dmesg shows lots of "hda: lost interrupt" messages.
However, doing a "hdparm -w /dev/hda" after resume makes everything
work again.

-- 
 Manuel Lauss

Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

Stefan Seyfried wrote:
> On Sat, Dec 24, 2005 at 10:45:58AM +0200, Jaco Kroon wrote:
> 
>>Pavel Machek wrote:
>>
>>>rc5 should be good enough.
>>
>>Same problem.  SysRq+T reveals that the newly spawned process is getting
>>stuck in:
>>
>>ide_do_request+0x18a/0x3c5
>>io_schedule+0xe/0x16
>>sync_page+0x3e/0x4b
>>__wait_on_bit_lock+0x41/0x61
>>sync_page+0x0/0x4b
>>__lock_page+0x9d/0xb1
>>wake_bit_function+0x0/0x55
>>wake_bit_function+0x0/0x55
>>do_generic_mapping_read+0x335/0x7fd
>>__generic_file_aio_read+0x19d/0x203
>>file_read_actor+0x0/0xfa
>>generic_file_read+0xba/0xd8
>>autoremove_wake_function+0x0/0x57
>>vfs_read+0x1a5/0x1aa
>>kernel_read+0x50/0x5f
>>prepare_binprm+0xd8/0x103
>>do_execve+0xfe/0x203
>>sys_execve+0x3c/0x6f
>>sysenter_past_esp+0x54/0x75
> 
> 
> To my untrained eye this looks like an IDE suspend / resume problem.
> Maybe another machine that needs those ACPI methods for the IDE drives
> badly :-(

To mine as well.  _WAK?  Some other methods?  I'm posting my DSDT at
http://www.kroon.co.za/downloads/toshiba_p10-792/ now.  If somebody else
can take a look it just might reveal something I'm missing.

dsdt.dat (orriginal DSDT)
dsdt.dsl (my so-far edited version)
dsdt.dsl.orig (orriginal decompiled version).

Hmm, just noticed that iasl still creates a .hex file even though it
gives me 13 errors!  Including into kernel ... same issue.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

Re: [ACPI] Toshiba Satellite P10

[Stefan S. <se...@su...>]

On Sat, Dec 24, 2005 at 10:45:58AM +0200, Jaco Kroon wrote:
> Pavel Machek wrote:
> > rc5 should be good enough.
>=20
> Same problem.  SysRq+T reveals that the newly spawned process is gettin=
g
> stuck in:
>=20
> ide_do_request+0x18a/0x3c5
> io_schedule+0xe/0x16
> sync_page+0x3e/0x4b
> __wait_on_bit_lock+0x41/0x61
> sync_page+0x0/0x4b
> __lock_page+0x9d/0xb1
> wake_bit_function+0x0/0x55
> wake_bit_function+0x0/0x55
> do_generic_mapping_read+0x335/0x7fd
> __generic_file_aio_read+0x19d/0x203
> file_read_actor+0x0/0xfa
> generic_file_read+0xba/0xd8
> autoremove_wake_function+0x0/0x57
> vfs_read+0x1a5/0x1aa
> kernel_read+0x50/0x5f
> prepare_binprm+0xd8/0x103
> do_execve+0xfe/0x203
> sys_execve+0x3c/0x6f
> sysenter_past_esp+0x54/0x75

To my untrained eye this looks like an IDE suspend / resume problem.
Maybe another machine that needs those ACPI methods for the IDE drives
badly :-(
--=20
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, N=FCrnberg \                    -- Leonard Cohe=
n

Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

Pavel Machek wrote:
> Hi!
> 
> 
>>>Okay, what *other* patches do you have installed? What kernel are you
>>>running? 2.6.15-rc6?
>>
>>I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can
>>always get the VI patch to rc6).  Was intending to run the acpi_include
>>patch, but since that is a standard option in 2.6.14.x I never actually
>>pulled in that patch, so no other patches and I've backed out suspend2
>>now.  Will also give 15rc6 a go in the morning.
> 
> rc5 should be good enough.

Same problem.  SysRq+T reveals that the newly spawned process is getting
stuck in:

ide_do_request+0x18a/0x3c5
io_schedule+0xe/0x16
sync_page+0x3e/0x4b
__wait_on_bit_lock+0x41/0x61
sync_page+0x0/0x4b
__lock_page+0x9d/0xb1
wake_bit_function+0x0/0x55
wake_bit_function+0x0/0x55
do_generic_mapping_read+0x335/0x7fd
__generic_file_aio_read+0x19d/0x203
file_read_actor+0x0/0xfa
generic_file_read+0xba/0xd8
autoremove_wake_function+0x0/0x57
vfs_read+0x1a5/0x1aa
kernel_read+0x50/0x5f
prepare_binprm+0xd8/0x103
do_execve+0xfe/0x203
sys_execve+0x3c/0x6f
sysenter_past_esp+0x54/0x75

Second run round the first command I issued worked fine, as did cd to
/usr/src/linux, but running make menuconfig failed.  This time the stack
trace was considerably longer (I'm not going to type that over).  The
top two calls are the same, but it comes in from sync_buffer,
__wait_on_bit, sync_buffer, sync_buffer, out_of_line_wait_on_bit,
wake_bit_function, wakebit_function, and so forth.  A quick scan of the
VI between rc5  and rc6 doesn't reveal any changes that could possibly
affect this (I'm going to patch to rc6 in any case).

Could it be a bug in reiserfs?  I have run a fsck but no errors were
found, so I presume the fs is still in tact.

Right, I've done this for userspace programs linked with -rdynamic
before, but how do I convert those hexadecimal offsets into line numbers
for the kernel?  Just point me at the docs to RTFM so that I can RTFS.

The keyboard auto-repeat still breaks.  If it's possible to re-enable
this using some command-line tool (which I'm not aware off) then I can
just re-enable that manually from a suspend/resume script.

>>>>This feels like a post-wakeup racecondition to me... Disabling the big
>>>>kernel lock preemption think again... yes, seems to be working better
>>>>now.  Suspending to ram and then to disk still fails.  (resume from mem
>>>>works, can do make menuconfig - a few times - and then it starts
>>>>suspend-to-disk process and then just hangs).
>>>
>>>So... there's no module to blame? I do have CONFIG_PREEMPT=y and
>>>CONFIG_PREEMPT_BKL=y set here, but there were some problems with those
>>>before, so keeping it disabled may be wise.
>>
>>I've also found that I forgot to disable registers.  Neither made a
>>difference though.
> 
> CONFIG_REGPARM?

Argh.  It was too early in the morning (late at night?).  Yes.

>>>Ouch and now that suspend-to-ram more or less works for you, can you
>>>submit update to Doc*/power/video.txt?
>>
>>Will do if I get it working.  more-or-less is simply not good enough (or
>>should I just make a note there?).
> 
> It is good enough for video.txt. It describes how to get _video_
> working, and video works just ok for you.

You should have received the patch.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

[ACPI] Add Toshiba Satellite P10-792 to Doc*/power/video.txt

[Jaco K. <jk...@kr...>]

This patch adds the Toshiba Satellite P10-792 to the list of systems where video can be made to work during suspend-to-ram.

Signed-of-by: Jaco Kroon <ja...@kr...>

--- linux/Documentation/power/video.txt.orig	2005-12-24 09:57:04.000000000 +0200
+++ linux/Documentation/power/video.txt	2005-12-24 09:57:15.000000000 +0200
@@ -134,6 +134,7 @@
 Toshiba Satellite 4080XCDT      s3_mode (3)
 Toshiba Satellite 4090XCDT      ??? (*)
 Toshiba Satellite P10-554       s3_bios,s3_mode (4)(****)
+Toshiba Satellite P10-792       s3_bios,s3_mode (4)(****)
 Toshiba M30                     (2) xor X with nvidia driver using internal AGP
 Uniwill 244IIO			??? (*)
 

Re: [ACPI] Toshiba Satellite P10

[Pavel M. <pa...@su...>]

Hi!

> > Okay, what *other* patches do you have installed? What kernel are you
> > running? 2.6.15-rc6?
> 
> I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can
> always get the VI patch to rc6).  Was intending to run the acpi_include
> patch, but since that is a standard option in 2.6.14.x I never actually
> pulled in that patch, so no other patches and I've backed out suspend2
> now.  Will also give 15rc6 a go in the morning.

rc5 should be good enough.

> >>This feels like a post-wakeup racecondition to me... Disabling the big
> >>kernel lock preemption think again... yes, seems to be working better
> >>now.  Suspending to ram and then to disk still fails.  (resume from mem
> >>works, can do make menuconfig - a few times - and then it starts
> >>suspend-to-disk process and then just hangs).
> > 
> > So... there's no module to blame? I do have CONFIG_PREEMPT=y and
> > CONFIG_PREEMPT_BKL=y set here, but there were some problems with those
> > before, so keeping it disabled may be wise.
> 
> I've also found that I forgot to disable registers.  Neither made a
> difference though.

CONFIG_REGPARM?

> > Ouch and now that suspend-to-ram more or less works for you, can you
> > submit update to Doc*/power/video.txt?
> 
> Will do if I get it working.  more-or-less is simply not good enough (or
> should I just make a note there?).

It is good enough for video.txt. It describes how to get _video_
working, and video works just ok for you.

							Pavel
-- 
Thanks, Sharp!

Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

Pavel Machek wrote:
> Hi!
> 
> 
>>... and I didn't get the rest cause as soon as I accidentally pressed a
>>key it powered down ...
>>
>>It halted directly after "Shutting down hda" (can't remember the exact
>>message).  Powering up resuming worked just fine.  Including issues I
>>had with suspend-to-ram (described below).
> 
> Okay, what *other* patches do you have installed? What kernel are you
> running? 2.6.15-rc6?

I'm trying with 2.6.14.3, but I've got 2.6.15rc5 available here (can
always get the VI patch to rc6).  Was intending to run the acpi_include
patch, but since that is a standard option in 2.6.14.x I never actually
pulled in that patch, so no other patches and I've backed out suspend2
now.  Will also give 15rc6 a go in the morning.

>>This happened at least twice.  Having to hit some key to make it go away
>>is probably not the biggest issue I've had in my life, I guess if need
>>be I can live with that.
> 
> I have seen that before with acpi vgapost or something like
> that... Strange. Can you insert printks to find out what is going on?

In the morning.

>>This feels like a post-wakeup racecondition to me... Disabling the big
>>kernel lock preemption think again... yes, seems to be working better
>>now.  Suspending to ram and then to disk still fails.  (resume from mem
>>works, can do make menuconfig - a few times - and then it starts
>>suspend-to-disk process and then just hangs).
> 
> So... there's no module to blame? I do have CONFIG_PREEMPT=y and
> CONFIG_PREEMPT_BKL=y set here, but there were some problems with those
> before, so keeping it disabled may be wise.

I've also found that I forgot to disable registers.  Neither made a
difference though.

> Ouch and now that suspend-to-ram more or less works for you, can you
> submit update to Doc*/power/video.txt?

Will do if I get it working.  more-or-less is simply not good enough (or
should I just make a note there?).

>>If I posted my DSDT, could you possibly take a look?  It seems that the
>>compiler error message doesn't mean what it says.  Under certain
>>conditions it will complain if a certain string is set but some index is
>>not.  And I don't know enough with regards to DSL to be able to spot the
>>errors.
> 
> I'm not DSDT expert, sorry. (And problem is probably not in DSDT
> anyway).

Figured.

Thanks for you patience on this.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

Re: [ACPI] Toshiba Satellite P10

[Pavel M. <pa...@su...>]

Hi!

> ... and I didn't get the rest cause as soon as I accidentally pressed a
> key it powered down ...
> 
> It halted directly after "Shutting down hda" (can't remember the exact
> message).  Powering up resuming worked just fine.  Including issues I
> had with suspend-to-ram (described below).

Okay, what *other* patches do you have installed? What kernel are you
running? 2.6.15-rc6?

> This happened at least twice.  Having to hit some key to make it go away
> is probably not the biggest issue I've had in my life, I guess if need
> be I can live with that.

I have seen that before with acpi vgapost or something like
that... Strange. Can you insert printks to find out what is going on?

> This feels like a post-wakeup racecondition to me... Disabling the big
> kernel lock preemption think again... yes, seems to be working better
> now.  Suspending to ram and then to disk still fails.  (resume from mem
> works, can do make menuconfig - a few times - and then it starts
> suspend-to-disk process and then just hangs).

So... there's no module to blame? I do have CONFIG_PREEMPT=y and
CONFIG_PREEMPT_BKL=y set here, but there were some problems with those
before, so keeping it disabled may be wise.

Ouch and now that suspend-to-ram more or less works for you, can you
submit update to Doc*/power/video.txt?

> If I posted my DSDT, could you possibly take a look?  It seems that the
> compiler error message doesn't mean what it says.  Under certain
> conditions it will complain if a certain string is set but some index is
> not.  And I don't know enough with regards to DSL to be able to spot the
> errors.

I'm not DSDT expert, sorry. (And problem is probably not in DSDT
anyway).

								Pavel
-- 
Thanks, Sharp!

Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

Pavel Machek wrote:
> Hi!
> 
> 
>>>But try _minimal config_, first.
>>
>>Doesn't include CONFIG_NET imho, but kernel/power/ui.h (part of
>>suspend2?) doesn't compile without it.  I can probably write a patch,
>>the problem seems to be that ui_helper_data only gets declared if
>>CONFIG_NET is set, but it gets used elsewhere even if CONFIG_NET is
>>not set.
> 
> You did not tell me your kernel contains suspend2. Revert those
> patches. In-kernel code tends to have less bells/whistles, but seems
> more reliable to me. (And it is the only one I can help you with.)

Oops.  Reverted.

Still does the same thing though, doing:

# echo shutdown > /sys/power/disk
# echo disk > /sys/power/state

(then on that special VT):

Stopping tasks: =========|
Freeing memory... done (0 pages freed)
swsusp: Need to copy 10553 pages
swsusp: critical section/: done (10595 pages copied)
ACPI: PCI Interrupt 0000:00:14:

... and I didn't get the rest cause as soon as I accidentally pressed a
key it powered down ...

It halted directly after "Shutting down hda" (can't remember the exact
message).  Powering up resuming worked just fine.  Including issues I
had with suspend-to-ram (described below).

This happened at least twice.  Having to hit some key to make it go away
is probably not the biggest issue I've had in my life, I guess if need
be I can live with that.

>>Setting CONFIG_NET works around this problem.
>>
>>With almost nothing in the kernel though (only what is essential to make
>>it boot) suspend-to-ram works.  Still suspend-to-disk though.
>>
>>Guess it's time to go find the module that causes the problem and fix it
>>(if I can figure it out).
> 
> Yep ;-). Keep us updated with name of offending module.

Actually, I lie.  There are weird lockups.  I can typically do "echo
foo", or "ls", but I for example can't run make, diff or anything funky
(mount without any params works but mount -o rw,remount /boot locks up).
 This may be due to incompatibilities with the running kernel and the
installed glibc but I somehow suspect this is not the case.  I can also
post my kernel config somewhere if that would help.

In both cases issues any further suspend/resume commands locks up the
system.  As in this could also be that caused the lockup after resuming
from ram.  Indeed.  Retrying the suspend-to-ram and then performing a
remount works.  However, running make menuconfig in /usr/src/linux after
that does not.

This feels like a post-wakeup racecondition to me... Disabling the big
kernel lock preemption think again... yes, seems to be working better
now.  Suspending to ram and then to disk still fails.  (resume from mem
works, can do make menuconfig - a few times - and then it starts
suspend-to-disk process and then just hangs).

Guess I should start by enable many more of those kernel debugging
options ..., right now I need some sleep however.

If I posted my DSDT, could you possibly take a look?  It seems that the
compiler error message doesn't mean what it says.  Under certain
conditions it will complain if a certain string is set but some index is
not.  And I don't know enough with regards to DSL to be able to spot the
errors.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

Matthew Garrett wrote:
> On Fri, Dec 23, 2005 at 08:44:34AM +0200, Jaco Kroon wrote:
> 
> 
>>LOL!  I wish.  fglrx is the ati binary drivers (as asked in the response 
>>from Pavel).  According to another friend of mine the answer to this one 
>>is no.  He can suspend/resume his notebook as long as he's using the 
>>opensource radeon driver and not fglrx.  He's not using a P10 though.
> 
> 
> The latest fglrx should support suspend/resume. I don't think any 
> distributions include it yet, so you'll have to get it from ati.com.
> 

Sweet.  Trust me, upgrading those drivers is almost as important as
keeping your system secure.  They are probably my worst experience in
Linux - matched only by a very weird bug in OpenLDAP which turned out to
be a permissions problem caused by udev default permissions of 600 on
/dev/urandom (SSL failed to initialise).  I'm currently running version
8.20.8 of the ati drivers (On Gentoo - only one way to live Linux:  be
one with the source).  This also seems to be the newest version
available - so just maybe I'm lucky.  Not that I feel very lucky right
at this moment :p.

Jaco
-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

Re: [ACPI] Toshiba Satellite P10

[Matthew G. <mj...@sr...>]

On Fri, Dec 23, 2005 at 08:44:34AM +0200, Jaco Kroon wrote:

> LOL!  I wish.  fglrx is the ati binary drivers (as asked in the response 
> from Pavel).  According to another friend of mine the answer to this one 
> is no.  He can suspend/resume his notebook as long as he's using the 
> opensource radeon driver and not fglrx.  He's not using a P10 though.

The latest fglrx should support suspend/resume. I don't think any 
distributions include it yet, so you'll have to get it from ati.com.

-- 
Matthew Garrett | mj...@sr...

Re: [ACPI] Toshiba Satellite P10

[Pavel M. <pa...@su...>]

Hi!

> > But try _minimal config_, first.
> 
> Doesn't include CONFIG_NET imho, but kernel/power/ui.h (part of
> suspend2?) doesn't compile without it.  I can probably write a patch,
> the problem seems to be that ui_helper_data only gets declared if
> CONFIG_NET is set, but it gets used elsewhere even if CONFIG_NET is
> not set.

You did not tell me your kernel contains suspend2. Revert those
patches. In-kernel code tends to have less bells/whistles, but seems
more reliable to me. (And it is the only one I can help you with.)

> Setting CONFIG_NET works around this problem.
> 
> With almost nothing in the kernel though (only what is essential to make
> it boot) suspend-to-ram works.  Still suspend-to-disk though.
> 
> Guess it's time to go find the module that causes the problem and fix it
> (if I can figure it out).

Yep ;-). Keep us updated with name of offending module.

								Pavel
-- 
Thanks, Sharp!

Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

Pavel Machek wrote:
> But try _minimal config_, first.

Doesn't include CONFIG_NET imho, but kernel/power/ui.h (part of
suspend2?) doesn't compile without it.  I can probably write a patch,
the problem seems to be that ui_helper_data only gets declared if
CONFIG_NET is set, but it gets used elsewhere even if CONFIG_NET is not set.

Setting CONFIG_NET works around this problem.

With almost nothing in the kernel though (only what is essential to make
it boot) suspend-to-ram works.  Still suspend-to-disk though.

Guess it's time to go find the module that causes the problem and fix it
(if I can figure it out).

>>And that is where it all stops.
> 
> See Doc*/power/swsusp.txt. suspend to disk should be easier to fix.

That didn't really teach me anything new.

-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

[ACPI] [PATCH] identify which device is not power-manageable

[Randy.Dunlap <rd...@xe...>]

From: Jae-hyeon Park <jh...@tu...>

Identify which device is not power-manageable to make
the message more useful.

Signed-off-by: Randy Dunlap <rd...@xe...>
---
 drivers/acpi/bus.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

--- linux-2615-rc6g4.orig/drivers/acpi/bus.c
+++ linux-2615-rc6g4/drivers/acpi/bus.c
@@ -198,7 +198,8 @@ int acpi_bus_set_power(acpi_handle handl
 
 	if (!device->flags.power_manageable) {
 		ACPI_DEBUG_PRINT((ACPI_DB_WARN,
-				  "Device is not power manageable\n"));
+				  "Device '%s' is not power manageable\n",
+					device->kobj.name));
 		return_VALUE(-ENODEV);
 	}
 	/*


---

Re: [ACPI] Toshiba Satellite P10

[Pavel M. <pa...@su...>]

Hi!

> >>I still haven't managed to finish of the resume process.  The screen 
> >>comes back up and console switching works but that is just about where 
> >>it ends.  I don't see any kernel panic messages either.  Will RTFM and 
> >>fool around some more.
> > 
> > RTFM will not help you here, I'm afraid. Try it with minimal kernel
> > config.
> 
> Ok, that sucks.  This is what I get, one some VT that is not reachable
> with Alt+Fx, I get this:
> 
>          inu
> Back to C!
> ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ
>177


> The inu is in yellow and I presume forms part of the word "Linux".  I
> get this screen when it comes back, from here I can switch to all twelfe
> VTs with Alt+Fx, and back to this screen with Alt+right from tty1.

Yep, "Linux" is printed from assembly header. Fortunately your machine
gets into C, so you'll not have to debug _that_. You can just debug it
using printk().

But try _minimal config_, first.

> On tty1 I can type, but that is the only VT.  This is also the VT I run
> hibernate-ram from.  Auto-repeat however does not function.  The same
> applies when running "echo mem > /sys/power/state"
> 
> When running hibernate it doesn't power down!  This seems odd since
> powerdown works when going "init 0".  Anyhow, the last messages I see is
> this:
> 
> Freezing processes
> Preparing Image.
> Starting to save the image..
> Writing caches...
> Doing atormic copy.
> Writing kernel & process data...
> 
> And that is where it all stops.

See Doc*/power/swsusp.txt. suspend to disk should be easier to fix.

								Pavel
-- 
Thanks, Sharp!

Re: [ACPI] Toshiba Satellite P10

[Jaco K. <ja...@kr...>]

Pavel Machek wrote:
> Hi!
> 
> 
>>>>With regards to the ACPI code though - I've managed to fix all the 
>>>>warnings and errors, except the one about the ResourceSource error, 
>>>>which according to the spec is optional but iasl insists it's required. 
>>>>No idea what I'm going to do about that.  Also not sure whether fixing 
>>>>_WAK to always return a value will actually do something.
>>>
>>>I do not remember that i would have to fix any DSDT bugs, everything worked
>>>with the original DSDT.
>>
>>There is only really one error that bothers me, and I read somewhere 
>>that the kernel doesn't look at it's value, and that is the _WAK call 
>>that doesn't return a value.  Unless that of course changed recently. 
>>And I can't recompile the DSDT due to those ResourceSource required 
>>errors, which seems to be a bug in iasl.
> 
> 
> Fix iasl, then ;-).

Will try when I get back from the movies.  I've seen one other message
that mentioned this same error in iasl, can't remember where though.

>>I still haven't managed to finish of the resume process.  The screen 
>>comes back up and console switching works but that is just about where 
>>it ends.  I don't see any kernel panic messages either.  Will RTFM and 
>>fool around some more.
> 
> RTFM will not help you here, I'm afraid. Try it with minimal kernel
> config.

Ok, that sucks.  This is what I get, one some VT that is not reachable
with Alt+Fx, I get this:

         inu
Back to C!
ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 177

The inu is in yellow and I presume forms part of the word "Linux".  I
get this screen when it comes back, from here I can switch to all twelfe
VTs with Alt+Fx, and back to this screen with Alt+right from tty1.

On tty1 I can type, but that is the only VT.  This is also the VT I run
hibernate-ram from.  Auto-repeat however does not function.  The same
applies when running "echo mem > /sys/power/state"

When running hibernate it doesn't power down!  This seems odd since
powerdown works when going "init 0".  Anyhow, the last messages I see is
this:

Freezing processes
Preparing Image.
Starting to save the image..
Writing caches...
Doing atormic copy.
Writing kernel & process data...

And that is where it all stops.

That is all I've managed to become wizer today.  Really not particularly
usefull I know.  Sorry for the noise.

-- 
There are only 10 kinds of people in this world,
  those that understand binary and those that don't.
http://www.kroon.co.za/

Re: [ACPI] Toshiba Satellite P10

[Sebastian H. <ac...@ko...>]

howdy folks..

* Jaco Kroon <ja...@cs...> [2005-12-23 12:16 +0100]:
> Stefan Seyfried wrote:
> >On Thu, Dec 22, 2005 at 03:59:26PM +0200, Jaco Kroon wrote:
>=20
> LOL!  I wish.  fglrx is the ati binary drivers (as asked in the response=
=20
> from Pavel).  According to another friend of mine the answer to this one=
=20
> is no.  He can suspend/resume his notebook as long as he's using the=20
> opensource radeon driver and not fglrx.  He's not using a P10 though.

ATI has introduced support for suspension recently, since version 8.19.x
or so.=EE=80=80i had good luck in S3+S4 with the latest drivers on Samsung =
X20
and IBM T43p.

cheers,
 Sebastian
--=20
 _   ascii ribbon campaign     .oOo.   GCSd-s:+aC++ULB+++W++M+PS+++Y+
( )
 X   Jeden Tag eine Erisische Tat!
/ \ =20

[ACPI] Re: [PATCH] Work around asus_acpi driver oopses on Samsung P30s and the like due to the ACPI implicit return

[Karol K. <sz...@he...>]

Thus wrote Christian Aichinger:
> > Here it goes. Rediffed, also plugs a leak my previous patch introduced. I
> > believe it addresses Linus' comments. It's still not a proper fix (see
> > below), but I believe it's better than none.
> > Best regards,
> This will break other hardware as the P30/P35 as well, since there
> are some buggy DSDT's out there that return an ACPI_TYPE_BUFFER.

I've never seen one, I'd like to look at those if you've got them. Are you
sure it's the actual machine code that returns buffers, and not an implicit
return of the interpreter?

> That's the whole reason why I was testing exactly for
> ACPI_TYPE_INTEGER in my patch.

I don't really seem to follow: my logic checks for ACPI_TYPE_STRING, and if
not found, looks at DSDT signatures. If something different than a string
is returned by INIT _and_ the machine isn't a P30/P35 (DSDT sigs) then the
defaults are set as in every other case a machine is not recognized by the
driver.

> My first version was pretty simmilar to yours, until I was told on
> acpi-devel that this breaks someone elses hardware (causing it to be
> considered as P30/P35, while it isn't). I can dig up the mails if
> you want.

The original driver behaviour was: ( if INIT returns NULL && DSDT sigs
match ) machine is a P30. My patch changes that to ( if INIT returns
!ACPI_TYPE_STRING && DSDT sigs match ) machine is a P30. I'd like to see
those reports please.
Best regards,

-- 
Karol 'sziwan' Kozimor
sz...@he...

[ACPI] Re: [PATCH] Work around asus_acpi driver oopses on Samsung P30s and the like due to the ACPI implicit return

[Christian A. <Gr...@gm...>]

On Thu, Dec 22, 2005 at 06:42:26PM +0100, Karol Kozimor wrote:
> Thus wrote Brown, Len:
> > Karol,
> > Do you have an update of your asus driver in the pipeline
> > that addresses this?
>=20
> Here it goes. Rediffed, also plugs a leak my previous patch introduced. I
> believe it addresses Linus' comments. It's still not a proper fix (see
> below), but I believe it's better than none.
> Best regards,

This will break other hardware as the P30/P35 as well, since there
are some buggy DSDT's out there that return an ACPI_TYPE_BUFFER.
That's the whole reason why I was testing exactly for
ACPI_TYPE_INTEGER in my patch.

My first version was pretty simmilar to yours, until I was told on
acpi-devel that this breaks someone elses hardware (causing it to be
considered as P30/P35, while it isn't). I can dig up the mails if
you want.

Cheers,
Christian