Bug 124778 - kernel oops in ext3_discard_reservation
Summary: kernel oops in ext3_discard_reservation
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 2
Hardware: i586
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-29 22:16 UTC by Paul Jakma
Modified: 2015-01-04 22:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-29 22:15:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Paul Jakma 2004-05-29 22:16:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040510 Galeon/1.3.14

Description of problem:
I was unpacking a largeish cpio archive (~1.5GB) to an LVM LV located
on a RAID5 PV located on partitions on 3 disks driven by sata_sil,
when it segfaulted. A subsequent ls hung in kernel in start_get_handle
(iirc). As subsequently did various other processes.

The kernel is a self-compiled version of the 2.6.6-1.363 because of
[Bug 123339] (siimage compiled into kernel means sata_sil module cant
be used).

Here's the oops:

Unable to handle kernel paging request at virtual address 00200000
printing eip:
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: ip_conntrack_ftp ip_nat_irc 
ip_conntrack_irc ipt_MASQUERADE iptable_nat ipt_TOS iptable_mangle
ipt_REJECT ipt_LOG ipt_limit ipt_state ip_conntrack iptable_filter
loop sch_ingress cls_u32 sch_sfq sch_htb w83781d i2c_sensor i2c_isa
ppp_synctty ppp_deflate zlib_deflate ppp_async ppp_generic slhc nfsd
exportfs lockd
parport_pc lp parport sunrpc 3c59x ip6table_filter ip6table_mangle
ipv6 floppy sg usblp uhci_hcd sata_sil libata ext3 jbd raid5 xor raid1
ide_disk ide_core DAC960 sd_mod sym53c8xx scsi_transport_spi scsi_mod 
CPU:    0
EIP:    0060:[<d08d4142>]    Not tainted
EFLAGS: 00010206   (2.6.6-1.363.root) 
EIP is at ext3_discard_reservation+0x27/0x34 [ext3]
eax: 00000000   ebx: c98561ac   ecx: c985615c  edx: 00200000
esi: ce8dec00   edi: ffffffe4   ebp: c347cbc8  esp: ccca1e90
ds: 007b   es: 007b   ss: 0068 ask=ce6987b0)
Stack: c98561ac c0154417 c98561ac c0154ea1 c98561ac ffffffe4 c0154f16
       d08d697d ccca1edc c98561ac ccca1f14 00000006 c0182e20 00000080
       cdfbc400 00000246 c1393980 ffffffff 00000000 ce8dec00 00008180
Call Trace:
 [<c0154417>] clear_inode+0x7d/0xa9
 [<c0154ea1>] generic_forget_inode+0xc4/0xd0
 [<c0154f16>] iput+0x59/0x5b
 [<d08d697d>] ext3_new_inode+0x676/0x6bd [ext3]
 [<c0182e20>] may_create+0xce/0xd9
 [<d08dc111>] ext3_create+0x41/0x83 [ext3]
 [<c014c50c>] vfs_create+0xbd/0xf4
 [<c014c87a>] open_namei+0x169/0x3e2
 [<c01411ba>] filp_open+0x24/0x3d
 [<c0141509>] sys_open+0x31/0x7d
 [<c0261de7>] syscall_call+0x7/0xb

Code: 89 02 89 4b b0 89 50 04 89 49 04 5b c3 55 57 56 89 ce 53 83 

The machine is a K6-II (underclocked) with 256MB RAM. The virtual
address it faulted on looks a bit suspicious. Will try running
memtest86 at some stage as soon i get opportunity. Though, the machine
has been very reliable up until now (but it has a new memory module).

As I had 2.6.6-1.397.root installed (same config, but with
8kb-stack-noconfig patch removed and 8kB stack instead of 4kB.) I
booted this when i rebooted the machine. So we shall see.

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

How reproducible:
Didn't try

Additional info:

Comment 1 Paul Jakma 2004-05-31 02:52:16 UTC
I ran memtest86 for about 1.5 hours. It got through 2 full passes of
the memtest86 extended set of tests and ~33% of the way through a 3rd
without any errors.

Comment 2 Dave Jones 2004-10-26 03:43:32 UTC
did this go away with the errata kernel ? A number of
problems in the reservation code were fixed.

Comment 3 Paul Jakma 2004-10-26 03:51:07 UTC
I've not had any reoccurance of this problem. It's running a newer
kernel too now, (and has had hardware replaced with an Athlon 800MHz,
and ECC memory).

[root@hibernia ppp-2.4.2]# uname -r
[root@hibernia ppp-2.4.2]# uptime
 04:51:42 up 35 days, 23:41,  8 users,  load average: 0.08, 0.18, 0.32

So presume fixed!

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