sleep/wake-up timeout issue

Bug #1956559 reported by hyukmin kwon
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

I have a unexpected issue that related in sleep/wake-up timeout for task, while device driver develop.
my code use kernel function 'wait_for_completion_interruptible_timeout' when there is a reason for task sleep, this function parameter need input 'want timeout in jiffies', so i have try that input any value like "msecs_to_jiffies(255 * 1000)" for sleep task 255seconds.
I expected this function 'wait_for_completion_interruptible_timeout' return zero when after almost exactly 255seconds. but I measured the actual time, it was additionally delayed maximum almost 11 seconds(final time 266 seconds) in my test case.
so result of have additional test, the additionally delayed time is different, but the result is the same.
additionally delayed time range was random in 1ms ~ 11seconds.
this issue occur in kernel function 'msleep(255 * 1000)' too... because schedule_timeout() used in 'wait_for_completion_interruptible_timeout' and msleep.

※A additionally delayed time occurs even if a different number is entered like 1ms or 1seconds..

I think it "additionally delayed time" was mean that wake-up task but time to task racing until active run in cpu. am i guessing right? or not am i doing something wrong?
If my thoughts are right, How do I get the correct time?

Below is the sample code I tested.

struct completion cmp;
static long g_jiffies = 0;

static int _open(struct inode *inode, struct file *file)
    g_jiffies = 0;
    return 0;

static ssize_t _read(struct file *filp, char __user *buffer, size_t count, loff_t *ppos)
    long sch = 0;

    printk(KERN_NOTICE "start checking\n");
    g_jiffies = jiffies;
    sch = wait_for_completion_interruptible_timeout(&cmp, msecs_to_jiffies(255 * 1000));
    //msleep(255 * 1000)

    printk(KERN_NOTICE "delay time = %ld\n", jiffies_to_msecs(jiffies - g_jiffies));
    return 0;

result dmesg :
[목 1월 6 13:05:30 2022] start checking
[목 1월 6 13:09:52 2022] delay time = 261808

Revision history for this message
Chris Guiver (guiverc) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Bug reporting is about finding & fixing problems thus preventing future users from hitting the same bug.

I suspect a Support site would be more appropriate, eg. You can also find help with your problem in the support forum of your local Ubuntu community or asking at or, or for more support options please look at Please note: You may require a specialist programming site rather than generic Ubuntu support.

affects: ubuntu → linux (Ubuntu)
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1956559

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.