Re: BIOS causes (exposes?) modprobe (load_module) kernel oops

["Randy.Dunlap" <rdunlap@xenotime.net>]

On Wed, 22 Mar 2006 21:26:56 -0800 John Z. Bohach wrote:

> On Wednesday 22 March 2006 19:48, John Z. Bohach wrote:
> > On Wednesday 22 March 2006 01:06, Arjan van de Ven wrote:
> > > On Tue, 2006-03-21 at 20:05 -0800, John Z. Bohach wrote:
> > > > Linux 2.6.14.2, yeah, I know, and sorry if this has been fixed...but
> > > > read on, please, this is a new take...
> > >
> > > at least enable CONFIG_KALLSYMS to get us a readable backtrace
> >
> > I'll do you one better:  here's the failing line from module.c:
> >
> > 	/* Determine total sizes, and put offsets in sh_entsize.  For now
> > 	   this is done generically; there doesn't appear to be any
> > 	   special cases for the architectures. */
> > 	layout_sections(mod, hdr, sechdrs, secstrings);
> >
> > 	/* Do the allocs. */
> > 	ptr = module_alloc(mod->core_size);
> > 	if (!ptr) {
> > 		err = -ENOMEM;
> > 		goto free_percpu;
> > 	}
> > !!! --->	memset(ptr, 0, mod->core_size);
> > 	mod->module_core = ptr;
> >
> 
> Let me summarize this a little better:
> 
> ptr = module_alloc(mod->core_size);
> 
> is fine, but when a few lines later, memset() tries to operate on that same
> ptr to zero it out with
> 
> memset(ptr, 0, mod->core_size);
> 
> I get:
> 
> Unable to handle kernel paging request at virtual address f8806000
> (f8806000 is (in this case) the value of ptr returned by module_alloc()).
> 
> I've validated the parameters, they all look okay.  I think the page fault for ptr
> is normal(?), and the page fault handler is suppossed to set up this page???
> but fails...
> 
> Yet it succeeds with a different BIOS and bootloader, is what I'm trying to say.
> 
> So it seems that the page fault handler is somehow affected by something that the
> BIOS has/has not done, long after the system has booted and been running, with
> many page faults under its belt...now I've seen it all...or not.

Sounds like we need to see complete boot logs from both BIOSen boots.
Can you do that?

I'm just guessing that the memory maps are different, but who knows.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/