Some Windows 2012-R2 customers see an Error Code 38 when they try to re-enumerate a PnP device which has been previously removed even though a trace of the driver (WDM) for that device indicates its unload routine has been called and it has successfully completed. The description of that error code is:
“Windows cannot load the device driver for this hardware because a previous instance of the device driver is still in memory.”
I don't see how the driver can still be in memory if its unload routine is called. Perhaps the error code 38 indicates another problem despite its description?
Related
I am using Linux 4.19.55 armv7l on a omap3 processor. On my target there is a usb modem that gets power from a gpio pin value (defined under /sys/class/gpio). There are occasions when I change the value parameter of this gpio pin to bring down the hardware and while doing so I frequently get an error (thrown by musb_handle_intr_disconnect from inside drivers/usb/musb/musb_core.c ) as under:
"musb_handle_intr_disconnect 843: unhandled DISCONNECT transition (a_idle)"
I tried debugging the issue by mounting debugfs and capturing data from the concerned bus by using usbmon. Bus id is identified from lsusb output and confirmed by observing /sys/kernel/debug/usb/devices. I observe that usbmon is unable to capture data whenever the mentioned error shows up. In a no error scenario the usbmon does capture the traffic from the concerned bus. Please help how to debug this issue.
Just checked that a commit on kernel branch fixes this issue which is present inside the states handled by the glue layer. This is the required commit
I'm porting a game to Quest and so part of my work is to interface the engine's Vulkan renderer w/ the Oculus Mobile SDK.
I believe I'm setting up the SDK correctly (I'm following the examples and the guidelines from Oculus' docs) but still I'm getting a nasty error when trying to submit a frame.
Here's a high-level list of the things I'm currently doing:
I initialize the API.
I create a Vulkan instance and device w/ the expected extensions.
I acquire per-eye swapchains and get Vulkan handlers for each of their images.
I setup framebuffers and renderpasses using those images.
I acquire a native android window.
I enter VR mode (making sure the app is resumed).
Then at the end of my render loop I setup an ovrSubmitFrameDesc and then call vrapi_SubmitFrame2(). I'm also making sure I only call vrapi_SubmitFrame2() after all work has been submitted to the GPU (I'm currently using a fence on my work queues).
However, as I mentioned before, the call to vrapi_SubmitFrame2() fails. It currently raises a SIGSEGV inside Quest's Vulkan driver:
backtrace:
#00 pc 000000000010b2d8 /vendor/lib64/hw/vulkan.kona.so (!!!0000!b78ad09fc24eab751708d0a80613cf!09c6a36!+24) (BuildId: cc478ff923cc27b87607fb1f1a3b87ef)
#01 pc 00000000000c3b04 /vendor/lib64/hw/vulkan.kona.so (qglinternal::vkQueueSubmit(VkQueue_T*, unsigned int, VkSubmitInfo const*, VkFence_T*)+4468) (BuildId: cc478ff923cc27b87607fb1f1a3b87ef)
#02 pc 000000000018a608 /system/priv-app/VrDriver/VrDriver.apk!libvrapiimpl.so (offset 0x8cd000) (BuildId: aa2c28d3d4127c2e2e9a5125be000207dcc27ebd)
#03 pc 0000000000160a2c /system/priv-app/VrDriver/VrDriver.apk!libvrapiimpl.so (offset 0x8cd000) (BuildId: aa2c28d3d4127c2e2e9a5125be000207dcc27ebd)
#04 pc 0000000000162b6c /system/priv-app/VrDriver/VrDriver.apk!libvrapiimpl.so (offset 0x8cd000) (vrapi_SubmitFrame2+7564) (BuildId: aa2c28d3d4127c2e2e9a5125be000207dcc27ebd)
#05 pc 00000000048a85fc /data/app/myapp-Y6tT_vtGWj8JJ1PwgxheNA==/base.apk!libgrid.so (offset 0x6a9b000) (MyEngine::endVrFrame(unsigned int)+160) (BuildId: c9933f7ea0ad0c36a592bc4316e499e9db767d60)
The fact that the error is happening at an internal vkQueueSubmit() call makes me think that this is somehow related to the way I'm using command queues. But even if I set a separated queue as the synchronization queue and don't do anything with it (i.e., don't submit any command to it) I still get the same error.
Does anybody have an idea of what I could be doing wrong?
PS (1), I've tried to use a blank layer, instead of a proper projection layer, just to see if I could get past that point, but that didn't help.
PS (2), I'm getting no errors from the validation layer.
PS (3), the thread in which I enter VR mode is the same thread in which I'm calling vrapi_SubmitFrame2().
Let me start this by asking: who do you think would win, 18 years of experience in software development or this bad boi here '&'?
The mystery of SIGSEGV being raised from vrapi_SubmitFrame2() was nothing more than a stupid mistake when setting OVR's synchronization queue:
vpapi_DefaultModeParmsVulkan(&m_java, (long long)&queueHandle);
That line should have been written as:
vpapi_DefaultModeParmsVulkan(&m_java, (long long)queueHandle);
I'm using an 8-channel PCI-based framegrabber on Nvidia TX1 dev kit. I'm using this driver along with it. I can play up to 3/4 v4l2 camera feeds comfortably using mplayer, streamer or VLC but I always get a memory allocation error when I start playing the 5th camera feed, irrespective of the software I use to play it. I also wrote my own program to capture and display v4l2 streams but I'm getting the same problem. The exact error is an error 12 given by the ioctl command:
ioctl(fd, VIDIOC_REQBUFS, &req)
I have tried this framegrabber and device on a standalone PC and it works perfectly fine.
Any suggestions would be helpful.
Got it running my changing the CONFIG_CMA_SIZE_MBYTES variable from 16 to 32 while building the kernel.
My app communicates with a simple USB device as follows:
The app sends commands (2 or 3 bytes each) to the USB device by using WriteFile (kernel32.dll).
For each command that is send, the USB device sends a short response, which the PC receives using ReadFile (kernel32.dll).
Reading and writing is done asynchronously, using GetOverlappedResult to check the status of an operation.
Testing on 2 out of 3 PCs, the app and device function perfectly: all responses are received 100% reliably.
Under identical tests on the third PC, approximately 50% of the ReadFile requests do not return any data - the status remains as pending (ERROR_IO_INCOMPLETE) forever.
In other words, approximately for every 2 commands sent, one response is received.
Because the device functions perfectly with the other PCs, it lead me to believe that the problem might be occuring inside Windows, in the underlying code which is called by ReadFile (I presume some lower level USB driver code).
Question:
Please could you advise what debugging tool is most useful to investigate this? With my current knowledge, the internal workings of ReadFile are quite opaque.
The PC which is experiencing the issue is running Windows 8.0
You could try DebugView. Run as admin.
Go to "Capture", enable "Capture Kernel", enable "Enable Verbose Kernel Output".
This might help to investigate errors on Kernel level, if any occured.
software developed in vb.net(communicating with serialport) hanging and it is giving these rexceptions
1.The device does not recognize the command
2.Unhandled exception has occurred in your application. If you click continue, the application will ignore this error and attempt to continue. if you click Quit, the application will close immediatly. The device does not recognize the command..
I assume your question is incomplete. Please provide your code and the serialport library you use.
If you use .NET 2.0 (and above) System.IO.Ports.SerialPort, the exception is clearer and it's more device independent as long as you are communicating over serial port. If you don't, then the exception isn't clear and can be too broad or too specific for specific devices.