search for: journal_start

...g around 1-2. a large partition, formatted reiserfs within large partition are 80 300Mb loopback file systems, formatted ext3. I got the following assertion yesterday which forced a lot of processes into D state. I'm not sure how easy it is to reproduce this problem. Assertion failure in journal_start() at transaction.c:226: "handle->h_transaction->t_journal == journal" The oops follows: invalid operand: 0000 CPU: 1 EIP: 0010:[<c0165908>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010292 eax: 0000006c ebx: c416d4e0 ecx: 0000008...

always use the 2.6 variants and fix up for 2.4 under the hood Index: src/journal.c =================================================================== --- src/journal.c (revision 1156) +++ src/journal.c (working copy) @@ -105,9 +105,17 @@ return status; } -#else -#define ocfs_journal_start journal_start -#define ocfs_journal_stop journal_stop + +#define journal_start(journal, nblocks) \ + ocfs_journal_start(journal, nblocks) +#define journal_stop(handle) \ + ocfs_journal_stop(handle) + +/* these two gained another argument during 2.6 */ +#define journal_get_write_access(handle, bh, c...

...[<c024601e>] Jan 14 12:53:52 oceanic kernel: [<c0159fce>] [<c013e2e6>] [<c0148bb3>] [<c013f98d>] [<c013e397>] [<c010770f>] Jan 14 12:53:52 oceanic kernel: Code: 0f 0b f9 00 f4 4f 8b f8 ff 43 08 89 d8 8b 5c 24 14 8b 74 24 >>EIP; f88ab5df <[jbd]journal_start+5f/c0> <===== >>ebx; efeed7a0 <___strtok+2fb896e0/38546fa0> >>edx; e9925f7c <___strtok+295c1ebc/38546fa0> >>esi; ef818000 <___strtok+2f4b3f40/38546fa0> >>edi; f7719000 <___strtok+373b4f40/38546fa0> >>esp; ef819b74 <___strtok+2f4b5ab4...

...ut 185 messages like this: Mar 9 17:15:13 srck@trottelkunde attempt to access beyond end of device Mar 9 17:15:13 srck@trottelkunde 16:42: rw=0, want=0, limit=12289725 right before the bug(). this message didn't get parsed by ksymoops Mar 9 17:15:13 srck@trottelkunde Assertion failure in journal_start() at transaction.c:226: "handle->h_transaction->t_journal == journal" i'm somehow desperate by now, i get crashes like this on a monthly basis; the quota code always seems to be the cause... here are the lines of the last crashes (can't resolve call trace because the old k...

We have a machine that is trying its darndest to house a linux kernel cvs repository. The machine is a dual 733mhz p3 netfinity of some kind. 512M of mem. Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda1 16484504 4015876 11631240 26% / /dev/sda2 31079 3199 26276 11% /boot /dev/sdb2 16516084 32828 15644264 1%

.... v1 quotas are enabled. The stacktrace lines below are from a lightly editted "echo t > /proc/sysrq-trigger" output. A substantial number of nfsd threads a waiting to "start a handle": nfsd Call Trace: [sleep_on+75/124] [start_this_handle+205/368] [journal_start+149/196] [ext3_dirty_inode+116/268] [__mark_inode_dirty+50/168] [update_atime+75/80] [do_generic_file_read+1158/1172] [generic_file_read+147/400] [file_read_actor+0/224] [nfsd_read+477/636] [nfsd3_proc_read+295/388] [nfsd_dispatch+207/406] [svc_process+6...

...C0029C18 C002A08C C0045FC4 C00466A8 C0046DEC C0006ED0 C0003DFC 0000000C 01812B7C 01801E80 018021A4 018031A0 01804C00 01804FDC 0180578C 00000000 >>NIP; c0080424 <journal_blocks_per_page+148/e4f8> <===== Trace; c0080384 <journal_blocks_per_page+a8/e4f8> Trace; c0076440 <journal_start+ac/3a8> Trace; c006f998 <grok_partitions+9358/fd54> Trace; c0055650 <__mark_inode_dirty+4c/948> Trace; c0057394 <update_atime+64/74> Trace; c0029c18 <do_generic_file_read+4d0/8b4> Trace; c002a08c <generic_file_read+90/8bc> Trace; c0045fc4 <kernel_read+58/354>...

One of our servers (false) just oopsed. In the middle of lunch. Any advise? On console: false kernel: Assertion failure in journal_start() at transaction.c line 245: "handle->h_transaction->t_journal == journal" In kernel log (ran it through ksymoops): Nov 13 12:35:37 false kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Nov 13 12:35:37 false kernel: current->tss.cr3 = 00a...

...ation again. the only problem is load, which is incrementing constantly, but cpu is 99% idle... after few minutes i cannot login again ... machine: pentium 200, 72 mb of ram, eide disks (brand new), dcom ethernet cards what's wrong? brane Jan 16 12:37:37 frost kernel: Assertion failure in journal_start() at transaction.c:225: "handle->h_transaction- >t_journal == journal" Jan 16 12:37:37 frost kernel: invalid operand: 0000 Jan 16 12:37:37 frost kernel: CPU: 0 Jan 16 12:37:38 frost kernel: EIP: 0010:[journal_start+79/208] Not tainted Jan 16 12:37:38 frost kernel: EIP: 0...

...excert from my system logs. machine stops responing for a few seconds and after then it looks, like it's in normal operation again. the only problem is load, which is incrementing constantly, but cpu is 99% idle... what's wrong? brane Jan 16 12:37:37 frost kernel: Assertion failure in journal_start() at transaction.c:225: "handle->h_transaction- >t_journal == journal" Jan 16 12:37:37 frost kernel: invalid operand: 0000 Jan 16 12:37:37 frost kernel: CPU: 0 Jan 16 12:37:38 frost kernel: EIP: 0010:[journal_start+79/208] Not tainted Jan 16 12:37:38 frost kernel: EIP: 0...

Hi Jan, I am now reading quota support in ocfs2 and have some qs. Wish you can help me clarify it. Thanks. ocfs2_quota_write: In the comment, you said that "we know the transaction is already started", so it should be called within a transaction. But in this function, we call ocfs2_extend_no_holes and ocfs2_simple_size_update which will start another transaction. So we can survive

...016aa53 ca55a3c4 c2e67f40 00000000 c2e67e84 c9fa8ac0 ca55a3c4 c2e67f40 c016aac1 ca55a3c4 c9fa8ac0 Call Trace: [<c0171046>] journal_get_write_access+0xb/0x2d [<c016aa53>] ext3_reserve_inode_write+0x33/0x89 [<c016aac1>] ext3_mark_inode_dirty+0x18/0x31 [<c017082b>] journal_start+0x7f/0xa9 [<c016ab26>] ext3_dirty_inode+0x4c/0x5f [<c0156c20>] __mark_inode_dirty+0x24/0xce [<c01527d2>] inode_setattr+0x118/0x123 [<c016a951>] ext3_setattr+0xc9/0x104 [<c0152903>] notify_change+0xda/0x143 [<c013c6b9>] sys_utime+0xec/0x110 [<c013e5ad&gt...

...ps: [[[LVM is in the process of calling PV_FLUSH ioctl => invalidate_buffers()]]] Attempt to refile free buffer Unable to handle kernel NULL pointer dereference at virtual address 00000000 <kdb stuff> refile_buffer cleanup_transaction log_do_checkpoint log_wait_for_space start_this_handle journal_start ext3_file_write do_readv_writev sys_write The oops is from "*(char *)0 = 0" added by the ext3 patch, but I take it that trying to refile a free buffer is fundamentally a bad thing. The oops is caused from __invalidate_buffers() calling put_last_free(bh) on the device buffers (for buffe...

...4 00:08:08 server1 kernel: [<f88af27e>] ext3_free_branches+0xd6/0x1be [ext3] Feb 4 00:08:08 server1 kernel: [<f88af702>] ext3_truncate+0x39c/0x460 [ext3] Feb 4 00:08:08 server1 kernel: [<c0317627>] __cond_resched+0x14/0x3b Feb 4 00:08:08 server1 kernel: [<f8862737>] journal_start+0x78/0x9e [jbd] Feb 4 00:08:08 server1 kernel: [<f88ad4b5>] ext3_delete_inode+0x60/0xaa [ext3] Feb 4 00:08:23 server1 kernel: [<f88ad455>] ext3_delete_inode+0x0/0xaa [ext3] Feb 4 00:08:23 server1 kernel: [<c018adbb>] generic_delete_inode+0xef/0x229 Feb 4 00:08:23 server1 nr...

...0000000000000030 Jun 10 14:50:23 mithrandir kernel: [40871.729568] ---[ end trace 7ff9da295f74d790 ]--- Jun 10 14:50:23 mithrandir kernel: [40871.729588] BUG: unable to handle kernel paging request at 00000000000015bd Jun 10 14:50:23 mithrandir kernel: [40871.729632] IP: [<ffffffff8111a0c2>] journal_start+0x2f/0xc1 Jun 10 14:50:23 mithrandir kernel: [40871.729668] PGD 1391ca067 PUD 1391c9067 PMD 0 Jun 10 14:50:23 mithrandir kernel: [40871.729701] Oops: 0000 [#2] PREEMPT SMP Jun 10 14:50:23 mithrandir kernel: [40871.731455] CPU 0 Jun 10 14:50:23 mithrandir kernel: [40871.731467] Modules linked in:...

Hi, I am upgrading the tomsrtbt rescue distribution from kernel 2.0.39 to 2.2.20. Fitting a 2.4.x kernel on the floppy is not practical at this time. I am trying to support both ext3 and reiser filesystems. However, there are symbol collisions, it is impossible to use both. Is there any chance of getting the 2.2.x patch fixed? -Thanks -Tom

Hi! I experienced an ext3 crash a few days ago, the corresponding part of my kernel log is attached (there were no IDE-errors, just the ext3 stuff). The /home partition (/dev/hdd2) got remounted ro, so the box was still usable somehow (was able to log in, kill stuff and reboot it). I rebooted it, it came back up again w/o any problems, remounted /home ro and did a e2fsck on it, which reported

...into a different ext3 filesystem (both on LVs), and running pvscan (i.e. invalidate_buffers) repeatedly. At one point, I got several free buffers reported in cleanup_transaction. After that (this is the first time it happened) my kernel compile deadlocked and the kernel is stuck on: ext3_create journal_start start_this_handle log_wait_for_space log_do_checkpoint cleanup_transaction* __wake_up* The last 2 (*) functions appear and disappear from the KDB "bt" output, so I assume they are being called, but never finishing the transaction. I've added more debugging to determine which device...

...Trace; c0158303 <ext3_free_data+fb/160> Trace; c0115660 <schedule+210/234> Trace; c0158568 <ext3_free_branches+200/210> Trace; c0158434 <ext3_free_branches+cc/210> Trace; c0158640 <ext3_truncate+c8/3a4> Trace; c0158801 <ext3_truncate+289/3a4> Trace; c015e1ad <journal_start+95/c4> Trace; c015662d <start_transaction+55/80> Trace; c01566cc <ext3_delete_inode+0/124> Trace; c0156773 <ext3_delete_inode+a7/124> Trace; c01566cc <ext3_delete_inode+0/124> Trace; c014852a <iput+ca/1b8> Trace; c0146236 <dput+e6/144> Trace; c0140fdf <sys_...

...data3 kernel: 0000010024e32820 000001011cd75240 Dec 18 03:18:09 data3 kernel: Call Trace:<ffffffffa00528c2>{:ext3:ext3_mark_iloc_dirty+740} Dec 18 03:18:09 data3 kernel: <ffffffffa0052a14>{:ext3:ext3_mark_inode_dirty+65} Dec 18 03:18:10 data3 kernel: <ffffffffa003c4c6>{:jbd:journal_start+223} <ffffffffa0054726>{:ext3:ext3_dirty_inode+99} Dec 18 03:18:10 data3 kernel: <ffffffff8018fef0>{__mark_inode_dirty+40} <ffffffff80189748>{inode_update_time+182} Dec 18 03:18:10 data3 kernel: <ffffffff80155b7b>{generic_file_aio_write_nolock+620} Dec 18 03:18:10 data3 kern...