LHC@home

Keep getting the above issue.

Using Oracle Virtual Manager v5.2.6 r120293 and BOINC Manager v.7.8.3 wxWidgets 3.0.1

dicksog

One task restarted with CPU usage zero, so I aborted it.
Tullio

Keep getting the above issue.

Using Oracle Virtual Manager v5.2.6 r120293 and BOINC Manager v.7.8.3 wxWidgets 3.0.1

dicksog

Suspend all tasks, restart BOINC client (not only BOINC Manager) and resume 1 single ATLAS-task and see whether that will run.

I just upgraded from 5.1.30 to 5.2.6 and see the same it was working well before so i can't recommend 5.2.6 for reliable operation.

I will give it another 24hr to see if it's just a kink but will downgrade if I don't see improvements.

I ran a few about a week ago with 5.2.6 and had no problems.

I guess it is not caused by a specific VirtualBox version.

A few weeks ago I noticed the same error.
It was most likely caused when my BOINC client hit the max RAM setting and as a follow up the max swap setting.
I could solve the issue by tuning the RAM and swap settings in the client configuration and the OS, RAM as high as possible, swap nearly switched off via swappiness=0.

A disadvantage of this tuning is, that it is now necessary to keep an eye on the overall RAM usage (not only BOINC).

BTW: VirtualBox 5.2.6 (linux) runs without obvious issues.

Maybe on Windows its different?

I have 128GB of RAM, with the setting of allow up to 98%, the swap settings are 50% at most, but I don't expect to use any swap with 128GB. I see in task manager that I still have 45GB of un-used memory and 65GB in standby.

I didn't see this issue often with the older version of VirtualBox, hence my comment.

Maybe on Windows its different?

I have 128GB of RAM, with the setting of allow up to 98%, the swap settings are 50% at most, but I don't expect to use any swap with 128GB. I see in task manager that I still have 45GB of un-used memory and 65GB in standby.

I didn't see this issue often with the older version of VirtualBox, hence my comment.

Well, it occured while I did some test and I didn't expect to force THIS error.
But I could verify it. And yes, it may be different on windows or with different vbox versions.

Atlas uses an older version of vboxwrapper that doesn't support VirtualBox 5.2 though VirtualBox COM API. So vboxwrapper falls back to using VBoxManage. But this old version doesn't work correctly with VBoxManage either.

Solution: If you are on Windows and want to run Atlas, stick to VirtualBox 5.1.

Intresting different errors on different OS's?!

I went back to 5.1 seems back to normal, I assume we have to wait for the project to move up to new wrapper.

ALL of my 9 running computers are Windows 10 and 7 and running the newest versions of Boinc and VB

(and yes I also still have the XP Pro *T4T legend* able to run those X86 Sixtracks........of course not these)

---

Volunteer Mad Scientist For Life

A few weeks ago I noticed the same error.
It was most likely caused when my BOINC client hit the max RAM setting and as a follow up the max swap setting.
I could solve the issue by tuning the RAM and swap settings in the client configuration and the OS, RAM as high as possible, swap nearly switched off via swappiness=0.

I think that is probably it. I just got that error on LHCb, and could not download any more work units until I rebooted. But in the last couple of weeks I have had work units suspend themselves with a "low memory" warning, and I increased the amount of memory as much as I could using BOINC settings. That fixed it for a while. But when you get the wrong mix of jobs running, it may not be enough. I am now reducing the amount of RAM that I devote to a write cache, and that may fix it.

PS - I just ordered 32 GB more memory. That is the real fix.

After upgrading all PC for Boinc 7.10.2 and Virtualbox 5.2.8:
PC AMD A8 with 24 GByte (DDR3) RAM show this message (Win10pro) now since them.
When closing Boinc and deleting Boinc System Tray-process, the message come back after a while.
After a time up to one hour for Atlas this message is seen.

Will go back to 5.1.x for this PC to see if this help.

All other PC run in this constellation, BUT with allways 32 GByte (DDR3 or DDR4) RAM.

After a time up to one hour for Atlas this message is seen.

You could lengthen BOINC-Switch-Timing to 4 hours or more.

---

Supporting BOINC, a great concept !

Swirch-timing is 7500.
With 5.1.32 it was running the last months.

Virtualbox 5.1.x is not longer supported from Oracle.... :-(

Is it just the ATLAS project that runs into this? I've removed that project from the list, but am a little wary now of allowing new tasks for the whole bucket project.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

No reply, close to dropping the project completely now.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

The project is running fine at the moment.
Except some download/upload problems regarding ATLAS last week, but it seems they are solved.
Just try to get fresh work.

The reason I suspended the project was because I hit the "Postponed: VM job unmanageable, restarting later." problem, not uploads and downloads which can generally be ignored as they sort themselves out. I have allowed new tasks, (with ATLAS disabled), but if I see any more like that from the other sub projects, I'll dump the project.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.