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 such
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 such a device on a single CPU
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 core
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,
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, page fault, ... But
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 core machine (2 x Xeon
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
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
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 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);
>
>
ops, 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: Gilboa D
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
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 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 by do_IRQ problem.
(Hopefully) this patch
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
, 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: Gilboa Davara [EMAIL
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);
Note, the if condition is not needed, kfree handles
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
is really a big problem.
In general I
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 path, uses
print_symbol (display
Hello all,
As the title suggest.
i is declared as 0 and never assigned a new value.
Down the code there's an if (i40) 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
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
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 o
(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 when
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 when something bad
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 overflow... when CONFIG_DEBUG_STACKOVERFLOW is
enabled. (Though
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 locking)
26 matches
Mail list logo
