linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Charles P. Wright" <cpwright@cpwright.com>
To: linux-fsdevel@vger.kernel.org
Subject: Oops when Deleting Large File
Date: Tue, 21 Jan 2003 12:19:08 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0301211215110.26132-100000@cpwright.com> (raw)

When testing a new disk array I created a large (1.4TB) file that filled
up the entire file system (dd ended with ENOSPC).  After removing it I got
an Oops, the machine was totally locked, but I reproduced it over a serial
line.  Attached is the original Oops and the Oops run through ksymoops
after a reboot.

This is using a RedHat stock kernel 2.4.18-19.8.0smp on 8.0.  The file 
system is ext3, and has a total of 1372158232 1k blocks.

Has anyone else seen this behavior?

Charles

[root@story data]# rm BIGFILE 
rm: remove regular file `BIGFILE'? y
Assertion failure in do_get_write_access() at transaction.c:715: "handle->h_buffer_credits > 0"
------------[ cut here ]------------
kernel BUG at transaction.c:715!
invalid operand: 0000
binfmt_misc autofs sk98lin eepro100 iptable_filter ip_tables microcode mousedev keybdev hid input usb-ohci usbcore ext3 jbd 3w-xxxx sd_mod scsi_mod  
CPU:    1
EIP:    0010:[<f8851e2c>]    Not tainted
EFLAGS: 00010282

EIP is at do_get_write_access [jbd] 0x48c (2.4.18-19.8.0smp)
eax: 00000063   ebx: f5f80da0   ecx: c03b25f4   edx: f5dcfc9c
esi: f5de2c60   edi: f6be9a00   ebp: f7966440   esp: f5dcfcfc
ds: 0018   es: 0018   ss: 0018
Process rm (pid: 893, stackpage=f5dcf000)
Stack: f885a1c0 f8859b4e f8859ab0 000002cb f8859b7a 00000000 00000000 00000000 
       f5f80da0 00000259 00008000 f6b0a370 f88522c5 f5f80da0 f6b0a370 00000001 
       00000000 00000000 f6be9a94 f6be9a00 00000000 00000259 00008000 f6bce000 
Call Trace: [<f885a1c0>] .rodata.str1.32 [jbd] 0x0 (0xf5dcfcfc))
[<f8859b4e>] .rodata.str1.1 [jbd] 0xae (0xf5dcfd00))
[<f8859ab0>] .rodata.str1.1 [jbd] 0x10 (0xf5dcfd04))
[<f8859b7a>] .rodata.str1.1 [jbd] 0xda (0xf5dcfd0c))
[<f88522c5>] journal_get_undo_access_Rsmp_10be8bf9 [jbd] 0x55 (0xf5dcfd2c))
[<f886067a>] ext3_free_blocks [ext3] 0x2fa (0xf5dcfd5c))
[<f88671c7>] ext3_do_update_inode [ext3] 0x177 (0xf5dcfd6c))
[<f8857b08>] log_start_commit_Rsmp_9edff2e4 [jbd] 0x98 (0xf5dcfdd4))
[<f885124a>] start_this_handle [jbd] 0xaa (0xf5dcfde0))
[<f88661ea>] ext3_clear_blocks [ext3] 0xca (0xf5dcfe0c))
[<f8866397>] ext3_free_data [ext3] 0xa7 (0xf5dcfe54))
[<f8863c04>] start_transaction [ext3] 0x94 (0xf5dcfe94))
[<f8866bc8>] ext3_truncate [ext3] 0x478 (0xf5dcfeac))
[<f885124a>] start_this_handle [jbd] 0xaa (0xf5dcfec8))
[<f8851445>] journal_start_Rsmp_cbe620c6 [jbd] 0xa5 (0xf5dcfef4))
[<f8863c04>] start_transaction [ext3] 0x94 (0xf5dcff18))
[<f8863dd9>] ext3_delete_inode [ext3] 0x159 (0xf5dcff30))
[<f8869eb0>] ext3_unlink [ext3] 0x150 (0xf5dcff38))
[<f8863c80>] ext3_delete_inode [ext3] 0x0 (0xf5dcff44))
[<c0163be9>] iput [kernel] 0x149 (0xf5dcff4c))
[<c0158e35>] vfs_unlink [kernel] 0x185 (0xf5dcff68))
[<c01590a9>] sys_unlink [kernel] 0x119 (0xf5dcff84))
[<c010944f>] system_call [kernel] 0x33 (0xf5dcffc0))


Code: 0f 0b cb 02 b0 9a 85 f8 8b 4c 24 34 8b 41 04 e9 4c ff ff ff 
 Segmentation fault

ksymoops 2.4.5 on i686 2.4.18-19.8.0smp.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.18-19.8.0smp/ (default)
     -m /boot/System.map-2.4.18-19.8.0smp (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.

Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
Error (expand_objects): cannot stat(/lib/3w-xxxx.o) for 3w-xxxx
Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod
Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod
Warning (map_ksym_to_module): cannot match loaded module ext3 to a unique module object.  Trace may not be reliable.
kernel BUG at transaction.c:715!
invalid operand: 0000
CPU:    1
EIP:    0010:[<f8851e2c>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000063   ebx: f5f80da0   ecx: c03b25f4   edx: f5dcfc9c
esi: f5de2c60   edi: f6be9a00   ebp: f7966440   esp: f5dcfcfc
ds: 0018   es: 0018   ss: 0018
Process rm (pid: 893, stackpage=f5dcf000)
Stack: f885a1c0 f8859b4e f8859ab0 000002cb f8859b7a 00000000 00000000 00000000 
       f5f80da0 00000259 00008000 f6b0a370 f88522c5 f5f80da0 f6b0a370 00000001 
       00000000 00000000 f6be9a94 f6be9a00 00000000 00000259 00008000 f6bce000 
Call Trace: [<f885a1c0>] .rodata.str1.32 [jbd] 0x0 (0xf5dcfcfc))
[<f8859b4e>] .rodata.str1.1 [jbd] 0xae (0xf5dcfd00))
[<f8859ab0>] .rodata.str1.1 [jbd] 0x10 (0xf5dcfd04))
[<f8859b7a>] .rodata.str1.1 [jbd] 0xda (0xf5dcfd0c))
[<f88522c5>] journal_get_undo_access_Rsmp_10be8bf9 [jbd] 0x55 (0xf5dcfd2c))
[<f886067a>] ext3_free_blocks [ext3] 0x2fa (0xf5dcfd5c))
[<f88671c7>] ext3_do_update_inode [ext3] 0x177 (0xf5dcfd6c))
[<f8857b08>] log_start_commit_Rsmp_9edff2e4 [jbd] 0x98 (0xf5dcfdd4))
[<f885124a>] start_this_handle [jbd] 0xaa (0xf5dcfde0))
[<f88661ea>] ext3_clear_blocks [ext3] 0xca (0xf5dcfe0c))
[<f8866397>] ext3_free_data [ext3] 0xa7 (0xf5dcfe54))
[<f8863c04>] start_transaction [ext3] 0x94 (0xf5dcfe94))
[<f8866bc8>] ext3_truncate [ext3] 0x478 (0xf5dcfeac))
[<f885124a>] start_this_handle [jbd] 0xaa (0xf5dcfec8))
[<f8851445>] journal_start_Rsmp_cbe620c6 [jbd] 0xa5 (0xf5dcfef4))
[<f8863c04>] start_transaction [ext3] 0x94 (0xf5dcff18))
[<f8863dd9>] ext3_delete_inode [ext3] 0x159 (0xf5dcff30))
[<f8869eb0>] ext3_unlink [ext3] 0x150 (0xf5dcff38))
[<f8863c80>] ext3_delete_inode [ext3] 0x0 (0xf5dcff44))
[<c0163be9>] iput [kernel] 0x149 (0xf5dcff4c))
[<c0158e35>] vfs_unlink [kernel] 0x185 (0xf5dcff68))
[<c01590a9>] sys_unlink [kernel] 0x119 (0xf5dcff84))
[<c010944f>] system_call [kernel] 0x33 (0xf5dcffc0))
Code: 0f 0b cb 02 b0 9a 85 f8 8b 4c 24 34 8b 41 04 e9 4c ff ff ff 


>>EIP; f8851e2c <[jbd]do_get_write_access+48c/610>   <=====

>>ebx; f5f80da0 <_end+35b35f60/383db220>
>>ecx; c03b25f4 <runqueues+d74/13400>
>>edx; f5dcfc9c <_end+35984e5c/383db220>
>>esi; f5de2c60 <_end+35997e20/383db220>
>>edi; f6be9a00 <_end+3679ebc0/383db220>
>>ebp; f7966440 <_end+3751b600/383db220>
>>esp; f5dcfcfc <_end+35984ebc/383db220>

Trace; f885a1c0 <[jbd]__kstrtab_journal_force_commit+198/4d60>
Trace; f8859b4e <[jbd]__kstrtab_journal_get_create_access+26/40>
Trace; f8859ab0 <[jbd]__ksymtab_journal_ack_err+0/8>
Trace; f8859b7a <[jbd]__kstrtab_journal_get_undo_access+12/40>
Trace; f88522c5 <[jbd]journal_get_undo_access+55/140>
Trace; f886067a <[ext3].text.start+61a/d4bd>
Trace; f88671c7 <[ext3].text.start+7167/d4bd>
Trace; f8857b08 <[jbd]log_start_commit+98/c0>
Trace; f885124a <[jbd]start_this_handle+aa/190>
Trace; f88661ea <[ext3].text.start+618a/d4bd>
Trace; f8866397 <[ext3].text.start+6337/d4bd>
Trace; f8863c04 <[ext3].text.start+3ba4/d4bd>
Trace; f8866bc8 <[ext3].text.start+6b68/d4bd>
Trace; f885124a <[jbd]start_this_handle+aa/190>
Trace; f8851445 <[jbd]journal_start+a5/c0>
Trace; f8863c04 <[ext3].text.start+3ba4/d4bd>
Trace; f8863dd9 <[ext3].text.start+3d79/d4bd>
Trace; f8869eb0 <[ext3].text.start+9e50/d4bd>
Trace; f8863c80 <[ext3].text.start+3c20/d4bd>
Trace; c0163be9 <iput+149/2c0>
Trace; c0158e35 <vfs_unlink+185/2e0>
Trace; c01590a9 <sys_unlink+119/120>
Trace; c010944f <system_call+33/38>

Code;  f8851e2c <[jbd]do_get_write_access+48c/610>
00000000 <_EIP>:
Code;  f8851e2c <[jbd]do_get_write_access+48c/610>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  f8851e2e <[jbd]do_get_write_access+48e/610>
   2:   cb                        lret   
Code;  f8851e2f <[jbd]do_get_write_access+48f/610>
   3:   02 b0 9a 85 f8 8b         add    0x8bf8859a(%eax),%dh
Code;  f8851e35 <[jbd]do_get_write_access+495/610>
   9:   4c                        dec    %esp
Code;  f8851e36 <[jbd]do_get_write_access+496/610>
   a:   24 34                     and    $0x34,%al
Code;  f8851e38 <[jbd]do_get_write_access+498/610>
   c:   8b 41 04                  mov    0x4(%ecx),%eax
Code;  f8851e3b <[jbd]do_get_write_access+49b/610>
   f:   e9 4c ff ff ff            jmp    ffffff60 <_EIP+0xffffff60>


2 warnings and 5 errors issued.  Results may not be reliable.


             reply	other threads:[~2003-01-21 17:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-21 17:19 Charles P. Wright [this message]
2003-01-21 20:21 ` Oops when Deleting Large File Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0301211215110.26132-100000@cpwright.com \
    --to=cpwright@cpwright.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).