Re: First cut of catch up patch... Still frozen on restore...

Nigel Cunningham wrote:
> Hi.
>
> On 03/01/12 13:25, Woody Suwalski wrote:
>> No I have not. For the last 2 years I have been building kernels with
>> AGP and video built-in.
>> OTOH your suspicion is probably correct, TOI  seems to work fine on
>> EeePC with GMA500 video.
>> However starting in single mode with no kernel mode setting should be as
>> safe as conceptually possible - and kernel itself loads fine - I can see
>> that since I am starting TOI from the ramdisk.
>> So sooner or later it will need to be debugged - just I do not know how
>> to do it?
>>
>> There is no real serial on the boxes, but maybe ttyUSB will do? I will
>> try to create a smarter ramdisk  and channel dmesg to ttyUSB... Just
>> need to find another machine with a real serial port to receive the data
>> ;-)
>>
>> Any hints w hat to look for? Which parts of TOI/kernel sprinkle with more
>> printk's? Any suggestions how to slow it down / flush messages / force
>> some maximum-comatibilty mode? Maybe it is some weird timing problem?
> I wouldn't bother with sprinkling printks, at least not to begin with.
>
> What I would suggest would be to start with booting to init S or
> (better) init=/bin/bash and in the later case, mount /sys, /dev and so
> on. Having done that, try hibernating via:
>
> echo 1>  /sys/power/tuxonice/reboot
> echo 1>  /sys/power/tuxonice/do_hibernate
That is what I was actually doing in the last stage.
So the only drivers used are built-in AGP/i915 video and Intel ATAPIIX 
for hard disk (flash).
That is how I have got the last 2 messages (running without textgui)
(BTW. Is textgui v 1.0.0 too old? I have built it statically ages ago 
and so far was OK?)
>
> If that works, test it a second time. Some bugs in drivers'
That is precisely what does not work 8-(
I have a PC with Intel mobo and it has the same problem as well.
So it may be atapiix or i915 related.

I can try to remove these drivers and boot from USB - maybe that will 
let me find out which one is causing the problem? But then what?


> suspend/resume routines are such that things seem to work okay the first
> time, but die properly on the second attempt.
>
> When you're convinced the current configuration works reliably, add a
> kernel module or service one by one, and retry.
>
> If you find the first attempt doesn't work, look at what's built in to
> the kernel at the moment and see if you can modularise any of it.
>
> You could also try using a serial console and the verbose PM debugging
> compile time option. Another option might be to check out the so-called
> 'Magic number' (if I recall the terminology used correctly) that's
> stored in the clock when the Power Management Debug support is enabled.
> It creates a line in your dmesg at start up that says something like
> "Magic Number", and the values it gives can be used to find the last
> driver suspend/resume call that was made.
Right, I need way more verbosity that I am getting right now. Will these do?

echo 1 > /sys/power/tuxonice/user_interface/debug
echo 7 > /sys/power/tuxonice/user_interface/default_console_level
echo 1 > /sys/power/tuxonice/user_interface/log_everything

I remember that in the "old" times there used to be an option to do a 
"dry run" without actually powering off/resetting... Where is it gone?

How to increase verbosity for PM stuff?
> Regards,
>
> Nigel
Thanks, Woody

Ah, Christmas is over... Back to the human race 8-)