similar to: Assertion failure in 2.2.20

Hi, I found the following in the logs of a server that crashed: Mar 19 14:09:28 sc4 kernel: Assertion failure in ext3_free_blocks() at balloc.c line 358: "bh->b_committed_data != NULL" Mar 19 14:09:28 sc4 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Mar 19 14:09:28 sc4 kernel: current->tss.cr3 = 39b8b000, %%cr3 = 39b8b000 Mar 19 14:09:28

A mysql database file was copied over to a new box running Fedora Core 1. The kernel was updated to the latest Fedora release. However mysqld complains about corrupted tables. The kernel was then updated to 2.6.5 mysqld still complains about corrupted tables. Hardware: Dual PIII 800. 3ware RAID dmesg: ... ... ... EXT3-fs error (device sdb1): ext3_free_blocks: Freeing blocks not in

[Re-sending to the ext3 list, with minor edits] I'm in the process of fixing errors generated by the Coverity tool on the Linux kernel, and I would like your comment on a set of problems reported in ext3. The main issue reported is not checking the return code of ext3_journal_get_write_access() in various places. I would like to know if there should be error handling in these cases. The

All, I know that there is no official port to Kernel 2.4.4, thus I may not get any help, however I am hoping someone could point me in the right direction for my problem. I am currently forced to use kernel 2.4.4 for reasons out of my control (embedded board). Here are the exact versions of everything I'm running: ExT3 Version: ext3-2.4-0.9.6-248 Util Version: util-linux-2.11f.tar.bz2 e2fs

[sorry if this isn't threaded right... I just subscribed] Theodore Ts'o wrote: > > There are two reasons for the reserve. One is to reserve space on the > partition containing /var and /etc for log files, etc. The other is > to avoid the performance degredation when the last 5-10% of the disk > space is used. (BSD actually reserves 10% by default.) Given that > the

Just to make sure somebody reacts (please) I'm forwarding this. Please cc me on replies as I'm not subscribed to this list. -------- Original Message -------- Subject: [RESEND] 2.4.20: ext3: Assertion failure in journal_forget()/Oops on another system Date: Wed, 04 Dec 2002 21:27:31 +0100 From: Andreas Steinmetz <ast@domdv.de> To: Linux Kernel Mailing List

Bug report follows. Please CC me if you want me to read the reply, as I'm not subscribed to ext3-users. [1.] One line summary of the problem: Ext3 has just causing filesystem corruption which required fsck to fix. [2.] Full description of the problem/report: I just had my machine lock up with an ext3 oops, preceeded by a bunch of error messages in the logs. On rebooting, after replaying the

every one,I meet a problem: I used reahat9.0(kernel 2.4.20-8smp,I installed a SCSI RAID Card),and there are always some problems and them the system is dead. is anyone can help me about it? Thanks Crist Below is the error log: Jun 11 22:19:03 mail1 kernel: EXT3-fs error (device sd(8,18)): ext3_free_blocks: Freeing blocks not in datazone - block = 1382828372, count = 1 Jun 11 22:19:03 mail1

This is a 2.2.19 machine with ext3-0.0.7a and quota support running. The symptoms are a particular NFS export hangs (for linux clients but not Solaris clients?) the local filesystem gives the following: EXT3-fs warning (device sd(8,49)): ext3_free_blocks: bit already cleared for block 2213 EXT3-fs error (device sd(8,49)): ext3_free_blocks: Freeing blocks not in datazone - block = 1563120916,

This patch contains the following cleanups: - there's no need for ext3_count_free() #ifndef EXT3FS_DEBUG - having prototypes for ext3_count_free() in two different headers is nonsense Signed-off-by: Adrian Bunk <bunk at stusta.de> --- fs/ext3/balloc.c | 2 -- fs/ext3/bitmap.c | 8 +++++++- fs/ext3/bitmap.h | 8 -------- fs/ext3/ialloc.c | 1 - 4 files changed, 7

A brand new system setup with RH 7.3 is still Oopsing after every X hours. The problem started after about 1 week without errors. Sometimes everything is locked, sometimes still messages are written to /var/log/messages. Sometimes other processes keep running (can still ping the machine) I upgraded the kernel to 2.4.18-19.7.x, changed the memory, but still got problems. When I read all sort of

On a 2.4.15-pre5 system with a 3ware-Escalade-68000 IDE RAID (mode 1) we had the follwing "dmesg" output today: EXT3-fs error (device sd(8,38)): ext3_free_blocks: Freeing blocks in system zones - Block = 16, count = 1 EXT3-fs error (device sd(8,38)): ext3_free_blocks: bit already cleared for block 1052672 EXT3-fs error (device sd(8,38)): ext3_free_blocks: Freeing blocks not in datazone

After a bit of searching through these archives I haven't found quite my problem described yet, so let me bounce this off you guys: Red Hat 7.2, I run up2date whenever patches come out; right now I'm using kernel 2.4.9-21. Things have been quite pleasant for several months, but in the last week I have begun receiving the following error messages: Feb 22 08:06:27 medmeta kernel:

Hi I've got serious troubles - I posted a while back about experiencing ext3 errors using 2.4.18, at the time I put the problems down to harddisk failure, but these problems are occurring more and more - not all of our systems are having this problem but 3 systems have now shown this problem. The hardware is essentially the same, the only difference is disk manufacturers but we've now

hiya! i'm currently running 2.4.12-ac1 w/o any further ext3 patches. i've got a dir with some fairly big files (like 15mb/file) in it and while sfv-checking these i got the following errors: Oct 14 21:47:59 srck@trottelkunde attempt to access beyond end of device Oct 14 21:47:59 srck@trottelkunde 16:42: rw=0, want=600889688, limit=12289725 Oct 14 21:47:59 srck@trottelkunde attempt to

I had a failure over the weekend of my ext3 filesystems. Hardware: Dell 2550 (dual PIII 1 Ghz, 1GB ram, Acenic GigE card) Software: linux-2.4.14 ext3-2.4-0.9.15-2414 Trond's NFS patches (pathconf, tune,read,rpc_blk) The filesystem is RAID0 using LVM (1.0.1-rc4). The disks are connected using fiber channel (qlogic 2200, qlax00-4.27beta). I was generating high load on my nfs

Hi Stephen, I'm one of developers of SnapFS, which based on Ext3. I got Assertion failure from SnapFS, at ext3_new_block() in fs/ext3/balloc.c: J_ASSERT (!test_and_set_bit(BH_Alloced, &bh->b_state)) If J_ASSERT is only use as debug, why it will modify data? I found the 'BH_Alloced' flag only occures at two place: one is balloc.c as above, the other is at journal_forget() in

Since I ain't got a better place to report this, I do it here: Kernel 2.4.20-ac1 # uptime 16:31:00 up 2 days, 22:10, 7 users, load average: 1.89, 2.20, 2.99 This is our main mailbox server. We're running ext3: # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw 0 0 /proc /proc proc rw 0 0 /dev/sdb5 /boot ext3 rw 0 0 /dev/sda6 /home ext3 rw,noatime,nosuid 0 0 /dev/sdb8 /tmp

Hi all. I have two hosts with drbd: kmod-drbd83-8.3.8-1.el5.centos drbd83-8.3.8-1.el5.centos and kernel (CentOS 5.7): 2.6.18-308.4.1.el5 After a recent upgrade of kernel I have had two sitiuations when my ext3 filesystem on /dev/drbd0 became read-only. I've checked disks with smartctl -t long, they are ok. There are no messages with disks problems in /var/log/messages | dmesg. I've made

Hi all, after an uprade to new kernel 2.4.21-15.0.4.EL on my server appears a lot of these messages: EXT3-fs error (device sd(8,17)): ext3_free_blocks: bit already cleared for block 19268224 EXT3-fs error (device sd(8,17)): ext3_free_blocks: bit already cleared for block 19268225 EXT3-fs error (device sd(8,17)): ext3_free_blocks: bit already cleared for block 19268226 I try to rebuild array but