Re: possible typo in arch/sparc64/kernel/time.c

[David Miller]

From: Roel Kluin <[EMAIL PROTECTED]>
Date: Sat, 27 Oct 2007 17:25:51 +0200

> I already posted something on lkml, but it wasn't picked up
> 
> in arch/sparc64/kernel/time.c, line 1073 it reads:
> 
> if (!mregs && !dregs & !bregs)
> 
> shouldn this be
> 
> if (!mregs && !dregs && !bregs)
> 

Yep, thanks I'll fix it up.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: unkillable dpkg-query processes

[David Miller]

From: Bernd Zeimetz <[EMAIL PROTECTED]>
Date: Sat, 27 Oct 2007 20:09:47 +0200

> titan:~# [ 2427.313946] BUG: soft lockup - CPU#3 stuck for 11s! 
> [aptitude:13375]
> [ 2427.389128] TSTATE: 11009602 TPC: 0042f93c TNPC: 
> 0042f7d0 Y: Not tainted
> [ 2427.506821] TPC: <__delay+0x1c/0x48>
> [ 2427.549494] g0: 9000 g1: 0042f7d0 g2:  
> g3: 
> [ 2427.653670] g4: f8a00793c960 g5: f89fff994000 g6: f8a007dfc000 
> g7: 
> [ 2427.757835] o0: 0020 o1: 0020 o2:  
> o3: 
> [ 2427.862001] o4: 0030a0d0 o5:  sp: f8a007dff071 
> ret_pc: 0042f938
> [ 2427.970337] RPC: <__delay+0x18/0x48>
> [ 2428.013031] l0: 0005a6cab647 l1: 11009601 l2: 004417a8 
> l3: 0400
> [ 2428.117206] l4:  l5: 0001 l6:  
> l7: 0008
> [ 2428.221374] i0:  i1: f8a007dffa88 i2: 0004 
> i3: 0001
> [ 2428.325538] i4:  i5:  i6: f8a007dff131 
> i7: 004417ec
> [ 2428.429710] I7: 
> 
> and an unkillable, cpu-eating aptitude.

One cpu can't send a message successfully to another cpu, likely
because it is stuck somewhere with interrupts off.

I was going to give you a patch like the one at the end of this email
to try and get a register dump from all cpus with Alt-Sysrq-p but that
is guarenteed not to work.  It will just call back into
cheetah_xcall_deliver() and wedge further.  Again, don't use the
patch, trying to get a register dump with it in this state will just
wedge the machine further.

I don't know how to suggest a way to debug this further, sorry.

I'm sick of these bugs and I need to reproduce all of these
UltraSPARC-III issues locally to fix them.  So let's go.

Everyone who sees these UltraSPARC-III problems please send me PRECISE
and FULL description of how to install from scratch a machine and run
something that will trigger these errors.

DO NOT leave out any detail of your installation.  Any minor omission
will mean that I potentially won't be able to reproduce this bug and
therefore I won't be able to fix it either.

If you are using NIS, say so and give the exact configuration.  If you
have any modifications to some core configuration file like
/etc/nsswitch.conf, tell me.  If you are using static IP addresses,
tell me.  If you have netfilter enabled, tell me.  If you have even
installed some extra package, like libnss-db or anything else, tell me
even if you think it's not in use.

In short I want a flawless cook-book style recipe for installing a
machine that I can reproduce this problem on.  Do not omit any detail.

Thanks!

diff --git a/arch/sparc64/kernel/process.c b/arch/sparc64/kernel/process.c
index ca7cdfd..e10fdce 100644
--- a/arch/sparc64/kernel/process.c
+++ b/arch/sparc64/kernel/process.c
@@ -348,7 +348,7 @@ void show_regs(struct pt_regs *regs)
extern long etrap, etraptl1;
 #endif
__show_regs(regs);
-#if 0
+#if 1
 #ifdef CONFIG_SMP
{
extern void smp_report_regs(void);
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: unkillable dpkg-query processes

[David Miller]

From: Bernd Zeimetz <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 04:03:44 +0100

> 
> 
> 
> I think things got worse with 2.6.24...
> The machine shoots itself now, I guess by running cron jobs or so.
> 
> [29074.766486] TSTATE: 11009600 TPC: 0042f984 TNPC: 
> 0042f928 Y: Not tainted
> [29074.884191] TPC: 

What kind of OOPS is this?  Please provide the kernel log messages
that appeared right before these register dumps.

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: unkillable dpkg-query processes

[Bernd Zeimetz]

I think things got worse with 2.6.24...
The machine shoots itself now, I guess by running cron jobs or so.

[29074.766486] TSTATE: 11009600 TPC: 0042f984 TNPC: 
0042f928 Y: Not tainted
[29074.884191] TPC: 
[29074.929988] g0:  g1: 004417ec g2:  
g3: 
[29075.034163] g4: f8a00493a4e0 g5: f89fff97c000 g6: f8a006c64000 
g7: 
[29075.138329] o0:  o1: f8a006c67968 o2: 0008 
o3: 0001
[29075.242493] o4: 3385 o5:  sp: f8a006c67011 
ret_pc: 0042f980
[29075.350830] RPC: 
[29075.392482] l0: 0020 l1:  l2: 0096 
l3: 
[29075.496658] l4: 0200 l5: 0001c5569e6c l6: 0006c390404c 
l7: 6204052f31ec823e
[29075.600824] i0: 0044d100 i1: 00b0fcc2c000 i2:  
i3: 
[29075.704989] i4: 0040 i5: 007a0578 i6: f8a006c670d1 
i7: 004420d8
[29075.809161] I7: 
[29075.867493] BUG: soft lockup - CPU#2 stuck for 11s! [sh:4253]
[29075.936259] TSTATE: 11009600 TPC: 004417a8 TNPC: 
004417ac Y: Not tainted
[29076.053980] TPC: 
[29076.113311] g0:  g1:  g2:  
g3: 
[29076.217483] g4: f8a0048f9260 g5: f89fff98c000 g6: f8a006c7 
g7: 
[29076.321648] o0: 0020 o1: f8a006c73968 o2: 0002 
o3: 0001
[29076.425816] o4: 781b o5:  sp: f8a006c73011 
ret_pc: 004416a0
[29076.534150] RPC: 
[29076.592471] l0: 0008 l1:  l2: 0096 
l3: 
[29076.696645] l4: 0200 l5: 0001c5569e6c l6: 0006c3904054 
l7: 7e645445948ed154
[29076.800811] i0: 0044d100 i1: 00b0fcf8 i2:  
i3: 
[29076.904977] i4: 0040 i5: 007a0578 i6: f8a006c730d1 
i7: 004420d8
[29077.009144] I7: 

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Raid1/5 over iSCSI trouble

[Ming Zhang]

off topic, could you resubmit the alignment issue patch to list and see
if tomof accept. he needs a patch inlined in email. it is found and
fixed by you, so had better you post it (instead of me). thx.


On Sat, 2007-10-27 at 15:29 +0200, BERTRAND Joël wrote:
> Dan Williams wrote:
> > On 10/24/07, BERTRAND Joël <[EMAIL PROTECTED]> wrote:
> >> Hello,
> >>
> >> Any news about this trouble ? Any idea ? I'm trying to fix it, but 
> >> I
> >> don't see any specific interaction between raid5 and istd. Does anyone
> >> try to reproduce this bug on another arch than sparc64 ? I only use
> >> sparc32 and 64 servers and I cannot test on other archs. Of course, I
> >> have a laptop, but I cannot create a raid5 array on its internal HD to
> >> test this configuration ;-)
> >>
> > 
> > Can you collect some oprofile data, as Ming suggested, so we can maybe
> > see what md_d0_raid5 and istd1 are fighting about?  Hopefully it is as
> > painless to run on sparc as it is on IA:
> > 
> > opcontrol --start --vmlinux=/path/to/vmlinux
> > 
> > opcontrol --stop
> > opreport --image-path=/lib/modules/`uname -r` -l
> 
>   Done.
> 
> Profiling through timer interrupt
> samples  %image name   app name 
> symbol name
> 20028038 92.9510  vmlinux-2.6.23   vmlinux-2.6.23   cpu_idle
> 1198566   5.5626  vmlinux-2.6.23   vmlinux-2.6.23   schedule
> 41558 0.1929  vmlinux-2.6.23   vmlinux-2.6.23   yield
> 34791 0.1615  vmlinux-2.6.23   vmlinux-2.6.23   NGmemcpy
> 18417 0.0855  vmlinux-2.6.23   vmlinux-2.6.23 
> xor_niagara_5

raid5 use these 2. forgot to ask if you met any memory pressure here.




> 17430 0.0809  raid456  raid456  (no 
> symbols)
> 15837 0.0735  vmlinux-2.6.23   vmlinux-2.6.23 
> sys_sched_yield
> 14860 0.0690  iscsi_trgt.koiscsi_trgt   istd

could you get a call graph from oprofile. the yield is called quite
frequently. iet has some place to call it when no memory available. not
sure if this is the case.

i remember there was a post (maybe in lwn.net?) about some issues
between tickless kernel and yield() lead to 100% cpu utilization, i just
could not recalled the place, anybody have a clue?

or sparc64 does not have tickless kernel yet? did not follow these
carefully these days.


> 12705 0.0590  nf_conntrack nf_conntrack (no 
> symbols)
> 9236  0.0429  libc-2.6.1.solibc-2.6.1.so(no 
> symbols)
> 9034  0.0419  vmlinux-2.6.23   vmlinux-2.6.23 
> xor_niagara_2
> 6534  0.0303  oprofiledoprofiled(no 
> symbols)
> 6149  0.0285  vmlinux-2.6.23   vmlinux-2.6.23 
> scsi_request_fn
> 5947  0.0276  ip_tablesip_tables(no 
> symbols)
> 4510  0.0209  vmlinux-2.6.23   vmlinux-2.6.23 
> dma_4v_map_single
> 3823  0.0177  vmlinux-2.6.23   vmlinux-2.6.23 
> __make_request
> 3326  0.0154  vmlinux-2.6.23   vmlinux-2.6.23   tg3_poll
> 3162  0.0147  iscsi_trgt.koiscsi_trgt 
> scsi_cmnd_exec
> 3091  0.0143  vmlinux-2.6.23   vmlinux-2.6.23 
> scsi_dispatch_cmd
> 2849  0.0132  vmlinux-2.6.23   vmlinux-2.6.23 
> tcp_v4_rcv
> 2811  0.0130  vmlinux-2.6.23   vmlinux-2.6.23 
> nf_iterate
> 2729  0.0127  vmlinux-2.6.23   vmlinux-2.6.23 
> _spin_lock_bh
> 2551  0.0118  vmlinux-2.6.23   vmlinux-2.6.23   kfree
> 2467  0.0114  vmlinux-2.6.23   vmlinux-2.6.23 
> kmem_cache_free
> 2314  0.0107  vmlinux-2.6.23   vmlinux-2.6.23 
> atomic_add
> 2065  0.0096  vmlinux-2.6.23   vmlinux-2.6.23 
> NGbzero_loop
> 1826  0.0085  vmlinux-2.6.23   vmlinux-2.6.23   ip_rcv
> 1823  0.0085  nf_conntrack_ipv4nf_conntrack_ipv4(no 
> symbols)
> 1822  0.0085  vmlinux-2.6.23   vmlinux-2.6.23 
> clear_bit
> 1767  0.0082  python2.4python2.4(no 
> symbols)
> 1734  0.0080  vmlinux-2.6.23   vmlinux-2.6.23 
> atomic_sub_ret
> 1694  0.0079  vmlinux-2.6.23   vmlinux-2.6.23 
> tcp_rcv_established
> 1673  0.0078  vmlinux-2.6.23   vmlinux-2.6.23 
> tcp_recvmsg
> 1670  0.0078  vmlinux-2.6.23   vmlinux-2.6.23 
> netif_receive_skb
> 1668  0.0077  vmlinux-2.6.23   vmlinux-2.6.23   set_bit
> 1545  0.0072  vmlinux-2.6.23   vmlinux-2.6.23 
> __kmalloc_track_caller
> 1526  0.0071  iptable_nat  iptable_nat  (no 
> symbols)
> 1526  0.0071  vmlinux-2.6.23   vmlinux-2.6.23 
> kmem_cache_alloc
> 1373  0.0064  vmlinux-2.6.23   vmlinux-2.6.23 
> generic_unplug_device
> ...
> 
>   Is it enough ?
> 
>   Regards,
> 
>   JKB
-- 
Ming Zhang


@#$%^ purging memory... (*!%
http:

Re: [BUG] Raid1/5 over iSCSI trouble

[BERTRAND Joël]

Dan Williams wrote:

On 10/27/07, BERTRAND Joël <[EMAIL PROTECTED]> wrote:

Dan Williams wrote:

Can you collect some oprofile data, as Ming suggested, so we can maybe
see what md_d0_raid5 and istd1 are fighting about?  Hopefully it is as
painless to run on sparc as it is on IA:

opcontrol --start --vmlinux=/path/to/vmlinux

opcontrol --stop
opreport --image-path=/lib/modules/`uname -r` -l

Done.



[..]


Is it enough ?


I would expect md_d0_raid5 and istd1 to show up pretty high in the
list if they are constantly pegged at a 100% CPU utilization like you
showed in the failure case.  Maybe this was captured after the target
has disconnected?


	No, I have launched opcontrol before starting raid1 creation, and 
stopped after disconnection. Don't forget that this server has 32 CPU's.


Regards,

JKB
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: unkillable dpkg-query processes

[Bernd Zeimetz]

> 
> Luckily much more output of sysrq is in the syslog, so I should be able to 
> mail it later when the
> machine is finished with rebooting (which takes some time...).

the sysrq output from the syslog and my kernel config are attached to this mail.

Cheers,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


config-2.6.24-rc1-git2+bzed-farm1.gz
Description: GNU Zip compressed data


syslog.gz
Description: GNU Zip compressed data

Re: [BUG] Raid1/5 over iSCSI trouble

[Dan Williams]

On 10/27/07, BERTRAND Joël <[EMAIL PROTECTED]> wrote:
> Dan Williams wrote:
> > Can you collect some oprofile data, as Ming suggested, so we can maybe
> > see what md_d0_raid5 and istd1 are fighting about?  Hopefully it is as
> > painless to run on sparc as it is on IA:
> >
> > opcontrol --start --vmlinux=/path/to/vmlinux
> > 
> > opcontrol --stop
> > opreport --image-path=/lib/modules/`uname -r` -l
>
> Done.
>

[..]

>
> Is it enough ?

I would expect md_d0_raid5 and istd1 to show up pretty high in the
list if they are constantly pegged at a 100% CPU utilization like you
showed in the failure case.  Maybe this was captured after the target
has disconnected?
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: unkillable dpkg-query processes

[Bernd Zeimetz]

Bernd Zeimetz wrote:
>>> For those who can reproduce it an have something like libnss-db
>>> enabled, try disabling it.
> 
> - disabled it
> - running vgdisplay killed the machine (wanted to create a new LV for a
> chroot)... it's not accessible at all anymore, I think the kernel is
> a 2.6.23-something here, I'll build a recent one and give it a try
> again Will take some time as I need to build on USII...


I just wanted to write that I'm not able to reproduce this bug
anymore... but running aptitude -u often enough gave me this nice output:


titan:~# [ 2427.313946] BUG: soft lockup - CPU#3 stuck for 11s! [aptitude:13375]
[ 2427.389128] TSTATE: 11009602 TPC: 0042f93c TNPC: 
0042f7d0 Y: Not tainted
[ 2427.506821] TPC: <__delay+0x1c/0x48>
[ 2427.549494] g0: 9000 g1: 0042f7d0 g2:  
g3: 
[ 2427.653670] g4: f8a00793c960 g5: f89fff994000 g6: f8a007dfc000 
g7: 
[ 2427.757835] o0: 0020 o1: 0020 o2:  
o3: 
[ 2427.862001] o4: 0030a0d0 o5:  sp: f8a007dff071 
ret_pc: 0042f938
[ 2427.970337] RPC: <__delay+0x18/0x48>
[ 2428.013031] l0: 0005a6cab647 l1: 11009601 l2: 004417a8 
l3: 0400
[ 2428.117206] l4:  l5: 0001 l6:  
l7: 0008
[ 2428.221374] i0:  i1: f8a007dffa88 i2: 0004 
i3: 0001
[ 2428.325538] i4:  i5:  i6: f8a007dff131 
i7: 004417ec
[ 2428.429710] I7: 

and an unkillable, cpu-eating aptitude.


While retrieving some info using sysrq the machine froze after
echoing m into sysrq-trigger, producing this output while dieing:

[ 3680.006794] BUG: soft lockup - CPU#1 stuck for 11s! [pdflush:265]
[ 3680.078838] TSTATE: 80009603 TPC: 004417a8 TNPC: 
004417ac Y: Not tainted
[ 3680.196551] TPC: 
[ 3680.255881] g0:  g1:  g2: 0001869e 
g3: 
[ 3680.360055] g4: f8a0048e3260 g5: f89fff984000 g6: f8a00717c000 
g7: 
[ 3680.464220] o0: 0020 o1: f8a00717f418 o2: f8a005a84040 
o3: 0010
[ 3680.568384] o4: 0015 o5:  sp: f8a00717eac1 
ret_pc: 004416e4
[ 3680.676719] RPC: 
[ 3680.735042] l0: 0002 l1: 0002 l2: 0096 
l3: 
[ 3680.839217] l4:  l5: f8a0048d3cd8 l6: 00024098 
l7: f7d31000
[ 3680.943382] i0: 0044d100 i1: 00b0f60f8000 i2:  
i3: 0001
[ 3681.047548] i4: 0001 i5: 0001 i6: f8a00717eb81 
i7: 00442be4
[ 3681.151717] I7: 



Luckily much more output of sysrq is in the syslog, so I should be able to mail 
it later when the
machine is finished with rebooting (which takes some time...).


 2.6.24-rc1-git2 (SMP)
 gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)


titan:~# cat /proc/cpuinfo
cpu : TI UltraSparc III (Cheetah)
fpu : UltraSparc III integrated FPU
prom: OBP 4.22.34 2007/07/23 13:01
type: sun4u
ncpus probed: 4
ncpus active: 4
D$ parity tl1   : 0
I$ parity tl1   : 0
Cpu0ClkTck  : 2cb41780
Cpu1ClkTck  : 2cb41780
Cpu2ClkTck  : 2cb41780
Cpu3ClkTck  : 2cb41780
MMU Type: Cheetah
State:
CPU0:   online
CPU1:   online
CPU2:   online
CPU3:   online



-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 

-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

possible typo in arch/sparc64/kernel/time.c

[Roel Kluin]

I already posted something on lkml, but it wasn't picked up

in arch/sparc64/kernel/time.c, line 1073 it reads:

if (!mregs && !dregs & !bregs)

shouldn this be

if (!mregs && !dregs && !bregs)

or

if (!mregs && !(dregs & !bregs))

?
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Raid1/5 over iSCSI trouble

[BERTRAND Joël]

Dan Williams wrote:

On 10/24/07, BERTRAND Joël <[EMAIL PROTECTED]> wrote:

Hello,

Any news about this trouble ? Any idea ? I'm trying to fix it, but I
don't see any specific interaction between raid5 and istd. Does anyone
try to reproduce this bug on another arch than sparc64 ? I only use
sparc32 and 64 servers and I cannot test on other archs. Of course, I
have a laptop, but I cannot create a raid5 array on its internal HD to
test this configuration ;-)



Can you collect some oprofile data, as Ming suggested, so we can maybe
see what md_d0_raid5 and istd1 are fighting about?  Hopefully it is as
painless to run on sparc as it is on IA:

opcontrol --start --vmlinux=/path/to/vmlinux

opcontrol --stop
opreport --image-path=/lib/modules/`uname -r` -l


Done.

Profiling through timer interrupt
samples  %image name   app name 
symbol name

20028038 92.9510  vmlinux-2.6.23   vmlinux-2.6.23   cpu_idle
1198566   5.5626  vmlinux-2.6.23   vmlinux-2.6.23   schedule
41558 0.1929  vmlinux-2.6.23   vmlinux-2.6.23   yield
34791 0.1615  vmlinux-2.6.23   vmlinux-2.6.23   NGmemcpy
18417 0.0855  vmlinux-2.6.23   vmlinux-2.6.23 
xor_niagara_5
17430 0.0809  raid456  raid456  (no 
symbols)
15837 0.0735  vmlinux-2.6.23   vmlinux-2.6.23 
sys_sched_yield

14860 0.0690  iscsi_trgt.koiscsi_trgt   istd
12705 0.0590  nf_conntrack nf_conntrack (no 
symbols)
9236  0.0429  libc-2.6.1.solibc-2.6.1.so(no 
symbols)
9034  0.0419  vmlinux-2.6.23   vmlinux-2.6.23 
xor_niagara_2
6534  0.0303  oprofiledoprofiled(no 
symbols)
6149  0.0285  vmlinux-2.6.23   vmlinux-2.6.23 
scsi_request_fn
5947  0.0276  ip_tablesip_tables(no 
symbols)
4510  0.0209  vmlinux-2.6.23   vmlinux-2.6.23 
dma_4v_map_single
3823  0.0177  vmlinux-2.6.23   vmlinux-2.6.23 
__make_request

3326  0.0154  vmlinux-2.6.23   vmlinux-2.6.23   tg3_poll
3162  0.0147  iscsi_trgt.koiscsi_trgt 
scsi_cmnd_exec
3091  0.0143  vmlinux-2.6.23   vmlinux-2.6.23 
scsi_dispatch_cmd
2849  0.0132  vmlinux-2.6.23   vmlinux-2.6.23 
tcp_v4_rcv
2811  0.0130  vmlinux-2.6.23   vmlinux-2.6.23 
nf_iterate
2729  0.0127  vmlinux-2.6.23   vmlinux-2.6.23 
_spin_lock_bh

2551  0.0118  vmlinux-2.6.23   vmlinux-2.6.23   kfree
2467  0.0114  vmlinux-2.6.23   vmlinux-2.6.23 
kmem_cache_free
2314  0.0107  vmlinux-2.6.23   vmlinux-2.6.23 
atomic_add
2065  0.0096  vmlinux-2.6.23   vmlinux-2.6.23 
NGbzero_loop

1826  0.0085  vmlinux-2.6.23   vmlinux-2.6.23   ip_rcv
1823  0.0085  nf_conntrack_ipv4nf_conntrack_ipv4(no 
symbols)
1822  0.0085  vmlinux-2.6.23   vmlinux-2.6.23 
clear_bit
1767  0.0082  python2.4python2.4(no 
symbols)
1734  0.0080  vmlinux-2.6.23   vmlinux-2.6.23 
atomic_sub_ret
1694  0.0079  vmlinux-2.6.23   vmlinux-2.6.23 
tcp_rcv_established
1673  0.0078  vmlinux-2.6.23   vmlinux-2.6.23 
tcp_recvmsg
1670  0.0078  vmlinux-2.6.23   vmlinux-2.6.23 
netif_receive_skb

1668  0.0077  vmlinux-2.6.23   vmlinux-2.6.23   set_bit
1545  0.0072  vmlinux-2.6.23   vmlinux-2.6.23 
__kmalloc_track_caller
1526  0.0071  iptable_nat  iptable_nat  (no 
symbols)
1526  0.0071  vmlinux-2.6.23   vmlinux-2.6.23 
kmem_cache_alloc
1373  0.0064  vmlinux-2.6.23   vmlinux-2.6.23 
generic_unplug_device

...

Is it enough ?

Regards,

JKB
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html