search for: journal_commit_transact

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 usb-...

...d dirty buffer encountered at do_get_write_access:618 (03:05 blocknr 3616336) Mar 2 14:18:38 test5 kernel: Unexpected dirty buffer encountered at do_get_write_access:618 (03:05 blocknr 3692808) I've duplicated it in 2.4.22 and 2.4.25. Here's the crash from 2.4.25: Assertion failure in journal_commit_transaction() at commit.c:759: "!(((bh)->b_state & (1UL << BH_Dirty)) != 0)" kernel BUG at commit.c:759! invalid operand: 0000 CPU: 0 EIP: 0010:[<c0174064>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 00000074 ebx: f7221f00...

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 kernel: nfs lockd sunrpc eepro10...

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 at commit.c:535! May 19 12:50:16 server1 kernel: invalid operand: 0000 May 19 12:50:16 server1 kernel: ipt_LOG ipt_state ip_conntrack i...

...t >do_get_write_access:618 (03:05 blocknr 3616336) >Mar 2 14:18:38 test5 kernel: Unexpected dirty buffer encountered at >do_get_write_access:618 (03:05 blocknr 3692808) > >I've duplicated it in 2.4.22 and 2.4.25. Here's the crash from 2.4.25: > >Assertion failure in journal_commit_transaction() at commit.c:759: >"!(((bh)->b_state & (1UL << BH_Dirty)) != 0)" >kernel BUG at commit.c:759! >invalid operand: 0000 >CPU: 0 >EIP: 0010:[<c0174064>] Not tainted >Using defaults from ksymoops -t elf32-i386 -a i386 >EFLAGS: 00010282 >...

...as anyone seen this? If someone will give us some pointers, we are willing to put the time into a debugging-enabled kernel. I see various complaints about ext3+software RAID 1 in the archives, but they all seem to come down to older versions or hardware (mostly RAM) problems. Assertion failure in journal_commit_transaction() at commit.c:535:\ "buffer_jdirty(bh)" ------------[ cut here ]------------ kernel BUG at commit.c:535! invalid operand: 0000 autofs eepro100 ext3 jbd raid1 aic7xxx sd_mod scsi_mod CPU: 0 EIP: 0010:[<f885b0e4>] Not tainted EFLAGS: 00010286 EIP is at journal_commit_tra...

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 (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) /dev/cciss/c0d0p5 on /boot type ext3 (rw) /dev/shm on /var/amavis ty...

...? Oct 7 20:31:36 fargo kernel: (journal.c, 218): kjournald: kjournald wakes Oct 7 20:31:36 fargo kernel: (journal.c, 202): kjournald: commit_sequence=81, commit_request=82 Oct 7 20:31:36 fargo kernel: (journal.c, 205): kjournald: OK, requests differ Oct 7 20:31:36 fargo kernel: (commit.c, 78): journal_commit_transaction: JBD: starting commit of transaction 82 Oct 7 20:31:36 fargo kernel: (revoke.c, 413): journal_write_revoke_records: Wrote 0 revoke records Oct 7 20:31:36 fargo kernel: (checkpoint.c, 607): __journal_drop_transaction: Dropping transaction 81, all done Oct 7 20:31:36 fargo kernel: (commit.c, 69...

...b_state:0xb1 b_list:BUF_CLEAN b_jlist:BJ_Metadata on_lru:1 cpu:0 on_hash:1 b_count:2 b_blocknr:1 b_jbd:1 b_frozen_data:00000000 b_committed_data:00000000 b_transaction:1 b_next_transaction:0 b_cp_transaction:0 b_trans_is_running:1 b_trans_is_comitting:0 b_jcount:0 <0> journal_commit_transaction() [commit.c:385] ph3: write metadata b_state:0xb1 b_list:BUF_CLEAN b_jlist:BJ_Metadata on_lru:1 cpu:0 on_hash:1 b_count:3 b_blocknr:1 b_jbd:1 b_frozen_data:00000000 b_committed_data:00000000 b_transaction:1 b_next_transaction:0 b_cp_transaction:0 b_trans_is_running:0 b_t...

...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 journal_commit_transaction() at commit.c:535: "buffer_jdirty(bh)" Jul 16 01:45:34 ETG3 kernel: ------------[ cut here ]------------ Jul 16 01:45:34 ETG3 kernel: kernel BUG at commit.c:535! Jul 16 01:45:34 ETG3 kernel: invalid operand: 0000 Jul 16 01:45:34 ETG3 kernel: autofs tg3 eepro100 ext3 jbd aacraid aic7xxx...

...en 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 dereference at 0000000000000000 RIP: Jan 23 03:08:22 infinity kernel: [24686.841039] <ffffffff8810d3e2> {:jbd:journal_commit_transaction+2594} Jan 23 03:08:22 infinity kernel: [24686.841064] PGD 6ea20067 PUD 6ea97067 PMD 0 Jan 23 03:08:22 infinity kernel: [24686.841069] Oops: 0000 [1] SMP Jan 23 03:08:22 infinity kernel: [24686.841073] CPU 1 Jan 23 03:08:22 infinity kernel: [24686.841075] Modules linked in: ext2 binfmt_misc ipt_l...

...0 00000000 d3ee18c0 00000000 c0156b8e Nov 4 18:39:03 buba kernel: d37eb000 d37eb0e4 00000000 00000000 00000000 00000000 c5e7e750 d3ee18c0 Nov 4 18:39:03 buba kernel: c8b818c0 c5e7e300 37363534 42413938 46454443 4a494847 c4ae8740 d359e7c0 Nov 4 18:39:03 buba kernel: Call Trace: [journal_commit_transaction+558/4448] [__switch_to+35/208] [schedule+593/912] [kjournald+371/688] [commit_timeout+0/16] Nov 4 18:39:03 buba kernel: Call Trace: [<c0156b8e>] [<c0105813>] [<c0111be1>] [<c0159983>] [<c01597f0>] Nov 4 18:39:03 buba kernel: [<c0105536>] [<c0159810&g...

...8679 1 schedule_timeout 0.0 0.0 0 evlnotifyd 8689 1 schedule_timeout 0.0 0.0 0 evlactiond 8704 1 wait 0.0 0.0 1 bash 8882 8704 - 0.0 0.0 2 ps If I run ps repeatedly, I always see process 8379 in journal_commit_transaction, and it is always taking between 12% and 20% of processor 0 up. This process never completes. I also see process 8847 in start_this_handle forever as well - so I believe they are related. This system is using a 2.6.14 kernel. Has anyone seen this type of behaviour before? Note, if I chan...

.../406] [svc_process+655/1264] [nfsd+566/944] [arch_kernel_thread+40/56] This sleep_on is the one at line 136 of transcation.c(start_this_handle), where it is waiting for t_state to stop being T_LOCKED. The related kjournald is at: kjournald Call Trace: [sleep_on+75/124] [journal_commit_transaction+357/4044] [do_IRQ+221/236] [.text.lock.sched+131/471] [kjournald+326/540] [commit_timeout+0/12] [arch_kernel_thread+40/56] This sleep_on is at line 87 in commit.c (journal_commit_transaction) where it is waiting for t_updates to be 0. At this point, t_state is T_LOCKED, so...

...(pid: 1485, threadinfo ffff8100fade8000, task ffff8100fb9be880) Stack: ffff8100020ba898 ffff81008caebce8 0000000000000000 ffffffff8807c9d2 ffff8100f8b55024 0000000000000cf7 ffff8100f8b5515c 0000000000000000 0000000000000000 0000000000000000 Call Trace:<ffffffff8807c9d2>{:jbd:journal_commit_transaction+4194} <ffffffff801439f1>{del_timer+113} <ffffffff8807f4d3>{:jbd:kjournald+275} <ffffffff8807eba0>{:jbd:commit_timeout+0} <ffffffff801506e0>{autoremove_wake_function+0} <ffffffff8010f76b>{child_rip+8} <ffffffff8807f3c0>{:jbd:kjournald+...

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 EIP: 0010:[<f88540e4>] Not tainted EFLAGS: 00010286 EIP i...

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 did a value like that come from?) je .... ud2a - (looks like assembly for BUG()) One more thing I have seen is a problem with the following code do { new_bh = get_unused_buffer...

...pid: 14, stackpage=f7a99000) Stack: c0352a20 c034e401 c034e3a5 0000027c c034e3f8 f7b58e00 c016b5f7 f7b58e00 00001b0c d93e88e0 c0168c8d f7b58e00 f7b58ee4 00000000 00000fdc dc757024 00000002 db247c60 f28df240 f122f730 00000001 00000070 00000001 e2bc9ae0 Call Trace: [journal_next_log_block+103/112] [journal_commit_transaction+1661/3856] [do_softirq+123/224] [do_IRQ+221/240] [schedule+1113/1296] Call Trace: [<c016b5f7>] [<c0168c8d>] [<c011cdcb>] [<c01089bd>] [<c0115e59>] [kjournald+310/464] [commit_timeout+0/16] [kernel_thread+38/48] [kjournald+0/464] [<c016aff6>] [<c016aea0&g...

...0462 00001000 00000002 c3d3a9c0 c01327fa c3d3a9c0 c01a6a87 c3d3a9c0 c3e05ec0 c3e36d20 c3d2720c c7bedfc8 00001000 00000002 c7bec000 00000003 c7bedfc8 c0105ba6 c0105d88 c017ed2c 00000001 00000040 Call Trace: [refile_buffer+10/16] [ll_rw_block+423/624] [__up+22/32] [__up_wakeup+8/16] [journal_commit_transaction+4412/9456] [kjournald+267/464] [commit_timeout+0/16] [kernel_thread+40/64] Code: 0f 0b 83 c4 0c 31 f6 f6 43 1b 40 0f 84 bc 01 00 00 83 7b 40 VFS: Disk change detected on device fd(2,0) Assertion failure in __refile_buffer() at buffer.c:1122: "!journal_buffer_temp(bh)" kernel...

...000 task=f6801a60) Stack: c04295a0 c0429764 c0429567 00000265 c0429805 f6877400 f188cf8c c01f71c1 f6877400 d1abf680 f6877400 f6877414 f6877414 00000000 f68774c0 f6877454 f687743c d1abf6b8 f6877414 f6877414 ed3021b8 f6877478 f5e58000 00000000 Call Trace: [<c01f71c1>] journal_commit_transaction+0xf09/0xf68 [<c0163281>] rcu_check_quiescent_state+0x55/0x64 [<c016328b>] rcu_check_quiescent_state+0x5f/0x64 [<c0165f6c>] autoremove_wake_function+0x0/0x40 [<c0165f6c>] autoremove_wake_function+0x0/0x40 [<c015014b>] find_busiest_group+0xeb/0x2d8 [<c0150c3b...