The kernel symbol stem compression patch included in 2.5.54 unfortunately
had a few problems, triggered by various circumstances.
On some gas \x... in string constants seems to randomly eat any following
hex like character.
Hardens it more against bogus symbol table entries.
This should fix the reported crashes. No need anymore for akpm to
back it out.
Please apply.
-Andi
--- linux-vanilla/kernel/kallsyms.c 2003-01-02 06:55:55.000000000 +0100
+++ linux/kernel/kallsyms.c 2003-01-02 11:06:30.000000000 +0100
@@ -32,6 +32,7 @@
BUG();
namebuf[127] = 0;
+ namebuf[0] = 0;
if (addr >= (unsigned long)_stext && addr <= (unsigned long)_etext) {
unsigned long symbol_end;
@@ -46,9 +47,9 @@
/* Grab name */
for (i = 0; i < best; i++) {
- ++name;
- strncpy(namebuf + name[-1], name, 127);
- name += strlen(name)+1;
+ unsigned prefix = *name++;
+ strncpy(namebuf + prefix, name, 127);
+ name += strlen(name) + 1;
}
/* Base symbol size on next symbol. */
--- linux-vanilla/scripts/kallsyms.c 2003-01-02 06:55:56.000000000 +0100
+++ linux/scripts/kallsyms.c 2003-01-02 11:02:18.000000000 +0100
@@ -144,7 +144,7 @@
for (k = 0; table[i].sym[k] && table[i].sym[k] == prev[k]; ++k)
;
- printf("\t.asciz\t\"\\x%02x%s\"\n", k, table[i].sym + k);
+ printf("\t.byte 0x%02x ; .asciz\t\"%s\"\n", k, table[i].sym + k);
last_addr = table[i].addr;
prev = table[i].sym;
}
Andi Kleen wrote:
>
> The kernel symbol stem compression patch included in 2.5.54 unfortunately
> had a few problems, triggered by various circumstances.
>
With your patch I am still seeing an instant oops when running top(1):
connect(6, {sin_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory)
close(6) = 0
open("/etc/group", O_RDONLY) = 6
fcntl64(0x6, 0x1, 0, 0x1) = 0
fcntl64(0x6, 0x2, 0x1, 0x1) = 0
fstat64(6, {st_mode=S_IFREG|0644, st_size=720, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40023000
read(6, "root:x:0:root\nbin:x:1:root,bin,d"..., 4096) = 720
close(6) = 0
munmap(0x40023000, 4096) = 0
open("/proc/1/cmdline", O_RDONLY) = 6
read(6, "init [3]\0\0\0\0\0\0\0\0\0\0\0", 2047) = 19
close(6) = 0
open("/proc/1/wchan", O_RDONLY) = 6
read(6,
The oops isn't very informative. EIP is 0x00000000, call trace
is just "scheduling_functions_start_here+0x3dd/0x4a8"
Using procps from http://surriel.com/procps/
On Thu, Jan 02, 2003 at 12:52:29PM +0100, Andrew Morton wrote:
> Andi Kleen wrote:
> >
> > The kernel symbol stem compression patch included in 2.5.54 unfortunately
> > had a few problems, triggered by various circumstances.
> >
>
> With your patch I am still seeing an instant oops when running top(1):
Did you make sure the .tmp_kallsym* files in your kernel build were
regenerated ?
-Andi
Andi Kleen wrote:
>
> On Thu, Jan 02, 2003 at 12:52:29PM +0100, Andrew Morton wrote:
> > Andi Kleen wrote:
> > >
> > > The kernel symbol stem compression patch included in 2.5.54 unfortunately
> > > had a few problems, triggered by various circumstances.
> > >
> >
> > With your patch I am still seeing an instant oops when running top(1):
>
> Did you make sure the .tmp_kallsym* files in your kernel build were
> regenerated ?
>
I retested. A `cat /proc/1/wchan' still ooopses in the same manner.
(Shouldn't `make clean' remove that gunk? It doesn't...)
Hi all,
Lately I've been testing out two Gigabit Ethernet adapters on Pentium 4
Xeon platforms; onboard Intel 82544GC (e1000 driver) and onboard Broadcom
BCM5701 (tg3 driver), and I'm experiencing some wierd behaviour on
one-way tests (ping-ping). The machines I'm testing is connected back to
back (i.e no switch) and are fairly fast systems (Dual Xeon 2.4 GHz, 1GB
memory) configured to use Jumbo frames (9000 bytes).
With ping-pong traffic (the attached program run with -bo, or NetPipe
default) the bandwidth performance is close to wire speed (123 MByte/sec)
and the ping-pong/2 latency is ~30us with both GbE devices.
But, when running a one-way test (where one machine only sends, and the
other only receives, i.e ping-ping) there is a serious dip in the
performance curve at ~768 bytes and the bandwidth levels out at approx
60 MByte/sec (about half of peak) regadless of application and GbE device.
However, if the benchmark applications are started at 2048 bytes (and not
0 which is default), or the MTU is set to standard 1500 bytes, there is no
such "dip" in the performance curve.
Is there a new "silly window" syndrome going on here ? Both applications
use TCP_NODELAY.
I'll appreciate any feedback, and I'm happy to assist in the debugging
process testing out patches etc.
PS
Attached you'll find a yet another "bandwidth" program which measures TCP
performance i three ways; ping-ping (one-way), ping-pong, and exchange
(two way). Should compile fine with gcc -O2, and you must start a server
process (-Ts) on one machine and a client process (-Tc -s <server>) on the
other machine.
DS
Best regards,
--
Steffen Persvold | Scali AS
mailto:[email protected] | http://www.scali.com
Tel: (+47) 2262 8950 | Olaf Helsets vei 6
Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY
On Thursday 02 January 2003 13:00, Andi Kleen wrote:
> On Thu, Jan 02, 2003 at 12:52:29PM +0100, Andrew Morton wrote:
> > Andi Kleen wrote:
> > >
> > > The kernel symbol stem compression patch included in 2.5.54
unfortunately
> > > had a few problems, triggered by various circumstances.
> > >
> >
> > With your patch I am still seeing an instant oops when running top(1):
>
> Did you make sure the .tmp_kallsym* files in your kernel build were
> regenerated ?
applied Andi's patch, did a make mrproper and rebuild kernel, but it crashes
when I run ps (2.0.11 from http://surriel.com/procps/) no oops, nothing in
logs and I'm unable to switch consoles
without the patch it resulted in a crash with filesystem corruption (ext2)
Rudmer
Steffen Persvold writes:
> Hi all,
>
> Lately I've been testing out two Gigabit Ethernet adapters on Pentium 4
> Xeon platforms; onboard Intel 82544GC (e1000 driver) and onboard Broadcom
> BCM5701 (tg3 driver), and I'm experiencing some wierd behaviour on
> one-way tests (ping-ping). The machines I'm testing is connected back to
> back (i.e no switch) and are fairly fast systems (Dual Xeon 2.4 GHz, 1GB
> memory) configured to use Jumbo frames (9000 bytes).
> But, when running a one-way test (where one machine only sends, and the
> other only receives, i.e ping-ping) there is a serious dip in the
> performance curve at ~768 bytes and the bandwidth levels out at approx
> 60 MByte/sec (about half of peak) regadless of application and GbE device.
I've seen similar problems... and most of the times this seems due to
incorrect tuned mitigation. Think of what happens if you don't have TX-
interrupts enough to clean your TX-ring. Which means your app. can not
fill it at full speed -- and as long you have RX traffic it contributes
with interrupts so the problem is not visile.
If you test IP-forwarding with RX soly on one interface and TX soly on the
other and routing between them. You'll see drops at the qdisc in such case.
Cheers.
--ro