I have followed this tutorial for developing an operating system. I am using Windows 10 as my host sytem and used wsl for compiling. But my VM fails as soon as I enable interrupts.
This is the log file of the VM that is output, but I cannot understand it. I am pretty naive with VirtualBox. Can someone explain any possible error you see?
Here is the code of the Os. I just have changed the structure I believe. Rest code in execution point of view is same as shown in video series.
That is a lot of log to scroll through and it's hard to be sure on the face of it that just looking at that would be able to tell us what about your startup code (not visible to us as part of the question) would trigger it. However, I can speak to some general strategies about approaching a log file like this.
We can see some general state transitions in there. The log ends with:
00:00:15.712045 Changing the VM state from 'DESTROYING' to 'TERMINATED'
So I can go back through and look at where the first instance of DESTROYING showed up, which was:
00:00:15.698320 Changing the VM state from 'POWERING_OFF' to 'OFF'
00:00:15.701802 Changing the VM state from 'OFF' to 'DESTROYING'
Following the same process backwards to POWERING_OFF, I see:
00:00:08.577363 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
00:00:14.342287 ERROR [COM]: aRC=VBOX_E_INVALID_VM_STATE (0x80bb0002) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Invalid machine state GuruMeditation when checking if the guest entered the ACPI mode)}, preserve=false aResultDetail=0
00:00:15.643579 GUI: Request for close-action to power VM off.
00:00:15.643599 GUI: Passing request to power VM off from machine-logic to UI session.
00:00:15.643606 GUI: Powering VM down on UI session power off request...
00:00:15.644257 Console: Machine state changed to 'Stopping'
00:00:15.644763 Console::powerDown(): A request to power off the VM has been issued (mMachineState=Stopping, InUninit=0)
00:00:15.645075 Changing the VM state from 'GURU_MEDITATION' to 'POWERING_OFF'
That error line at the top of that block may point to something searchable that would turn up other instances of people having the same or a similar problem. If you scroll up a bit, you can also see that something VGA-related was happening right before the error, which may help narrow it down if it's directly related to the error, or may be another step to backtrack through on the way to the real issue.
Related
I'm using SLES 12.2 and recently had some trouble with NTP configuration.
The default settings for NTP in YAST were "Synchronize without Daemon" in the Start NTP Daemon section and "Manual" for "Runtime Configuration Policy". I changed those to "Now and on Boot" and "Auto", respectively. This fixed my problem, as expected.
However, I now need to apply this to a couple hundred machines and need to figure out how to do it from the console.
For the first option, I thought the obvious thing is to enable ntpd.service:
$ systemctl enable ntpd.service
But when I do that and open up YAST, it's still saying "Manual". At the same time if ntpd is disabled and I change it in YAST, it sets it to enabled. So apparently YAST enables the service AND does something else.
The second option I'm not sure about. It has manual, auto, and custom as options in YAST. At first I thought this might be related to the specifics in /etc/ntp.conf, but making changes in YAST doesn't change anything there.
There are of course a number of resources online, but they all get into the specifics of how to configure NTP either in the console or in YAST. What I'm looking for is what each setting in YAST does on the file system specifically.
I'm fairly new to SLES, so there might be something obvious I'm missing. Perhaps there's a setting similar to NM_CONTROLLED for network interfaces where I can simply turn off YAST for NTP and just do it the old-fashioned way?
Usually all SuSE system configuration stuff is stored under
/etc/sysconfig
More Info in documentation
I get the following error after upgrading via Migration Assistant my laptop from a 2-core to a 4-core processor:
cpum#1: X86_CPUID_FEATURE_ECX_MOVBE is not supported by the host but
has already exposed to the guest [ver=17 pass=final]
(VERR_SSM_LOAD_CPUID_MISMATCH).
How can i resolve the same?
The solution may be as simple as clicking the big yellow "Discard" button, which will delete the saved state (same as pulling the power cord).
Reference: https://forums.virtualbox.org/viewtopic.php?f=6&t=19351
For people working via a terminal.
The accepted answer correctly mentions to discard the current state of the VM. This basically means pull the power cord, so that the next time you start it, the machine reboots.
You can do this using
VBoxManage discardstate "your machine's name"
Click on the name of the virtual machine, right click on the menu and discard saved status
The Discard button worked for me. Thanks #Justin!
I've been chasing this exact error message off and on for months (fortunately my VM is not part of my daily work). The whole time I thought that it was an issue of being on a new CPU (based on CPUID_MISMATCH) so I was looking at how to move a VM from one CPU to another and how to change the expected CPUID. But everything I found in that searching required that you save and shut down properly on the original CPU, which I no longer have.
Simply "Discard"-ing the "Current State (changed)" version worked for me on all of my saved machines.
Whoda thunk that the fix for a virtual Windows machine was a hard reboot? Not like that works for hardware-based Windows boxes, right? ;-) I guess that's why they call rebooting "the Windows Panacea".
Thanks again.
I'm having problem making a permanent calibration in my embedded solution. I'm developing a Qt-based app for a Embedded Linux environment with touch screen. For this last part, I use tslib (configured by previous developers).
In what comes to simply calibrate the touch screen, everything is fine: ts_calibrate runs and creates the pointercal file correctly. If after calling ts_calibrate I run my Qt app (or ts_test), I can notice that the calibration is successful.
The problem is that the calibration results only works for 1 opening of my app: I calibrate with ts_calibrate, run my app, close it and if I run my app again, the screen is one again non-calibrated.
Now obviously I don't want to have to call the calibration each time my app is closed and reopened. The question is: how to make the calibration results become permanent? (that is, till another calibration is made)
Extra info:
I did some research on the web and I found this SO thread telling about a way to handle this problem using QWSServer. At first I disliked this solution since it depends on the Qt framework to do the job (I was expecting a more general, "C++ solution" (or a call to a script, whatever)). But I implemented it and it worked - but only in a specific case, namely, if I calibrate, open my software, close it and reopen it, then the calibration is maintained. But the problem nevertheless persists if I shut down the hardware completely, turn it on and run my app without a call to ts_calibrate (reloading the Linux kernel in the process); so this show to be only a partial solution and, therefore, not acceptable.
Trying to find the source of the problem, I created a copy of the pointercal file just after calibration and another copy of it after shutting down and turning up my hardware (and confirming that the calibration was over) and I noticed that the file was changed in the middle despite no call to the ts_calibrate or similar app was made:
After calibration:
55438 118 -1920736 -543 -36058 34531168 65536 800 480
After hardware shutdown:
-55040 1280 2526720 -288 35040 -34398240 -62768
The terminal log for the linux boot (tftp; bootm command) don't mention pointercal or a relevant calibration process.
Edit
I recently learned that the pointercal file located inside /etc/ is changing between sections because that entire folder is made new when the hardware is restarted. So what is essentially happening is that Tslib is going after a file that is constantly reset to default each time the hardware is restarted, and what I need to do is to configure Tslib not to look there, but to a more secure folder (in my case, the SD Card). The new question now is: how to do that? I know I have to configure the tslib.sh file making the TSLIB_CALIBFILE variable point to the new location of pointerscal, but tslib.shis itself inside /etc/, being itself temporary.
You have to change TSLIB_CALIBFILE in the image loaded via tftp.
That should do it, since you just have to change that once.
Build time of XPages application containing several JARs, Java sources and ~50 XP/CC elements takes about minute to build on server via WAN. I have replicated application to local, build time dropped to ~10s.
Since few days ago build of local application is extremely slow, about 2-5 minutes. After some experiments there is workaround: to disable TCP port in location document - it drops build times to just few seconds. Even tho it works, it does not help much - testing requires user to be authenticated, so I need to replicate design changes to remote or local server - and that means to change location (online/offline) every time.
UPDATE 2013-04-04: I have duplicated my current location document and removed home and directory servers. To my surprise, with this location build times went back to few seconds - with TCP port enabled so replication is possible. Bigger surprise was the fact, that returning home/directory servers back to new location did not reproduce the problem - in fact they do not affect performance. I know it because I have renamed current location document and everything went to normal. From my understanding, "something" in client configuration was connected to location name. Thanks to Simon's tips I will investigate further.
The question is still open: I am looking for some (eclipse) preference controlling this behavior - unintended communication with server during build of local application.
Solution:
Teamstudio CIAO hooks into designer and checks for every update of design element. Seems to be lack of code optimization to me: it checks whether currently built design element (every single one, one by one) should be controlled in CIAO config database.
This explains why the problem was solved by renaming of location document. I was disappointed yesterday, when performance problems started again. Fortunately, I recalled CIAO setup to that location document about that time. CIAO uses teamstudio.ini file in DATA directory to configure what CIAO configuration database is used for every location document. Look for entry:
CIAOConfigDb[location name]=server name;CIAO\CIAOConfig.nsf
For development on local replicas with connection to server (for replication or local server), use location document with CIAO disabled.
This works only with property ForceConfigLocation=0.
Not a solution (yet!), but may help in the investigation. I'll update further if you post results later.
Debug instructions.
Add the following to the shortcut that launches the Designer client.
-RPARAMS -console -debug -separateSysLogFiles -consoleLog
Start the designer client. This will also open up the OSGi console.
Reproduce the issue. While it is still in progress in the OSGi console type the following:
dump threads
Do this three times, with a small amount of time between completion of each dump. Once done open the three heap dumps (in the IBM_TECHNICAL_SUPPORT folder) in the Heap Dump Analyser.
It will show you what threads are consistent through all three dumps. Take a look at those and look for package names/calls which may appear to be a functional area. Once you have that then you can try adding the debug for the related class.
For example: Let's say you notice "com.ibm.designer.domino.ui.commons." in the thread, then you would edit the rcpinstall.properties file. It will be in:
<Notes Install>\Data\workspace\.config\rcpinstall.properties
and you would add (start with FINE, then FINEST if nothing):
com.ibm.designer.domino.ui.commons.level=FINE
Now when you restart the designer client it will generate debug output in the workspace\logs folder for that package. You need to then go through the trace logs looking for the time when the delay occurred and see if it makes any references to related design elements.
Other open applications may get built at the same time (which looks like a bug top me). Be sure to close all other applications and the server based replica. Open applications have their icon showing in the application list and they stay open even if you close and reopen the Designer. In Designer 9 right click application and select "Close Application". In 8.5 you need to use Package Exprorer for closing.
Another good way is to use Working Sets. Only applications in open Working Set will be built (AFAIK). Have a Working Set with this one app only (and the app only in this Working Set).
update 1
If these don't help I would delete/rename bookmark.nsf, Cache.NDK and desktop8.ndk. Then open just this one app and see what happens.
update 2
Check that there are no referenced projects. Right click the application and select "Project Properties". From there "Project Referencies" and make sure no check boxes are checked.
update 3
Based on your update I would check the item names starting with $ in location document. Sometimes there are saved IP addresses etc. which could cause this problem. All those items can be removed.
If possible (and if You are not using it yet) try to use version 9 of the Domino designer (You do not have to use Domino 9 to do that - it works fine with Domino 8.5.3).
For our projects build times went down to only few seconds from few minutes. I guess that they finally noticed at IBM that the build process used to heavily relay on connection to server and done something with it.
With new designer You don't event have to replicate to local. You can directly work on Your local server.
Sometimes a network drive that is already mapped to a drive letter because "disconnected". Using the normal Windows functions to access files / folders on that drive fail. As soon as the user manually clicks on that drive it the Windows Explorer dialog, it's magically repaired.
Since my program is a batch program I'd like to start this "magic" from my program (C++) but I haven't found a Windows function for that. There's nothing in the usual WNet... functions...
NET USE V: /DELETE
NET USE V: "\\server1\videos"
NET USE L: /DELETE
NET USE L: "\\server2\archive"
When the path is inserted, you could check to see if it is a network resource and before opening files, use WNetGetConnection() to get the network resource.
You could also try to use WNetRestoreConnectionW(), which seems to have more spurious support, depending on the environment.
Try re-connecting to the share via net use:
net use \\server\folder [/user:[domain\]username] [password]
If that doesn't work, you can net use /delete it first, then re-connect.
Isn't this what WNetAddConnection and WNetAddConnection2 are for?
I suspect that is really the same thing, though. Explorer probably caches the connection info somewhere in the registry. When the user tries to go to that drive Explorer sees that the mapping is disconnected, reads the connection info from the registry, and re-creates the connection. Maybe you could try running regmon while you create a drive mapping and see if you can figure out where and how the connection information is cached.
I had trouble with this at a client of mine not long ago. I don't know if it's possible in your situation, but our fix was to tweak the Server's network settings to stop the timeouts and disconnects. See MSKB 297684 for details.
I agree with the comment from CMB, above. I've been down this path (excuse the pun) in the past and it caused me no end of trouble.
If the path is user configurable, they could use m:\pathonserver or they could use \server\c\pathonserver.
It shouldn't make any difference to your code, opening a file as m:\blahdeblah.dat or \server\c\blahdeblah.dat will be identical.
Using the UNC path is far more reliable, Windows will reconnect to that path automatically whether or not the mapped letter is there.
If you map a drive to a network
share, the mapped drive may be disconnected after a regular interval
of inactivity, and Windows Explorer may display a red "X" on the icon
of the mapped drive. However, if you try to access or browse the
mapped drive, it reconnects quickly.
To avoid this behavior use the following command:
net config server /autodisconnect:-1
Explanation of Microsoft on this topic:
https://support.microsoft.com/da-dk/help/297684/mapped-drive-connection-to-network-share-may-be-lost