From: Andrew Morton <akpm@osdl.org>
To: tglx@linutronix.de
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Frank v Waveren <fvw@var.cx>
Subject: Re: [PATCH] prevent timespec/timeval to ktime_t overflow
Date: Fri, 1 Sep 2006 20:13:05 -0700 [thread overview]
Message-ID: <20060901201305.f01ec7d2.akpm@osdl.org> (raw)
In-Reply-To: <1157103042.29250.337.camel@localhost.localdomain>
On Fri, 01 Sep 2006 11:30:42 +0200
Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > With that patch the machine emits 88 bigabytes of stuff then locks up.
> > Something a little less aggressive is needed, methinks.
>
> Fun, here is a version with a bigabyte blocker.
Your patch triggers waaaaaaay early.
netconsole: remote IP 192.168.2.33
netconsole: remote ethernet address 00:0d:56:c6:c6:cc
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer.
time.c: Detected 3400.238 MHz processor.
ktime_set: -1157140842 : 0
BUG: warning at include/linux/ktime.h:84/ktime_set()
Call Trace:
<IRQ> [<ffffffff80247021>] hrtimer_run_queues+0x10e/0x211
[<ffffffff8023a5ca>] run_timer_softirq+0x28/0x1dc
[<ffffffff802368f1>] __do_softirq+0x58/0xcf
[<ffffffff8020ac28>] call_softirq+0x1c/0x28
[<ffffffff8020c7b5>] do_softirq+0x31/0x84
[<ffffffff802365ea>] irq_exit+0x3f/0x4b
[<ffffffff8020c77a>] do_IRQ+0x62/0x6c
[<ffffffff80209f1d>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff806a46ec>] console_init+0x0/0x37
[<ffffffff80691749>] start_kernel+0x123/0x1d0
[<ffffffff8069127a>] _sinittext+0x27a/0x281
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
So I modified it to only trigger if current->mm!=NULL and:
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 156k freed
ktime_set: -1157141318 : 0
BUG: warning at kernel/hrtimer.c:892/ktime_set()
Call Trace:
<IRQ> [<ffffffff80246957>] ktime_set+0x73/0x8b
[<ffffffff80246de4>] hrtimer_run_queues+0x55/0x140
[<ffffffff8023a4f2>] run_timer_softirq+0x28/0x1dc
[<ffffffff80236819>] __do_softirq+0x58/0xcf
[<ffffffff8020ac28>] call_softirq+0x1c/0x28
[<ffffffff8020c7b5>] do_softirq+0x31/0x84
[<ffffffff80236512>] irq_exit+0x3f/0x4b
[<ffffffff802193b1>] smp_apic_timer_interrupt+0x42/0x46
[<ffffffff8020a5c6>] apic_timer_interrupt+0x66/0x6c
<EOI> [<ffffffff8026611b>] __handle_mm_fault+0x42a/0x990
[<ffffffff802660fa>] __handle_mm_fault+0x409/0x990
[<ffffffff804d6629>] _spin_unlock_irqrestore+0x1a/0x38
[<ffffffff8021f656>] do_page_fault+0x3b6/0x75c
[<ffffffff8025d214>] free_hot_cold_page+0x12c/0x14f
[<ffffffff8025d28a>] free_hot_page+0xb/0xd
[<ffffffff8025d2b5>] __free_pages+0x29/0x32
[<ffffffff8025d33e>] free_pages+0x80/0x82
[<ffffffff8020a721>] error_exit+0x0/0x84
I wonder if this is related to the occasional hrtimr_run_queues() lockup
which Andi is encountering.
--
VGER BF report: H 9.0096e-09
next prev parent reply other threads:[~2006-09-02 3:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-30 8:44 [PATCH] prevent timespec/timeval to ktime_t overflow Thomas Gleixner
2006-08-30 21:44 ` Frank v Waveren
2006-08-30 22:05 ` Thomas Gleixner
2006-08-30 22:08 ` Frank v Waveren
2006-08-30 22:22 ` Thomas Gleixner
2006-08-30 22:26 ` Frank v Waveren
2006-09-01 3:46 ` Andrew Morton
2006-09-01 8:56 ` Thomas Gleixner
2006-09-01 9:04 ` Andrew Morton
2006-09-01 9:30 ` Thomas Gleixner
2006-09-02 3:13 ` Andrew Morton [this message]
2006-09-02 3:32 ` Andrew Morton
2006-09-02 8:08 ` Andi Kleen
2006-09-02 18:41 ` Thomas Gleixner
2006-09-02 19:28 ` Thomas Gleixner
2006-09-02 19:43 ` Andrew Morton
2006-09-02 19:32 ` Andrew Morton
2006-09-02 11:04 ` Frank v Waveren
2006-09-02 18:44 ` Thomas Gleixner
2006-09-03 3:13 ` Frank v Waveren
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=20060901201305.f01ec7d2.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=fvw@var.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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.