Wed 31 Aug 2005 12:46:56 PM UTC, comment #12:
OK. I've made the change. I will be posting 2.1.0-pre8 tomorrow. Thanks again for your help.
|
Wed 31 Aug 2005 09:04:05 AM UTC, comment #11:
It is OK except of minor term...
suspend1 in the new kernel uses the same interface of suspend2... but in order not to alarm people... don't state that they have suspend2...
if [ $LINUX26_USE_TRYTOFREEZE -ne 0 ]
then
- echo "ok (suspend2)"
+ echo "ok (suspend1 or suspend2)"
else
echo "ok (suspend1)"
fi
|
Mon 29 Aug 2005 06:57:23 PM UTC, comment #10:
I have committed a similar version of your patch to CVS. Rather than using "ifdef PF_FREEZE" I have the "configure" script actually look to see which suspend is being used. (PF_FREEZE is defined for suspend1 and suspend2.)
Please check out the current CVS version and let me know if it is ok for you. (It is functionally identical to your patch, so I assume it will be ok.)
$ env CVS_RSH="ssh" cvs -z3 \
-d:ext:anoncvs@subversions.gnu.org:/cvsroot/dazuko \
co dazuko
Once I get the ok from you, I will post a 2.1.0-pre8 version. Thanks for all your help on this.
|
Sun 28 Aug 2005 05:19:47 PM UTC, comment #9:
Hi,
1. There are two methods of suspend... suspend1 and suspend2.
suspend1 had the refregerator.
suspend2 has try_to_freeze in linux/sched.h
as for vanilla 2.6.13 there is only one method: try_to_freeze
this why if PF_FREEZE is not defined I use try_to_freeze.
This way the modules compiles for both suspend1 or suspend2, 2.6.12 or 2.6.13.
Please read Documentation/power/swsusp.txt regarding try_to_freeze.
suspend2 is about to merge so many modifications are moved to the kernel.
2. I think the while (1) should always performed regardless of te PF_FREEZE... since you can always be interrupted by suspend.
But I don't think you need to while (1) since I think it is OK to wakeup and find no events in queue...
This way most of kernel drivers are written... (Most that I've read) they have a thread that performs the main loop and that's it.
Attached is my updated patch, please have a look.
|
Sun 28 Aug 2005 02:04:59 PM UTC, comment #8:
Hi,
I have 2 comments about your patch:
1. Where does the try_to_freeze() come from? I could not find this function.
2. I believe that we need to wait for the condition again since freezing a process should not be interpretted as success or abort.
I have attached a new patch that I think would be more appropriate. Please comment.
|
Sun 28 Aug 2005 01:32:53 PM UTC, comment #7:
Strange...
I've done nothing... :)
Here it is again...
|
Sun 28 Aug 2005 01:18:50 PM UTC, comment #6:
Hi,
The attached files seemed to have disappeared. ?? They were invalid and so I deleted them. Is it possible that you could post the patch again (or send it directly to me at jogness@antivir.de)?
|
Tue 26 Jul 2005 09:03:55 PM UTC, comment #5:
I forgot to remove return from last patch. sorry.
Attached is a new patch.
|
Tue 26 Jul 2005 06:44:54 PM UTC, comment #4:
It compiles OK for vanilla 2.6.12.2.
I cannot check it but it compiles.
Notice that you don't support suspend1 either... and it is merged into the kernel.
This patch should work with both suspend1 and suspend2.
Again... I am no expert but for my understanding the wait function will receive a signal and then you should try to freeze.
I saw you using wait with signals blocked... it can posses a problem... Please consider not use wait_event.
|
Tue 26 Jul 2005 06:21:42 PM UTC, comment #3:
I'll have to look at the patch in detail. I am concerned that people using a standard kernel will not be able to compile.
|
Tue 26 Jul 2005 05:08:27 PM UTC, comment #2:
Disregard the ebuild... Sorry...
The .patch file is attached.
|
Tue 26 Jul 2005 05:05:32 PM UTC, comment #1:
Please consider the following patch.
I am no kernel modules expert... But it seem to be right according to other samples I've seen.
|
Mon 25 Jul 2005 07:42:57 PM UTC, original submission:
Hello,
It seems that there is a problem with dazuko and software suspend2 (www.suspend2.net).
I use the 2.1.0 pre 7.
Can you please look into this problem?
It seems that it does not allow software suspend 2 to freeze processes.
Best Regards,
Alon Bar-Lev
dmesg
---------------------------------------------------------
Software Suspend 2.1.9.9: Suspending enabled.
Stopping tasks failed.
Tasks that refused to be refrigerated and haven't since exited:
- kdesktop_lock (#32630) signalled but didn't enter refrigerator.
kdesktop_lock D C0361DF0 0 32630 13710 (NOTLB)
cddf9e00 00000082 cf99a510 c0361df0 001004b8 c0116454 c27d4ac0 00000001
cf99a510 00000000 6c124240 001004b8 cf99a510 c4cb6a40 c4cb6b64 cddf9e10
d6c07504 cddf9e44 cddf9e80 d6c01c45 cddf9e80 c0116e98 00000000 c4cb6a40
Call Trace:
[<c0116454>] try_to_wake_up+0xb4/0xc0
[<d6c01c45>] xp_wait_until_condition+0x135/0x170 [dazuko]
[<c0116e98>] __wake_up_common+0x38/0x70
[<c0130190>] autoremove_wake_function+0x0/0x60
[<c0130190>] autoremove_wake_function+0x0/0x60
[<c0282705>] preempt_schedule+0x45/0x70
[<d6bfbda2>] dazuko_run_daemon_on_slotlist+0x102/0x240 [dazuko]
[<d6bfa520>] two_slot_state_not_condition+0x0/0xd0 [dazuko]
[<d6bffbba>] dazuko_process_access+0x1aa/0x210 [dazuko]
[<d6c02921>] dazuko_sys_generic+0x1b1/0x200 [dazuko]
[<c0178238>] permission+0xb8/0xe0
[<c0167ddd>] sys_access+0x10d/0x180
[<c01031e5>] syscall_call+0x7/0xb
|