RE: 2.5.51: sleep broken

RE: 2.5.51: sleep broken

[Grover, Andrew]

> From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org] 
> > However, /proc/acpi/sleep has all S0 S1 S2 S3 S4 S5
> > When I 'echo 1 >/proc/acpi/sleep', nothing happens.
> > I'll let you know if I have more details..
> I noticed I had some extra dbg code to indicate what's 
> happening in the procfs 
> level.
> Now, it seems that "1" doesn't get written to the acpi/sleep 
> entry. It's a 
> procfs bug.

Look for a msg on 11/30 by Pavel Machek. Apparently the proc code got broken
by the seq_file stuff... supposedly they were going to fix it, but maybe it
would be easier if we all did.

-		entry->write_proc = acpi_system_write_sleep;
+		entry->proc_fops->write = acpi_system_write_sleep;

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51: sleep broken

[P. Christeas]

> > From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org]
> >
> > > However, /proc/acpi/sleep has all S0 S1 S2 S3 S4 S5
> > > When I 'echo 1 >/proc/acpi/sleep', nothing happens.
> > > ... It's a procfs bug.
>
> Look for a msg on 11/30 by Pavel Machek. Apparently the proc code got
> broken by the seq_file stuff... supposedly they were going to fix it, but
> maybe it would be easier if we all did.
>
> -		entry->write_proc = acpi_system_write_sleep;
> +		entry->proc_fops->write = acpi_system_write_sleep;
>
> Regards -- Andy

Sorry, I was quite lazy debugging that. Seems though that 20021205 doesn't 
have that. I'll let you know if it should be pushed into 2.5.52..



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51: sleep broken

[P. Christeas]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

>
> Sorry, I was quite lazy debugging that. Seems though that 20021205 doesn't
> have that. I'll let you know if it should be pushed into 2.5.52..
>
That line should go on, it works.
However, it seems that something is still broken w. sleep.  
Yesterday, 1 out of 2 attempts to sleep,wake failed. The machine froze, with 
an apparent race (the cpu heated up).
Today, I could get an OOPS in 1 of 3 attempts to sleep. I give (early) the 
decoded info (I have no ksyms!? ). Perhaps you could make out sth of the 
trace..

[-- Attachment #2: oops.dec --]
[-- Type: text/plain, Size: 2459 bytes --]

ksymoops 2.4.5 on i686 2.5.51.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -K (specified)
     -l /proc/modules (default)
     -o /lib/modules/2.5.51/ (default)
     -m /boot/System.map (specified)

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
NMI: IOCK error (debug interrupt?)
CPU:    0
EIP:    0060:[acpi_hw_register_read+207/528]    Not tainted
EIP:    0060:[<c01c555f>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00000046
eax: 00000000   ebx: 00000000   ecx: cff54100   edx: 00000000
esi: 00000001   edi: 00000001   ebp: c4fb5eb8   esp: c4fb5e94
ds: 0068   es: 0068   ss: 0068
Stack: 00000010 c4fb5ea8 cff54100 00000000 00feebc0 00000000 00000000 c4fb5ef4
       c032f078 c4fb5edc c01c5271 00000000 00000001 c4fb5ecc 00000000 c4fb5ef4
       c032f0a0 c032f0a8 c4fb5f08 c01c5d9b 00000006 c4fb5ef4 00000001 00003001
Call Trace: [acpi_get_register+97/160]  [acpi_enter_sleep_state+507/608]  [acpi_system_suspend+76/80]  [acpi_suspend+135/192]  [acpi_system_write_sleep+171/224]  [vfs_write+175/288]  [sys_write+60/96]  [syscall_call+7/11]
Call Trace: [<c01c5271>]  [<c01c5d9b>]  [<c01dca9c>]  [<c01dcb27>]  [<c01dcccb>]  [<c014c71f>]  [<c014c82c>]  [<c010a203>]
Code: eb 9f a1 50 5b 39 c0 0f b6 50 58 05 94 00 00 00 c7 04 24 10


>>EIP; c01c555f <acpi_hw_register_read+cf/210>   <=====

>>ecx; cff54100 <END_OF_CODE+fba9e8c/????>
>>ebp; c4fb5eb8 <END_OF_CODE+4c0bc44/????>
>>esp; c4fb5e94 <END_OF_CODE+4c0bc20/????>

Trace; c01c5271 <acpi_get_register+61/a0>
Trace; c01c5d9b <acpi_enter_sleep_state+1fb/260>
Trace; c01dca9c <acpi_system_suspend+4c/50>
Trace; c01dcb27 <acpi_suspend+87/c0>
Trace; c01dcccb <acpi_system_write_sleep+ab/e0>
Trace; c014c71f <vfs_write+af/120>
Trace; c014c82c <sys_write+3c/60>
Trace; c010a203 <syscall_call+7/b>

Code;  c01c555f <acpi_hw_register_read+cf/210>
00000000 <_EIP>:
Code;  c01c555f <acpi_hw_register_read+cf/210>   <=====
   0:   eb 9f                     jmp    ffffffa1 <_EIP+0xffffffa1> c01c5500 <acpi_hw_register_read+70/210>   <=====
Code;  c01c5561 <acpi_hw_register_read+d1/210>
   2:   a1 50 5b 39 c0            mov    0xc0395b50,%eax
Code;  c01c5566 <acpi_hw_register_read+d6/210>
   7:   0f b6 50 58               movzbl 0x58(%eax),%edx
Code;  c01c556a <acpi_hw_register_read+da/210>
   b:   05 94 00 00 00            add    $0x94,%eax
Code;  c01c556f <acpi_hw_register_read+df/210>
  10:   c7 04 24 10 00 00 00      movl   $0x10,(%esp,1)

Re: 2.5.51: sleep broken

[P. Christeas]

I also noted some perculiarity in the code:

in: linux/arch/i386/kernel/acpi.c
in: acpi_reserve_bootmem(void)
...
        if ((&wakeup_end - &wakeup_start) > PAGE_SIZE)
                printk(KERN_CRIT "ACPI: Wakeup code way too big, will crash on 
                      attempt to suspend (0x%8.8lx)\n",
                        (&wakeup_end - &wakeup_start));

--- I added the parameter to see what's happening. The message indicated an 
0x3000 size. (12k)

the comment for the fn says:
 * We allocate a page in low memory for the wakeup
 * routine for when we come back from a sleep state. The
 * runtime allocator allows specification of <16M pages, but not
 * <1M pages.

Are the above lines correct? AFAIK macro PAGE_SIZE = 4096
That would mean that only <4k code is allowed. OK, but the comment suggests 
otherwise...



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51: sleep broken

[Ducrot Bruno]

On Sun, Dec 15, 2002 at 11:56:09PM +0200, P. Christeas wrote:
> I also noted some perculiarity in the code:
> 
> in: linux/arch/i386/kernel/acpi.c
> in: acpi_reserve_bootmem(void)
> ...
>         if ((&wakeup_end - &wakeup_start) > PAGE_SIZE)
>                 printk(KERN_CRIT "ACPI: Wakeup code way too big, will crash on 
>                       attempt to suspend (0x%8.8lx)\n",
>                         (&wakeup_end - &wakeup_start));
> 
> --- I added the parameter to see what's happening. The message indicated an 
> 0x3000 size. (12k)
> 
> the comment for the fn says:
>  * We allocate a page in low memory for the wakeup
>  * routine for when we come back from a sleep state. The
>  * runtime allocator allows specification of <16M pages, but not
>  * <1M pages.
> 
> Are the above lines correct? AFAIK macro PAGE_SIZE = 4096
> That would mean that only <4k code is allowed. OK, but the comment suggests 
> otherwise...

Search for wakeup_stack under acpi_wakeup.S
I have modified that and it look something like that for me now:

.org 0x800
wakup_stack:
.org 0x900
ENTRY(wakup_end)
.org 0x1000

(hint given by Pavel)

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51: sleep broken

[P. Christeas]

> Search for wakeup_stack under acpi_wakeup.S
> I have modified that and it look something like that for me now:
>
> .org 0x800
> wakup_stack:
> .org 0x900
> ENTRY(wakup_end)
> .org 0x1000
>
> (hint given by Pavel)

Looks already OK. Shouldn't the comments reflect that behaviour?



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51: sleep broken

[P. Christeas]

>
> .org 0x800
> wakup_stack:
> .org 0x900
> ENTRY(wakup_end)
> .org 0x1000
>

...correction: not OK!

that's "stack", not "start" !

.org    0x2000
wakeup_stack:
	^^^^^^^^^^
.org    0x3000
ENTRY(wakeup_end)

I found "start" in the begining of the assembly.
Did you write the code in the first place?

One more thing, the resume OOPS did happen again, w. 2.5.52. I couldn't grab 
it..



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

2.5.51: sleep broken

[P. Christeas]

I 've just tested the 2.5.51 (w. official 20021205 ACPI)
I noted that S1 is broken now (had worked long since)

In dmesg I note:
ACPI: Wakeup code way too big, will crash on attempt to suspend

However, /proc/acpi/sleep has all S0 S1 S2 S3 S4 S5
When I 'echo 1 >/proc/acpi/sleep', nothing happens.
I'll let you know if I have more details..


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: 2.5.51: sleep broken

[Pavel Machek]

Hi!

> I 've just tested the 2.5.51 (w. official 20021205 ACPI)
> I noted that S1 is broken now (had worked long since)

Still the 2.5.50 bug with sleep writes being ignored?

> In dmesg I note:
> ACPI: Wakeup code way too big, will crash on attempt to suspend

This is about S3
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: 2.5.51: sleep broken

[P. Christeas]

I've had a better look at it...

I have written:
> I 've just tested the 2.5.51 (w. official 20021205 ACPI)
> I noted that S1 is broken now (had worked long since)
>
> In dmesg I note:
> ACPI: Wakeup code way too big, will crash on attempt to suspend
Seems irrelevant.

> However, /proc/acpi/sleep has all S0 S1 S2 S3 S4 S5
> When I 'echo 1 >/proc/acpi/sleep', nothing happens.
> I'll let you know if I have more details..
I noticed I had some extra dbg code to indicate what's happening in the procfs 
level.
Now, it seems that "1" doesn't get written to the acpi/sleep entry. It's a 
procfs bug.



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/