I ran my code (the code had a bug that wrong "path" to show the image on the Pepper tablet), I fixed my code's issue, but blocked Pepper. After I rebooted pepper robot again, the Pepper tablet was totally black, I called the ALTabletService, it shows "cannot find ALTabletService".
I used qicli to check all services, I cannot find ALTabletService. It seems the TabletService is crashed. I tried to do many times special reboot, it still did not work. I noticed there was a similar issue as me on stackoverflow (Pepper Robot doesn't boot up properly), but there is no good answer.
Here are journalctl logs from the robot.
We had a similar issue where the screen was black but the backlight was always on (even when the robot was powered off). We tried to perform a factory reset, a special startup and reseting the tablet but nothing worked.
However, letting the robot run completely out of battery to force the tablet to shut down fixed it for us.
That happened to me once after the tablet was grabbed and pulled away from the robot (without success).
After I turned off the robot normally, pushed the tablet towards the torso and slightly down, and then restarting the robot, it worked again.
But at this stage I cannot tell if I really figured out the cause or if it just luck.
Related
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.
I have created a sample project in choreograph which is responsible for playing a video on pepper's tablet, it works nicely in choreograph. now i packaged and uploaded it on the robot and called this behavior (by albehaviormanger) in my python code as following:
behaviormanager = session.service("ALBehaviorManager")
if (behaviormanager.isBehaviorRunning(choregraph_Code)):
behaviormanager.stopBehavior(choregraph_Code)
behaviormanager.runBehavior(choregraph_Code)
It works but sometimes the video stopped suddenly, in every single run in a different moment! so whats the problem with it?
also I tried to play videos from net by:
tabletService.enableWifi()
tabletService.loadUrl(url)
tabletService.showWebview()
but after some time it stops too
so does any one know what's a problem?
Most likely your problem here is that Autonomous Life is resetting the tablet. And that happens because Autonomous Life doesn't know that your behavior is running.
Autonomous Life has the concept of "focused activity"; of which there can only be one at a time (lower priority activities will not be started, and when a higher activity priority is started, the lower priority one will be stopped). Between activities, Autonomous Life resets the tablet, but won't do so inside an activity.
So instead of doing ALBehaviorManager.runBehavior, you should use ALAutonomousLife.switchFocus (with the same behavior path as a parameter), and AutonomousLife won't reset your tablet.
(Not all behaviors are intended to be activities; some activities have sub-behaviors, and some behaviors may be expected to be running quietly in the background without getting the focus - that's not a good practice, but sometimes happens)
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 moved five different sites into MAMP Pro 4.0.6 recently, and now the program is running very sluggishly. I get periodic spinning beach balls anytime I touch the interface, and Activity Monitor shows MAMP %CPU shooting up to 75 and even 100 + shortly after. Once I get a site actually open, it seems to run fine in the browser. It's just the MAMP interace has ground to a halt.
I thought this might be a port conflict, but moving away from 80/3306 to program defaults has not solved the problem.
I also thought this might have something to do with using PHP 7.0.12, so I moved back to 5.6.27, but this has had not impact either.
Can anyone suggest other ways to troubleshoot this? I've looked in my logs and have found nothing overly suspicious except for reference to a two.crt files left over from a dev server SSL install. I removed these, but I'm not sure if this would have any impact.
Thanks.
-- Lee
Sometimes (in about 50% of runs), EnumDevices takes 5-10 seconds to return. Normally it is almost instant. I couldn't find any other reports of this kind of behaviour.
When things are this slow, it's ok to profile by watching stdout :) This:
std::cout << "A";
directInput8Interface->EnumDevices(DI8DEVCLASS_GAMECTRL, MyCallback, NULL, DIEDFL_ATTACHEDONLY);
std::cout << "C";
...
BOOL CALLBACK MyCallback(LPCDIDEVICEINSTANCE, LPVOID)
{
std::cout << "B";
return DIENUM_CONTINUE;
}
Seems to hang at a random point through enumerating devices - sometimes it'll be before the callback is called at all, sometimes after a couple, and sometimes it will be after the last call to it.
This is clearly a simplified chunk of code; I'm actually using the OIS input library ( http://sourceforge.net/projects/wgois/ ), so for context, please see the full source here:
http://wgois.svn.sourceforge.net/viewvc/wgois/ois/trunk/src/win32/Win32InputManager.cpp?revision=39&view=markup
There doesn't seem to be anything particularly fruity going on there though, but possibly something in their initialisation could be the cause - I don't know enough about DI8 to spot it.
Any ideas about why it could be so slow will be greatly appreciated!
EDIT:
I've managed to catch the hang in an etl trace file and analysed it in Windows Performance Analyzer. It looks like EnumDevices eventually calls through to DInput8.dll!fGetProductStringFromDevice, which calls HIDUSB.SYS!HumCallUSB, which calls KeWaitForSingleObject and waits. 9 times out of 10 (literally - there are 10 samples in the trace) this returns very quickly (324us each), with the readying callstack containing usbport.sys!USBPORT_Core_iCompleteDoneTransfer followed by HIDUSB.SYS!HumCallUsbComplete, which looks quite normal.
But 1 time in 10, this takes almost exactly 5 seconds to return. On the readying callstack is ntkrnlmp.exe!KiTimerExpiration instead of the HIDUSB.SYS function. I guess all this indicates that the HIDUSB.SYS driver is querying devices asynchronously with a timeout of 5 seconds, and sometimes it fails and hits this timeout.
I don't know whether this failure is associated with any one device in particular (I do have a few USB HIDs) or if it's random - it's hard to test because it doesn't always happen. Again, any information anyone can give me will be appreciated, though I don't hold out any hope for Microsoft fixing this any time soon given the odd situation DirectInput is in!
Perhaps I'll just have to start initialising input earlier, asynchronously, and accept that sometimes there'll be a 5 second delay before user input can happen.
I was running into this too, largely as an end user, but it's been annoying the hell out of me for years. I didn't realize it was this issue until I ran into it on an open source project and was able to debug it.
Turns out it was my USB Headphone DAC (The Objective DAC from Massdrop), it installs the driver: wdma_usb.inf_amd64_134cb113911feba4\wdma_usb.inf for Device Instance ID USB\VID_262A&PID_1048&MI_01\7&F217D4F&0&0001 and then shows up in Device Manager under Sound, video and game controllers as: ODAC-revB USB DAC and, under Human Interface Devices as: USB Input Device and HID-compliant consumer control device.
I have no idea what the HID entries do but... When they are enabled and this DAC is set as the Audio Output device both IDirectInput8_CreateDevice and EnumDevices are painfully slow. Disabling the "USB Input Device" entry seems to cause no negative effects and completely solves my issue.
Changing the Audio output from the DAC to anything else also weirdly solved the issue.
This was so bad that it made the Gamepad Configuration dialog joy.cpl unusable, hanging and eventually crashing.
I was wanting this to just be a comment but I don't have enough rep for it, and this is pretty much the only place on the internet that describes this problem though so hopefully this helps someone else one day!
I had the same issue. I have a Corsair K65 LUX RGB keyboard. I updated CUE and it seems to have fixed the issue
Got same issue when having my Corsair K55 Keyboard. Changing the keyboard of USB port fixes the issue for a while, but then it comes back later on. So it seems to be a buggy drivers issue.
As DaFox has pointed out, a likely cause appears to be certain device drivers being enabled. I contacted JDS Labs support (who sell one device which happens to install one such driver) and they kindly pointed out that the root cause is actually a bug within Windows (not the installed driver), and they actually provide the solution on their troubleshooting page. See Games hang or experience loading delays, which explicitly mentions VID_262. Disabling this driver fixes the issue without apparent side effects (under the condition that that is the only driver triggering the bug). As for what exactly is going wrong within Windows, here there be dragons.
So I guess the go-to solution (for users) is to scrape all the troubleshooting and FAQ pages for all devices which you have ever connected to your system and see if there is a mention of delays/lag caused by a driver.
As a software developer, you will probably want to benchmark the execution time of the affected code and kindly tell the user there is something wrong with their system configuration and where to look for how to fix it in case it is unreasonably long.
Same issue with Corsair K70 Keyboard.
Quickly reconnecting keyboard fixes this, until next time. Usually happens after some DirectInput devices removed from the system or go to sleep.
This has been plaguing me as a developer and my friend as a user for years. All games using DInput, SDL SDL_INIT_JOYSTICK or anything depending on that, took extremely long to initialize.
It was caused by a faulty driver of a DAC, and as pointed out by DaFox, disabling the corresponding USB Input Device resolved the issue. Although it's labeled with a different manufacturer name, the vendor IDs match.
The hardware ID of the device is USB\VID_262A&PID_9023&REV_0001&MI_00.
Same issue appears to happen with a Steelseries Apex 7 keyboard. Unplugging and plugging that keyboard back again got rid of 3 freezes (of 10 seconds each) while enumerating USB devices.