Re: ext3 journalling BUG on full filesystem
* Stephen C. Tweedie ([EMAIL PROTECTED]) wrote: > On Thu, 2005-03-24 at 19:38, Chris Wright wrote: > > > OK, good to know. When I last checked you were working on a higher risk > > yet more complete fix, and I thought we'd wait for that one to stabilize. > > Looks like the one Jan attached is the better -stable candidate? > > Definitely; it's the one I gave akpm. The lock reworking is going to > remove one layer of locks, so it's worthwhile from that point of view; > but it's longer-term, and I don't know for sure of any paths to chaos > with that simpler journal_unmap_buffer() fix in place. (It's just very > hard to _prove_ all cases are correct without the locking rework.) Great, I'll add to -stable queue. Thanks Stephen. -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
Hi, On Thu, 2005-03-24 at 19:38, Chris Wright wrote: > OK, good to know. When I last checked you were working on a higher risk > yet more complete fix, and I thought we'd wait for that one to stabilize. > Looks like the one Jan attached is the better -stable candidate? Definitely; it's the one I gave akpm. The lock reworking is going to remove one layer of locks, so it's worthwhile from that point of view; but it's longer-term, and I don't know for sure of any paths to chaos with that simpler journal_unmap_buffer() fix in place. (It's just very hard to _prove_ all cases are correct without the locking rework.) --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
* Stephen C. Tweedie ([EMAIL PROTECTED]) wrote: > Hi, > > On Thu, 2005-03-24 at 10:39, Jan Kara wrote: > > > Actually the patch you atached showed in the end as not covering all > > the cases and so Stephen agreed to stay with the first try (attached) > > which should cover all known cases (although it's not so nice). > > Right. The later patch is getting reworked into a proper locking > overhaul for the journal_put_journal_head() code. The earlier one (that > Jan attached) is the one that's appropriate in the mean time; it covers > all of the holes we know about for sure and has proven robust in > testing. OK, good to know. When I last checked you were working on a higher risk yet more complete fix, and I thought we'd wait for that one to stabilize. Looks like the one Jan attached is the better -stable candidate? thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
Hi, On Thu, 2005-03-24 at 10:39, Jan Kara wrote: > Actually the patch you atached showed in the end as not covering all > the cases and so Stephen agreed to stay with the first try (attached) > which should cover all known cases (although it's not so nice). Right. The later patch is getting reworked into a proper locking overhaul for the journal_put_journal_head() code. The earlier one (that Jan attached) is the one that's appropriate in the mean time; it covers all of the holes we know about for sure and has proven robust in testing. --Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
Hi, > Looks like you need to apply the attached patch (for the current > bk kernel or see the link below for an earlier version (which > will require some modification to remove implicit warnings, see > to extern and prototype declarations for __journal_temp_unlink_buffer > in attached patch). Actually the patch you atached showed in the end as not covering all the cases and so Stephen agreed to stay with the first try (attached) which should cover all known cases (although it's not so nice). Honza > > Looking at Anton reply this may not be true but worth a try. > > Darren > > -- > > Stephen > I am still seeing this Oops on ext3 journal with current bk tree, this > patch: > > http://lkml.org/lkml/2005/3/8/147 > > fixes the problem though required changes to remove implicit declaration > warnings updated patch attached. > > Unable to handle kernel NULL pointer dereference (address 0018) > kjournald[16894]: Oops 8821862825984 [1] > > Pid: 16894, CPU 0, comm:kjournald > psr : 101008026018 ifs : 8e21 ip : [] > Not tainted > ip is at journal_commit_transaction+0x840/0x2700 > unat: pfs : 0e21 rsc : 0003 > rnat: bsps: pr : 1641 > ldrs: ccv : fpsr: 0009804c8a70433f > csd : ssd : > b0 : a001001ce300 b6 : a00100633000 b7 : a001a9d0 > f6 : 0fffbc8c0 f7 : 0ffea9877e000 > f8 : 1000ff0f0 f9 : 10002a000 > f10 : 1000cc0bffc303400 f11 : 1003e3030 > r1 : a00100a8c830 r2 : 0286 r3 : > r8 : 0001 r9 : e70062f40d50 r10 : e70062f40d60 > r11 : r12 : e70062f47d10 r13 : e70062f4 > r14 : e70062f47cb0 r15 : e7005c2632f8 r16 : 4000 > r17 : e7005c263338 r18 : r19 : 0009804c8a70433f > r20 : 070062f4 r21 : a0010062f9d0 r22 : > r23 : r24 : r25 : > r26 : r27 : r28 : 5a41 > r29 : r30 : r31 : e70079ab18dc > > Call Trace: > [] show_stack+0x80/0xa0 > sp=e70062f478d0 bsp=e70062f41060 > [] show_regs+0x7e0/0x800 > sp=e70062f47aa0 bsp=e70062f41000 > [] die+0x150/0x1c0 > sp=e70062f47ab0 bsp=e70062f40fb8 > [] ia64_do_page_fault+0x370/0x980 > sp=e70062f47ab0 bsp=e70062f40f50 > [] ia64_leave_kernel+0x0/0x260 > sp=e70062f47b40 bsp=e70062f40f50 > [] journal_commit_transaction+0x840/0x2700 > sp=e70062f47d10 bsp=e70062f40e48 > [] kjournald+0x180/0x4e0 > sp=e70062f47d80 bsp=e70062f40dd8 > [] kernel_thread_helper+0xd0/0x100 > sp=e70062f47e30 bsp=e70062f40db0 > [] start_kernel_thread+0x20/0x40 > sp=e70062f47e30 bsp=e70062f40db0 > > > > > On Wed, 23 Mar 2005, Mark Wong wrote: > > > I originally reported this to the linuxppc64-dev list, since I made it > > happen on a POWER system. I'm told this might be more generic... > > > > Anyone run into something like this? > > > > Mark > > > > - Forwarded message from Mark Wong <[EMAIL PROTECTED]> - > > > > Date: Wed, 23 Mar 2005 08:05:30 -0800 > > To: [EMAIL PROTECTED] > > From: Mark Wong <[EMAIL PROTECTED]> > > Subject: ext3 journalling BUG on full filesystem > > > > Hi, > > > > I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is > > causing the following problem when performing some journaling > > operation. Let me know if I can provide more details: > > > > cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] > > pc: c00a5fbc: .submit_bh+0x64/0x1fc > > lr: c00a62b4: .ll_rw_block+0x160/0x164 > > sp: c002e4f3f950 > >msr: 80029032 > > current = 0xc0038ff5c7c0 > > paca= 0xc0612000 > > pid = 1376, comm = kjournald > > kernel BUG in submit_bh at fs/buffer.c:2706! > > enter ? for help > > 6:mon> t > > [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 > > [c002e4f3f
Re: ext3 journalling BUG on full filesystem
Mark Wong wrote: I originally reported this to the linuxppc64-dev list, since I made it happen on a POWER system. I'm told this might be more generic... Anyone run into something like this? Mark If i'm not wrong I think I have had something around the same place "ext3 journalling": 1) The kjournald daemon hits a bugcheck: Assertion failure in journal_commit_transaction() at fs/jbd/commit.c:760: "jh->b_next_transaction == ((void *)0)" kernel BUG at fs/jbd/commit.c:760! (fs/jbd/transaction.c, 954): journal_dirty_data: jh: e023ee0f9a58, tid:205049 2) reading your email I decide to start a test and get this: (fs/jbd/transaction.c, 954): journal_dirty_data: jh: e023ee0f9a58, tid:205049 kernel BUG at kernel/timer.c:416! mkdir09[30886]: bugcheck! 0 [2] /* Linux version 2.6.10 with CONFIG_JBD_DEBUG enable */ hope that it can help, Jacky - Forwarded message from Mark Wong <[EMAIL PROTECTED]> - Date: Wed, 23 Mar 2005 08:05:30 -0800 To: [EMAIL PROTECTED] From: Mark Wong <[EMAIL PROTECTED]> Subject: ext3 journalling BUG on full filesystem Hi, I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is causing the following problem when performing some journaling operation. Let me know if I can provide more details: cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] pc: c00a5fbc: .submit_bh+0x64/0x1fc lr: c00a62b4: .ll_rw_block+0x160/0x164 sp: c002e4f3f950 msr: 80029032 current = 0xc0038ff5c7c0 paca= 0xc0612000 pid = 1376, comm = kjournald kernel BUG in submit_bh at fs/buffer.c:2706! enter ? for help 6:mon> t [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 [c002e4f3fab0] c0151ac4 .journal_commit_transaction+0xd88/0x16d4 [c002e4f3fe30] c0155590 .kjournald+0x114/0x308 [c002e4f3ff90] c0013ec0 .kernel_thread+0x4c/0x6c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Jacky Malcles B1-403 Email : [EMAIL PROTECTED] Bull SA, 1 rue de Provence, B.P 208, 38432 Echirolles CEDEX, FRANCE Tel : 04.76.29.73.14 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
Mark Wong wrote: I originally reported this to the linuxppc64-dev list, since I made it happen on a POWER system. I'm told this might be more generic... Anyone run into something like this? Mark If i'm not wrong I think I have had something around the same place ext3 journalling: 1) The kjournald daemon hits a bugcheck: Assertion failure in journal_commit_transaction() at fs/jbd/commit.c:760: jh-b_next_transaction == ((void *)0) kernel BUG at fs/jbd/commit.c:760! (fs/jbd/transaction.c, 954): journal_dirty_data: jh: e023ee0f9a58, tid:205049 2) reading your email I decide to start a test and get this: (fs/jbd/transaction.c, 954): journal_dirty_data: jh: e023ee0f9a58, tid:205049 kernel BUG at kernel/timer.c:416! mkdir09[30886]: bugcheck! 0 [2] /* Linux version 2.6.10 with CONFIG_JBD_DEBUG enable */ hope that it can help, Jacky - Forwarded message from Mark Wong [EMAIL PROTECTED] - Date: Wed, 23 Mar 2005 08:05:30 -0800 To: [EMAIL PROTECTED] From: Mark Wong [EMAIL PROTECTED] Subject: ext3 journalling BUG on full filesystem Hi, I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is causing the following problem when performing some journaling operation. Let me know if I can provide more details: cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] pc: c00a5fbc: .submit_bh+0x64/0x1fc lr: c00a62b4: .ll_rw_block+0x160/0x164 sp: c002e4f3f950 msr: 80029032 current = 0xc0038ff5c7c0 paca= 0xc0612000 pid = 1376, comm = kjournald kernel BUG in submit_bh at fs/buffer.c:2706! enter ? for help 6:mon t [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 [c002e4f3fab0] c0151ac4 .journal_commit_transaction+0xd88/0x16d4 [c002e4f3fe30] c0155590 .kjournald+0x114/0x308 [c002e4f3ff90] c0013ec0 .kernel_thread+0x4c/0x6c - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Jacky Malcles B1-403 Email : [EMAIL PROTECTED] Bull SA, 1 rue de Provence, B.P 208, 38432 Echirolles CEDEX, FRANCE Tel : 04.76.29.73.14 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
Hi, Looks like you need to apply the attached patch (for the current bk kernel or see the link below for an earlier version (which will require some modification to remove implicit warnings, see to extern and prototype declarations for __journal_temp_unlink_buffer in attached patch). Actually the patch you atached showed in the end as not covering all the cases and so Stephen agreed to stay with the first try (attached) which should cover all known cases (although it's not so nice). Honza Looking at Anton reply this may not be true but worth a try. Darren -- Stephen I am still seeing this Oops on ext3 journal with current bk tree, this patch: http://lkml.org/lkml/2005/3/8/147 fixes the problem though required changes to remove implicit declaration warnings updated patch attached. Unable to handle kernel NULL pointer dereference (address 0018) kjournald[16894]: Oops 8821862825984 [1] Pid: 16894, CPU 0, comm:kjournald psr : 101008026018 ifs : 8e21 ip : [a001001ce1e0] Not tainted ip is at journal_commit_transaction+0x840/0x2700 unat: pfs : 0e21 rsc : 0003 rnat: bsps: pr : 1641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001001ce300 b6 : a00100633000 b7 : a001a9d0 f6 : 0fffbc8c0 f7 : 0ffea9877e000 f8 : 1000ff0f0 f9 : 10002a000 f10 : 1000cc0bffc303400 f11 : 1003e3030 r1 : a00100a8c830 r2 : 0286 r3 : r8 : 0001 r9 : e70062f40d50 r10 : e70062f40d60 r11 : r12 : e70062f47d10 r13 : e70062f4 r14 : e70062f47cb0 r15 : e7005c2632f8 r16 : 4000 r17 : e7005c263338 r18 : r19 : 0009804c8a70433f r20 : 070062f4 r21 : a0010062f9d0 r22 : r23 : r24 : r25 : r26 : r27 : r28 : 5a41 r29 : r30 : r31 : e70079ab18dc Call Trace: [a001fd80] show_stack+0x80/0xa0 sp=e70062f478d0 bsp=e70062f41060 [a001000105e0] show_regs+0x7e0/0x800 sp=e70062f47aa0 bsp=e70062f41000 [a00100033f90] die+0x150/0x1c0 sp=e70062f47ab0 bsp=e70062f40fb8 [a00100052d50] ia64_do_page_fault+0x370/0x980 sp=e70062f47ab0 bsp=e70062f40f50 [a001b160] ia64_leave_kernel+0x0/0x260 sp=e70062f47b40 bsp=e70062f40f50 [a001001ce1e0] journal_commit_transaction+0x840/0x2700 sp=e70062f47d10 bsp=e70062f40e48 [a001001d5260] kjournald+0x180/0x4e0 sp=e70062f47d80 bsp=e70062f40dd8 [a00100011df0] kernel_thread_helper+0xd0/0x100 sp=e70062f47e30 bsp=e70062f40db0 [a00190e0] start_kernel_thread+0x20/0x40 sp=e70062f47e30 bsp=e70062f40db0 On Wed, 23 Mar 2005, Mark Wong wrote: I originally reported this to the linuxppc64-dev list, since I made it happen on a POWER system. I'm told this might be more generic... Anyone run into something like this? Mark - Forwarded message from Mark Wong [EMAIL PROTECTED] - Date: Wed, 23 Mar 2005 08:05:30 -0800 To: [EMAIL PROTECTED] From: Mark Wong [EMAIL PROTECTED] Subject: ext3 journalling BUG on full filesystem Hi, I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is causing the following problem when performing some journaling operation. Let me know if I can provide more details: cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] pc: c00a5fbc: .submit_bh+0x64/0x1fc lr: c00a62b4: .ll_rw_block+0x160/0x164 sp: c002e4f3f950 msr: 80029032 current = 0xc0038ff5c7c0 paca= 0xc0612000 pid = 1376, comm = kjournald kernel BUG in submit_bh at fs/buffer.c:2706! enter ? for help 6:mon t [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 [c002e4f3fab0] c0151ac4 .journal_commit_transaction+0xd88/0x16d4 [c002e4f3fe30] c0155590 .kjournald+0x114/0x308 [c002e4f3ff90] c0013ec0 .kernel_thread+0x4c/0x6c - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http
Re: ext3 journalling BUG on full filesystem
Hi, On Thu, 2005-03-24 at 10:39, Jan Kara wrote: Actually the patch you atached showed in the end as not covering all the cases and so Stephen agreed to stay with the first try (attached) which should cover all known cases (although it's not so nice). Right. The later patch is getting reworked into a proper locking overhaul for the journal_put_journal_head() code. The earlier one (that Jan attached) is the one that's appropriate in the mean time; it covers all of the holes we know about for sure and has proven robust in testing. --Stephen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
* Stephen C. Tweedie ([EMAIL PROTECTED]) wrote: Hi, On Thu, 2005-03-24 at 10:39, Jan Kara wrote: Actually the patch you atached showed in the end as not covering all the cases and so Stephen agreed to stay with the first try (attached) which should cover all known cases (although it's not so nice). Right. The later patch is getting reworked into a proper locking overhaul for the journal_put_journal_head() code. The earlier one (that Jan attached) is the one that's appropriate in the mean time; it covers all of the holes we know about for sure and has proven robust in testing. OK, good to know. When I last checked you were working on a higher risk yet more complete fix, and I thought we'd wait for that one to stabilize. Looks like the one Jan attached is the better -stable candidate? thanks, -chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
Hi, On Thu, 2005-03-24 at 19:38, Chris Wright wrote: OK, good to know. When I last checked you were working on a higher risk yet more complete fix, and I thought we'd wait for that one to stabilize. Looks like the one Jan attached is the better -stable candidate? Definitely; it's the one I gave akpm. The lock reworking is going to remove one layer of locks, so it's worthwhile from that point of view; but it's longer-term, and I don't know for sure of any paths to chaos with that simpler journal_unmap_buffer() fix in place. (It's just very hard to _prove_ all cases are correct without the locking rework.) --Stephen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
* Stephen C. Tweedie ([EMAIL PROTECTED]) wrote: On Thu, 2005-03-24 at 19:38, Chris Wright wrote: OK, good to know. When I last checked you were working on a higher risk yet more complete fix, and I thought we'd wait for that one to stabilize. Looks like the one Jan attached is the better -stable candidate? Definitely; it's the one I gave akpm. The lock reworking is going to remove one layer of locks, so it's worthwhile from that point of view; but it's longer-term, and I don't know for sure of any paths to chaos with that simpler journal_unmap_buffer() fix in place. (It's just very hard to _prove_ all cases are correct without the locking rework.) Great, I'll add to -stable queue. Thanks Stephen. -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
Hi Mark Looks like you need to apply the attached patch (for the current bk kernel or see the link below for an earlier version (which will require some modification to remove implicit warnings, see to extern and prototype declarations for __journal_temp_unlink_buffer in attached patch). Looking at Anton reply this may not be true but worth a try. Darren -- Stephen I am still seeing this Oops on ext3 journal with current bk tree, this patch: http://lkml.org/lkml/2005/3/8/147 fixes the problem though required changes to remove implicit declaration warnings updated patch attached. Unable to handle kernel NULL pointer dereference (address 0018) kjournald[16894]: Oops 8821862825984 [1] Pid: 16894, CPU 0, comm:kjournald psr : 101008026018 ifs : 8e21 ip : []Not tainted ip is at journal_commit_transaction+0x840/0x2700 unat: pfs : 0e21 rsc : 0003 rnat: bsps: pr : 1641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001001ce300 b6 : a00100633000 b7 : a001a9d0 f6 : 0fffbc8c0 f7 : 0ffea9877e000 f8 : 1000ff0f0 f9 : 10002a000 f10 : 1000cc0bffc303400 f11 : 1003e3030 r1 : a00100a8c830 r2 : 0286 r3 : r8 : 0001 r9 : e70062f40d50 r10 : e70062f40d60 r11 : r12 : e70062f47d10 r13 : e70062f4 r14 : e70062f47cb0 r15 : e7005c2632f8 r16 : 4000 r17 : e7005c263338 r18 : r19 : 0009804c8a70433f r20 : 070062f4 r21 : a0010062f9d0 r22 : r23 : r24 : r25 : r26 : r27 : r28 : 5a41 r29 : r30 : r31 : e70079ab18dc Call Trace: [] show_stack+0x80/0xa0 sp=e70062f478d0 bsp=e70062f41060 [] show_regs+0x7e0/0x800 sp=e70062f47aa0 bsp=e70062f41000 [] die+0x150/0x1c0 sp=e70062f47ab0 bsp=e70062f40fb8 [] ia64_do_page_fault+0x370/0x980 sp=e70062f47ab0 bsp=e70062f40f50 [] ia64_leave_kernel+0x0/0x260 sp=e70062f47b40 bsp=e70062f40f50 [] journal_commit_transaction+0x840/0x2700 sp=e70062f47d10 bsp=e70062f40e48 [] kjournald+0x180/0x4e0 sp=e70062f47d80 bsp=e70062f40dd8 [] kernel_thread_helper+0xd0/0x100 sp=e70062f47e30 bsp=e70062f40db0 [] start_kernel_thread+0x20/0x40 sp=e70062f47e30 bsp=e70062f40db0 > On Wed, 23 Mar 2005, Mark Wong wrote: > I originally reported this to the linuxppc64-dev list, since I made it > happen on a POWER system. I'm told this might be more generic... > > Anyone run into something like this? > > Mark > > - Forwarded message from Mark Wong <[EMAIL PROTECTED]> - > > Date: Wed, 23 Mar 2005 08:05:30 -0800 > To: [EMAIL PROTECTED] > From: Mark Wong <[EMAIL PROTECTED]> > Subject: ext3 journalling BUG on full filesystem > > Hi, > > I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is > causing the following problem when performing some journaling > operation. Let me know if I can provide more details: > > cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] > pc: c00a5fbc: .submit_bh+0x64/0x1fc > lr: c00a62b4: .ll_rw_block+0x160/0x164 > sp: c002e4f3f950 >msr: 80029032 > current = 0xc0038ff5c7c0 > paca= 0xc0612000 > pid = 1376, comm = kjournald > kernel BUG in submit_bh at fs/buffer.c:2706! > enter ? for help > 6:mon> t > [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 > [c002e4f3fab0] c0151ac4 .journal_commit_transaction+0xd88/0x16d4 > [c002e4f3fe30] c0155590 .kjournald+0x114/0x308 > [c002e4f3ff90] c0013ec0 .kernel_thread+0x4c/0x6c > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Darren Williams [EMAIL PROTECTED] -- Fix destruction of in-use journal_head journal_put_journal_head() can destroy a journal_head at any time as long as the jh's b_jcount is zero and b_transaction is NULL. It has no locking
Re: ext3 journalling BUG on full filesystem
Hi, > I originally reported this to the linuxppc64-dev list, since I made it > happen on a POWER system. I'm told this might be more generic... > > Anyone run into something like this? Just in case it got lost in the rest of the xmon output... We hit a BUG(): kernel BUG in submit_bh at fs/buffer.c:2706! Which looks like: BUG_ON(!buffer_mapped(bh)); Backtrace: ll_rw_block+0x160/0x164 journal_commit_transaction+0xd88/0x16d4 kjournald+0x114/0x308 kernel_thread+0x4c/0x6c Anton - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ext3 journalling BUG on full filesystem
I originally reported this to the linuxppc64-dev list, since I made it happen on a POWER system. I'm told this might be more generic... Anyone run into something like this? Mark - Forwarded message from Mark Wong <[EMAIL PROTECTED]> - Date: Wed, 23 Mar 2005 08:05:30 -0800 To: [EMAIL PROTECTED] From: Mark Wong <[EMAIL PROTECTED]> Subject: ext3 journalling BUG on full filesystem Hi, I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is causing the following problem when performing some journaling operation. Let me know if I can provide more details: cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] pc: c00a5fbc: .submit_bh+0x64/0x1fc lr: c00a62b4: .ll_rw_block+0x160/0x164 sp: c002e4f3f950 msr: 80029032 current = 0xc0038ff5c7c0 paca= 0xc0612000 pid = 1376, comm = kjournald kernel BUG in submit_bh at fs/buffer.c:2706! enter ? for help 6:mon> t [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 [c002e4f3fab0] c0151ac4 .journal_commit_transaction+0xd88/0x16d4 [c002e4f3fe30] c0155590 .kjournald+0x114/0x308 [c002e4f3ff90] c0013ec0 .kernel_thread+0x4c/0x6c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ext3 journalling BUG on full filesystem
I originally reported this to the linuxppc64-dev list, since I made it happen on a POWER system. I'm told this might be more generic... Anyone run into something like this? Mark - Forwarded message from Mark Wong [EMAIL PROTECTED] - Date: Wed, 23 Mar 2005 08:05:30 -0800 To: [EMAIL PROTECTED] From: Mark Wong [EMAIL PROTECTED] Subject: ext3 journalling BUG on full filesystem Hi, I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is causing the following problem when performing some journaling operation. Let me know if I can provide more details: cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] pc: c00a5fbc: .submit_bh+0x64/0x1fc lr: c00a62b4: .ll_rw_block+0x160/0x164 sp: c002e4f3f950 msr: 80029032 current = 0xc0038ff5c7c0 paca= 0xc0612000 pid = 1376, comm = kjournald kernel BUG in submit_bh at fs/buffer.c:2706! enter ? for help 6:mon t [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 [c002e4f3fab0] c0151ac4 .journal_commit_transaction+0xd88/0x16d4 [c002e4f3fe30] c0155590 .kjournald+0x114/0x308 [c002e4f3ff90] c0013ec0 .kernel_thread+0x4c/0x6c - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
Hi, I originally reported this to the linuxppc64-dev list, since I made it happen on a POWER system. I'm told this might be more generic... Anyone run into something like this? Just in case it got lost in the rest of the xmon output... We hit a BUG(): kernel BUG in submit_bh at fs/buffer.c:2706! Which looks like: BUG_ON(!buffer_mapped(bh)); Backtrace: ll_rw_block+0x160/0x164 journal_commit_transaction+0xd88/0x16d4 kjournald+0x114/0x308 kernel_thread+0x4c/0x6c Anton - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext3 journalling BUG on full filesystem
Hi Mark Looks like you need to apply the attached patch (for the current bk kernel or see the link below for an earlier version (which will require some modification to remove implicit warnings, see to extern and prototype declarations for __journal_temp_unlink_buffer in attached patch). Looking at Anton reply this may not be true but worth a try. Darren -- Stephen I am still seeing this Oops on ext3 journal with current bk tree, this patch: http://lkml.org/lkml/2005/3/8/147 fixes the problem though required changes to remove implicit declaration warnings updated patch attached. Unable to handle kernel NULL pointer dereference (address 0018) kjournald[16894]: Oops 8821862825984 [1] Pid: 16894, CPU 0, comm:kjournald psr : 101008026018 ifs : 8e21 ip : [a001001ce1e0]Not tainted ip is at journal_commit_transaction+0x840/0x2700 unat: pfs : 0e21 rsc : 0003 rnat: bsps: pr : 1641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001001ce300 b6 : a00100633000 b7 : a001a9d0 f6 : 0fffbc8c0 f7 : 0ffea9877e000 f8 : 1000ff0f0 f9 : 10002a000 f10 : 1000cc0bffc303400 f11 : 1003e3030 r1 : a00100a8c830 r2 : 0286 r3 : r8 : 0001 r9 : e70062f40d50 r10 : e70062f40d60 r11 : r12 : e70062f47d10 r13 : e70062f4 r14 : e70062f47cb0 r15 : e7005c2632f8 r16 : 4000 r17 : e7005c263338 r18 : r19 : 0009804c8a70433f r20 : 070062f4 r21 : a0010062f9d0 r22 : r23 : r24 : r25 : r26 : r27 : r28 : 5a41 r29 : r30 : r31 : e70079ab18dc Call Trace: [a001fd80] show_stack+0x80/0xa0 sp=e70062f478d0 bsp=e70062f41060 [a001000105e0] show_regs+0x7e0/0x800 sp=e70062f47aa0 bsp=e70062f41000 [a00100033f90] die+0x150/0x1c0 sp=e70062f47ab0 bsp=e70062f40fb8 [a00100052d50] ia64_do_page_fault+0x370/0x980 sp=e70062f47ab0 bsp=e70062f40f50 [a001b160] ia64_leave_kernel+0x0/0x260 sp=e70062f47b40 bsp=e70062f40f50 [a001001ce1e0] journal_commit_transaction+0x840/0x2700 sp=e70062f47d10 bsp=e70062f40e48 [a001001d5260] kjournald+0x180/0x4e0 sp=e70062f47d80 bsp=e70062f40dd8 [a00100011df0] kernel_thread_helper+0xd0/0x100 sp=e70062f47e30 bsp=e70062f40db0 [a00190e0] start_kernel_thread+0x20/0x40 sp=e70062f47e30 bsp=e70062f40db0 On Wed, 23 Mar 2005, Mark Wong wrote: I originally reported this to the linuxppc64-dev list, since I made it happen on a POWER system. I'm told this might be more generic... Anyone run into something like this? Mark - Forwarded message from Mark Wong [EMAIL PROTECTED] - Date: Wed, 23 Mar 2005 08:05:30 -0800 To: [EMAIL PROTECTED] From: Mark Wong [EMAIL PROTECTED] Subject: ext3 journalling BUG on full filesystem Hi, I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is causing the following problem when performing some journaling operation. Let me know if I can provide more details: cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] pc: c00a5fbc: .submit_bh+0x64/0x1fc lr: c00a62b4: .ll_rw_block+0x160/0x164 sp: c002e4f3f950 msr: 80029032 current = 0xc0038ff5c7c0 paca= 0xc0612000 pid = 1376, comm = kjournald kernel BUG in submit_bh at fs/buffer.c:2706! enter ? for help 6:mon t [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 [c002e4f3fab0] c0151ac4 .journal_commit_transaction+0xd88/0x16d4 [c002e4f3fe30] c0155590 .kjournald+0x114/0x308 [c002e4f3ff90] c0013ec0 .kernel_thread+0x4c/0x6c - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- Fix destruction of in-use journal_head journal_put_journal_head() can destroy a journal_head at any time as long as the jh's b_jcount is zero and b_transaction is NULL. It has
