Re: [linux-pm] wait_for_completion_interruptible does not wait !!
On Sun, Jun 20, 2010 at 8:52 AM, Alan Stern st...@rowland.harvard.edu wrote:
What happens if the variable is completed while nobody is waiting for
it? The next time somebody tries to wait, won't the wait terminate
immediately?
Haven't tested it but will reply with the answer once I get a chance to test it.
I tried wait_for_completion instead, but now the kernel refuses to suspend.
I have tried wait queues and mutexs with no success.
Could anyone please point me how I can resolve this issue? Is there
any construct which can block inside the kernel during suspend/resume?
Yes: The freezer.
Can there be a blocking call active while we suspend?
Yes, in theory. In practice it's not a good idea, since the call
wouldn't be able to distinguish between an actual signal and the onset
of a suspend. You might end up with a call that ignores all signals
and hence cannot be interrupted.
Just for the information of others on the list, here is what we did to
solve this issue, we designed a freezer-friendly wrapper around
wait_for_completion_interruptible()
SNIP
#define wait_for_completion_freezable(ptr_completion) \
({ \
int __retval;\
do { \
__retval = wait_for_completion_interruptible(\
ptr_completion); \
if (__retval !freezing(current)) \
break; \
} while (try_to_freeze()); \
__retval;\
})
/SNIP
Thanks
Suresh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
wait_for_completion_interruptible does not wait !!
I have an application which calls the ioctl of the codec driver to know the status of the headset. The ioctl waits on a completion variable (using wait_for_completion_interruptible). The variable is completed in the interrupt handler, which happens on headset insertion/removal. Once the variable is completed, the ioctl returns (with appropriate value in the argument) and the application decides what to do with the event. Once done handling the event, the application then calls the ioctl once again (bascially it polls the audio driver) to know the status of the headset. The call is blocked until the headset status changes. I am running the system on linux-2.6.29 on a OMAP1 based board. All this works well when the OMAP is awake. The problem starts when we suspend the OMAP. The moment we suspend, the wait_for_completion_interruptible is interrupted and the ioctl returns. Application ends up thinking that the headset was either removed/inserted. Our system does an aggressive sleep (wakes up every 500 ms and sleeps again) and hence the application gets the event of headset every 500 ms. I tried wait_for_completion instead, but now the kernel refuses to suspend. I have tried wait queues and mutexs with no success. Could anyone please point me how I can resolve this issue? Is there any construct which can block inside the kernel during suspend/resume? Can there be a blocking call active while we suspend? Ideally I would resort to a method in which I would signal the process when there is a headset event, but I am not free to change the application. Its a legacy application and I have to make the kernel work for it. Thanks in advance, Suresh PS: It might be unrelated, but I am mentioning it here because I learnt this while debugging the issue. If I use an application scheduled as SCHED_FIFO to suspend the kernel (using a driver ioctl which in turn calls enter_state), the operation fails (kernel aborts the process of suspending after 20 seconds saying some applications failed to freeze). Just changing the application scheduling policy to SCHED_OTHER resolves the issue. I was unable to find an explaination for this. However, my current test applications are scheduled as SCHED_OTHER. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wait_for_completion_interruptible does not wait !! [During PM suspend]
On Sun, Jun 20, 2010 at 12:23 AM, Jiri Slaby jirisl...@gmail.com wrote:
On 06/20/2010 08:52 AM, Suresh Rajashekara wrote:
The ioctl waits on a completion variable (using
wait_for_completion_interruptible).
...
I tried wait_for_completion instead, but now the kernel refuses to suspend.
Do you check return value of wait_for_completion_interruptible and
return its value if nonzero?
We need the code to comment, otherwise it's hard to say.
No. I am not checking the return value of the
wait_for_completion_interruptible. I can do it
The code is as follows. I have cut the relevant portion of the code
and pasted in to the email
My test application. The actual application is exactly similar (actual
application has different names)
SNIP
void *headset_detect_thread_start ( void *private_date )
{
int hs_fd = 0;
int iState = 0;
hs_fd = open(/dev/adc, O_RDWR);
if ( hs_fd == -1 ) {
printf(The headset device could not be opened\n);
goto hs_thread_exit;
}
for (;;) {
pthread_testcancel();
ioctl(hs_fd, IOCTL_CODEC_HEADSET_DETECT, iState);
pthread_testcancel();
if ( iState )
printf(\n Headset Insertion detected\n);
else
printf(\n Headset Removal detected\n);
SignalEvent(); // Dummy function, but the actual application
does inside the function
}
hs_thread_out:
close(hs_fd);
hs_thread_exit:
pthread_exit(NULL);
}
/SNIP
Kernel Code:
/* Code from Ioctl of the codec driver*/
SNIP
case IOCTL_CODEC_HEADSET_DETECT:
headset_detect();
headset_detect_state = get_hsdetect_state();
copy_to_user( argp, headset_detect_state, sizeof(int)) ;
break;
/SNIP
implementation of headset_detect in the codec driver
SNIP
void headset_detect(void){
/* This variable is completed in interrupt handler */
wait_for_completion_interruptible(drv_priv-headset_completion);
}
/SNIP
Thanks,
Suresh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Timekeeping issue on aggressive suspend/resume
On Thu, Jun 10, 2010 at 12:52 PM, john stultz johns...@us.ibm.com wrote: I think Thomas was suggesting that you consider creating a option for where CLOCK_MONOTONIC included total_sleep_time. In that case the *hack* (and this is a hack, we'll need some more thoughtful discussion before anything like it could make it upstream) would be in timekeeping_resume() to comment out the lines that update wall_to_monotonic and total_sleep_time. It would be interesting to hear if that hack works for you, and we can try to come up with a better way to think about how to accommodate both views of how to account time over suspend. Thanks. I tried this fix. It seemed to help, however the accuracy of sleep time for the process was not quite right. A process thread which was supposed to wake up every (X) seconds, seemed to wake up every (X - delta X) seconds. Also another side effect of this change was that the system time was no longer in sync with the wall time. These problems were more pronounced when the suspend/wakeup cycle time was brought down to 0.5 seconds from 4 seconds. The periodicity of most of the process threads were disturbed. I decided to NOT suspend/resume the timekeeping subsystem in the kernel and try. It seemed to work. Every application seems to work fine. Now my question is; Is it safe to disable suspend/resume of the timekeeping subsystem? Will it have an effect (on functionality/performance) which may not surface in my short experiments? Thanks in advance, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Timekeeping issue on aggressive suspend/resume
On Wed, Jun 9, 2010 at 1:22 PM, Thomas Gleixner t...@linutronix.de wrote: Though we could change that conditionally - the default would still be the freeze of jiffies and CLOCK_MONOTONIC for historical compability. If I were to change it only for our implementation, and make all the user space timers use CLOCK_REALTIME, then could you please point me in a direction as to what part of the kernel I should be touching to make that change? Earlier we faced issue with time that the application sees. It wasn't getting updated when we suspend and resume the system (where as the time inside the kernel kept updating) and hence eventually would drift from the actual time. for eg, if I use this loop at the command prompt while date do echo mem /sys/power/state done then the date command always displayed the same time, but the prints from the kernel (I was using the printk time information) was advancing as expected. I found a patch at https://patchwork.kernel.org/patch/50070/ Though this fixed the application time update issue, there are lot of timers in the application which is still not working right. Could anyone please point in some direction to find the solution? Thanks, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Timekeeping issue on aggressive suspend/resume
I have an application (running on 2.6.29-omap1) which puts an OMAP1 system to suspend aggressively. The system wakes up every 4 seconds and stays awake for about 35 milliseconds and sleeps again for another 4 seconds. This design is to save power on a battery operated device. This aggressive suspend resume action seems like creating an issue to other applications in the system waiting for some timeout to happen (especially an application which is waiting using the mq_timedreceive and is supposed to timeout every 30 seconds. It seems to wake up every 90 seconds). Seems like the timekeeping is not happening properly in side the kernel. If the suspend duration is changed from 4 second to 1 second, then things work somewhat better. On reducing it to 0.5 second (which was our earlier design on 2.6.16-rc3), the problem seems to disappear. Is this expected? Thanks in advance, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Physical NAND corruption due to extended use
Not sure if its of any use to you, but we had a similar situation and we are now looking at UBI (http://www.linux-mtd.infradead.org/doc/ubi.html). We use JFFS2 and we are considering using it over UBI. We had problems of data corruption in the flash so we now mount only partitions with writable data as RW. Rest of them remain RO and gets remounted as RW only when we want to write to it. Once written, we mount it RO again. Suresh On Wed, Jun 2, 2010 at 12:14 PM, Elvis Dowson elvis.dow...@mac.com wrote: Hi, I've got android-2.6.29 kernel and android-1.5r3 SDK version running on a gumstix Overo Earth (TI OMAP 3503), and I'm using the platform to implement a data logging application. The partition has been configured as read-write /dev/mtd4, with a merged rootfs and system folder. There are no separate /userdata and /cache partitions, all the rootfs, system, userdata and cache folders are on the /dev/mtd4 partition in rw mode. Now after 3 days of extended use and continuous writing, we suspect a potential corruption of the NAND device (a micron 256MB FLASH, 256MB RAM POP module). Has anyone else found micron NAND devices to get corrupted due to extended use? What options should I consider if I want to run my application from NAND and write data to the on-board NAND, and run the application reliably without corrupting the NAND device for at least 5 years? I am using the YAFFS2 filesystem. Best regards, Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with SCHED_FIFO app (using CFS)
Hi All,
I have been trying to find the reason for the problem I am facing with
CFS and process with SCHED_FIFO.
Here is a small program I wrote.
/* Lets call this V1 */
#include sys/types.h
#include sys/stat.h
/* There are other includes but for brevity I have not shown */
main ()
{
/* I have even tried using the IOCTL to put the system
to sleep, but the results are same */
system (echo mem /sys/power/state);
exit (0);
}
When I execute this program from the shell, the system sleeps and
wakes up as soon as the RTC interrupt happens (after 4 seconds, as per
our design). There is no visible delay.
When I put the program in a loop (using bash's while), I see the
system going to sleep and coming out (on RTC interrupt) exactly at 4
seconds as it should.
Now when I change the program slightly as below (it's made a RT process)
/* Lets call this V2 */
#include sys/types.h
#include sys/stat.h
/* There are other includes but for brevity I have not shown */
main ()
{
struct sched_param p;
int ret;
p.sched_priority = 5;
ret = sched_setscheduler (0, SCHED_FIFO, p);
if (ret == -1)
{
printf (sch.c: sched_setscheduler() failed\n);
exit (1);
}
/* I have even tried using the IOCTL to put the system
to sleep, but the results are same */
system (echo mem /sys/power/state);
exit (0);
}
Now when I execute the program from the shell, there is an observable
delay once the processor wakes up before the prompt is returned. The
prints (in kernel/power/main.c) in the kernel confirms that the
process is awake but the application does not finish and drop back to
shell atleast for the 2 to 3 seconds. This delay is not observed in V1
but only on V2.
When put in a loop, I clearly observe that the time we sleep is
proportional to the delay.
I can avoid this delay problem using
echo -1 /proc/sys/kernel/sched_rt_runtime_us
but this creates more problems. Our system has lot of other other
SCHED_FIFO threads (higher in priority and using pthreads) which
suffer and don't run as expected. One of them is a watchdog thread
which also does not run (inspite of being at priority 54) and thus the
system gets reset.
This issue was not observed in 2.6.16 but seen on 2.6.29. CFS has lot
of knobs, but very little documentation. We understand that turning
these knobs will fix the problem, but we don't know which ones.
I am pasting below some of the values of procfs files and debugfs
files. I can send the complete kernel configuration is required.
Please hint us on something so that we can dig deeper and find a
resolution for this.
We are using this kernel on OMAP platform.
Thanks in advance,
Suresh
[ procfs files ]
sched_child_runs_first = 1
sched_compat_yield = 0
sched_features = 24191
sched_latency_ns = 2000
sched_migration_cost = 50
sched_min_granularity_ns = 400
sched_nr_migrate = 32
sched_rt_period_us = 100
sched_rt_runtime_us = 95
sched_shares_ratelimit = 25
sched_shares_thresh = 4
sched_wakeup_granularity_ns = 500
[ CFS related kernel configuration ]
# CONFIG_GROUP_SCHED is not set
# CONFIG_CGROUPS is not set
[ debugfs file ]
#/debug cat sched_features
NEW_FAIR_SLEEPERS NORMALIZED_SLEEPER WAKEUP_PREEMPT START_DEBIT
AFFINE_WAKEUPS CACHE_HOT_BUDDY SYNC_WAKEUPS NO_HRTICK NO_DOUBLE_TICK
ASYM
_GRAN LB_BIAS LB_WAKEUP_UPDATE ASYM_EFF_LOAD NO_WAKEUP_OVERLAP LAST_BUDDY
On Wed, May 12, 2010 at 8:16 PM, Xianghua Xiao xiaoxiang...@gmail.com wrote:
On Wed, May 12, 2010 at 9:49 PM, Con Kolivas ker...@kolivas.org wrote:
On Wed, 12 May 2010 12:46:20 Xianghua Xiao wrote:
On Sun, May 9, 2010 at 11:42 PM, Suresh Rajashekara
suresh.raj+linuxo...@gmail.com wrote:
Hi All,
I had a couple of application (with real time priority SCHED_FIFO)
which were working fine on 2.6.16. They have started behaving
differently on 2.6.29.
I will explain my problem briefly.
Application A (my main application) is scheduled with SCHED_FIFO and
priority 5. Application B (watchdog application) is also scheduled with
SCHED_FIFO but with priority 54.
A keeps putting the OMAP to sleep and wake up every 4 seconds and
again puts it to sleep.
B is supposed to be running every 1.25 seconds to kick watchdog, but
since A keeps OMAP in sleep for 4 seconds, it should run as soon as
OMAP wakes up.
Since B is of a higher priority, its supposed to run whenever the OMAP
wakes up and then A should again put it back to sleep. This happens
perfectly on 2.6.16
On 2.6.29, B fails to run when OMAP wakes up and before A puts it back
to sleep. B only runs if there is atleast 1.5 seconds of delay between
the awake-sleep cycle.
On searching the internet, I figured out that CFS (completely fair
scheduler) was introduced in 2.6.23, which makes some changes to the
RT bandwidth (and many users started facing issues with they
applications with SCHED_FIFO). Somewhere on the web I found that
issuing
echo -1
Issue with SCHED_FIFO app
Hi All, I had a couple of application (with real time priority SCHED_FIFO) which were working fine on 2.6.16. They have started behaving differently on 2.6.29. I will explain my problem briefly. Application A (my main application) is scheduled with SCHED_FIFO and priority 5. Application B (watchdog application) is also scheduled with SCHED_FIFO but with priority 54. A keeps putting the OMAP to sleep and wake up every 4 seconds and again puts it to sleep. B is supposed to be running every 1.25 seconds to kick watchdog, but since A keeps OMAP in sleep for 4 seconds, it should run as soon as OMAP wakes up. Since B is of a higher priority, its supposed to run whenever the OMAP wakes up and then A should again put it back to sleep. This happens perfectly on 2.6.16 On 2.6.29, B fails to run when OMAP wakes up and before A puts it back to sleep. B only runs if there is atleast 1.5 seconds of delay between the awake-sleep cycle. On searching the internet, I figured out that CFS (completely fair scheduler) was introduced in 2.6.23, which makes some changes to the RT bandwidth (and many users started facing issues with they applications with SCHED_FIFO). Somewhere on the web I found that issuing echo -1 /proc/sys/kernel/sched_rt_runtime_us should disable the changes which affects the RT bandwidth. It actually did help to an extent in solving some other problem (not described above. A's IOCTL call return was getting delayed), but this problem still persists. Any pointers to where I should look for the solution. Is there a way I can revert back to the scheduler behavior as it was on 2.6.16? I have disabled CONFIG_GROUP_SCHED and also CONFIG_CGROUPS. I am using 2.6.29 on an OMAP1 platform. Thanks in advance, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Issue with SCHED_FIFO app
Hi All, I had a couple of application (with real time priority SCHED_FIFO) which were working fine on 2.6.16. They have started behaving differently on 2.6.29. I will explain my problem briefly. Application A (my main application) is scheduled with SCHED_FIFO and priority 5. Application B (watchdog application) is also scheduled with SCHED_FIFO but with priority 54. A keeps putting the OMAP to sleep and wake up every 4 seconds and again puts it to sleep. B is supposed to be running every 1.25 seconds to kick watchdog, but since A keeps OMAP in sleep for 4 seconds, it should run as soon as OMAP wakes up. Since B is of a higher priority, its supposed to run whenever the OMAP wakes up and then A should again put it back to sleep. This happens perfectly on 2.6.16 On 2.6.29, B fails to run when OMAP wakes up and before A puts it back to sleep. B only runs if there is atleast 1.5 seconds of delay between the awake-sleep cycle. On searching the internet, I figured out that CFS (completely fair scheduler) was introduced in 2.6.23, which makes some changes to the RT bandwidth (and many users started facing issues with they applications with SCHED_FIFO). Somewhere on the web I found that issuing echo -1 /proc/sys/kernel/sched_rt_runtime_us should disable the changes which affects the RT bandwidth. It actually did help to an extent in solving some other problem (not described above. A's IOCTL call return was getting delayed), but this problem still persists. Any pointers to where I should look for the solution. Is there a way I can revert back to the scheduler behavior as it was on 2.6.16? I have disabled CONFIG_GROUP_SCHED and also CONFIG_CGROUPS. I am using 2.6.29 on an OMAP1 platform. Thanks in advance, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Is there anyway to know the way OMAP got reset
Is there anyway on OMAP systems (or in general in embedded systems) to know a way in which the processor was reset, after the reset. I am using a system based on OMAP5912 OSK and its getting reset for no known reason. Thanks in advance, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Where is DSP Gateway
Hi All, We had been using dspgateway 3.3 on 2.6.16. Recently we changed our kernel to 2.6.29 and we found that the dspgateway driver has been removed from the tree ( http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=2512fd29db4eb09e82d182596304c7aaf76d2c5c). What do I do, If I want to use the dspgateway on 2.6.29? I tried searching the patch for dspgateway on 2.6.29, but found none except this http://archive.netbsd.se/?ml=linux-kernela=2009-07m=11155350 Any pointers would be really helpful Thanks in advance, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem in Flashing uboot on OSK5912c
Try this http://omap.spectrumdigital.com/osk5912/factoryconfig/ Suresh On Thu, Mar 26, 2009 at 6:24 AM, Manoj Kotnala kotn...@techmahindra.com wrote: Hi Experts, Sorry this query is not specific to the kernel but to the OMAP/OSK so am posting it here. I am having OSK5912 board (rev C). I am not getting any boot messages on it. I tried the Flash Recovery Utility for OMAP from http://www.celinuxforum.org/CelfPubWiki/FlashRecoveryUtility But I am not able to install the respective driver in WinXP. I also tried OSTBoot ver 2.5 from http://focus.ti.com/download/wtbu/OSTTools_NoSource_v2_5.zip but couldn't succeed. It is waiting at Waiting for USB device to connect message. Next I tried the (Open source) OMAP Flash Loader omapfl from http://www.celinuxforum.org/CelfPubWiki/FlashRecoveryUtility?action=AttachFiledo=viewtarget=omapfl-1.0.tar.gz Again Failed. I inserted debug messages in omapfl source It seems that OSK Board is not even throwing/publishing VendorID and Product ID from the board. Could anyone tell me how recover the board from this stage? Thanks in Advance, Manoj Kotnala Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at a href=http://www.techmahindra.com/Disclaimer.html;http://www.techmahindra.com/Disclaimer.html/a externally and a href=http://tim.techmahindra.com/Disclaimer.html;http://tim.techmahindra.com/Disclaimer.html/a internally within Tech Mahindra. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix section mismatch warning on OSK
Section mismatch warnings when compiling latest git for MACH_OMAP_OSK.
Missing __initdata on the omap1_clk_functions.
Signed-off-by: Suresh Rajashekara [EMAIL PROTECTED]
---
arch/arm/mach-omap1/clock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 4d0c444..aab7ab1 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -636,7 +636,7 @@ static void __init omap1_clk_disable_unused(struct clk *clk)
#define omap1_clk_disable_unused NULL
#endif
-static struct clk_functions omap1_clk_functions = {
+static struct clk_functions omap1_clk_functions __initdata = {
.clk_enable = omap1_clk_enable,
.clk_disable = omap1_clk_disable,
.clk_round_rate = omap1_clk_round_rate,
--
1.4.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: unknown partition table
mohammed shareef wrote: sda: Write Protect is off sda: assuming drive cache: write through sda:7usb-storage: queuecommand called unknown partition table sd 0:0:0:0: Attached scsi removable disk sda Try formatting once. Use fdisk (on Linux) to format it and make partitions. Regards, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Power Management on OMAP2
Hi All, I was planning to start some work on the power management for Mistral's OMAP2 EVM. Has anyone started working on this? Any idea what state the PM support is in the current GIT tree? Thanks in advance, Best Regards, Suresh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
