All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@gmail.com>
To: "Björn Steinbrink" <B.Steinbrink@gmx.de>
Cc: Adrian McMenamin <lkmladrian@gmail.com>,
	linux-kernel@vger.kernel.org, linuxsh-dev@lists.sourceforge.net,
	Paul Mundt <lethal@linux-sh.org>
Subject: Re: time_after - what on earth???
Date: Wed, 12 Sep 2007 01:16:22 +0200	[thread overview]
Message-ID: <46E721C6.8030109@gmail.com> (raw)
In-Reply-To: <20070911230940.GA7070@atjola.homenet>

On 09/12/2007 01:09 AM, Björn Steinbrink wrote:
> On 2007.09.12 00:19:09 +0200, Rene Herman wrote:
>> On 09/12/2007 12:15 AM, Adrian McMenamin wrote:
>>
>>> On 11/09/2007, Rene Herman <rene.herman@gmail.com> wrote:
>>>> On 09/12/2007 12:05 AM, Adrian McMenamin wrote:
>>>>
>>>>> OK, why does this line occasionally return true:
> 
> What exactly is "occassionally"?  Does it happen more than once per
> boot? If not, and it happens after a certain time after booting, it
> might be wrapping of the jiffie counter (see below).
> 
>>>>>       if ((maple_dev->interval > 0) && (jiffies >maple_dev->when))
>>>>>
>>>>> while this one never does (no other changes made):
>>>>>
>>>>> if  ((maple_dev->interval > 0) && (time_after(jiffies, 
>>>>> maple_dev->when)))
>>>> Is maple_dev->when an unsigned long?
>>>>
>>> Yes. Does that make a difference?
>> If it had been a signed type, it could've wrapped to something you didn't 
>> expect, explaining the difference at least...
>>
>> With an unsigned long, the only diference should be that time_after() deals 
>> with jiffie wrapping which I assume is not an actual problem here. I'll 
>> retreat into the shades again... ;-(
> 
> If "occasionally" is limited to once per boot, it might be jiffie
> wrapping. IIRC jiffies are initialized so that they wrap after about 5
> minutes of uptime to reveal such bugs without forcing you to wait for
> ages just to have the counter wrap for the first time.

Yes, but if jiifie wrapping was the problem, I'd expect the contrary 
behaviour with the time_after() one hitting while the > one does not.

Rene.

      parent reply	other threads:[~2007-09-11 23:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-11 22:05 time_after - what on earth??? Adrian McMenamin
2007-09-11 22:11 ` Rene Herman
2007-09-11 22:15   ` Adrian McMenamin
2007-09-11 22:19     ` Rene Herman
2007-09-11 23:09       ` Björn Steinbrink
2007-09-11 23:10         ` Adrian McMenamin
2007-09-11 23:50           ` Björn Steinbrink
2007-09-12  0:03             ` Adrian McMenamin
2007-09-11 23:16         ` Rene Herman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46E721C6.8030109@gmail.com \
    --to=rene.herman@gmail.com \
    --cc=B.Steinbrink@gmx.de \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxsh-dev@lists.sourceforge.net \
    --cc=lkmladrian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.