2.5.39 Insomniac, any first dbg?

2.5.39 Insomniac, any first dbg?

[P. Christeas]

Hi, 
I 've compiled 2.5.39 (since Sat.) and it is Insomniac (can't sleep). When I 
'echo [1|4] > /proc/acpi/sleep',  nothing gets logged and nothing happens.
I also tried S2, the system re-booted (after hard lock).
Do you have any first dbg comments? Where should I start debugging from?

Details:
2.5.39 on HP Xe3 GC
kernel: uni-proc, APIC, IO-APIC (don't work, I think, but are compiled in).
ACPI: 20020918, all enabled, also tried with 'debug statements' set. It 
reports it can do S0,1,2,3,4,5 ..

I echo to /proc/acpi/sleep. Nothing happens, nothing gets logged for 1,4.
I looked into kernel/suspend.c and acpi/sleep.c . Which fn's can cause the 
sleep procedure to fail w/o notices?




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

Re: 2.5.39 Insomniac, any first dbg?

[Knut Neumann]

Am Mon, 2002-09-30 um 14.41 schrieb P. Christeas:
> Hi, 
> I 've compiled 2.5.39 (since Sat.) and it is Insomniac (can't sleep). When I 
> 'echo [1|4] > /proc/acpi/sleep',  nothing gets logged and nothing happens.

I can confirm that, and I remember Pavel already did too.

> I also tried S2, the system re-booted (after hard lock).
> Do you have any first dbg comments? Where should I start debugging from?

Can you reproduce that? My notebook does not do anything on echoing 1 to
5 to /proc/acpi/sleep.

> Details:
> 2.5.39 on HP Xe3 GC
> kernel: uni-proc, APIC, IO-APIC (don't work, I think, but are compiled in).
> ACPI: 20020918, all enabled, also tried with 'debug statements' set. It 
> reports it can do S0,1,2,3,4,5 ..

I assume it is not system related but has been introduced when
everything got split out to sleep.c though I am not sure about that (I
planned some debugging for tonight)

> I echo to /proc/acpi/sleep. Nothing happens, nothing gets logged for 1,4.
> I looked into kernel/suspend.c and acpi/sleep.c . Which fn's can cause the 
> sleep procedure to fail w/o notices?


Not quite sure...I would start making sure that the kernel actually
notices that something has been echoed to sleep. There must be some
handling of sleep as a proc filesystem entry - maybe in sleep.c. Look
for it. I think starting there makes sense. If you find anything..let me
know...I would not have to do double work then.

-Knut

-- 
Knut Neumann <knut.neumann-4bfl1RV3iZDOEhgYWvzSCYQuADTiUCJX@public.gmane.org>
Physikalische Grundpraktika - Heinrich-Heine Universitaet Duesseldorf
Raum 25.33.01.63  -   Universitaetsstrasse 1   -  D-40225 Duesseldorf
fon: +49-211-81-11314                           fax: +49-211-81-13105











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

Re: 2.5.39 Insomniac, any first dbg?

[P. Christeas]

> > I echo to /proc/acpi/sleep. Nothing happens, nothing gets logged for 1,4.
> > I looked into kernel/suspend.c and acpi/sleep.c . Which fn's can cause
> > the sleep procedure to fail w/o notices?
>
> Not quite sure...I would start making sure that the kernel actually
> notices that something has been echoed to sleep. There must be some
> handling of sleep as a proc filesystem entry - maybe in sleep.c. Look
> for it. I think starting there makes sense. If you find anything..let me
> know...I would not have to do double work then.
>
> -Knut

I guess that's the point to start from. Did you say there was some code 
splitting in sleep.c? Last kernel that runned fine for me was 2.5.36 (I 
couldn't cleanly compile .37 and .38).
It seems as if the code code in sleep.c doesn't call anything. It was 
interesting, though that S2 did something, where it really wasn't supposed 
to. The /proc entries should be fine. So, the bug must be after the 
'switch(state){ \n case 1: '. You 'll need to add some trace messages in the 
early state of those fn's.

Thanks for the help.



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

Re: 2.5.39 Insomniac, any first dbg?

[Knut Neumann]

Am Mon, 2002-09-30 um 15.12 schrieb P. Christeas:
> I guess that's the point to start from. Did you say there was some code 
> splitting in sleep.c? Last kernel that runned fine for me was 2.5.36 (I 
> couldn't cleanly compile .37 and .38).

IIRC Patrick Mochel splitted the sleep stuff out from system.c into
sleep.c in 2.5.37

> It seems as if the code code in sleep.c doesn't call anything. It was 
> interesting, though that S2 did something, where it really wasn't supposed 
> to. The /proc entries should be fine. So, the bug must be after the 
> 'switch(state){ \n case 1: '. You 'll need to add some trace messages in the 
> early state of those fn's.

Hmmm...just had a quick look at the code...can you _confirm_ that
acpi_system_write_sleep gets called and that state has a correct value
(aka the one you echoed to /proc/acpi/sleep) after the following line:

state = simple_strtoul(state_string, NULL, 0);?

Since software_suspend() gets called from there and IIRC thats not part
of the acpi subsytem I wonder why S4 would not work in case state is 
correctly set there...

Anyway, thats only a quick shot assumption so do not flame in case 
I am plain wrong ;)

-Knut

-- 
Knut Neumann <knut.neumann-4bfl1RV3iZDOEhgYWvzSCYQuADTiUCJX@public.gmane.org>
Physikalische Grundpraktika - Heinrich-Heine Universitaet Duesseldorf
Raum 25.33.01.63  -   Universitaetsstrasse 1   -  D-40225 Duesseldorf
fon: +49-211-81-11314                           fax: +49-211-81-13105











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

Sleeping pills for the 2.5.39 Insomnia ..

[P. Christeas]

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

> Since software_suspend() gets called from there and IIRC thats not part
> of the acpi subsytem I wonder why S4 would not work in case state is
> correctly set there...
>
> Anyway, thats only a quick shot assumption so do not flame in case
> I am plain wrong ;)
>

I already solved the bug. Don't try any more..

To A.Grover: please apply the patch (or just the '!' yourself).
I'd like the two extra messages to be always logged. It's your call to keep 
them.

Can you give me a one-line explanation for those messages I get with S4? Is 
the S1 warning of any importance?

[-- Attachment #2: sleep.diff --]
[-- Type: text/x-diff, Size: 1060 bytes --]

diff -bBaur ./drivers/acpi/sleep.c /usr/src/linux/drivers/acpi/sleep.c
--- ./drivers/acpi/sleep.c	2002-09-28 14:05:32.000000000 +0300
+++ /usr/src/linux/drivers/acpi/sleep.c	2002-09-30 19:11:58.000000000 +0300
@@ -329,8 +329,9 @@
 	state_string[count] = '\0';

 	state = simple_strtoul(state_string, NULL, 0);
+	printk(KERN_INFO PREFIX "sleep: S%d written\n", state);

-	if (sleep_states[state])
+	if (!sleep_states[state])
 		return_VALUE(-ENODEV);

 #ifdef CONFIG_SOFTWARE_SUSPEND
@@ -341,6 +342,8 @@
 #endif
 	status = acpi_suspend(state);

+	printk(KERN_INFO PREFIX "sleep: S%d resumed w. status 0x%x\n", state, status);
+
 	if (ACPI_FAILURE(status))
 		return_VALUE(-ENODEV);

@@ -665,7 +668,7 @@
 	if (acpi_disabled)
 		return_VALUE(0);

-	printk(KERN_INFO PREFIX "(supports");
+	printk(KERN_INFO PREFIX "Sleep supports");
 	for (i=0; i<ACPI_S_STATE_COUNT; i++) {
 		u8 type_a, type_b;
 		status = acpi_get_sleep_type_data(i, &type_a, &type_b);
@@ -674,7 +677,7 @@
 			printk(" S%d", i);
 		}
 	}
-	printk(")\n");
+	printk("\n");


 	/* 'sleep' [R/W]*/


[-- Attachment #3: messages.bz2 --]
[-- Type: application/x-bzip2, Size: 609 bytes --]