Opened 12 years ago

Closed 9 years ago

#5737 closed bug (fixed)

Installer does not enable virtual memory by default?

Reported by: andreasf Owned by: kallisti5
Priority: normal Milestone: R1/beta1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: x86


The Installer from the hrev36100 nightly gcc4 hybrid image does not enable virtual memory by default. When building a haiku-image from source, this is different.

I think this should be looked into before Alpha 2 because with the default settings on a system with 1 GB RAM, at about 512 MB used the system starts doing funny stuff. Like Jam crashing during "Patience..." and the system offering to open the debugger but gdb unable to open and things hanging. Or jam failing with vfork: Out of memory.

Change History (9)

comment:1 by stippi, 12 years ago

First of all, the Installer has nothing to do with this. There are three things which can have an influence:

1) Swap support can be disabled at build time, via the kernel_debug_config.h file in build/config_headers or build/user_config_headers, the default of ENABLE_SWAP_SUPPORT is 1, so it has to be turned off deliberately, but I don't assume this is done on the Build-O-Matic machine.

2) src/system/kernel/vm/VMAnonymousCache.cpp reads the "virtual_memory" kernel settings file in swap_init_post_modules(). The file either exists or it does not exist. In the case that it does not exist, the system tries to allocate a swap file that is twice the ammount of physical memory. Which can of course easily fail if there is not enough room on the boot partition. This may actually be your situation, in case you installed Alpha 2 on a dedicated partition which is too small, or if you installed it on your regular partition, but Alpha 2 comes with more stuff and again the partition is too small.

3) If a user has run the VirtualMemory preflet, then the kernel settings file exists. By default, it turns virtual memory on ("vm on").

Can you please check which situation could apply in your case? I agree that running without swap space can have bad consequences on system behavior, so perhaps allocating a dynamic swap file in swap_init_post_modules() that only spans a certain percentage of the free space on the boot disk is a better idea then to fail completely. This would then be the proper fix for this ticket, in case it's really your situation, but it would deserve a fix in either case.

comment:2 by stippi, 12 years ago

Component: Applications/InstallerSystem/Kernel
Owner: changed from korli to axeld

comment:3 by andreasf, 12 years ago

Seen it again at hrev36573, with a custom-built anyboot CD.

1) does not apply, header is untouched.

2) There would've been enough space on the partitions (5 GB w/ 1 GB RAM, 4 GB w/ 128 MB). I did not specially add a settings file nor do I see one in Live CD mode.

3) I did not run the preflet.

That's why I considered it odd. :-)

comment:4 by modeenf, 11 years ago

In the latest build (hrev41280) I just enable swap with the VirtualMemory preflet for it an reboot. I don't think it should be enabled by default. I think you should enabled it if youu need it :)

comment:5 by scottmc, 11 years ago

Milestone: R1/alpha3R1/beta1

Please recheck this one. There were some changes to the virtual memory default settings during GCI IIRC.

comment:6 by leavengood, 11 years ago

Owner: changed from axeld to leavengood
Status: newassigned

I'll take a look at this since I have an interest in sorting out Virtual Memory problems.

comment:7 by SeanCollins, 9 years ago

I am fiarly sure commits 44611 through 44634 adressed this ticket. VM is now enabled during install and first boot. Can this ticket be closed ?

comment:8 by diver, 9 years ago

Owner: changed from leavengood to kallisti5

comment:9 by scottmc, 9 years ago

Resolution: fixed
Status: assignedclosed

appears to be fixed between hrev44611 and hrev44634.

Note: See TracTickets for help on using tickets.