On Mon, 2007-12-03 at 07:12 +0200, Avi Kivity wrote:
> Andi Kleen wrote:
> > Avi Kivity <[EMAIL PROTECTED]> writes:
> >
> >> [I really doubt there are that many of these; syscall
> >> entry/dispatch/exit, interrupt dispatch, context switch, what else?]
> >>
> >
> > Networking, block IO, pa
On Mon, 2007-12-03 at 14:35 +0200, Gilboa Davara wrote:
> Intel's newest dual 10GbE NIC can easily (?) throw ~14M packets per
> second. (theoretical peak at 1514bytes/frame)
> Granted, installing such a device on a single CPU/single core machine is
> absurd - but even on an 8
On Tue, 2007-12-04 at 12:50 -0500, Lennart Sorensen wrote:
> On Mon, Dec 03, 2007 at 02:35:31PM +0200, Gilboa Davara wrote:
> > Intel's newest dual 10GbE NIC can easily (?) throw ~14M packets per
> > second. (theoretical peak at 1514bytes/frame)
> > Granted, installing
(I
rather not spam world + dog for such a minor patch)
--
Gilboa Davara <[EMAIL PROTECTED]>
[1]
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00640.html
[2]. In theory, there's a second option: pre-allocating memory on a
per_cpu basis, however:
A. dump_trace/stack are usually called
On Sat, 2007-09-15 at 18:32 +0530, Satyam Sharma wrote:
> Hi,
>
>
> On 9/15/07, Gilboa Davara <[EMAIL PROTECTED]> wrote:
> > Hello all,
> >
> > In a small exchange in fedora-kernel-list [1] Eric Sandeen has pointed
> > out a possible stack over
Hello all, Satyam,
This is my second stab at solving the "stack over flow due to
dump_strace when close to stack-overflow is detected by do_IRQ" problem.
(Hopefully) this patch is creates less noise then the previous one.
[snip]
> I'll try and create an option 2 (static allocation, minimal lockin
Hello Satyam,
On Wed, 2007-09-19 at 06:30 +0530, Satyam Sharma wrote:
> Hi Gilboa,
>
>
> On Sat, 15 Sep 2007, Gilboa Davara wrote:
> >
> > This is my second stab at solving the "stack over flow due to
> > dump_strace when close to stack-overflow is detected
Hello Paulo,
[snip]
> I must say I agree with Satyam here.
>
> Locking in the panic path might leave us without some critical debug
> information, which is much more important than all this.
>
> Maybe it would be better to change the print_symbol interface to avoid
> having a "char buffer[KSYM
alled by oops, or by
a "debug/warning" code).
III. Possible solutions:
A. Add oops_in_progress_cpuid to bust_spinlocks (Hack, but generates far
less noise).
B. Add priority tag to all the functions that handle the calls stuck.
(Nicer, requires a massive tree-changing patch.)
Signed-off-by
On Fri, 2007-09-21 at 10:47 -0400, Steven Rostedt wrote:
> On Sat, Sep 15, 2007 at 02:35:29PM +0300, Gilboa Davara wrote:
> > - return sprintf(buffer, "%s+%#lx/%#lx", name, offset, size);
> > + if (namebuf)
> > + kfree(namebuf);
>
>
On Fri, 2007-09-21 at 15:21 +0100, Paulo Marques wrote:
> Gilboa Davara wrote:
> > Hello Paulo,
>
> Hi, Gilboa
>
> Usually the developer can separate the output by hand in the unlikely
> case of simultaneous concurrent users of printk, so I don't think this
&
On Fri, 2007-09-21 at 17:02 +0100, Paulo Marques wrote:
> Gilboa Davara wrote:
> > Hello all,
>
> Hi, Gilboa
>
> > (1) Problem:
> > I. When CONFIG_4KSTACKS and CONFIG_DEBUG_STACKOVERFLOW are enabled on
> > i386 kernels, do_IRQ calls dump_stack which, down the
Hello all,
As the title suggest.
"i" is declared as 0 and never assigned a new value.
Down the code there's an if (i>40) and a certain dangling piece of code.
I assume that I should have gotten a string length (?) from somewhere?
Am I missing something?
- Gilboa
---
static void
dik_show_trace(u
13 matches
Mail list logo
