Hello, I would like to report an Ooops that I observed lately.
Hope this information is helpful.
Since I am not on the linux-kernel mailing list, please send me an
e-mail
if you need more information.
Happy Hacking,
Chiaki Ishikawa
--- begin report ----
Lately I have seen a few Ooops.
I have not seen Ooops for close to half a year or so thanks to
the great work of kernel hackers.
(I have seen hard lockups due to driver problems.)
This particular ooopses happened after I began compiling the kernel
using gcc 2.95.2 around mid-December and I added a new memory card at
the end of December.
Kernel version.: sorry I am not sure if the FIRST similar Ooops I saw
was with 2.12.13 (on Jan 2nd or Jan 3rd).
But the second last and the last Ooops messages are definitely from
kernel 2.12.14.
uname -a output:
Linux standard 2.2.14 #18 SMP Thu Jan 6 06:07:45 JST 2000 i586 unknown
gcc -v output
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)
I noticed that the Ooops error messages (so far three times) showed
the SAME process `xntpd' being the culprit during at the time of
Ooops, and so I think the hardware problem may not be there.
All three Ooopses happened during the first cold-boot of the day
in January of this year.
(Many of you suspect the hardware failure, say, the memory chip, but
I have a suspicion that gcc 2.95.2 miscompiles something here.
Also, there could be a y2k related problem, but I am in doubt there.)
As soon as I power-cycle the machine, the linux boots up OK.
After seeing this for the third time, I am writing this report.
Strange Ooops display:
One strange thing I noticed about this particular Ooops is that
Ooops-like message is
shown at least twice during the failure.
During the booting, somewhere in the middle of initial booting
process, Ooops-like message is shown and I recognize it, but the
booting continues as if nothing happened and the message is scrolled
up and disappear. (Strange, the system doesn't crash then and there.)
Only after the various daemons start, the second (or possibly the
third since I suspect there was another Ooops message that was
scrolled so quickly that I didn't catch it in its entirely) fatal
Ooops is shown. So far, on the three occasions, the xntpd daemons are
shown as the running process at the time of the final Ooops.
This observation prompted me to think that the bug is software-related.
Given that arp-related functions appear in the following Ooops stack
dump I should mention that I have a dial-up router ( a device that has
built-in ppp and acts as a router) that is connected to the linux
PC. When the linux Ooops occurs, the device has not started the ppp
connection yet. Also, only god knows what the arp table status within
that device when the linux PC is booted up after several hours of
rest. (The LAN is for a home use and so there is only linux-PC and
another Win95 PC on the LAN side of the dial-up router.)
----------------------------------------
Used Network devices and such:
Before I proceed to give the Ooops message, I should probably
explain what devices are there.
I use Intel EtherExpress Pro 10/100 Ethernet card
although the dial-up router supports only 10Mb ethernet
connection.
>ishikawa@standard$ cat /proc/interrupts
> CPU0
> 0: 418605 XT-PIC timer
> 1: 27622 XT-PIC keyboard
> 2: 0 XT-PIC cascade
> 5: 2196 XT-PIC Intel EtherExpress Pro 10/100 Ethernet
> 8: 2 XT-PIC rtc
> 9: 144206 XT-PIC BusLogic BT-930
> 10: 7 XT-PIC tmscsim
> 12: 12534 XT-PIC PS/2 Mouse
> 13: 0 XT-PIC fpu
> 14: 79 XT-PIC ide0
>NMI: 0
>ERR: 0
Another thing I should probably mention is that I enabled
RTC support in the config as below.
># CONFIG_NVRAM is not set
>CONFIG_RTC=y
I thought this was needed for better support of ntp daemons
such as xntp. I am not sure if this matters, but given that
the running process at the time of Ooopses
was xntpd, I should mention this just in case.
========================================
Finally, here is the Ooops lines that I copied from the screen at the
time of the third crash. The "al address 0000000" in the first line is
NOT a typo. It is shown like that. (I suspect there was more
information preceding this final screenful of lines. Maybe the ending
part of another quickly disppearping Ooops line,
"... virtual address 00000000"? )
CRT screen image of the dump.
al address 00000000
current->tss.cr3 = 0c53d000, %cr3 = 0c53d000
*pde = 0000000
Ooops = 0000
cpu: 0
EIP: 0010:[<00000000>]
EFLAGS: 00010283
eax: 00000000 ebx: cdfec920 ecx: cd6050e0 edx: cdfec990
esi: cd6050e0 edi: cda90800 ebp: cda9086f esp: cc53fbd8
ds: 0018 es: 0018 ss: 0018
Process xntpd (pid = 186, process nr:19, stackpage = cc53f000)
Stack: cda90800 cc53fbf4 00000282 cda90800 cdfec920 cd8707e8 cda90868
c0201460
00001209 10108000 c0159de6 cda90800 cdfec920 cd8707d0 c0159db8
cd6050e0
cda90800 cd870680 c01702cf cd6050e0 cda90800 00000806 c01703a6
cd6050e0
Call Trace: [<c0159de6>] [<c0159db8>] [<c01702cf>] [<c01703a6>]
[<c016ff8f>] [<c015c1eb>] [<c015c1de>]
[<c015c19b>] [<c015c81b>] [<c0162cd8>] [<c0163512>] [<c0163695>]
[<c016f4b1>] [<c016f0b4>] [<c0173931>]
[<c01ad5d7>] [<c0155f2b>] [<c0156c3f>] [<f011b669>] [<c0133484>]
[<c01575b6>] [<c0109314>]
Code: <1>Unable to handle kernel NULL pointer dereference at virtual
addresss 00000000
current->tss.cr3=0c53d000, %cr3 = 0c53d000
*pde = 00000000
----------------------------------------
ksymoops output using the above record.
(ppp module and hpfs module are used and I think that is why we see
warnings about the module bsd_comp, and the module hpfs.)
ishikawa@standard$ ksymoops < oops-2000-01-09.txt
ksymoops 2.3.3 on i586 2.2.14. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.14/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Warning (compare_ksyms_lsmod): module bsd_comp is in lsmod but not in
ksyms, probably no symbols exported
Warning (compare_ksyms_lsmod): module hpfs is in lsmod but not in ksyms,
probably no symbols exported
current->tss.cr3 = 0c53d000, %cr3 = 0c53d000
*pde = 0000000
cpu: 0
EIP: 0010:[<00000000>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010283
eax: 00000000 ebx: cdfec920 ecx: cd6050e0 edx: cdfec990
esi: cd6050e0 edi: cda90800 ebp: cda9086f esp: cc53fbd8
ds: 0018 es: 0018 ss: 0018
Stack: cda90800 cc53fbf4 00000282 cda90800 cdfec920 cd8707e8 cda90868
c0201460
00001209 10108000 c0159de6 cda90800 cdfec920 cd8707d0 c0159db8
cd6050e0
cda90800 cd870680 c01702cf cd6050e0 cda90800 00000806 c01703a6
cd6050e0
Call Trace: [<c0159de6>] [<c0159db8>] [<c01702cf>] [<c01703a6>]
[<c016ff8f>] [<c015c1eb>] [<c015c1de>]
[<c015c19b>] [<c015c81b>] [<c0162cd8>] [<c0163512>] [<c0163695>]
[<c016f4b1>] [<c016f0b4>] [<c0173931>]
[<c01ad5d7>] [<c0155f2b>] [<c0156c3f>] [<f011b669>] [<c0133484>]
[<c01575b6>] [<c0109314>]
Code: <1>Unable to handle kernel NULL pointer dereference at virtual
addresss 00000000
Warning (Oops_code): trailing garbage ignored on Code: line
Text: 'Code: <1>Unable to handle kernel NULL pointer dereference at
virtual addresss 00000000'
Garbage: 'Unable to handle kernel NULL pointer dereference at virtual
addresss 00000000'
Warning (Oops_code_values): Code looks like message, not hex digits. No
disassembly attempted.
>>EIP; 00000000 Before first symbol
Trace; c0159de6 <dev_queue_xmit+46/e4>
Trace; c0159db8 <dev_queue_xmit+18/e4>
Trace; c01702cf <arp_send+ef/1d4>
Trace; c01703a6 <arp_send+1c6/1d4>
Trace; c016ff8f <arp_solicit+c7/d4>
Trace; c015c1eb <__neigh_event_send+6b/154>
Trace; c015c1de <__neigh_event_send+5e/154>
Trace; c015c19b <__neigh_event_send+1b/154>
Trace; c015c81b <neigh_resolve_output+4f/154>
Trace; c0162cd8 <ip_output+a4/d0>
Trace; c0163512 <ip_build_xmit+fe/2bc>
Trace; c0163695 <ip_build_xmit+281/2bc>
Trace; c016f4b1 <udp_sendmsg+2d9/320>
Trace; c016f0b4 <udp_getfrag+0/d8>
Trace; c0173931 <inet_sendmsg+91/a4>
Trace; c01ad5d7 <do_sd_request+1e7/1f8>
Trace; c0155f2b <sock_sendmsg+73/98>
Trace; c0156c3f <sys_sendto+eb/128>
Trace; f011b669 <END_OF_CODE+218f2ca9/????> <= could have been c011b669?
Trace; c0133484 <do_select+1e0/23c>
Trace; c01575b6 <sys_socketcall+156/21c>
Trace; c0109314 <system_call+34/40>
current->tss.cr3=0c53d000, %cr3 = 0c53d000
*pde = 00000000
5 warnings issued. Results may not be reliable.
ishikawa@standard$
----------------------------------------
DUMP as suggested in /usr/src/linux/Documentation/oops-tracing.txt
ishikawa@standard$ file /usr/src/linux/vmlinux
/usr/src/linux/vmlinux: ELF 32-bit LSB executable, Intel 80386, version
1, statically linked, not stripped
ishikawa@standard$ gdb /usr/src/linux/vmlinux
GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i486-pc-linux-gnu"...
(no debugging symbols found)...
(gdb) disassemble dev_queue_xmit
Dump of assembler code for function dev_queue_xmit:
0xc0159da0 <dev_queue_xmit>: subl $0x14,%esp
0xc0159da3 <dev_queue_xmit+3>: pushl %esi
0xc0159da4 <dev_queue_xmit+4>: pushl %ebx
0xc0159da5 <dev_queue_xmit+5>: movl 0x20(%esp,1),%esi
0xc0159da9 <dev_queue_xmit+9>: movl 0x18(%esi),%ebx
0xc0159dac <dev_queue_xmit+12>: lock incl 0xc023acf8
0xc0159db3 <dev_queue_xmit+19>: call 0xc010b5a0 <synchronize_bh>
0xc0159db8 <dev_queue_xmit+24>: movl 0x94(%ebx),%eax
0xc0159dbe <dev_queue_xmit+30>: cmpl $0x0,0x4(%eax)
0xc0159dc2 <dev_queue_xmit+34>: je 0xc0159e04 <dev_queue_xmit+100>
0xc0159dc4 <dev_queue_xmit+36>: addl $0xfffffff8,%esp
0xc0159dc7 <dev_queue_xmit+39>: pushl %eax
0xc0159dc8 <dev_queue_xmit+40>: pushl %esi
0xc0159dc9 <dev_queue_xmit+41>: movl 0x4(%eax),%eax
0xc0159dcc <dev_queue_xmit+44>: call *%eax
0xc0159dce <dev_queue_xmit+46>: addl $0x10,%esp
0xc0159dd1 <dev_queue_xmit+49>: cmpl $0x0,0x24(%ebx)
0xc0159dd5 <dev_queue_xmit+53>: jne 0xc0159e34 <dev_queue_xmit+148>
0xc0159dd7 <dev_queue_xmit+55>: movl 0x94(%ebx),%esi
0xc0159ddd <dev_queue_xmit+61>: addl $0xfffffff4,%esp
0xc0159de0 <dev_queue_xmit+64>: pushl %ebx
0xc0159de1 <dev_queue_xmit+65>: call 0xc015d530 <qdisc_restart>
---Type <return> to continue, or q <return> to quit---q
Quit
----------------------------------------
Comment: We see the recursive calls to
dev_queue_xmit() in the stack trace.
This looks to me due to the calling of
a member function of a certain structure of
which pointer was somehow passed to dev_queeu_xmit.
(we are passing 0-valued pointer in certain fields???)
----------------------------------------
FULL disassemble of net/core/dev.o
standard:/opt/kernel/2.2.9# make net/core/dev.o
make: `net/core/dev.o' is up to date.
standard:/opt/kernel/2.2.9#
bash: cd: net/core/dev.o: Not a directory
standard:/opt/kernel/2.2.9# cd net/core
standard:/opt/kernel/2.2.9/net/core# gdb dev.o
GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i486-pc-linux-gnu"...
(no debugging symbols found)...
(gdb) disassembly dev_queue_xmit
Undefined command: "disassembly". Try "help".
(gdb)
Undefined command: "disasseble". Try "help".
(gdb) disassemble dev_queue_xmit
Dump of assembler code for function dev_queue_xmit:
0x59c <dev_queue_xmit>: subl $0x14,%esp
0x59f <dev_queue_xmit+3>: pushl %esi
0x5a0 <dev_queue_xmit+4>: pushl %ebx
0x5a1 <dev_queue_xmit+5>: movl 0x20(%esp,1),%esi
0x5a5 <dev_queue_xmit+9>: movl 0x18(%esi),%ebx
0x5a8 <dev_queue_xmit+12>: lock incl 0x0
0x5af <dev_queue_xmit+19>: call 0x5b0 <dev_queue_xmit+20>
0x5b4 <dev_queue_xmit+24>: movl 0x94(%ebx),%eax
0x5ba <dev_queue_xmit+30>: cmpl $0x0,0x4(%eax)
0x5be <dev_queue_xmit+34>: je 0x600 <dev_queue_xmit+100>
0x5c0 <dev_queue_xmit+36>: addl $0xfffffff8,%esp
0x5c3 <dev_queue_xmit+39>: pushl %eax
0x5c4 <dev_queue_xmit+40>: pushl %esi
0x5c5 <dev_queue_xmit+41>: movl 0x4(%eax),%eax
0x5c8 <dev_queue_xmit+44>: call *%eax
0x5ca <dev_queue_xmit+46>: addl $0x10,%esp
0x5cd <dev_queue_xmit+49>: cmpl $0x0,0x24(%ebx)
0x5d1 <dev_queue_xmit+53>: jne 0x630 <dev_queue_xmit+148>
0x5d3 <dev_queue_xmit+55>: movl 0x94(%ebx),%esi
0x5d9 <dev_queue_xmit+61>: addl $0xfffffff4,%esp
0x5dc <dev_queue_xmit+64>: pushl %ebx
0x5dd <dev_queue_xmit+65>: call 0x5de <dev_queue_xmit+66>
---Type <return> to continue, or q <return> to quit---
0x5e2 <dev_queue_xmit+70>: addl $0x10,%esp
0x5e5 <dev_queue_xmit+73>: testl %eax,%eax
0x5e7 <dev_queue_xmit+75>: je 0x630 <dev_queue_xmit+148>
0x5e9 <dev_queue_xmit+77>: cmpl $0x0,(%esi)
0x5ec <dev_queue_xmit+80>: jne 0x630 <dev_queue_xmit+148>
0x5ee <dev_queue_xmit+82>: movl 0x0,%eax
0x5f3 <dev_queue_xmit+87>: movl %eax,(%esi)
0x5f5 <dev_queue_xmit+89>: movl %esi,0x0
0x5fb <dev_queue_xmit+95>: jmp 0x630 <dev_queue_xmit+148>
0x5fd <dev_queue_xmit+97>: leal 0x0(%esi),%esi
0x600 <dev_queue_xmit+100>: testb $0x1,0x50(%ebx)
0x604 <dev_queue_xmit+104>: je 0x658 <dev_queue_xmit+188>
0x606 <dev_queue_xmit+106>: cmpl $0x0,0x0
0x60d <dev_queue_xmit+113>: je 0x61c <dev_queue_xmit+128>
0x60f <dev_queue_xmit+115>: addl $0xfffffff8,%esp
0x612 <dev_queue_xmit+118>: pushl %ebx
0x613 <dev_queue_xmit+119>: pushl %esi
0x614 <dev_queue_xmit+120>: call 0x454 <dev_queue_xmit_nit>
0x619 <dev_queue_xmit+125>: addl $0x10,%esp
0x61c <dev_queue_xmit+128>: addl $0xfffffff8,%esp
0x61f <dev_queue_xmit+131>: pushl %ebx
0x620 <dev_queue_xmit+132>: pushl %esi
0x621 <dev_queue_xmit+133>: movl 0xb0(%ebx),%eax
---Type <return> to continue, or q <return> to quit---
0x627 <dev_queue_xmit+139>: call *%eax
0x629 <dev_queue_xmit+141>: addl $0x10,%esp
0x62c <dev_queue_xmit+144>: testl %eax,%eax
0x62e <dev_queue_xmit+146>: jne 0x63c <dev_queue_xmit+160>
0x630 <dev_queue_xmit+148>: lock decl 0x0
0x637 <dev_queue_xmit+155>: jmp 0x676 <dev_queue_xmit+218>
0x639 <dev_queue_xmit+157>: leal 0x0(%esi),%esi
0x63c <dev_queue_xmit+160>: call 0x63d <dev_queue_xmit+161>
0x641 <dev_queue_xmit+165>: testl %eax,%eax
0x643 <dev_queue_xmit+167>: je 0x658 <dev_queue_xmit+188>
0x645 <dev_queue_xmit+169>: addl $0xfffffff8,%esp
0x648 <dev_queue_xmit+172>: movl (%ebx),%eax
0x64a <dev_queue_xmit+174>: pushl %eax
0x64b <dev_queue_xmit+175>: pushl $0x180
0x650 <dev_queue_xmit+180>: call 0x651 <dev_queue_xmit+181>
0x655 <dev_queue_xmit+185>: addl $0x10,%esp
0x658 <dev_queue_xmit+188>: lock decl 0x0
0x65f <dev_queue_xmit+195>: lock decl 0x70(%esi)
0x663 <dev_queue_xmit+199>: sete %al
0x666 <dev_queue_xmit+202>: testb %al,%al
0x668 <dev_queue_xmit+204>: je 0x676 <dev_queue_xmit+218>
0x66a <dev_queue_xmit+206>: addl $0xfffffff4,%esp
0x66d <dev_queue_xmit+209>: pushl %esi
---Type <return> to continue, or q <return> to quit---
0x66e <dev_queue_xmit+210>: call 0x66f <dev_queue_xmit+211>
0x673 <dev_queue_xmit+215>: addl $0x10,%esp
0x676 <dev_queue_xmit+218>: xorl %eax,%eax
0x678 <dev_queue_xmit+220>: popl %ebx
0x679 <dev_queue_xmit+221>: popl %esi
0x67a <dev_queue_xmit+222>: addl $0x14,%esp
0x67d <dev_queue_xmit+225>: ret
0x67e <dev_queue_xmit+226>: movl %esi,%esi
End of assembler dump.
(gdb)
----------------------------------------
Checking where dev_queue_xmit is called.
>From the following we can see net/ipv4/arp.c does call
dev_queue_xmit.
ishikawa@standard$ find . -name "*.[cChH]" -print | xargs egrep
dev_queue_xmit
./include/linux/netdevice.h:extern int dev_queue_xmit(struct
sk_buff *skb);
./include/linux/netdevice.h:extern void
dev_queue_xmit_nit(struct sk_buff *skb, struct device *dev);
./net/802/llc_sendpdu.c: dev_queue_xmit(skb);
./net/802/llc_sendpdu.c: dev_queue_xmit(tmp);
./net/802/llc_sendpdu.c: dev_queue_xmit(skb);
./net/appletalk/aarp.c: dev_queue_xmit(skb);
./net/appletalk/aarp.c: dev_queue_xmit(skb);
./net/appletalk/aarp.c: dev_queue_xmit(skb);
./net/appletalk/aarp.c: dev_queue_xmit(skb);
./net/appletalk/aarp.c: dev_queue_xmit(skb);
./net/appletalk/aarp.c: dev_queue_xmit(skb);
./net/appletalk/aarp.c: dev_queue_xmit(skb);
./net/appletalk/aarp.c: dev_queue_xmit(skb);
./net/ax25/ax25_out.c: * A small shim to dev_queue_xmit to add
the KISS control byte, and do
./net/ax25/ax25_out.c: dev_queue_xmit(skb);
./net/ax25/ax25_ds_subr.c: dev_queue_xmit(skb);
./net/core/dev.c:NET_PROFILE_DEFINE(dev_queue_xmit)
./net/core/dev.c:void dev_queue_xmit_nit(struct sk_buff *skb, struct
device *dev)
./net/core/dev.c:int dev_queue_xmit(struct sk_buff *skb)
./net/core/dev.c: NET_PROFILE_ENTER(dev_queue_xmit);
./net/core/dev.c: NET_PROFILE_LEAVE(dev_queue_xmit);
./net/core/dev.c: dev_queue_xmit_nit(skb,dev);
./net/core/dev.c:
NET_PROFILE_LEAVE(dev_queue_xmit);
./net/core/dev.c: NET_PROFILE_LEAVE(dev_queue_xmit);
./net/core/dev.c: dev_queue_xmit(skb);
./net/core/dev.c: NET_PROFILE_REGISTER(dev_queue_xmit);
./net/core/neighbour.c:/* This function can be used in contexts, where
only old dev_queue_xmit
./net/core/neighbour.c: return dev_queue_xmit(skb);
./net/ipv4/arp.c: dev_queue_xmit,
./net/ipv4/arp.c: dev_queue_xmit
./net/ipv4/arp.c: dev_queue_xmit,
./net/ipv4/arp.c: dev_queue_xmit
./net/ipv4/arp.c: dev_queue_xmit,
./net/ipv4/arp.c: dev_queue_xmit,
./net/ipv4/arp.c: dev_queue_xmit,
./net/ipv4/arp.c: dev_queue_xmit
./net/ipv4/arp.c: dev_queue_xmit,
./net/ipv4/arp.c: dev_queue_xmit,
./net/ipv4/arp.c: dev_queue_xmit(skb);
./net/ipv4/route.c: r->u.dst.hh ?
(r->u.dst.hh->hh_output == dev_queue_xmit) : 0,
./net/ipv4/ipip.c: * This function assumes it is being called from
dev_queue_xmit()
./net/ipv4/ipconfig.c: dev_queue_xmit(skb) < 0)
./net/ipx/af_ipx.c: dev_queue_xmit(skb);
./net/netsyms.c:EXPORT_SYMBOL(dev_queue_xmit);
./net/ipv6/ndisc.c: dev_queue_xmit,
./net/ipv6/ndisc.c: dev_queue_xmit
./net/ipv6/ndisc.c: dev_queue_xmit,
./net/ipv6/ndisc.c: dev_queue_xmit
./net/ipv6/ndisc.c: dev_queue_xmit,
./net/ipv6/ndisc.c: dev_queue_xmit,
./net/ipv6/ndisc.c: dev_queue_xmit,
./net/ipv6/ndisc.c: dev_queue_xmit
./net/ipv6/ndisc.c: dev_queue_xmit(skb);
./net/ipv6/ndisc.c: dev_queue_xmit(skb);
./net/ipv6/ndisc.c: dev_queue_xmit(skb);
./net/ipv6/ndisc.c: dev_queue_xmit(buff);
./net/ipv6/ndisc.c: neigh->flags |
(!neigh->hh ? 0 : (neigh->hh->hh_output==dev_queue_xmit ? 4 : 2)),
./net/ipv6/sit.c: * This function assumes it is being called from
dev_queue_xmit()
./net/ipv6/mcast.c: dev_queue_xmit(skb);
./net/bridge/br.c: dev_queue_xmit(skb);
./net/bridge/br.c: dev_queue_xmit(skb);
./net/bridge/br.c: dev_queue_xmit(skb);
./net/bridge/br.c: dev_queue_xmit(nskb);
./net/econet/econet.c: dev_queue_xmit(skb);
./net/x25/x25_dev.c: dev_queue_xmit(skb);
./net/x25/x25_dev.c: dev_queue_xmit(skb);
./net/x25/x25_dev.c: dev_queue_xmit(skb);
./net/packet/af_packet.c: dev_queue_xmit(skb);
./net/packet/af_packet.c: dev_queue_xmit(skb);
./net/sched/sch_generic.c: dev_queue_xmit_nit(skb,
dev);
./net/sched/sch_generic.c: dev_queue_xmit and a new
device could appear
./net/irda/irlan/irlan_eth.c: * confuse do_dev_queue_xmit()
in dev.c! I have
./net/irda/irlap_frame.c: * A little wrapper for dev_queue_xmit, so
we can insert some common
./net/irda/irlap_frame.c: dev_queue_xmit(skb);
./drivers/net/sk_g16.c: * 1 - Could not transmit
(dev_queue_xmit will queue it)
./drivers/net/eql.c: dev_queue_xmit (skb);
./drivers/net/eql.c: * dev_queue_xmit just queue it up
on the eql's queue.
./drivers/net/hamradio/bpqether.c: dev_queue_xmit(skb);
./drivers/net/shaper.c: dev_queue_xmit(newskb);
./drivers/net/lapbether.c: dev_queue_xmit(skb);
./drivers/net/syncppp.c: dev_queue_xmit(skb);
./drivers/net/syncppp.c: dev_queue_xmit(skb);
./drivers/net/comx-proto-fr.c: dev_queue_xmit(skb);
./drivers/net/comx-proto-fr.c: dev_queue_xmit(newskb);
./drivers/isdn/isdn_net.c: /* This check stolen from 2.1.72
dev_queue_xmit_nit() */
ishikawa@standard$
[end of report]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:14 EST