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

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

On Sat, 25 Mar 2006 10:36:40 -0800 John Z. Bohach wrote:

> 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.

AFAIK the page fault is not expected, but I would be happier if someone else
confirmed that.

BTW, Documentation/kernel-parameters.txt suggests using mem= and memmap=
together, so maybe you could use memmap=.... to prevent this problem.

---
~Randy