This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 454575 - null pointer dereference BUG in tulip driver
null pointer dereference BUG in tulip driver
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-08 22:45 EDT by Eric Harney
Modified: 2009-07-15 04:25 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-15 04:25:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Harney 2008-07-08 22:45:50 EDT
Description of problem:
I ran "service network restart" and saw this.
Afterward, running "ifconfig" hung in I/O state, had to reboot machine.

Version-Release number of selected component (if applicable):
kernel-2.6.25.9-49

How reproducible:
Has only happened once

Additional info:

BUG: unable to handle kernel NULL pointer dereference at 00000098
IP: [<e08fd3cf>] :tulip:tulip_interrupt+0x2dc/0xb01
*pde = 1b0c1067 *pte = 00000000
Oops: 0000 [#1] SMP
Modules linked in: sit tunnel4 autofs4 fuse sunrpc nf_conntrack_ipv4 ipt_REJECT
iptable_filter ip_tables nf_conntrack_ipv6 xt_state nf_conntrack xt_tcpudp
ip6t_ipv6header ip6t_REJECT ip6table_filter ip6_tables x_tables ipv6 dm_mirror
dm_multipath dm_mod snd_emu10k1_synth snd_emux_synth snd_seq_virmidi
snd_seq_midi_emul snd_emu10k1 parport_pc parport snd_rawmidi ns558
snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
snd_pcm_oss snd_mixer_oss button snd_pcm snd_seq_device snd_timer snd_page_alloc
snd_util_mem snd_hwdep snd i2c_viapro i2c_core joydev soundcore via_ircc irda
serio_raw pcspkr emu10k1_gp via_rhine sr_mod tulip mii cdrom crc_ccitt gameport
sg pata_pdc2027x pata_acpi pata_via ata_generic libata sd_mod scsi_mod ext3 jbd
mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]

Pid: 5173, comm: ip Not tainted (2.6.25.9-40.fc8 #1)
EIP: 0060:[<e08fd3cf>] EFLAGS: 00210006 CPU: 0
EIP is at tulip_interrupt+0x2dc/0xb01 [tulip]
EAX: dedab500 EBX: 00000000 ECX: 000000f4 EDX: dedab500
ESI: 0000004d EDI: 000004d0 EBP: db0cce48 ESP: db0ccdf8
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process ip (pid: 5173, ti=db0cc000 task=db096000 task.ti=db0cc000)
Stack: e08ae028 dedab000 dedab500 e08ae000 fc69c0d0 00000000 00000000 00000000
       00000019 00000001 00f40000 00000000 0000007f dedab500 000000f4 00000220
       c07483d8 00200202 db0421e0 00000012 db0cce68 c045b654 00000080 e08fd0f3
Call Trace:
 [<c045b654>] ? request_irq+0xb5/0xe8
 [<e08fd0f3>] ? tulip_interrupt+0x0/0xb01 [tulip]
 [<e08ff8d4>] ? tulip_open+0x1f/0x1a5 [tulip]
 [<c05bbec9>] ? dev_open+0x42/0x74
 [<c05babfc>] ? dev_change_flags+0x9c/0x14a
 [<c05f6d9b>] ? devinet_ioctl+0x211/0x50a
 [<c05f7406>] ? inet_ioctl+0x8c/0xa8
 [<c05b066b>] ? sock_ioctl+0x1b8/0x1d9
 [<c05b04b3>] ? sock_ioctl+0x0/0x1d9
 [<c048ad92>] ? vfs_ioctl+0x22/0x67
 [<c048b039>] ? do_vfs_ioctl+0x262/0x279
 [<c062c2c7>] ? do_page_fault+0x303/0x5d8
 [<c048b090>] ? sys_ioctl+0x40/0x5c
 [<c0405b7e>] ? syscall_call+0x7/0xb
 =======================
Code: 3b 83 9c 00 00 00 76 0f b9 b1 d3 8f e0 8b 55 e8 89 d8 e8 aa 78 cb df f0 83
04 24 00 e9 8e 00 00 00 8b 45 e4 8b 9c f0 18 01 00 00 <8b> 93 98 00 00 00 89 55
d4 83 7b 54 00 74 04 0f 0b eb fe 0f bf
EIP: [<e08fd3cf>] tulip_interrupt+0x2dc/0xb01 [tulip] SS:ESP 0068:db0ccdf8
---[ end trace 62706e910236238d ]---
Comment 1 Eric Harney 2008-07-08 22:50:34 EDT
Ok, it just happened again when I did another "service network restart".

Also saw this on the screen:

./network-functions: line 313:  6424 Segmentation fault     ip link set dev $1
up > /dev/null 2>&1
Comment 2 Eric Harney 2008-07-09 22:42:57 EDT
Just upgraded to F9 to try to remedy this, and am experiencing the same crash
when running "service network restart".

kernel-2.6.25.9-76.i686

Stack trace is slightly different, but steps to reproduce and symptoms are the same.

This machine has 1 card on tulip driver and 2 cards on via_rhine.


BUG: unable to handle kernel NULL pointer dereference at 000000a4
IP: [<e0942341>] :tulip:tulip_interrupt+0x261/0xaf8
*pde = 18929067 *pte = 00000000 
Oops: 0000 [#1] SMP 
Modules linked in: sit tunnel4 autofs4 fuse sunrpc nf_conntrack_ipv4 ipt_REJECT
iptable_filter ip_tables nf_conntrack_ipv6 xt_state nf_conntrack xt_tcpudp
ip6t_ipv6header ip6t_REJECT ip6table_filter ip6_tables x_tables ipv6 dm_mirror
dm_multipath dm_mod ppdev parport_pc ns558 parport snd_emu10k1_synth
snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_rawmidi
snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
snd_pcm_oss snd_mixer_oss pcspkr snd_pcm snd_seq_device snd_timer serio_raw
i2c_viapro button joydev snd_page_alloc i2c_core snd_util_mem emu10k1_gp
via_ircc snd_hwdep tulip snd gameport irda soundcore crc_ccitt via_rhine mii sg
sr_mod cdrom pata_pdc2027x pata_acpi pata_via ata_generic libata sd_mod scsi_mod
ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]

Pid: 3074, comm: ip Not tainted (2.6.25.9-76.fc9.i686 #1)
EIP: 0060:[<e0942341>] EFLAGS: 00010016 CPU: 0
EIP is at tulip_interrupt+0x261/0xaf8 [tulip]
EAX: 00000000 EBX: df36d840 ECX: 0000000f EDX: decfc500
ESI: 00000065 EDI: df241612 EBP: d8933b38 ESP: d8933adc
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process ip (pid: 3074, ti=d8933000 task=def4c000 task.ti=d8933000)
Stack: 00000000 00000000 e08b6028 decfcbd0 decfc000 decfc500 e08b6000 fc69c0d0 
       00000000 00000000 00000000 00000019 00000000 decfc02c 003c0000 0000007f 
       decfc500 00000080 0000003c 00000650 dfb9adc0 00000202 e09420e0 d8933b58 
Call Trace:
 [<e09420e0>] ? tulip_interrupt+0x0/0xaf8 [tulip]
 [<c045bf60>] ? request_irq+0xb2/0xe6
 [<e09456fe>] ? tulip_open+0x1f/0x18d [tulip]
 [<c05ba345>] ? dev_open+0x46/0x7e
 [<c05b9ece>] ? dev_change_flags+0x9c/0x14f
 [<c05c096b>] ? do_setlink+0x211/0x2c3
 [<c05c1c4e>] ? rtnl_newlink+0x2a0/0x40b
 [<c05c1a14>] ? rtnl_newlink+0x66/0x40b
 [<c05c1a55>] ? rtnl_newlink+0xa7/0x40b
 [<c05c11f3>] ? rtnl_dump_ifinfo+0x4d/0x7b
 [<c05b12b0>] ? sock_def_readable+0x12/0x5c
 [<c05c19ae>] ? rtnl_newlink+0x0/0x40b
 [<c05c1994>] ? rtnetlink_rcv_msg+0x1a0/0x1ba
 [<c05c17f4>] ? rtnetlink_rcv_msg+0x0/0x1ba
 [<c05ce7fa>] ? netlink_rcv_skb+0x30/0x86
 [<c05c17ec>] ? rtnetlink_rcv+0x1c/0x24
 [<c05ce324>] ? netlink_unicast+0x1b1/0x20f
 [<c05ce5d7>] ? netlink_sendmsg+0x255/0x262
 [<c05af450>] ? sock_sendmsg+0xde/0xf9
 [<c0437b27>] ? autoremove_wake_function+0x0/0x33
 [<c0437b27>] ? autoremove_wake_function+0x0/0x33
 [<c041aff9>] ? kunmap_atomic+0x87/0xa7
 [<c04f4dc4>] ? copy_from_user+0x39/0x121
 [<c05b59b9>] ? verify_iovec+0x40/0x6f
 [<c05af5aa>] ? sys_sendmsg+0x13f/0x192
 [<c05afce4>] ? sys_sendto+0xa4/0xc3
 [<c04f4ee7>] ? copy_to_user+0x3b/0x10a
 [<c05afe69>] ? move_addr_to_user+0x56/0x6e
 [<c05b019f>] ? sys_getsockname+0x59/0x76
 [<c04710ea>] ? __vma_link+0x6e/0x73
 [<c047113e>] ? vma_link+0x4f/0xbe
 [<c05b049b>] ? sys_socketcall+0x16b/0x188
 [<c04720c4>] ? sys_brk+0xd8/0xe0
 [<c0405bf2>] ? syscall_call+0x7/0xb
 =======================
Code: 83 80 98 00 00 00 10 83 80 a4 00 00 00 02 83 80 98 00 00 00 02 8b 55 e4 8b
4d ec 8b b8 a4 00 00 00 8b 84 f2 18 01 00 00 c1 e9 02 <8b> b0 a4 00 00 00 f3 a5
8b 4d ec 83 e1 03 74 02 f3 a4 83 7b 54 
EIP: [<e0942341>] tulip_interrupt+0x261/0xaf8 [tulip] SS:ESP 0068:d8933adc
---[ end trace 539d0738023b1a4d ]---
Comment 3 Chuck Ebbert 2008-07-17 13:03:48 EDT
Another race found by CONFIG_DEBUG_SHIRQ
Comment 4 Dave Jones 2008-07-17 14:08:29 EDT
this might be as simple as..

--- linux-2.6.26.noarch/drivers/net/tulip/tulip_core.c~	2008-07-17
14:04:46.000000000 -0400
+++ linux-2.6.26.noarch/drivers/net/tulip/tulip_core.c	2008-07-17
14:07:38.000000000 -0400
@@ -504,11 +504,11 @@ tulip_open(struct net_device *dev)
 {
 	int retval;
 
+	tulip_init_ring(dev);
+
 	if ((retval = request_irq(dev->irq, &tulip_interrupt, IRQF_SHARED, dev->name,
dev)))
 		return retval;
 
-	tulip_init_ring (dev);
-
 	tulip_up (dev);
 
 	netif_start_queue (dev);
Comment 5 Fedora Update System 2008-07-21 09:56:57 EDT
kernel-2.6.25.11-97.fc9 has been submitted as an update for Fedora 9
Comment 6 Fedora Update System 2008-07-23 03:17:20 EDT
kernel-2.6.25.11-97.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-6634
Comment 7 Dave Jones 2008-07-29 00:39:43 EDT
is this fixed in the update mentioned above ?
Comment 8 Dave Jones 2008-08-04 15:46:28 EDT
ping?
Comment 9 Eric Harney 2008-08-20 11:15:38 EDT
Sorry, the tulip card was removed from that machine and installed elsewhere, so I haven't been able to retest.  Not sure if I will be able to any time soon.
Comment 10 Bug Zapper 2009-06-09 21:59:16 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Bug Zapper 2009-07-15 04:25:06 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.