Re: [uml-devel] Kernel mode fault at addr 0x92c00000, ip 0x80bcead

[Christopher S. A. <ca...@th...>]

Blaisorblade wrote:
> Which is the cmd line? With how much memory where these instances started?

Kernel command line: mem=300M fake_ide fakehd con=null con0=fd:0,fd:1 
devfs=nomount root=/dev/ubda ubda=<snip> 7 ubdb=<snip> 
eth0=tuntap,encode1_0,fe:fd:46:55:81:95 token_max=400000 token_refill=512

> Ok, Jeff, I recall something but I'm not sure. I even thought kernel threads 
> mapped the whole RAM at boot in their physical range part (which is their 
> entire address space), but it does not seem so.
> 
> The host is just a 64G with 3G/1G split, however the UML is a TT+SKAS with 
> HALF_GIGS=2 (which _is_ unusual, and could be replaced with disabling TT 

Jeff had this discussion with me a few weeks ago when I was trying to 
get UML to use more than ~550M.

At that time, I tried disabling TT mode but had to revert because non-TT 
mode enabled umls wouldn't boot on some very old skas hosts of mine.  I 
suspected that you might point in the same direction he did.  That 
problem is less important since I should really just upgrade those boxes...

> entirely, which gives a free 2,75G of memory space for UML). In fact, the UML 
> binary starts at 0x8000 0000 (i.e. 2G), and there are various holes in the 
> virtual RAM mapped in kernel side - a big part of about 30M (the 
> 0x80607000-0x92c00000 range), then there is a 4M hole (the pre-vmalloc hole 
> should be 8M, but we have a 4M hole for uml_reserved after current brk()), 
> then various holes and allocated ranges (with varying offsets) here and 
> there, like if the area were allocated for vmalloc(). The problem is that we 
> have an allocated anonymous memory range (which the checksum is accessing) 
> before the 4M hole!
> 
> 80000000-80514000 rwxp 00000000 fd:00 540678     /vbin/kernel/2.6.18-linode25
> 80514000-80607000 rwxp 80514000 00:00 0          [heap]
> 80607000-92c00000 rwxs 00607000 00:16
> 	738427     /linodes/encode1/tmp/vm_file-AVT0fb (deleted)
> <hole here>
> 93000000-9300b000 rwxs 006b6000 00:16
> 	738427     /linodes/encode1/tmp/vm_file-AVT0fb (deleted)
> 9300c000-93017000 rwxs 006c2000 00:16
> 	738427     /linodes/encode1/tmp/vm_file-AVT0fb (deleted)
> 
> I can't follow this code at the moment, so I go for now.
> Bye!

-Chris