From: Stanislav Meduna <stano@meduna.org>
To: "linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] Re: timerfd read does not return
Date: Mon, 22 Apr 2013 10:55:23 +0200 [thread overview]
Message-ID: <5174FAFB.7010105@meduna.org> (raw)
In-Reply-To: <5174E842.4050408@meduna.org>
On 22.04.2013 09:35, Stanislav Meduna wrote:
> FWIW, the following patch seems to solve the issue for me.
> Unfortunately I have no idea whether this is a sane way to
> do and whether it solves or just masks or delays the issue,
Unfortunately it only delays it (funny how it crashes minutes
after I write to the list, after running for hours and hours
before), so please, disregard :(
The dumped call trace at the time the throttler kicks in this time
restore_all+0xf/0xf
irq_exit+0x6d/0x80
sub_preempt_count+0x36/0x50
irq_exit+0x6d/0x80
do_IRQ+0x48/0x94
__kunmap_atomic+0x50/0x60
handle_pte_fault+0x141/0xa00
trace_hardirqs_on_thunk+0xc/0x10
restore_all+0xf/0xf
handle_mm_fault+0x80/0xc0
rt_up_read+0x1d/0x30
do_page_fault+0x168/0x390
irq_exit+0x6d/0x80
irq_to_desc+0x14/0x20
handle_irq+0x1f/0x90
do_IRQ+0x3f/0x94
common_interrupt+0x2e/0x40
__kill_pgrp_info+0x5b/0x60
__put_user_8+0x11/0x19
timerfd_read+0x18e/0x2a0
wake_up_bit+0x60/0x60
vfs_read+0x9f/0x150
fget_light+0x87/0xe0
sys_timerfd_gettime+0x140/0x140
sys_read+0x42/0x70
syscall_call+0x7/0xb
init_memory_mapping+0x230/0x410
and again the last logged trace is sched_switch to the timer thread
and there is no softirq_exit from HRTIMER
Again __put_user_8 and then something signal-related. Note: I do not
(knowingly) use signals in my application, neither explicitly nor
pthread_cancel or something like that via glibc.
The problem does not manifest if I use timer_create instead
of timerfd (at least such version did run for 2,5 days without
a problem).
Regards
--
Stano
next prev parent reply other threads:[~2013-04-22 8:55 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-15 11:02 hrtimer: interrupt took 6742 ns, then RT throttling and hung machine for nearly 2 seconds Stanislav Meduna
2013-04-15 11:54 ` Stanislav Meduna
2013-04-15 12:22 ` Thomas Gleixner
2013-04-15 12:56 ` Stanislav Meduna
2013-04-17 15:46 ` timerfd and softirqd [Was: Re: hrtimer: interrupt took 6742 ns, then RT throttling and hung machine for nearly 2 seconds] Stanislav Meduna
2013-04-18 9:11 ` timerfd read does not return [Was: Re: timerfd and softirqd] Stanislav Meduna
2013-04-19 19:53 ` Stanislav Meduna
2013-04-22 7:35 ` [PATCH] Re: timerfd read does not return Stanislav Meduna
2013-04-22 8:55 ` Stanislav Meduna [this message]
2013-04-27 8:34 ` timerfd read does not return - was probably fixed in 3.4.38 Stanislav Meduna
2013-04-28 11:53 ` Carsten Emde
2013-04-29 8:43 ` Stanislav Meduna
2013-05-02 20:02 ` Steven Rostedt
2013-05-10 12:42 ` timerfd read does not return - some traces Stanislav Meduna
2013-05-12 17:31 ` Stanislav Meduna
2013-05-12 23:20 ` timerfd read does not return - hangs inside put_user Stanislav Meduna
2013-05-13 8:05 ` timerfd read does not return - caused by MM fault Stanislav Meduna
2013-05-14 8:31 ` Livelock in handle_pte_fault [Was: Re: timerfd read does not return] Stanislav Meduna
2013-11-25 10:36 ` Vijay Katoch
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=5174FAFB.7010105@meduna.org \
--to=stano@meduna.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.