[lkml]   [2006]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: mem= causes oops (was Re: BIOS causes (exposes?) modprobe (load_module) kernel oops)
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-25 19:39    [W:0.041 / U:0.908 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site