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

["John Z. Bohach" <jzb@aexorsyst.com>]

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.