similar to: consistent crash with data=journal

Hello ext3-users-request, request ======= 2004-03-03 12:00:00 You writed======= >Send Ext3-users mailing list submissions to > ext3-users at redhat.com > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/ext3-users >or, via email, send a message with subject or body 'help' to > ext3-users-request at redhat.com >

Hi Ext3! I'm running about 30 dedicated MySQL machines under quite decent loads, and they are occassionally crashing. I've been logging console messages recently in an effort to find the cause, and some appear to be related to I perused your lists and found the message I'm replying to. If you don't mind, I've included messages and ksymoops from two crashes that I had

While writing a file to an ext3 filesystem, i get some drive errors on the console. I guess is a drive/ide related problem more that a ext3 one, but anyway the debug output is here if you want to take a look. And, by the way, what means that DRQ thing?? Oct 7 20:31:36 fargo kernel: (journal.c, 218): kjournald: kjournald wakes Oct 7 20:31:36 fargo kernel: (journal.c, 202): kjournald:

I use redhat7.3 . Sep 20 20:39:31 Xhwsrhtrs2 kernel: Assertion failure in journal_commit_transaction() at commit.c:535: "buffer_jdirty(bh)" Sep 20 20:39:31 Xhwsrhtrs2 kernel: ------------[ cut here ]------------ Sep 20 20:39:31 Xhwsrhtrs2 kernel: kernel BUG at commit.c:535! Sep 20 20:39:31 Xhwsrhtrs2 kernel: invalid operand: 0000 Sep 20 20:39:31 Xhwsrhtrs2 kernel: autofs eepro100

Hello,ext3-users: Yep, We meet the same problem. Jul 17 22:41:40 sh_intel5 kernel: Assertion failure in journal_commit_transaction() at commit.c:535: "buffer_jdirty(bh)" Jul 17 22:41:40 sh_intel5 kernel: ------------[ cut here ]------------ Jul 17 22:41:40 sh_intel5 kernel: kernel BUG at commit.c:535! Jul 17 22:41:40 sh_intel5 kernel: invalid operand: 0000 Jul 17 22:41:40 sh_intel5

Hello: My RedHat 7.3 machine just locked up and I could not reboot it. I had to punch the reset button. Here is what I found in the /var/log/messages file: May 19 12:50:16 server1 kernel: Assertion failure in journal_commit_transaction() at commit.c:535: "buffer_jdirty(bh)" May 19 12:50:16 server1 kernel: ------------[ cut here ]------------ May 19 12:50:16 server1 kernel: kernel BUG

We're getting the below errors about once a day on a system we're trying to set up with RedHat 7.3. This has happened to multiple filesystems on multiple physical and logical disks (basically we've got 4 drives as 2 sets of RAID 1 arrays, details below). Until a week ago, this box was a high-volume IMAP server running RedHat 6.2 with uptimes in the 200-day range, so I don't

I don't know enough about it to know whether this is a known problem (I couldn't make much sense of what I found on Google), but it seems to be a journal-related issue. Is it likely that data has been corrupted? Do I need to take any action? 2.6.12-9-amd64-k8-smp, Ubuntu 5.10, dual opteron 2GB Jan 23 03:08:22 infinity kernel: [24686.841032] Unable to handle kernel NULL pointer

Hi, A couple of our important servers, both running FC4 but one i386 and one x86_64, have been crashing recently. They both are running ext3 data=journal with large external journals and high commit intervals. Both machines use the gdth driver for their hardware RAID sets, if that's of any use. I think the hardware is good in both cases. I hope someone finds this data useful enough to be

Anyone got a clue about this: Server: DELL EdgeServer 2550 with PERC RAID card RH 7.3. Interestingly it happen with PureFTP and then started to hang socket connections until the box hung.. (or was it something else - maybe I have it backwards... that's why I'm comming to you guys..) Log entry in /var/log/messages: Jul 16 01:45:34 ETG3 kernel: <0>Assertion failure in

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

Today our mailserver froze after just one day of uptime. I was able to capture the Oops on the screen using my digital camera: http://www.stahl.bau.tu-bs.de/~hildeb/bugreport/ Keywords: EIP is at journal_commit_transaction, process kjournald # mount /dev/cciss/c0d0p6 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts

Hi all. I am running the 2.4.18-3smp kernel and over the poast couple of days, ext3 has been crashing. Here is the output: Assertion failure in journal_commit_transaction() at commit.c:535: "buffer_jdirty(bh)" ------------[ cut here ]------------ kernel BUG at commit.c:535! invalid operand: 0000 loop autofs nfs lockd sunrpc 3c59x ns83820 ide-scsi ide-cd cdrom usb-uhci usbc CPU: 0

Started with buffer.c v1.19. Reversing change works for me in linux-2.4.6. Loaded 16705 symbols from /lib/modules/2.4.6-pre3/System.map. Symbols match kernel version 2.4.6. Loaded 256 symbols from 12 modules. Linux version 2.4.6-pre3 (root@home1) (gcc version 2.95.3 20010315 (release)) #2 Wed Jun 13 19:53:28 EDT 2001 ----- SNIP ------- VFS: Disk change detected on device ide1(22,64) Assertion

Hello! I got oops after about 3 hours of uptime. Load was about 1,5. This is output of ksymoops after forced reboot if it helps someone. :-) ksymoops 2.4.0 on i686 2.4.14-pre8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.14-pre8/ (default) -m /boot/System.map-2.4.14-pre8 (default) Warning (compare_maps): mismatch on

We have here an knfs fileserver running ext3 on 2.4.18 kernel with three filesystems: <CLIP> Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda3 10080520 3609632 6368476 37% / /dev/hda4 16437332 12295408 3974932 76% /home /dev/md1 1024872060 409906136 614441636 41% /fs </CLIP> The /fs filesystem lives on a

Hi all, and particularly Andrew and Stephen, I recently "upgraded' one of my NFS fileservers from (patched)2.4.18 to 2.4.23-pre7 (in order to resolve a HIMEM related memory pressure problem). Unfortunately I have experienced what appears to be a deadlock. The one I will describe was experienced while running 2.4.23-pre7, though I had a very similar problem in 2.4.22 (but

I sent this report sometime ago to l-k and to the preempt-patch maintainer, but omitted to send a copy here, where some people could have clues about the problem - so here it is: ----- Forwarded message ----- To: linux-kernel@vger.kernel.org, Robert Love <rml@tech9.net> Subject: oops with 2.4.18 and preempt patch, on SMP + ext3 machine Coming back home tonight, I found my machine in a bad

Hello All, I am running Linux 2.4.7-10, 2.4.18-4 and 2.4.19-pre9, I see the following oops quite often (mainly on 2.4.19-pre9 with kdb). All the kernels I use have the kdb patch installed. 1 kmem_cache_alloc (offset 0x125) get_unused_buffer_head journal_write_metadata_buffer journal_commit_transaction kjournald kernel_thread kmem_cache_alloc dis xchg %eax, (%ebx) cmp $0x5a2cf071, %eax (where

I previously wrote: > I have come across what appears to be a bug in __invalidate_buffers() > w.r.t. the change in ext3-0.0.6 using BH_JDirty instead of BH_Dirty > for buffers held in the journal. If invalidate_buffers() is called > on a device (LVM likes to do this a lot, for whatever reason), it yanks > JDirty buffers out from underneath the journal layer, and causes an > oops