A simple run of ./listdevs from the libusb examples directory (without any devices connected) results in kernel messages like:
kernel[0]: [0xffffff8023f73c00](1)/(5) Device not responding
kernel[0]: com_apple_driver_AppleUSBCardReaderUMC:: Stop::Controller Reset
kernel[0]: considerRebuildOfPrelinkedKernel org.virtualbox.kext.VBoxDrv triggered rebuild
kernel[0]: USBMSC Identifier (non-unique): 000000009833 0x5ac 0x8403 0x9833, 2
More than one run may result in:
kernel[0]: AppleUSBMultitouchDriver::message - kIOUSBMessagePortHasBeenReset.
kernel[0]: AppleUSBMultitouchDriver: Touch failed to initialize after 765 ms
And at that point the internal keyboard and trackpad of my MacBook Pro are frozen. I can still use a Bluetooth keyboard and mouse. This was hard to track down since I first noticed it using a very simple test script which used pylibftdi (which uses libftdi, which uses libusb).
How can I fix this problem? Does this happen on older versions of OS X?
It turns out that libusbx does NOT exhibit this problem. In fact, it works perfectly.
Related
When I disabled SIP via recovery mode, the kext could be loaded by kextload, anyway, when system restart, kext will not be loaded by kext manager like it supposed to be in Mojave and lower.
If I enabled SIP and load the kext (the kext is full functional with 10.14 -), it will show following message
Kext rejected due to system policy: <OSKext 0x7ff02df0b450 [0x7fff89d4aba0]> { URL = "file:///Library/StagedExtensions/Library/Extensions/...
BTW, In Catalina, how user to allow a kext ? I know in 10.13, it will show on the General of Security & Privacy, in 10.14, I was using Kextdrop, anyway, kextdrop won't work with Catalina.
Found out I just need sign the kext and notarize the kext in order to get system to load it
When I run the simctl launch command to launch an app in iOS Simulator, the app may or may not come up, depending on how long it takes for the iOS Simulator to get its act together. The following observations lead me to believe that there is some sort of a timeout involved, but it's not apparent from the limited simctl documentation what that timeout is and how to control it.
When launching the app, it may not launch (iOS Simulator comes to the home screen) if the app is not up in anywhere from 35-90 seconds. However, if the app manages to launch in under 20 seconds, it always comes up.
If first launch fails, same app, same machine, same command will usually succeed on 2nd or 3rd attempt as whatever needs to 'warm up' does so.
I am guessing the timeout is probably 30 seconds. How can I set it to a larger value?
Update:
Here's our exact sequence of events:
If device is shut down, boot it (simctl boot ...) and wait for status to change to Booted in simctl list
Uninstall app (simctl uninstall ...)
Install app (simctl install ...)
Shut down the device (simctl shutdown ...) and wait till it has shut down
Start iOS Simulator (open -a "<path to simulator> --args -CurrentDeviceUDID <device id>)
Wait for device to reach status Booted
Launch app (simctl launch ...)
It is this last step that doesn't always succeed. There is no error, the app just doesn't come up.
There is no way to configure the timeout to be higher than 30s. 30s is already extremely high for the issue we have the timeout for (waiting for the system app to checkin). Assuming the device is already booted, that should not be an issue.
Update:
Based on the updated question, it is now clear that the device is being booted via 'simctl boot' rather than with the iOS Simulator. Currently, if you boot a device from the command line, it is only available for NonUI work (eg: unit tests) because the device is configured to not have a head attached to it. If you try to launch an app in this state, you will get an error because the system app is unavailable to respond to the launch request. I suspect you may instead want to do something like I describe in my answer to Xcode 6 - Launch simulator from command line
open -a "iOS Simulator" --args -CurrentDeviceUDID <DEVICE UDID>
simctl install ...
simctl launch ...
In other words, start at step 5.
If the iOS Simulator is already running, you have to switch to another device from the iOS Simulator GUI (or kill the process and relaunch it with the command line argument as above).
If the issue happens in the absence of using 'simctl boot', please update.
We had those issues exactly until we've upgraded hardware to device with SSD drive. Similarly to iPhoto... the iOS Simulator ceised to be usable on computers with classical hard drives. This seems like one of ways, how to force developers buy new hardware even though the old one would still work well.
I've just upgraded to Mountain Lion and Xcode 4.6 but have kept my phone on iOS 5.1 to ensure I can test my apps are backward compatible. I'd like to profile them using Instruments' TIme Profiler but I don't get any details when attaching to the app running on the device. Doing the same procedure works fine with the simulator thought. I Select my device as the target, "Build for Profiling" then "Profile", choose "Time Profiler" and the app starts on the device but I don't get any data at all, only a few little black flags to show low memory warnings. If I do the same thing targeting the simulator I get lots of data in the Call Tree panel. Is it not possible to Time Profile apps on devices? I think I have before.
It is possible to Time Profile apps on devices, but you might have unearthed an issue with Xcode 4.6 /iOS5.1 / device
instument: Leaks Time profiler
device:
iPad mini/iOS6.1 YES YES
iPhone4S/iOS5.1 YES IT DEPENDS...
iPhone3GS/iOS6.1 YES YES
simulator/iOS5.1 YES YES
"IT DEPENDS..."
...on whether you want your profile data live: the data seems to get recorded but you won't see it while the profiler is running. When you STOP, the call tree and samples list appears. Sometimes you have to do this twice to get a full list of samples (the first time you just get one sample)
This doesn't seem like something you'd want to rely on...
update
The same behaviour is exhibited under OSX 10.7/XCode4.4 and OSX 10.6.8/XCode4.2 so nothing seems to have changed. In fact the live use of Time Profiler on a device seems to be a new feature with iOS6+
We've observed that when attaching a device to Windows, all USB messages come and go as expected. However under Mac OS X, a device returning the same data as the last message will be 'swallowed' and not passed on to the calling App. On our device, we've taken to toggling a bit on every message we send back to ensure that these duplicates are not summarily deleted by the OS. The device is NOT a mouse/keyboard however is using HID.
Have others had similar experiences?
Why does Mac OS X do this?
Is there a way for the Mac OS X app to turn this 'de-duplication feature' off?
Short recap for people that came here via the internet search.
On some installations Delphi can't debug FireMonkey applications on OS X. Symptoms: Delphi starts loading the Debug desktop and then locks. Pressing Ctrl+C in the PAServer stops the PAServer and unfreezes the Delphi. The problem was observed with Delphi XE2 Update 4 and OS X 10.7.3.
Longer description is attached below.
I have a brand new Mac Mini (mc815z/a model - i5 2.3 GHz/2GB/500GB/Nvidia Intel HD Graphics 3000). It came with OS X Lion (10.7) which I upgraded to 10.7.3.
On my main computer (Windows 7 64-bit) runs Delphi XE2 Update 4. I've installed platform assistant from setup_paserver.zip (15.656.945 bytes). It installed Java first (Java for Mac OS X 10.7 Update 1). I'm starting PAServer via paserver.command and it seems to be working fine. PAServer says it is version 1.0.2.
Then I've set up a remote profile and it works fine (Test Connection reports success).
When I run (with debugging) a FireMonkey project (I tried various Sample projects and also fresh, minimal FireMonkey application), Delphi starts switching to the Debug layout and then freezes. PAServer reports:
Process Control Server Started pid 343 exe build Jan 15 2012
sentinelFunc 345
[The number in the second line is different every time I try to debug the program.] Nothing happens then. I can kill the PAServer with Ctrl-C and that unfreezes the Delphi. Delphi then reports error:
Debugger Assertion Failure: "obj"
in ..\win32src\rproxy.cpp at line 663
Package file seems fine to me:
I'm logged on locally as a user in the Admin group.
I can start the application from /Users/primoz/Applications/Embarcadero/PAServer/scratch-dir. No problems there. Run without debugging in Delphi also works. The problem only appears if I try to debug my app.
EDIT: This seems to be a problem with my Delphi installation. I tried the same from my notebook (also running XE2 Update 4) and it works just fine.
EDIT: It seems that this is related to my debug desktop. When I changed debug desktop to be the same as the edit desktop, problems disappeared.
EDIT: This problem only appears if I have 'Thread Status' window visible on the debug desktop. Furthermore, this is related to my Delphi installation - the other computer I tested on works fine with 'Thread Status' window visible.
This problems is related to the Thread Status window. If you experience locking while debugging on OS X, remove Thread Status from the Debug desktop.
Strangely, some XE2 Update 4 installations are working quite fine with Thread Status visible, and some are not.
If you Ctrl-click the app bundle you can choose "show package contents". Now you can browse for the executable itself (not the bundle). If you double click the executable it will run from a terminal window. With a bit of luck a helpful error message appears in the terminal window.
FWIW: my app works fine with 10.7.3 (not sure if I've tried it with PAServer after upgrading from 10.7.2)