Hi,
On Wed, Jun 05, 2002 at 03:07:16PM +0530, BALBIR SINGH wrote:
> 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.
Well, 2.4.7-10 and 2.4.18-4 both look like Red Hat kernel releases,
and those do _not_ have kdb installed.
> kmem_cache_alloc (offset 0x125)
> get_unused_buffer_head
> journal_write_metadata_buffer
> journal_commit_transaction
> kjournald
> kernel_thread
This is not an oops. It might be a kdb backtrace, though. Could you
post the actual oops? That contains much more information than I've
got here. However, the backtrace you showed is inside the VM, not in
ext3, so it doesn't appear to be necessarily an ext3 problem.
> 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())
Where in this sequence is the EIP that is failing? What are the
register contents?
> One more thing I have seen is a problem with the following code
>
> do {
> new_bh = get_unused_buffer_head(0);
> if (!new_bh) {
> printk (KERN_NOTICE __FUNCTION__
> ": ENOMEM at get_unused_buffer_head,
"
> "trying again.\n");
> current->policy |= SCHED_YIELD;
> schedule();
> }
>
> when get_unused_buffer_head fails, the call to printk would eventually
> want to flush the contents to /var/log/messages and if /var/log/messages
> happens to be on a journalled file system, well it kind of gets
> recursive.
No, the printk buffer will wrap (discarding data if necessary) if
klogd can't dump the information from it fast enough, so there's no
deadlock.
Cheers,
Stephen