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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox