[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
VTSWITCH vs. Timers vs. Sleep Mode
From: "Gil Glass" ####@####.#### Date: 30 Nov 2006 20:12:01 +0000 Message-Id: <6ECE57DF49376146B91A92A3C37EFC0E026A72BF@SJEXCH03.ds.jdsu.net> Hello, I'd written a while back saying that I was unable to get GrGetNextEventTimeout() to work correctly. Greg suggested that I check whether VTSWITCH was set to 'Y' in my config file and it turned out that it was. Not remembering why I'd set it to 'Y', I changed it to 'N' and, all of a sudden, GrGetNextEventTimeout() began working correctly. HOWEVER, I've come to realize that the reason I had VTSWITCH set to 'Y' is because if it is not, then I cannot place my hardware into sleep mode using the power manager, i.e. writing "mem" to /sys/power/state. I don't understand how VTSWITCH and the power state are connected but if I have VTSWITCH set to 'N', then the unit just hangs up and does not enter the sleep state. I'm hoping someone can help. Both the hardware sleep and the GrGetNextEventTimeout() are quite critical to my project. Thanks. Gil Glass Senior Software Engineer Telecom Field Services Division JDSU Germantown, MD, USA +1 (240) 404-2551 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [nanogui] VTSWITCH vs. Timers vs. Sleep Mode
From: "Greg Haerr" ####@####.#### Date: 30 Nov 2006 23:55:33 +0000 Message-Id: <013f01c714da$fe1c1db0$6401a8c0@winXP> > HOWEVER, I've come to realize that the reason I had VTSWITCH set to 'Y' is because if it is not, then I cannot place my hardware into sleep mode using the power manager, i.e. writing "mem" to /sys/power/state. I don't understand how VTSWITCH and the power state are connected but if I have VTSWITCH set to 'N', then the unit just hangs up and does not enter the sleep state. Hmmm. You should study the vtswitch.c code carefully, I can think of a couple possibilities: perhaps without vtswitch, the system never assigns a text console and it can't determine when the system should sleep? Also try commenting out a few lines of the vtswitch code while enabled, (like the signal() calls, then ioctl()s). This will give a better understanding of what is required for your power manager. Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: [nanogui] VTSWITCH vs. Timers vs. Sleep Mode
From: "Gil Glass" ####@####.#### Date: 1 Dec 2006 16:29:18 +0000 Message-Id: <6ECE57DF49376146B91A92A3C37EFC0E026A7779@SJEXCH03.ds.jdsu.net> Thanks, Greg. I have come up with a hack that I THINK solves my problem. I'm wondering whether you know of any hidden gotchas that I may have introduced. The problem with having VTSWTICH enabled was that the 50 millisecond timer created in srvmain.c to periodically check for VT switches was superseding my 1000 millisecond timer created by my call to GrGetNextEventTimeout(&e, 1000) Since I never do any VT switching during operation of my application, I went in and heartlessly commented out the GdAddTimer(50, CheckVtChange, NULL) calls in srvmain.c -- the one that initiates the VT switch checking and the one that perpetuates it. This means, AS I UNDERSTAND IT, that Nano-X will not check for VT changes on a regular basis and I'm hoping that his is OK! With this change in place, my GrEventGetNextTimeout() appears to work and the hardware does enter sleep mode when I command it to do so. I'm keeping my fingers crossed that I have not introduced some anomaly that's going to come back to bite me when the planets align on the second Tuesday in February. ;-) Cheers, Gil -----Original Message----- From: Greg Haerr ####@####.#### Sent: Thursday, November 30, 2006 6:55 PM To: Gil Glass; ####@####.#### Subject: Re: [nanogui] VTSWITCH vs. Timers vs. Sleep Mode > HOWEVER, I've come to realize that the reason I had VTSWITCH set to 'Y' is because if it is not, then I cannot place my hardware into sleep mode using the power manager, i.e. writing "mem" to /sys/power/state. I don't understand how VTSWITCH and the power state are connected but if I have VTSWITCH set to 'N', then the unit just hangs up and does not enter the sleep state. Hmmm. You should study the vtswitch.c code carefully, I can think of a couple possibilities: perhaps without vtswitch, the system never assigns a text console and it can't determine when the system should sleep? Also try commenting out a few lines of the vtswitch code while enabled, (like the signal() calls, then ioctl()s). This will give a better understanding of what is required for your power manager. Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [nanogui] VTSWITCH vs. Timers vs. Sleep Mode
From: "Greg Haerr" ####@####.#### Date: 6 Dec 2006 23:30:33 +0000 Message-Id: <06df01c7198e$9533aa30$0300a8c0@RDP> > GdAddTimer(50, CheckVtChange, NULL) > This means, AS I UNDERSTAND IT, that Nano-X will not check for VT changes on a regular basis and I'm hoping that his is OK! Yes, that should be OK. > With this change in place, my GrEventGetNextTimeout() appears to work and the hardware does enter sleep mode when I command it to do so. Likely the reason you needed VTSWITCH=Y in the first place has to do with it catching the SIGUSR1 signal. There's nothing else in the vtswitch code doing anything funny, is there? > I'm keeping my fingers crossed that I have not introduced some anomaly that's going to come back to bite me when the planets align on the second Tuesday in February. ;-) It would be interesting to learn why the vtswitch code is required for your sleep mode. Otherwise, you know how programs are, one Tuesday the stars may align without your permission... I think you're fix will work for the long term, however. Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |