Bug 121697

Summary: (8139too?) iptraf triggers kernel OOPS
Product: [Fedora] Fedora Reporter: ADi <adi>
Component: kernelAssignee: Alexander Viro <aviro>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ecarlseen-redhat-bugzilla, hugo, karsten, mb/redhat, pavlin-public, vj, wtogami, yves.junqueira
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: FC4 and later Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-06 11:57:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A sample program that can be used to trigger the bug
none
oops for iptraf and crash test program none

Description ADi 2004-04-26 09:51:03 UTC 
Hi,

iptraf-2.7.0-9 memory segmentation fault on any statistics
i don't know how to solve this problem

kernel ver and system architecture:
kernel-2.6.5-1.332 on i686 athlon i386 GNU/Linux
Comment 1 ADi 2004-05-07 07:59:27 UTC 
I've noticed that this buq exists when i'm runing squid. Without 
squid iptraf works fine for a long time.

Logs from systems when iptraf hangs:

May  7 09:52:39 zielone kernel:  <1>Unable to handle kernel NULL 
pointer derefer
ence at virtual address 00000000
May  7 09:52:39 zielone kernel:  printing eip:
May  7 09:52:39 zielone kernel: 0223553e
May  7 09:52:39 zielone kernel: *pde = 00000000
May  7 09:52:39 zielone kernel: Oops: 0000 [#2]
May  7 09:52:39 zielone kernel: CPU:    0
May  7 09:52:39 zielone kernel: EIP:    0060:[<0223553e>]    Not 
tainted
May  7 09:52:39 zielone kernel: EFLAGS: 00010202   (2.6.5-1.351)
May  7 09:52:39 zielone kernel: EIP is at 
__dev_get_by_index+0x14/0x2b
May  7 09:52:39 zielone kernel: eax: 105a4534   ebx: 06386ef4   ecx: 
0000000b
edx: 00000000
May  7 09:52:39 zielone kernel: esi: feeff610   edi: 00008910   ebp: 
feeff610
esp: 06386eec
May  7 09:52:39 zielone kernel: ds: 007b   es: 007b   ss: 0068
May  7 09:52:39 zielone kernel: Process iptraf (pid: 23885, 
threadinfo=06386000
May  7 09:52:39 zielone kernel: Stack: 022365d3 00000000 31687465 
008b71cc feeff
May  7 09:52:39 zielone kernel:        00200320 008a3f74 00008910 
feeff610 00008
May  7 09:52:39 zielone kernel:        0000002b 00000004 0213f1ba 
030d7600 05dcf
May  7 09:52:39 zielone kernel: Call Trace:
May  7 09:52:39 zielone kernel:  [<022365d3>] dev_ifname+0x30/0x66
May  7 09:52:39 zielone kernel:  [<02236e5c>] dev_ioctl+0x83/0x283
May  7 09:52:39 zielone kernel:  [<0213f1ba>] rw_vm+0x1ce/0x1ea
May  7 09:52:39 zielone kernel:  [<0227e129>] packet_ioctl+0xe1/0xeb
May  7 09:52:39 zielone kernel:  [<022301c9>] sock_ioctl+0x268/0x280
May  7 09:52:39 zielone kernel:  [<02231200>] 
sys_socketcall+0x118/0x179
May  7 09:52:39 zielone kernel:  [<0214ea0e>] sys_ioctl+0x1f2/0x224
May  7 09:52:39 zielone kernel:
May  7 09:52:39 zielone kernel: Code: 0f 18 02 90 2d 34 01 00 00 39 
48 34 74 08
Comment 2 Karsten Hopp 2004-05-07 09:29:25 UTC 
can you try to reproduce this with the latest FC2T3 kernel, please ?
Comment 3 Karsten Hopp 2004-05-07 11:03:21 UTC 
ok, the kernel oops is from the latest kernel...  
reassigning to a kernel developer
Comment 5 ADi 2004-05-10 07:25:31 UTC 
The kernel-2.6.5-1.353 give the same error:

May 10 09:22:50 zielone kernel:  <1>Unable to handle kernel NULL 
pointer dereference at virtual address 00000000
May 10 09:22:50 zielone kernel:  printing eip:
May 10 09:22:50 zielone kernel: 02235552
May 10 09:22:50 zielone kernel: *pde = 00000000
May 10 09:22:50 zielone kernel: Oops: 0000 [#2]
May 10 09:22:50 zielone kernel: CPU:    0
May 10 09:22:50 zielone kernel: EIP:    0060:[<02235552>]    Not 
tainted
May 10 09:22:50 zielone kernel: EFLAGS: 00010202   (2.6.5-1.353)
May 10 09:22:50 zielone kernel: EIP is at 
__dev_get_by_index+0x14/0x2b
May 10 09:22:50 zielone kernel: eax: 033e2534   ebx: 09e4cef4   ecx: 
0000000b   edx: 00000000
May 10 09:22:50 zielone kernel: esi: fee7f380   edi: 00008910   ebp: 
fee7f380   esp: 09e4ceec
May 10 09:22:50 zielone kernel: ds: 007b   es: 007b   ss: 0068
May 10 09:22:50 zielone kernel: Process iptraf (pid: 5343, 
threadinfo=09e4c000 task=09ce97b0)
May 10 09:22:50 zielone kernel: Stack: 022365e7 00000000 09d09b48 
00000020 009f07c8 009f0780 0000000b 009f0780
May 10 09:22:50 zielone kernel:        009f0780 00000018 00008910 
fee7f380 00008910 fee7f380 02236e70 fee7f380
May 10 09:22:50 zielone kernel:        00000032 00000004 0213f1ba 
031f5c20 11120fec 000009fc 0f9d5080 031f5c20
May 10 09:22:50 zielone kernel: Call Trace:
May 10 09:22:50 zielone kernel:  [<022365e7>] dev_ifname+0x30/0x66
May 10 09:22:50 zielone kernel:  [<02236e70>] dev_ioctl+0x83/0x283
May 10 09:22:50 zielone kernel:  [<0213f1ba>] rw_vm+0x1ce/0x1ea
May 10 09:22:50 zielone kernel:  [<0227e16d>] packet_ioctl+0xe1/0xeb
May 10 09:22:50 zielone kernel:  [<022301c5>] sock_ioctl+0x268/0x280
May 10 09:22:50 zielone kernel:  [<02231214>] 
sys_socketcall+0x118/0x179
May 10 09:22:50 zielone kernel:  [<0214ea0e>] sys_ioctl+0x1f2/0x224
May 10 09:22:50 zielone kernel:
May 10 09:22:50 zielone kernel: Code: 0f 18 02 90 2d 34 01 00 00 39 
48 34 74 08 85 d2 89 d0 75 ea
Comment 6 Warren Togami 2004-05-10 07:44:25 UTC 
Works for me on my IBM Thinkpad T41 with i686 kernel-2.6.5-1.353 and
e1000 network driver.  Which what network card and driver are you
running?  How much RAM do you have?
Comment 7 ADi 2004-05-11 06:27:54 UTC 
I'm using realtek network card with 8139too modules. I'm using 256MB 
RAM. Maybe I must choose a different modules for this network??
Comment 8 Warren Togami 2004-05-11 06:35:11 UTC 
I have not tried 8139too for a while, and it is possible that an
individual network driver can cause this kind of problem.  You can
help the kernel developers in fixing this problem if you can isolate
it definitively.  Try using a completely different network card that
uses a different driver, and the same test with iptraf.

Also please attach the following information to this report.  Do the
bottom one twice, once before the oops, and once after.
lspci -n
lspci -vvv
Comment 10 ADi 2004-05-19 08:51:04 UTC 
Outputs of this two commannd are the same before and after the oops.
In my system presents four realtek card connected to pci interface 
and one network card basicaly distrubuted with motherboard. It's 
working as router/bridge on my network. I don't want to change my 
interfaces but if this bug will still exists I will not any different 
way:

lspci -n gives:
00:00.0 Class 0600: 1106:3189 (rev 80)
00:01.0 Class 0604: 1106:b198
00:0a.0 Class 0200: 10ec:8139 (rev 10)
00:0b.0 Class 0200: 10ec:8139 (rev 10)
00:0c.0 Class 0200: 10ec:8139 (rev 10)
00:0d.0 Class 0200: 10ec:8139 (rev 10)
00:0f.0 Class 0104: 1106:3149 (rev 80)
00:0f.1 Class 0101: 1106:0571 (rev 06)
00:10.0 Class 0c03: 1106:3038 (rev 81)
00:10.1 Class 0c03: 1106:3038 (rev 81)
00:10.2 Class 0c03: 1106:3038 (rev 81)
00:10.3 Class 0c03: 1106:3038 (rev 81)
00:10.4 Class 0c03: 1106:3104 (rev 86)
00:11.0 Class 0601: 1106:3227
00:11.5 Class 0401: 1106:3059 (rev 60)
00:13.0 Class 0200: 10ec:8139 (rev 10)
00:14.0 Class 0c00: 1106:3044 (rev 46)
01:00.0 Class 0300: 5333:8a22 (rev 02)

lspci -vvv gives:
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] 
Host Bridge (rev 80)
        Subsystem: Giga-byte Technology GA-7VAX Mainboard
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 8
        Region 0: Memory at d0000000 (32-bit, prefetchable)
        Capabilities: [80] AGP version 3.5
                Status: RQ=32 Iso- ArqSz=0 Cal=2 SBA+ ITACoh- GART64- 
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- 
FW- Rate=<none>
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,
D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 
00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: e0000000-e1ffffff
        Prefetchable memory behind bridge: d8000000-dfffffff
        BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,
D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (8000ns min, 16000ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at a000
        Region 1: Memory at e3000000 (32-bit, non-prefetchable) 
[size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (8000ns min, 16000ns max)
        Interrupt: pin A routed to IRQ 5
        Region 0: I/O ports at a400
        Region 1: Memory at e3001000 (32-bit, non-prefetchable) 
[size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (8000ns min, 16000ns max)
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at a800
        Region 1: Memory at e3002000 (32-bit, non-prefetchable) 
[size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RT8139
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (8000ns min, 16000ns max)
        Interrupt: pin A routed to IRQ 6
        Region 0: I/O ports at ac00
        Region 1: Memory at e3003000 (32-bit, non-prefetchable) 
[size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA 
RAID Controller (rev 80)
        Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID 
Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Interrupt: pin B routed to IRQ 11
        Region 0: I/O ports at b000
        Region 1: I/O ports at b400 [size=4]
        Region 2: I/O ports at b800 [size=8]
        Region 3: I/O ports at bc00 [size=4]
        Region 4: I/O ports at c000 [size=16]
        Region 5: I/O ports at c400 [size=256]
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,
D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0f.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 
(prog-if 8a [M
aster SecP PriP])
        Subsystem: Giga-byte Technology GA-7VAX Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Interrupt: pin A routed to IRQ 6
        Region 4: I/O ports at c800 [size=16]
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,
D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 81) (prog-if 00 [UHCI])
        Subsystem: Giga-byte Technology GA-7VAX Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32, Cache Line Size 08
        Interrupt: pin A routed to IRQ 10
        Region 4: I/O ports at cc00 [size=32]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 81) (prog-if 00 [UHCI])
        Subsystem: Giga-byte Technology GA-7VAX Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32, Cache Line Size 08
        Interrupt: pin A routed to IRQ 10
        Region 4: I/O ports at d000 [size=32]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 81) (prog-if 00 [UHCI])
        Subsystem: Giga-byte Technology GA-7VAX Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32, Cache Line Size 08
        Interrupt: pin B routed to IRQ 6
        Region 4: I/O ports at d400 [size=32]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 
Controller (rev 81) (prog-if 00 [UHCI])
        Subsystem: Giga-byte Technology GA-7VAX Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32, Cache Line Size 08
        Interrupt: pin B routed to IRQ 6
        Region 4: I/O ports at d800 [size=32]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) 
(prog-if 20 [EHCI])
        Subsystem: Giga-byte Technology GA-7VAX Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32, Cache Line Size 10
        Interrupt: pin C routed to IRQ 11
        Region 0: Memory at e3004000 (32-bit, non-prefetchable)
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 
South]
        Subsystem: Giga-byte Technology: Unknown device 5001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping+ SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,
D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.5 Multimedia audio controller: VIA Technologies, Inc. 
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
        Subsystem: Giga-byte Technology GA-7VAX Onboard Audio 
(Realtek ALC650)
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin C routed to IRQ 11
        Region 0: I/O ports at dc00
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,
D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
        Subsystem: Giga-byte Technology GA-7VM400M Motherboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (8000ns min, 16000ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at e000
        Region 1: Memory at e3005000 (32-bit, non-prefetchable) 
[size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,
D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:14.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host 
Controller (rev 46) (prog-if 10 [OHCI])
        Subsystem: Giga-byte Technology: Unknown device 1000
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (8000ns max), Cache Line Size 08
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at e3006000 (32-bit, non-prefetchable)
        Region 1: I/O ports at e400 [size=128]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA PME(D0-,
D1-,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: S3 Inc. Savage 4 (rev 02) (prog-if 
00 [VGA])
        Subsystem: S3 Inc. 86C394-397 Savage4
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 248 (1000ns min, 63750ns max), Cache Line Size 08
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at e1000000 (32-bit, non-prefetchable)
        Region 1: Memory at d8000000 (32-bit, prefetchable) 
[size=128M]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,
D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [80] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- 
HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- 
FW- Rate=<none>
Comment 11 Need Real Name 2004-06-22 15:44:06 UTC 
I see this problem with 3c59x and e100, even on kernel-2.6.6-1.435.
Our machines are Athlons; don't know if this is relevant.
Comment 12 ADi 2004-06-22 23:22:37 UTC 
On my new P4HT 2,8GHz on ASUS P4P800 mainboard and Intel Corp. 
82557/8/9 [Ethernet Pro 100] eth1 and Realtek Semiconductor Co., Ltd. 
RTL-8169 Gigabit Ethernet this bug no longer exist (on this computer 
I installed directly FC2). Maybe its problem with upgrading installed 
test FC1.91 version to FC2 by yum repositories. Maybe its something 
wrong and upgrading packets haven't these same functionality. I'll 
try to install FC2 directly on the other system where the bug still 
exist and I sent an answer to this topic.
Comment 13 Pavlin Radoslavov 2004-07-09 00:58:02 UTC 
I have seen a very similar kernel Oops (RedHat FC2, kernel
2.6.5-1.358) but it was triggered with a different program. After some
 debugging, I managed to isolate the problem to the following system
call (which is called by if_indextoname(3)):

ioctl(s, SIOCGIFNAME, &ifr)

The problem can be triggered by a simple program that just calls
twice the above ioctl() and then pauses (the program itself is attached).

Several observations:

 * The sample program has to be run through strace to trigger the
kernel oops (but the original program didn't require strace):

  strace -f -v ./a.out

  When the problem is triggered, I can see the following strace
  messages:

socket(PF_FILE, SOCK_DGRAM, 0)          = 3
ioctl(3, SIOCGIFNAME, 0xfef3f8e0)       = 0
ioctl(3, SIOCGIFNAME <unfinished ...>
+++ killed by SIGSEGV +++

  If the problem was not triggered, then there was no
  "killed by SIGSEGV" message.

 * On average, I had to run the above command approximately 5-10 times
   before the problem is triggered.

 * The binary program itself had to contain two ioctl() calls,
   otherwise I coudn't trigger the problem.

The Oops message is:
 <1>Unable to handle kernel NULL pointer dereference at virtual
address 00000000
 printing eip:
02235532
*pde = 00000000
Oops: 0000 [#102]
CPU:    0
EIP:    0060:[<02235532>]    Not tainted
EFLAGS: 00010202   (2.6.5-1.358) 
EIP is at __dev_get_by_index+0x14/0x2b
eax: 20907134   ebx: 06ee7ef8   ecx: 00000002   edx: 00000000
esi: 00000000   edi: 00008910   ebp: fef3f8e0   esp: 06ee7ef0
ds: 007b   es: 007b   ss: 0068
Process a.out (pid: 6243, threadinfo=06ee7000 task=10bb6230)
Stack: 022365c7 00000000 00000000 00000000 00000000 00000000 00000002
00000000 
       00000000 00000000 00008910 00000000 00008910 fef3f8e0 02236e50
fef3f8e0 
       00040004 00001863 00004343 00000005 00000000 00000004 022cfa00
00000001 
Call Trace:
 [<022365c7>] dev_ifname+0x30/0x66
 [<02236e50>] dev_ioctl+0x83/0x283
 [<0227c090>] unix_ioctl+0x72/0x7b
 [<022301a5>] sock_ioctl+0x268/0x280
 [<0214ea0e>] sys_ioctl+0x1f2/0x224

Code: 0f 18 02 90 2d 34 01 00 00 39 48 34 74 08 85 d2 89 d0 75 ea 

Additional info. The sample program tries to get the interface
names for ifindex 1 and 2, which in my case are interfaces "lo"
and "sit0":

root@uakari[7] ifconfig -a
eth0      
...

eth1

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8611643 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8611643 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:996791545 (950.6 Mb)  TX bytes:996791545 (950.6 Mb)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Comment 14 Pavlin Radoslavov 2004-07-09 01:01:03 UTC 
Created attachment 101737 [details]
A sample program that can be used to trigger the bug

This is the sample program that can be used to trigger the bug
(see Comment #13 for additional info).
Comment 15 David Miller 2004-07-09 20:13:17 UTC 
Looks more like strace (thus ptrace in the kernel, there have
been some ptrace corruption discussions recently on the lists
wrt. 2.6.x kernels) corrupting the user arguments in the
second call than an actual networking bug.

Please get a testcase that actually triggers without being
run under strace so we can remove that variable from the
analysis.
Comment 16 Yves Junqueira 2004-07-27 18:54:49 UTC 
Created attachment 102234 [details]
oops for iptraf and crash test program

kernel logs
Comment 17 Yves Junqueira 2004-07-27 18:59:24 UTC 
See comment #16. I get oops running iptraf and the program provided 
by Pavlin Radoslavov. It didn't require strace to trigger the oop.

FC2
kernel 2.6.6-1.435.2.3
# lspci -v |grep Ether
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-
8139/8139C/8139C+ (rev 10)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] 
(rev 74)
Comment 18 Karsten Hopp 2004-08-09 10:07:16 UTC 
*** Bug 129374 has been marked as a duplicate of this bug. ***
Comment 19 Erik Carlseen 2004-08-09 15:52:56 UTC 
Per Karsten Hopp, I'm posting comments re: bug 129374 to this bug now...


Karsten,
Actually, as far as I can tell I am running the latest kernel (cat
/proc/version returns: Linux version 2.6.7-1.494.2.2
(bhcompile.redhat.com) (gcc version 3.3.3 20040412 (Red
Hat Linux 3.3.3-7)) #1 Tue Aug 3 09:39:58 EDT 2004 which matches the
latest production version on the download site).

The problem still exists in this version.

Here is some info on my NICs:

#lspci -v |grep Ether
00:08.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 08)
        Subsystem: Intel Corp. EtherExpress PRO/100+ Server Adapter
(PILA8470B)
00:09.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 0c)
        Subsystem: Intel Corp. EtherExpress PRO/100 S Server Adapter
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II]
(rev 74)
        Subsystem: VIA Technologies, Inc. VT6102 [Rhine II] Embeded
Ethernet Controller on VT8235
Comment 20 Erik Carlseen 2004-08-09 16:00:56 UTC 
More info:

In one of my posts re: bug 129374 I noted that I had not observed the
Segfault when gathering statistics with iptraf on my boxes. I ran
iptraf in this mode overnight and did generate segfaults; it just took
a very long time on my machines.

Here is some NIC info from another machine:

# lspci -v |grep Ether
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
02:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 0d) Subsystem: Intel Corp. EtherExpress PRO/100 S Dual Port
Server Adapter
02:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 0d) Subsystem: Intel Corp. EtherExpress PRO/100 S Dual Port
Server Adapter
Comment 21 Hugo Cisneiros 2004-08-11 19:19:30 UTC 
I'm dealing with this problem since I began using Fedora Core 2. I
have many machines that is running Fedora Core 2 and doing this
problem. Maybe I can help telling my experience here.

I always used iptraf for traffic monitoring here, with 15 servers. I
used Red Hat 9 and later Fedora Core 1, and later Fedora Core 2. My
Red Hat 9 and Fedora Core 1 machines does not do this problem, only
the Fedora Core 2. But I have Fedora Core 2 running on two servers and
iptraf is working very well. But all the others generate this error.

The only diference I see is that the servers causing this problem have
two network cards. My two servers that are perfect only have one. Is
this relevant? In home I have FC2 running with one network card
connected to a ADSL modem and iptraf is working well too.

And ALL servers are using iptables to give me some protection as firewall.

The kernel oops here is the same posted in the comments here. I also
tried to compile iptraf from source and it didn't work. I like iptraf
very much, I hope this bug can be resolved soon :(

If you need more information (details) or so, just ask and I'll be
glad to help!
Comment 22 VJ 2004-08-13 15:39:31 UTC 
IPTraf crashes after 5-10 seconds of monitoring here too. Sometimes 
disabling name lookup helps, but not for long. here is the log 
in /var/log/messages file:

Aug 12 09:21:04 hostname kernel: Unable to handle kernel NULL pointer 
dereference at virtual address 00000000
Aug 12 09:21:04 hostname kernel:  printing eip:
Aug 12 09:21:04 hostname kernel: 0229dabe
Aug 12 09:21:04 hostname kernel: *pde = 00000000
Aug 12 09:21:04 hostname kernel: Oops: 0000 [#1]
Aug 12 09:21:04 hostname kernel: Modules linked in: snd_pcm_oss 
snd_mixer_oss snd_ens1371 snd_rawmidi snd_seq_device snd_pcm snd_pag
e_alloc snd_timer snd_ac97_codec gameport snd soundcore ipt_state 
ipt_MASQUERADE iptable_nat ip_conntrack iptable_filter ip_tables nfsd 
exportfs l
ockd ipv6 parport_pc lp parport autofs4 sunrpc e100 mii sg scsi_mod 
ext3 jbd loop vfat fat dm_mod button battery asus_acpi ac reiserfs
Aug 12 09:21:04 hostname kernel: CPU:    0
Aug 12 09:21:04 hostname kernel: EIP:    0060:[<0229dabe>]    Not 
tainted
Aug 12 09:21:04 hostname kernel: EFLAGS: 00010202   (2.6.7-1.494.2.2)
Aug 12 09:21:04 hostname kernel: EIP is at 
__dev_get_by_index+0x14/0x2b
Aug 12 09:21:04 hostname kernel: eax: 0b159194   ebx: 10ddbef0   ecx: 
00000005   edx: 00000000
Aug 12 09:21:04 hostname kernel: esi: 00008910   edi: 00008910   ebp: 
fef9c830   esp: 10ddbee8
Aug 12 09:21:04 hostname kernel: ds: 007b   es: 007b   ss: 0068
Aug 12 09:21:04 hostname kernel: Process iptraf (pid: 2830, 
threadinfo=10ddb000 task=103520f0)
Aug 12 09:21:04 hostname kernel: Stack: 0229f2a8 00000000 30687465 
041ab19c fef9c868 0418a6a4 00000005 00000c00
Aug 12 09:21:04 hostname kernel:        00000c20 04197dc4 11fd7400 
00008910 00008910 fef9c830 0229fb61 fef9c830
Aug 12 09:21:04 hostname kernel:        10ddbf44 0f61bfec 00000e70 
0684c0e0 031c3be0 0214e5a6 10ddbf70 00000018
Aug 12 09:21:04 hostname kernel: Call Trace:
Aug 12 09:21:04 hostname kernel:  [<0229f2a8>] dev_ifname+0x30/0x66
Aug 12 09:21:04 hostname kernel:  [<0229fb61>] dev_ioctl+0x8a/0x28a
Aug 12 09:21:04 hostname kernel:  [<0214e5a6>] 
follow_page_pfn+0xec/0xfd
Aug 12 09:21:04 hostname kernel:  [<022f4056>] 
packet_ioctl+0x20c/0x217
Aug 12 09:21:04 hostname kernel:  [<02296a77>] sock_ioctl+0x2f4/0x3aa
Aug 12 09:21:04 hostname kernel:  [<02297bca>] 
sys_socketcall+0x118/0x179
Aug 12 09:21:04 hostname kernel:  [<0217546e>] sys_ioctl+0x29a/0x33c
Aug 12 09:21:04 hostname kernel: Code: 0f 18 02 90 2d 94 01 00 00 39 
48 34 74 08 85 d2 89 d0 75 ea
Comment 23 Karsten Hopp 2005-09-06 11:57:51 UTC 
I haven't seen this problem anymore for quite some time now, I assume this has
been fixed with the more recent kernel version.