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

[John Z. Bohach]

On Friday 24 March 2006 16:32, Randy.Dunlap wrote:
> > Here it is:
> >
> > fails with cmdline:
> >
> > Kernel command line: ro root=/dev/sda1 rootdelay=10 mem=0x200M
> > console=ttyS0,115200n8
> >
> > works with:
> >
> > Kernel command line: ro root=/dev/sda1 rootdelay=10
> > console=ttyS0,115200n8
> >
> > Note the "mem=" being the differentiator!
>
> OK, that is memory map difference.
>
> Can you test a more recent kernel to see if it has the same problem?
> (like 2.6.16 or 2.6.16-git9)

No luck, or difference, for that matter.  2.6.16 behaves identically.  I'm
trying a few different options, such as disabling MSI/MSI-X support,
because what I've seen is that it all works fine with it as long as the h/w
has MSI support, but in all the case I've seen fail, the common denominator
is no MSI (and also all ICH4 platforms).  The cases where I can't make it fail
is where the h/w has MSI support.  One other noteworthy difference is that the
failures all occur on Intel graphics chipsets, while the successes are non-graphics.
Still trying to find out whether the failure follows graphics or the ICH4.

Anyway, what would help me is if someone could tell me if the page fault is a normal and
expected code path by design, in order to page in the area setup by __vmalloc_area()
as triggered by the module_alloc() call.  I'd really rather not have to trace through the
page fault handler to identify the difference between success/failure unless I have to.

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