Re: Boot time memory issue
SMAP type=01 base= len= 0009f800 SMAP type=02 base= 0009f800 len= 0800 SMAP type=02 base= 000e8400 len= 00017c00 SMAP type=01 base= 0010 len= 13ef SMAP type=03 base= 13ff len= f800 SMAP type=04 base= 13fff800 len= 0800 SMAP type=02 base= fff8 len= 0008 Too many holes in the physical address space, giving up Can you try changing the declaration of phys_avail at the top of sys/i386/i386/machdep.c from: vm_offset_t phys_avail[10]; to vm_offset_t phys_avail[100]; Did that and got the same error. I put a printf just before the pa_indx++ in machdep.c and watched it increment by 2's all the way up to 100. How many SMAP lines did it print? All the ones above look legitimate, and there are only 7 of them. What about the values of pa, i and physmap_idx? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot time memory issue
Sat, May 26, 2001 at 22:03:34, barry (Barry Lustig) wrote about Re: Boot time memory issue: SMAP type=01 base= 0010 len= 13ef [...] Did that and got the same error. I put a printf just before the pa_indx++ in machdep.c and watched it increment by 2's all the way up to 100. Any other ideas? This code in machdep.c performs easy memory test for each page and adds it to previous chunk or creates new one. The idea AFAIU is to test declared memory regions for real ones. If you have 100 really different regions in declared two memory regions, something bad happened with your hardware: memory modules are broken, or chipset incorrectly detects them, or yet another problem... You can test its logic by adding following patch or similar one: --- machdep.c.orig Sun May 27 11:12:19 2001 +++ machdep.c Sun May 27 11:13:57 2001 @@ -1785,10 +1785,12 @@ printf(Too many holes in the physical address space, giving up\n); pa_indx--; break; } phys_avail[pa_indx++] = pa; /* start */ + printf( getmemsize: new chunk at %08lx\n, + (unsigned long) pa ); phys_avail[pa_indx] = pa + PAGE_SIZE; /* end */ } physmem++; } } /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot time memory issue
Valentin Nechayev wrote: Sun, May 20, 2001 at 19:53:29, barry (Barry Lustig) wrote about Boot time memory issue: Do verbose boot (`boot -v') with large SC_HISTORY_SIZE (1000 at least, 2000 at most), and after boot check for SMAP ... lines at the very beginning of the kernel boot log at /dev/console. (They are not written to log viewable with dmesg.) Another way is to use serial console. With this SMAP lines one can say more concrete diagnosis. Here are the SMAP lines: SMAP type=01 base= len= 0009f800 SMAP type=02 base= 0009f800 len= 0800 SMAP type=02 base= 000e8400 len= 00017c00 SMAP type=01 base= 0010 len= 13ef SMAP type=03 base= 13ff len= f800 SMAP type=04 base= 13fff800 len= 0800 SMAP type=02 base= fff8 len= 0008 Too many holes in the physical address space, giving up I was curious whether the memory limitation on the Sony VAIO Z505 machines was an actual hardware limitation or a marketing issue. I just tried adding a 256MB module to my machine. The BIOS seemed to mostly recognize it. It did see 320MB of RAM, but had problems when testing all of it. Current (from a couple of weeks ago) boots, but gives me: Too many holes in the physical address space, giving up and comes up showing 64MB of RAM. Is this something that can be worked around, or have I run up against an actual hardware limit on the machine? /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot time memory issue
Mike Smith wrote: Here are the SMAP lines: SMAP type=01 base= len= 0009f800 SMAP type=02 base= 0009f800 len= 0800 SMAP type=02 base= 000e8400 len= 00017c00 SMAP type=01 base= 0010 len= 13ef SMAP type=03 base= 13ff len= f800 SMAP type=04 base= 13fff800 len= 0800 SMAP type=02 base= fff8 len= 0008 Too many holes in the physical address space, giving up Can you try changing the declaration of phys_avail at the top of sys/i386/i386/machdep.c from: vm_offset_t phys_avail[10]; to vm_offset_t phys_avail[100]; Did that and got the same error. I put a printf just before the pa_indx++ in machdep.c and watched it increment by 2's all the way up to 100. Any other ideas? barry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Boot time memory issue
Sun, May 20, 2001 at 19:53:29, barry (Barry Lustig) wrote about Boot time memory issue: Do verbose boot (`boot -v') with large SC_HISTORY_SIZE (1000 at least, 2000 at most), and after boot check for SMAP ... lines at the very beginning of the kernel boot log at /dev/console. (They are not written to log viewable with dmesg.) Another way is to use serial console. With this SMAP lines one can say more concrete diagnosis. I was curious whether the memory limitation on the Sony VAIO Z505 machines was an actual hardware limitation or a marketing issue. I just tried adding a 256MB module to my machine. The BIOS seemed to mostly recognize it. It did see 320MB of RAM, but had problems when testing all of it. Current (from a couple of weeks ago) boots, but gives me: Too many holes in the physical address space, giving up and comes up showing 64MB of RAM. Is this something that can be worked around, or have I run up against an actual hardware limit on the machine? /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
