[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: can't restore from suspend



Emma Jane Hogbin [Donnerstag, 17. April 2003 02:12]:
>| which says APM isn't supported. (Which means I need to stick with ACPI to
>| get my overclocked fan under control.)
Perhaps it wasn't the fan but the cpu who was overclocked ?
Anyway an acpi issue, then.
>| Because I can't find what's triggering the suspend. :(
Hmm... how to find out ?
It would first find out if there's a timeout (idle time after that the event 
occurs).
btw is the battery status recognized correctly (at least the fact it's 
plugged into main) ?

>| > One point to start analyzing is the output of:
>| > dmesg
>| I've already pasted that to the list.
Yes, of course. Just for completness.
>| > cat /proc/acpi/dsdt
>| that's a binary file
ok...so i guess it's more for real acpi specialists ... sorry that i butted I 
just like weird problems, true. I'm sure anybody else on this list can help 
you more than me. (Perhaps they're on holiday ?)
 t's said on the developer.intel.com site one should attach the dsdt to 
problem reports. However, my impression is the device table to be more 
important with booting problems.
Hey, there _must_ be some people around the world running exactly your laptop 
with linux ! Some of them with acpi working .... 
Perhaps you ask the acpi (+/- developer) list if there are any problems known 
special to yours.
>| > lspci
>| > cat /proc/cpuinfo
Just for some standard overview, when psoting problems to experts 
( t.i., the acpi-developer-list, e.g.). Anyway sometimes external devices or 
internal chipsets tell stories... 
>| I'm not sure at what point the system suspends...
No idle-time ? The other two cases i know are battery low and cpu overheat.
>| and if I were to type in
>| any commands the system wouldn't suspend.
Probably (but not prooven) right ! ;-)
If you would know the time span, you could possibly arrange an 'at' job (with 
atd, the at-daemon) Just wild ideas, you see. 
... Anyway better you'd find the event handling ... i imagine somthing 
similar to /etc/apm/ directory here. 'man acpid' must reveal this, if it 
exists. But maybe all echo > /proc/acpi is done by 'frontends' now ?

>| I had kde (just installed fluxconf which un-installed kde stuff). But the
>| power management tools were all turned OFF. (I checked.)
klaptopdaemon ? sleepd ? daemons are always suspisious. It's their nature ;-)
>| Not sure. It was supposed to be KDE and the matrix screen saver but
>| something else was overriding it and giving a black screen.
Something ! It's funny, isn't it ;-)
Usually, I'd say this is the BIOS, then. What does it's config say ?
One more idea. There's a powermanagement-option in /etc/XF86Config-4.
It's for 'green' monitors, not for laptop-lcd's, afaik. But wdikaa...

I'm not sure how KDE settle things down. If once configured some 'flags' (or 
files) would'nt they stay until somebody's gonna change things again ?

>| Tried there as well. All of what I found was "works for me out of the
>| box."
After all the problems i heard about acpi i hardly can believe that ....
 
>| Ugh. Again, I'm missing stuff that is supposed to be there. This time it's
>| hte contents of:
>| /proc/acpi/processor/0/info
It's no more called /proc/acpi/processor/CPU0/info ?
>| I have <TBD> instead of something like this:
yes, please !
>|  This should look like this:
>|  processor id:            0
>|  acpi id:                 0
>|  bus mastering control:   no
>|  power management:        yes
>|  throttling control:      yes
>|  performance management:  no
>|  limit interface:         yes
If this is not existent i would wonder if the patching was alright...
( btw. perhaps you try kernel 2.5.6 ? But i can't say what this would imply 
to install, then. Perhaps someone else on this list is running a 2.5 kernel ?)

I think what we really do need is a dedicated laptop distro.
If i remember right, Werner Heuser proposed this already...
                                                                              
                      micha.



Reply to: