Re: [boinc_dev] Typo in computer detail, but only at E@H

[Jord van der Elst]

It's not a very recent problem, and it can even be worse: 'Stepnnng9'.
Various BOINC projects shows it happened on hosts with last contacts as far
back as 2013.

http://primaboinca.com/top_hosts.php?sort_by=expavg_credit=880
http://boinc.med.usherbrooke.ca/nrg/hosts_user.php?sort=os=1_all=1=1209
http://boinc.gorlaeus.net/hosts_user.php?userid=14492_all=1=id
http://www.outlawz.co.uk/Boinc/Project/26/Hosts/4/Name
http://burp.renderfarming.net/top_hosts.php?sort_by=total_credit=2520


-- Jord van der Elst.

On Fri, Oct 16, 2015 at 7:36 PM, David Anderson 
wrote:

> That string comes from the client;
> I'm not sure why E@h would show it incorrectly.
> -- David
>
> On 10/16/2015 6:27 AM, TarotApprentice wrote:
>
>> On Einstein I have a bunch of computers that show as:
>>
>>
>> GenuineIntel
>>   Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz [Family 6 Model 58
>> Stepinng9]](8 processors)
>>
>> Seti displays as:
>> GenuineIntel
>> Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz [Family 6 Model 58 Stepping 9]
>> (8 processors)
>> On Seti and GPUgrid they show "Stepping" correctly. I did ask Bernd about
>> it but he's not aware where it builds the string. I haven't checked CPDN as
>> they seem to down at the moment. Seeing as they display correctly on other
>> projects I presume its in the server software if someone could point out
>> where. Its cosmetic I know and not worth any effort but I thought I would
>> mention it.
>> MarkJ
>> ___
>> boinc_dev mailing list
>> boinc_dev@ssl.berkeley.edu
>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>> To unsubscribe, visit the above URL and
>> (near bottom of page) enter your email address.
>>
>
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] vbox64 and virtualization

[Marius Millea]

Thanks for the explanation Rom, thats helpful. However I'm using VBox
4.3.30 and vboxwrapper 26175 so I don't think that's it. I'm attaching my
vbox.log, there's some errors in there about VT-x but searching
for ERR_CPU_VM_EXTENSIONS_DISABLED yields nothing.

Marius


On Fri, Oct 16, 2015 at 1:55 AM, Rom Walton  wrote:

> What is supposed to happen is:
>
> When the VM shuts down, vboxwrapper parses the end of vbox.log looking for
> the possible error codes related to the VM extensions being disabled.  If
> found, it then writes the following to stderr
> 'ERR_CPU_VM_EXTENSIONS_DISABLED'.
>
> BOINC parses the stderr text when the app exits, if it detects the above
> text it sets a flag that says the VM extensions have been disabled on the
> machine.  In the sched_request file it is named .
>
> I recently updated vboxwrapper to support the newer error codes returned
> in VirtualBox 5.0:
>
> https://github.com/BOINC/boinc/commit/0ee90d7995118ff5fd00c68af734050172f7733a
>
> That commit should be in 26173 or above.
>
> - Rom
>
> List of VirtualBox error codes is in vbox_common.cpp:320-338
>
> What is written to stderr is in vboxwrapper.cpp:774-784
>
> -Original Message-
> From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of
> Marius Millea
> Sent: Thursday, October 15, 2015 7:31 PM
> To: BOINC-dev email list 
> Subject: [boinc_dev] vbox64 and virtualization
>
> Hi all,
>
> Virtualbox can't run a 64bit guest OS unless you have virtualization (VT-x
> or AMD-v or whatever it might be called...) enabled in your BIOS. Hence no
> app which is plan class vbox64 should be sent to a host which does not have
> this enabled. Unfortunately I'm not seeing either happen. First, I turned
> off VT-x on my machine, rebooted and readded the project, and I'm still
> receiving vbox64 jobs. Should this be happening or is this a feature which
> does not exist yet?
>
> Secondly, it seems like vboxwrapper ought to catch this and shut down with
> some informative error message. From the source it looks like it does have
> some code which attempts to catch this, but at least on my system it
> doesn't seem to work. It gets stuck saying "Status Report:
> virtualbox/vboxheadless is no longer running." for a while, then gives me
> "Waiting to run (VM Hypervisor failed to enter an online state in a timely
> fashion)". Any ideas what's going on?
>
> Thanks,
>
> Marius
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
VirtualBox VM 4.3.30 r101610 linux.amd64 (Jul 10 2015 12:58:13) release log
00:00:00.034078 Log opened 2015-10-15T23:11:01.126818000Z
00:00:00.034079 Build Type: release
00:00:00.034081 OS Product: Linux
00:00:00.034082 OS Release: 3.13.0-65-generic
00:00:00.034083 OS Version: #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015
00:00:00.034103 DMI Product Name: 2342CTO
00:00:00.034109 DMI Product Version: ThinkPad T430
00:00:00.034169 Host RAM: 7686MB total, 5244MB available
00:00:00.034172 Executable: /usr/lib/virtualbox/VBoxHeadless
00:00:00.034172 Process ID: 12436
00:00:00.034173 Package type: LINUX_64BITS_UBUNTU_13_04
00:00:00.044921 Installed Extension Packs:
00:00:00.048370   Oracle VM VirtualBox Extension Pack (Version: 4.3.30 r101610; VRDE Module: VBoxVRDP)
00:00:00.051999 SUP: Loaded VMMR0.r0 (/usr/lib/virtualbox/VMMR0.r0) at 0xa07cd020 - ModuleInit at a07eb570 and ModuleTerm at a07eb800
00:00:00.052021 SUP: VMMR0EntryEx located at a07ecbe0, VMMR0EntryFast at a07ec820 and VMMR0EntryInt at a07ec810
00:00:00.053001 Guest OS type: 'Linux26_64'
00:00:00.055456 WARNING! 64-bit guest type selected but the host CPU does NOT support HW virtualization.
00:00:00.055536 fHMForced=true - SMP
00:00:00.059975 File system of '/var/lib/boinc-client/slots/1/vm_isocontext.iso' (DVD) is ext4
00:00:00.061477 File system of '/usr/share/virtualbox/VBoxGuestAdditions.iso' (DVD) is ext4
00:00:00.068500 Shared clipboard mode: Off
00:00:00.068946 Drag'n'drop mode: Off
00:00:00.071025 * CFGM dump *
00:00:00.071028 [/] (level 0)
00:00:00.071035   CSAMEnabled= 0x0001 (1)
00:00:00.071040   CpuExecutionCap= 0x0064 (100)
00:00:00.071041   EnablePAE  = 0x0001 (1)
00:00:00.071042   HMEnabled  = 0x0001 (1)
00:00:00.071042   MemBalloonSize = 0x (0)
00:00:00.071043   Name= "boinc_08cf100ffb36acff" (cb=23)
00:00:00.071044   NumCPUs= 0x0004 (4)
00:00:00.071045   PATMEnabled= 0x0001 (1)
00:00:00.071045   PageFusionAllowed  = 0x (0)
00:00:00.071046   RamHoleSize= 0x2000 (536 870 912, 512 MB)

Re: [boinc_dev] vbox64 and virtualization

[Christian Beer]

On 10/16/2015 11:16 AM, Marius Millea wrote:
> However I'm using VBox
> 4.3.30 and vboxwrapper 26175 so I don't think that's it. I'm attaching my
> vbox.log, there's some errors in there about VT-x but searching
> for ERR_CPU_VM_EXTENSIONS_DISABLED yields nothing.
The vbox.log contains VERR_VMX_MSR_VMXON_DISABLED at the end. Which is
the VirtualBox errorcode to say you have a 64bit Guest but Hardware
Virtualization is not enabled (it says so in the begining of the log
too). This gets picked up by vboxwrapper and
ERR_CPU_VM_EXTENSIONS_DISABLED gets output to stderr.txt in the slot
directory which gets reported back to the server as part of the
sched_request file. The stderr.txt shoud be visible as part of the
failed task once it is reported.

You should change the plan_class vbox64 to include the
 tag. This is the plan_class I use at RNA World:
> 
> vbox64
> 
> 
> 70224
> 40010
> 
> 
This will not send a 64bit VM to a host that has no Hardware
Virtualization enabled. This should really be the default as VirtualBox
doesn't allow a 64bit guest without the HW Virtualization enabled.

Regards
Christian
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] vbox64 and virtualization

[Marius Millea]

Thanks Christian, I added that option but same result.

Its clear to me now that vboxwrapper is missing the fact that the VM
doesn't start correctly. If you look at the attached stderr.txt, if says
"Successfully started VM." Hence it never makes it to the part in the code
that checks vbox.log for "VERR_VMX_MSR_VMXON_DISABLED" and hence never
prints "ERR_CPU_VM_EXTENSIONS_DISABLED".

I'm looking into why, any ideas? Otherwise yea it looks like the code to do
exactly what you guys describe is there.

Marius


On Fri, Oct 16, 2015 at 11:42 AM, Christian Beer 
wrote:

> On 10/16/2015 11:16 AM, Marius Millea wrote:
> > However I'm using VBox
> > 4.3.30 and vboxwrapper 26175 so I don't think that's it. I'm attaching my
> > vbox.log, there's some errors in there about VT-x but searching
> > for ERR_CPU_VM_EXTENSIONS_DISABLED yields nothing.
> The vbox.log contains VERR_VMX_MSR_VMXON_DISABLED at the end. Which is
> the VirtualBox errorcode to say you have a 64bit Guest but Hardware
> Virtualization is not enabled (it says so in the begining of the log
> too). This gets picked up by vboxwrapper and
> ERR_CPU_VM_EXTENSIONS_DISABLED gets output to stderr.txt in the slot
> directory which gets reported back to the server as part of the
> sched_request file. The stderr.txt shoud be visible as part of the
> failed task once it is reported.
>
> You should change the plan_class vbox64 to include the
>  tag. This is the plan_class I use at RNA World:
> > 
> > vbox64
> > 
> > 
> > 70224
> > 40010
> > 
> > 
> This will not send a 64bit VM to a host that has no Hardware
> Virtualization enabled. This should really be the default as VirtualBox
> doesn't allow a 64bit guest without the HW Virtualization enabled.
>
> Regards
> Christian
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
2015-10-16 12:59:25 (31557): vboxwrapper (7.7.26175): starting
2015-10-16 12:59:25 (31557): Feature: Checkpoint interval offset (239 seconds)
2015-10-16 12:59:25 (31557): Detected: VirtualBox VboxManage Interface 
(Version: 4.3.30)
2015-10-16 12:59:25 (31557): Detected: Minimum checkpoint interval (600.00 
seconds)
2015-10-16 12:59:25 (31557): Create VM. (boinc_6053e2c6604d57b1, slot#0)
2015-10-16 12:59:25 (31557): Updating drive controller type and model for 
desired configuration.
2015-10-16 12:59:26 (31557): Setting Memory Size for VM. (2048MB)
2015-10-16 12:59:26 (31557): Setting CPU Count for VM. (4)
2015-10-16 12:59:26 (31557): Setting Chipset Options for VM.
2015-10-16 12:59:26 (31557): Setting Boot Options for VM.
2015-10-16 12:59:26 (31557): Setting Network Configuration for NAT.
2015-10-16 12:59:26 (31557): Enabling VM Network Access.
2015-10-16 12:59:26 (31557): Disabling USB Support for VM.
2015-10-16 12:59:26 (31557): Disabling COM Port Support for VM.
2015-10-16 12:59:26 (31557): Disabling LPT Port Support for VM.
2015-10-16 12:59:26 (31557): Disabling Audio Support for VM.
2015-10-16 12:59:26 (31557): Disabling Clipboard Support for VM.
2015-10-16 12:59:26 (31557): Disabling Drag and Drop Support for VM.
2015-10-16 12:59:27 (31557): Adding storage controller(s) to VM.
2015-10-16 12:59:27 (31557): Adding virtual ISO 9660 disk drive to VM. 
(vm_isocontext.iso)
2015-10-16 12:59:27 (31557): Adding VirtualBox Guest Additions to VM.
2015-10-16 12:59:27 (31557): Adding network bandwidth throttle group to VM. 
(Defaulting to 1024GB)
2015-10-16 12:59:27 (31557): Enabling shared directory for VM.
2015-10-16 12:59:27 (31557): Enabling scratch shared directory for VM.
2015-10-16 12:59:27 (31557): Starting VM. (boinc_6053e2c6604d57b1, slot#0)
2015-10-16 12:59:29 (31557): Successfully started VM. (PID = '31929')
2015-10-16 12:59:29 (31557): Reporting VM Process ID to BOINC.
2015-10-16 12:59:29 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:30 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:31 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:32 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:33 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:34 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:35 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:36 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:37 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:38 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.
2015-10-16 12:59:39 (31557): Status Report: virtualbox/vboxheadless is no 
longer running.

Re: [boinc_dev] Fwd: New Defects reported by Coverity Scan for BOINC/boinc

[McLeod, John]

Coverity is a tool that uncovers security problems. You should investigate each 
one, and most of them will need a fix.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-Original Message-
From: David Anderson [da...@ssl.berkeley.edu]
Received: Tuesday, 13 Oct 2015, 6:49PM
To: Rom Walton [rwal...@ssl.berkeley.edu]; Charlie Fenton 
[charl...@ssl.berkeley.edu]; BOINC Developers Mailing List 
[boinc_dev@ssl.berkeley.edu]
Subject: [boinc_dev] Fwd: New Defects reported by Coverity Scan for BOINC/boinc

FYI.  I'm not sure how to fix these, or if they matter.
-- David


 Forwarded Message 
Subject: New Defects reported by Coverity Scan for BOINC/boinc
Date:Tue, 13 Oct 2015 13:45:52 -0700
From:scan-ad...@coverity.com
To:  da...@ssl.berkeley.edu



Hi,

Please find the latest report on new defect(s) introduced to BOINC/boinc found 
with Coverity Scan.

13 new defect(s) introduced to BOINC/boinc found with Coverity Scan.
14 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 13 of 13 defect(s)


** CID 117641:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgAdvPreferences.cpp: 105 in 
CDlgAdvPreferences::CDlgAdvPreferences(wxWindow *)()



*** CID 117641:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgAdvPreferences.cpp: 105 in 
CDlgAdvPreferences::CDlgAdvPreferences(wxWindow *)()
99 SetSpecialTooltips();
100 //setting the validators for correct input handling
101 SetValidators();
102 //read in settings and initialize controls
103 ReadPreferenceSettings();
104
>>> CID 117641:  Uninitialized members  (UNINIT_CTOR)
>>> Non-static class member "lastErrorCtrl" is not initialized in this 
>>> constructor nor in any functions that it calls.
105 if (! m_bOKToShow) return;
106
107 // Get default preference values
108 defaultPrefs.enabled_defaults();
109 //
110 RestoreState();

** CID 117640:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgEventLogListCtrl.cpp: 42 in 
MyEvtLogEvtHandler::MyEvtLogEvtHandler()()



*** CID 117640:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgEventLogListCtrl.cpp: 42 in 
MyEvtLogEvtHandler::MyEvtLogEvtHandler()()
36 IMPLEMENT_DYNAMIC_CLASS(MyEvtLogEvtHandler, wxEvtHandler)
37
38 BEGIN_EVENT_TABLE(MyEvtLogEvtHandler, wxEvtHandler)
39 EVT_PAINT(MyEvtLogEvtHandler::OnPaint)
40 END_EVENT_TABLE()
41
>>> CID 117640:  Uninitialized members  (UNINIT_CTOR)
>>> Non-static class member "m_view_startX" is not initialized in this 
>>> constructor nor in any functions that it calls.
42 MyEvtLogEvtHandler::MyEvtLogEvtHandler() {}
43
44 MyEvtLogEvtHandler::MyEvtLogEvtHandler(wxGenericListCtrl 
*theListControl) {
45 m_listCtrl = theListControl;
46 m_view_startX = 0;
47 }

** CID 117639:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgEventLogListCtrl.cpp: 97 in 
CDlgEventLogListCtrl::CDlgEventLogListCtrl(CDlgEventLog *, int, int)()



*** CID 117639:  Uninitialized members  (UNINIT_CTOR)
/clientgui/DlgEventLogListCtrl.cpp: 97 in 
CDlgEventLogListCtrl::CDlgEventLogListCtrl(CDlgEventLog *, int, int)()
91
92 #ifdef __WXMAC__
93 m_fauxHeaderView = NULL;
94 m_fauxBodyView = NULL;
95 SetupMacAccessibilitySupport();
96 #endif
>>> CID 117639:  Uninitialized members  (UNINIT_CTOR)
>>> Non-static class member "savedHandler" is not initialized in this 
>>> constructor nor in any functions that it calls.
97 }
98
99
100 #ifdef __WXMAC__
101 CDlgEventLogListCtrl::~CDlgEventLogListCtrl()
102 {

** CID 117638:  Uninitialized members  (UNINIT_CTOR)
/clientgui/sg_CustomControls.cpp: 142 in 
CTransparentHyperlinkCtrl::CTransparentHyperlinkCtrl()()



*** CID 117638:  Uninitialized members  (UNINIT_CTOR)
/clientgui/sg_CustomControls.cpp: 142 in 
CTransparentHyperlinkCtrl::CTransparentHyperlinkCtrl()()
136 BEGIN_EVENT_TABLE(CTransparentHyperlinkCtrl, wxHyperlinkCtrl)
137 EVT_ERASE_BACKGROUND(CTransparentHyperlinkCtrl::OnEraseBackground)
138 EVT_PAINT(CTransparentHyperlinkCtrl::OnPaint)
139 END_EVENT_TABLE()
140 #endif
141
>>> CID 117638:  Uninitialized members  (UNINIT_CTOR)
>>> Non-static class member "m_pParentsBgBmp" is not initialized in this 
>>> constructor nor in any functions that it calls.
142 CTransparentHyperlinkCtrl::CTransparentHyperlinkCtrl() {}
143
144 

Re: [boinc_dev] vbox64 and virtualization

[Marius Millea]

On Fri, Oct 16, 2015 at 2:23 PM, Marius Millea  wrote:

> Here's the relevant lines from the scheduler log, vmx is there, and its
> present in /proc/cpuinfo as well.
>
> 2015-10-16 12:12:34.6279 [PID=66   ][send] CPU features: fpu vme de
> pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts
> acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc
> arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf
> eagerfpu pni pclmulqdq dtes64 monitor ds_cpl *vmx* smx est tm2 ssse3 cx16
> xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx
> f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi
> flexpriority ept vpid fsgsbase smep erms
> 2015-10-16 12:12:34.6596 [PID=66   ][send] Sending app_version
> camb_boinc2docker 4 5 vbox64_mt; projected 14.64 GFLOPS
>
> Reading eg here
> 
> or here
> 
>  it
> seems vmx appearing there just means your CPU supports it, not that it is
> actually enabled. Clearly in my case its disabled yet still shows up.
>
> So I suppose the questions are now,
>
> 1) is there a way BOINC can check if vmx is actually enabled?
>

There's two things I could find (keeping in mind this whole discussion is
Linux, someone should check how it plays out on Win/Mac).

* "dmesg | grep kvm" will show the line "kvm: disabled by bios" if
VT-x/AMD-v is disabled
* "sudo kvm-ok" will tell you also, but this requires sudo and installing a
package, so likely not an option.

Its beyond me to incorporate usage of this into the BOINC client, but I'll
leave it here as reference. I think it'd be something good to have.





> 2) whats going on with vboxwrapper
>
> Marius
>
>
>
> On Fri, Oct 16, 2015 at 2:01 PM, Christian Beer  > wrote:
>
>> Did you restart the server processes just to make sure? The scheduler
>> should use the new plan_class.xml config instantly and not send you any
>> work. This seems to be a separate problem.
>>
>> So in theory the server shouldn't send you any task but it is. And the
>> vboxwrapper should recognize the error code but it isn't. Very strange.
>>
>> Next thing to check would be the scheduler_request and reply from the
>> client and the scheduler log on the server the interesting part there is
>> the cpu capabilities. This is where the BIOS setting is reported. There
>> should be no vmx or svm capability reported by your computer (as you
>> have HW accell turned off).
>>
>> Regards
>> Christian
>>
>> On 10/16/2015 01:47 PM, Marius Millea wrote:
>> > Thanks Christian, I added that option but same result.
>> >
>> > Its clear to me now that vboxwrapper is missing the fact that the VM
>> > doesn't start correctly. If you look at the attached stderr.txt, if
>> > says "Successfully started VM." Hence it never makes it to the part in
>> > the code that checks vbox.log for "VERR_VMX_MSR_VMXON_DISABLED" and
>> > hence never prints "ERR_CPU_VM_EXTENSIONS_DISABLED".
>> >
>> > I'm looking into why, any ideas? Otherwise yea it looks like the code
>> > to do exactly what you guys describe is there.
>> >
>> > Marius
>> >
>> >
>> > On Fri, Oct 16, 2015 at 11:42 AM, Christian Beer
>> > > wrote:
>> >
>> > On 10/16/2015 11:16 AM, Marius Millea wrote:
>> > > However I'm using VBox
>> > > 4.3.30 and vboxwrapper 26175 so I don't think that's it. I'm
>> > attaching my
>> > > vbox.log, there's some errors in there about VT-x but searching
>> > > for ERR_CPU_VM_EXTENSIONS_DISABLED yields nothing.
>> > The vbox.log contains VERR_VMX_MSR_VMXON_DISABLED at the end. Which
>> is
>> > the VirtualBox errorcode to say you have a 64bit Guest but Hardware
>> > Virtualization is not enabled (it says so in the begining of the log
>> > too). This gets picked up by vboxwrapper and
>> > ERR_CPU_VM_EXTENSIONS_DISABLED gets output to stderr.txt in the slot
>> > directory which gets reported back to the server as part of the
>> > sched_request file. The stderr.txt shoud be visible as part of the
>> > failed task once it is reported.
>> >
>> > You should change the plan_class vbox64 to include the
>> >  tag. This is the plan_class I use at RNA World:
>> > > 
>> > > vbox64
>> > > 
>> > > 
>> > > 70224
>> > > 40010
>> > > 
>> > > 
>> > This will not send a 64bit VM to a host that has no Hardware
>> > Virtualization enabled. This should really be the default as
>> > VirtualBox
>> > doesn't allow a 64bit guest without the HW Virtualization enabled.
>> >
>> > Regards
>> > Christian
>> > ___
>> > boinc_dev mailing list
>> >   

Re: [boinc_dev] vbox64 and virtualization

[Christian Beer]

Did you restart the server processes just to make sure? The scheduler
should use the new plan_class.xml config instantly and not send you any
work. This seems to be a separate problem.

So in theory the server shouldn't send you any task but it is. And the
vboxwrapper should recognize the error code but it isn't. Very strange.

Next thing to check would be the scheduler_request and reply from the
client and the scheduler log on the server the interesting part there is
the cpu capabilities. This is where the BIOS setting is reported. There
should be no vmx or svm capability reported by your computer (as you
have HW accell turned off).

Regards
Christian

On 10/16/2015 01:47 PM, Marius Millea wrote:
> Thanks Christian, I added that option but same result. 
>
> Its clear to me now that vboxwrapper is missing the fact that the VM
> doesn't start correctly. If you look at the attached stderr.txt, if
> says "Successfully started VM." Hence it never makes it to the part in
> the code that checks vbox.log for "VERR_VMX_MSR_VMXON_DISABLED" and
> hence never prints "ERR_CPU_VM_EXTENSIONS_DISABLED". 
>
> I'm looking into why, any ideas? Otherwise yea it looks like the code
> to do exactly what you guys describe is there. 
>
> Marius
>
>
> On Fri, Oct 16, 2015 at 11:42 AM, Christian Beer
> > wrote:
>
> On 10/16/2015 11:16 AM, Marius Millea wrote:
> > However I'm using VBox
> > 4.3.30 and vboxwrapper 26175 so I don't think that's it. I'm
> attaching my
> > vbox.log, there's some errors in there about VT-x but searching
> > for ERR_CPU_VM_EXTENSIONS_DISABLED yields nothing.
> The vbox.log contains VERR_VMX_MSR_VMXON_DISABLED at the end. Which is
> the VirtualBox errorcode to say you have a 64bit Guest but Hardware
> Virtualization is not enabled (it says so in the begining of the log
> too). This gets picked up by vboxwrapper and
> ERR_CPU_VM_EXTENSIONS_DISABLED gets output to stderr.txt in the slot
> directory which gets reported back to the server as part of the
> sched_request file. The stderr.txt shoud be visible as part of the
> failed task once it is reported.
>
> You should change the plan_class vbox64 to include the
>  tag. This is the plan_class I use at RNA World:
> > 
> > vbox64
> > 
> > 
> > 70224
> > 40010
> > 
> > 
> This will not send a 64bit VM to a host that has no Hardware
> Virtualization enabled. This should really be the default as
> VirtualBox
> doesn't allow a 64bit guest without the HW Virtualization enabled.
>
> Regards
> Christian
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu 
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>
>

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] vbox64 and virtualization

[Marius Millea]

On Fri, Oct 16, 2015 at 2:23 PM, Marius Millea  wrote:

> Here's the relevant lines from the scheduler log, vmx is there, and its
> present in /proc/cpuinfo as well.
>
> 2015-10-16 12:12:34.6279 [PID=66   ][send] CPU features: fpu vme de
> pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts
> acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc
> arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf
> eagerfpu pni pclmulqdq dtes64 monitor ds_cpl *vmx* smx est tm2 ssse3 cx16
> xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx
> f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi
> flexpriority ept vpid fsgsbase smep erms
> 2015-10-16 12:12:34.6596 [PID=66   ][send] Sending app_version
> camb_boinc2docker 4 5 vbox64_mt; projected 14.64 GFLOPS
>
> Reading eg here
> 
> or here
> 
>  it
> seems vmx appearing there just means your CPU supports it, not that it is
> actually enabled. Clearly in my case its disabled yet still shows up.
>
> So I suppose the questions are now,
>
> 1) is there a way BOINC can check if vmx is actually enabled?
> 2) whats going on with vboxwrapper
>
>
Yea, can confirm "VBoxManage startvm" returns successfully on my system
even though the VM immediately dies with the VERR_VMX_MSR_VMXON_DISABLED
error. That's why vboxwrapper never catches it. Not sure if this is a VBox
bug and/or if its limited to my system.






> Marius
>
>
>
> On Fri, Oct 16, 2015 at 2:01 PM, Christian Beer  > wrote:
>
>> Did you restart the server processes just to make sure? The scheduler
>> should use the new plan_class.xml config instantly and not send you any
>> work. This seems to be a separate problem.
>>
>> So in theory the server shouldn't send you any task but it is. And the
>> vboxwrapper should recognize the error code but it isn't. Very strange.
>>
>> Next thing to check would be the scheduler_request and reply from the
>> client and the scheduler log on the server the interesting part there is
>> the cpu capabilities. This is where the BIOS setting is reported. There
>> should be no vmx or svm capability reported by your computer (as you
>> have HW accell turned off).
>>
>> Regards
>> Christian
>>
>> On 10/16/2015 01:47 PM, Marius Millea wrote:
>> > Thanks Christian, I added that option but same result.
>> >
>> > Its clear to me now that vboxwrapper is missing the fact that the VM
>> > doesn't start correctly. If you look at the attached stderr.txt, if
>> > says "Successfully started VM." Hence it never makes it to the part in
>> > the code that checks vbox.log for "VERR_VMX_MSR_VMXON_DISABLED" and
>> > hence never prints "ERR_CPU_VM_EXTENSIONS_DISABLED".
>> >
>> > I'm looking into why, any ideas? Otherwise yea it looks like the code
>> > to do exactly what you guys describe is there.
>> >
>> > Marius
>> >
>> >
>> > On Fri, Oct 16, 2015 at 11:42 AM, Christian Beer
>> > > wrote:
>> >
>> > On 10/16/2015 11:16 AM, Marius Millea wrote:
>> > > However I'm using VBox
>> > > 4.3.30 and vboxwrapper 26175 so I don't think that's it. I'm
>> > attaching my
>> > > vbox.log, there's some errors in there about VT-x but searching
>> > > for ERR_CPU_VM_EXTENSIONS_DISABLED yields nothing.
>> > The vbox.log contains VERR_VMX_MSR_VMXON_DISABLED at the end. Which
>> is
>> > the VirtualBox errorcode to say you have a 64bit Guest but Hardware
>> > Virtualization is not enabled (it says so in the begining of the log
>> > too). This gets picked up by vboxwrapper and
>> > ERR_CPU_VM_EXTENSIONS_DISABLED gets output to stderr.txt in the slot
>> > directory which gets reported back to the server as part of the
>> > sched_request file. The stderr.txt shoud be visible as part of the
>> > failed task once it is reported.
>> >
>> > You should change the plan_class vbox64 to include the
>> >  tag. This is the plan_class I use at RNA World:
>> > > 
>> > > vbox64
>> > > 
>> > > 
>> > > 70224
>> > > 40010
>> > > 
>> > > 
>> > This will not send a 64bit VM to a host that has no Hardware
>> > Virtualization enabled. This should really be the default as
>> > VirtualBox
>> > doesn't allow a 64bit guest without the HW Virtualization enabled.
>> >
>> > Regards
>> > Christian
>> > ___
>> > boinc_dev mailing list
>> > boinc_dev@ssl.berkeley.edu 
>> > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
>> > To unsubscribe, visit the above URL and
>> > (near bottom of page) enter 

Re: [boinc_dev] vbox64 and virtualization

[Rom Walton]

> Yea, can confirm "VBoxManage startvm" returns successfully on my system even 
> though the VM immediately
> dies with the VERR_VMX_MSR_VMXON_DISABLED error. That's why vboxwrapper never 
> catches it. Not sure if
> this is a VBox bug and/or if its limited to my system.

Well, it is a bug in vboxwrapper.  It may or may not be a change in behavior 
for VirtualBox.

Ideally, BOINC relies on vboxwrapper to tell it whether the host machine is 
properly configured to support running VirtualBox Virtual Machines.  
Vboxwrapper relies on VirtualBox.

This was working at one time.

- Rom

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Marius 
Millea
Sent: Friday, October 16, 2015 9:12 AM
To: Christian Beer 
Cc: BOINC-dev email list 
Subject: Re: [boinc_dev] vbox64 and virtualization

On Fri, Oct 16, 2015 at 2:23 PM, Marius Millea  wrote:

> Here's the relevant lines from the scheduler log, vmx is there, and 
> its present in /proc/cpuinfo as well.
>
> 2015-10-16 12:12:34.6279 [PID=66   ][send] CPU features: fpu vme de
> pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush 
> dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
> constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
> aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl *vmx* smx est 
> tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt 
> tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb 
> xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep 
> erms
> 2015-10-16 12:12:34.6596 [PID=66   ][send] Sending app_version
> camb_boinc2docker 4 5 vbox64_mt; projected 14.64 GFLOPS
>
> Reading eg here
>  ocessor-supports-vt/>
> or here
>  nsions-enabled-in-bios> it seems vmx appearing there just means your 
> CPU supports it, not that it is actually enabled. Clearly in my case its 
> disabled yet still shows up.
>
> So I suppose the questions are now,
>
> 1) is there a way BOINC can check if vmx is actually enabled?
> 2) whats going on with vboxwrapper
>
>
Yea, can confirm "VBoxManage startvm" returns successfully on my system even 
though the VM immediately dies with the VERR_VMX_MSR_VMXON_DISABLED error. 
That's why vboxwrapper never catches it. Not sure if this is a VBox bug and/or 
if its limited to my system.






> Marius
>
>
>
> On Fri, Oct 16, 2015 at 2:01 PM, Christian Beer 
>  > wrote:
>
>> Did you restart the server processes just to make sure? The scheduler 
>> should use the new plan_class.xml config instantly and not send you 
>> any work. This seems to be a separate problem.
>>
>> So in theory the server shouldn't send you any task but it is. And 
>> the vboxwrapper should recognize the error code but it isn't. Very strange.
>>
>> Next thing to check would be the scheduler_request and reply from the 
>> client and the scheduler log on the server the interesting part there 
>> is the cpu capabilities. This is where the BIOS setting is reported. 
>> There should be no vmx or svm capability reported by your computer 
>> (as you have HW accell turned off).
>>
>> Regards
>> Christian
>>
>> On 10/16/2015 01:47 PM, Marius Millea wrote:
>> > Thanks Christian, I added that option but same result.
>> >
>> > Its clear to me now that vboxwrapper is missing the fact that the 
>> > VM doesn't start correctly. If you look at the attached stderr.txt, 
>> > if says "Successfully started VM." Hence it never makes it to the 
>> > part in the code that checks vbox.log for 
>> > "VERR_VMX_MSR_VMXON_DISABLED" and hence never prints 
>> > "ERR_CPU_VM_EXTENSIONS_DISABLED".
>> >
>> > I'm looking into why, any ideas? Otherwise yea it looks like the 
>> > code to do exactly what you guys describe is there.
>> >
>> > Marius
>> >
>> >
>> > On Fri, Oct 16, 2015 at 11:42 AM, Christian Beer 
>> > > wrote:
>> >
>> > On 10/16/2015 11:16 AM, Marius Millea wrote:
>> > > However I'm using VBox
>> > > 4.3.30 and vboxwrapper 26175 so I don't think that's it. I'm
>> > attaching my
>> > > vbox.log, there's some errors in there about VT-x but searching
>> > > for ERR_CPU_VM_EXTENSIONS_DISABLED yields nothing.
>> > The vbox.log contains VERR_VMX_MSR_VMXON_DISABLED at the end. 
>> > Which
>> is
>> > the VirtualBox errorcode to say you have a 64bit Guest but Hardware
>> > Virtualization is not enabled (it says so in the begining of the log
>> > too). This gets picked up by vboxwrapper and
>> > ERR_CPU_VM_EXTENSIONS_DISABLED gets output to stderr.txt in the slot
>> > directory which gets reported back to the server as part of the
>> > sched_request file. The stderr.txt shoud be 

[boinc_dev] Suggestion for a RPC for reporting invalid (and other status) tasks

[AgentB]

Hi devs

My first post -so thanks for making boinc, it really works well!

Apologies for the long post, the formatting should be fixed format.

 - appreciate any comments or thoughts.


BR
Mike


Summary: Suggestion for a RPC for reporting invalid (and other status)
tasks

This proposal started from a thread posted on the boinc Q User Forum here
http://boinc.berkeley.edu/dev/forum_thread.php?id=10539=64913#64913

Current issues:
---
+ Users only see invalid results if they *regularly* visit *all* their
project websites and check their tasks
+ Task are often purged from the user visible data so no long term
record is visible
+ Invalid tasks waste more host and server resources (power, bandwidth
etc) on average than error tasks (they take longer)
+ Project administrators may not have time to advise users about hosts
which deliver bad results
+ The boinc manager program(s) currently report nicely on historical RAC
values but not so well on task reliability and host utilization.
+ RAC values are slow to respond to changes (by design)
+ There is an RPC for getting *pending* tasks (project/pending.php)
documented here https://boinc.berkeley.edu/trac/wiki/WebRpc
+ There is no RPC for getting *errors* or *invalid* tasks


Existing php which is similar: results.php
--

The existing project/results.php (and the only mechanism available for
users to see invalid tasks) accepts parameters

hostid= or userid= # must match authentication
offset=   # default 0
show_names=<0|1> #
state=4  # 4 is invalid, 0 default
matches all states
appid=0  # 0 default matches all apps

it then displays a maximum of 20 tasks one per row in a HTML table,
and the user has to follow links to the next page of 20 results.

Example
http://einstein.phys.uwm.edu/results.php?userid==0_names=1=4=0

Shows my first page of E@H invalids

Suggestion:
--
Create a similar RPC to pending.php called say resultsRPC.php
 which would
 accept the parameters (except offset above) like results.php,
 then deliver an XML file like pending.php RPC with task data


Benefit:
---

The resultsRPC could be used in a number of ways in the future

Future versions of boinc or the boincmgr could use it to
+ put an alert notice if a new error detected recently
+ log the event, like the job_.txt files
+ put a last week scorecard showing host/user efficiency
+ report user/host health statistics (like RAC/Credit statistics tab)

Users could write scripts using for alerts on errors and invalids,
helpful for "farmers" with headless hosts to get a daily email with new
invalids and errors from the farm.

Project Managers could also use this RPC across users to monitor app
performance trends after changes.



Detail
--

Select result records based on parameters
state, appid, hostid, userid (like results.php)

and these new optional parameters

max_results= # default 1000, the project
 # should be able to set an
upper limit
sent_end_time= # default to "now"
sent_time_interval=   # default to 2419200 (28 days)
 
to filter results returned.

Then produce (like pending.php) an XML file with one or two tables based
on optional formatting parameters

format=xml   # placeholder defaults to xml
report_results=<0|1> # default 1 = report results table
report_totals=<0|1>  # default 1 = report totals table


-XML file---

   ... data values matching the results.php web page output,
   any time/date output in epoch seconds.



   ... which simply counts or sums the column, where that makes sense.
(eg. count_of_results, Runtime, CPUtime, Claimedcredit, Grantedcredit)



--



-- 
BR 
Mike

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] Typo in computer detail, but only at E@H

[David Anderson]

That string comes from the client;
I'm not sure why E@h would show it incorrectly.
-- David

On 10/16/2015 6:27 AM, TarotApprentice wrote:

On Einstein I have a bunch of computers that show as:


GenuineIntel
  Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz [Family 6 Model 58 Stepinng9]](8 
processors)

Seti displays as:
GenuineIntel
Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz [Family 6 Model 58 Stepping 9]
(8 processors)
On Seti and GPUgrid they show "Stepping" correctly. I did ask Bernd about it 
but he's not aware where it builds the string. I haven't checked CPDN as they seem to 
down at the moment. Seeing as they display correctly on other projects I presume its in 
the server software if someone could point out where. Its cosmetic I know and not worth 
any effort but I thought I would mention it.
MarkJ
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.