Hello, While working on a driver for an I2C device I noticed that a call to wait_event_interruptible_timeout() would wait much longer than expected (2s-10s instead of 200ms). I've started by the obvious and checked the jiffies counter, which runs fine at the expected rate.
Further investigation showed that the schedule_timeout() call inside wait_event_interruptible_timeout() returns immediately. As the wait condition involves I2C access and thus takes significantly more time to run than schedule_timeout(), the probability of schedule_timeout() crossing a jiffies boundary is relatively small. The function thus returns the timeout value it received unchanged, and the jiffies boundary crossed by the condition check remains unnoticed. The actual timeout is thus much longer than requested. I still need to investigate why schedule_timeout() returns immediately (help would be appreciated, I'm not familiar with the scheduler), but regardless of that I believe that wait_event_interruptible_timeout() should behave properly. Shouldn't it store the target jiffies before the loop and compare the current jiffies as part of the exit condition instead of relying on schedule_timeout() to update the timeout ? I don't want to break the recent effort to consolidate all wait macros around ___wait_event, so I'd appreciate both opinions on whether this should be considered as a wait_event_interruptible_timeout() bug, and hints regarding the preferred way to fix it. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
