A note:
I'm working on reverse engineering a certain OS X driver dependent on physical hardware, so a VM environment just won't do.
In my environment I have 2x 2015 Macbook Pro's running OS X 10.11.6 (15G18013) and have installed the latest KDK on both. To perform the remote debugging I setup network debugging over Ethernet using a Thunderbolt NIC on the second machine.
I have lldb working for the most part. I can set breakpoints, resume the kernel and breakpoint just fine, but the problem is after some time of doing ni (next instruction) I get the error error: invalid thread, and I can't send anymore commands to the other machine. When in this state the machine is still frozen (since I was stepping over instructions) and I can't seem to reattach to the other machine either, even after doing an NMI.
The latest KDK for 10.11.6 is 15G17023. You can downgrade or wait for apple to release 15G18013.
I have the same problem if I want to test the latest updates from apple with a kext.
Related
I'm currently trying to run ARM assembly on my DE series board. However when I try to open my project I get the following error on the Intel FPGA Monitor Program:
Error running 'make DETECT_DEVICES'. (java.io.IOException: The pipe is
being closed)
How can I solve that?
Depends on the OS you are running. If you are running on Windows 11, it's not going to work because there is no USB Blaster II driver support for it unfortunately.
(see: https://community.intel.com/t5/Programmable-Devices/USB-Blaster-for-Windows-11/m-p/1422212#M87272)
NazrulNaim_Intel Employee
10-16-2022 11:57 PM
Hi Fari,
Regarding the issue with the USB blaster, as mention by ak6dn there will be issues regarding installing the USB blaster in Windows 11 because It is not officially supported yet by Intel. We cannot sure that it will 100% works in windows 11. As for work around to troubleshoot the issue, you can follow the instruction from the link that I have attached below.
https://www.terasic.com.tw/wiki/Altera_USB_Blaster_Driver_Installation_Instructions
Regards,
Nazrul Naim
I suggest you use a VM with Windows 10 if that's the case.
The FPGA monitor program requires WSL1 with a Linux distro installed on your PC. Make sure WSL1 is set to default, WSL2 is not supported and will result in crashes while trying to compile your code.
To install WSL1 and set it to default, follow this link:
https://learn.microsoft.com/en-us/windows/wsl/install
After installation, launch the installed distro and follow this link step by step:
https://www.intel.com/content/www/us/en/docs/programmable/683525/21-3/installing-windows-subsystem-for-linux.html
Although the document refers to the NIOS II EDS it is also applicable for the FPGA monitor.
Also make sure that the version of Quartus corresponds to the version of the FPGA monitor and keep the Linux distro running in the background while compiling.
I'm trying to kernel debug a physical Macbook pro device.
When my setup contains a VM, between a host MacOS and guest MacOS, its working with no problem using lldb -o "kdp-remote <guest_machine_ip>"
my boot-args on my remote (to debug) Macbook are:
user$ nvram boot-args
boot-args debug=0x44 kext-dev-mode=1 pmuflags=1 -v kcsuffix=debug
When i'm triggering kernel debug using either
sudo dtrace -w -n "BEGIN { breakpoint(); }"
or LEFT CMD + RIGHT CMD + PowerButton, the system is in halt mode, not responsive to anything (Mouse not moving, etc)
But when I'm trying to connect to the machine from the host using the lldb command provided earlier, it's not working.
I've made sure the machines can ping each other and I can set up a SSH connection.
To the best of my understanding, I had to user special Apple adapters (Real™ Ethernet adapter), so I'm using the following adapters to debug the remote machine:
https://www.apple.com/shop/product/MMEL2AM/A/thunderbolt-3-usb-c-to-thunderbolt-2-adapter
https://www.apple.com/shop/product/MD463LL/A/thunderbolt-to-gigabit-ethernet-adapter
The physical connections setup looks like that:
MacOS-Debugger --(USBC to Ethernet adapter)--> Ethernet cable <-- (ThunderBolt to Ethernet adapter) <-- (ThunderBolt3 to ThunderBolt2 adapter) <-- MacOS-debuggee
Generally for the debugging I used the following tutorial, which worked for VM debugging:
https://knight.sc/debugging/2018/08/15/macos-kernel-debugging.html, I didn't find the exact KDK version, but I don't think it should be the problem here
My debugger is BigSur, and my debugee is Catalina
Any ideas to what the problem may be will be helpful
Your hardware setup sounds fine. Note that you don't necessarily need a direct ethernet cable connection, you can use your normal office-/home-wide wired network, it's fine to have a switch (or even more than one) between debugger and target. The debugger machine can even be using wifi as long as it can reach the target's wired network connection that way, though it's not recommended. The Thunderbolt Ethernet interface need not be Apple branded, but its driver does need to include kernel debugging support. In practice, for example, I've successfully used the Ethernet port in a OWC brand Thunderbolt Dock as well. Using one of Apple's own adapters of course guarantees it will work.
If the boot-args on your target machine are the same as what you used in the VM, that's probably where your problem is coming from. You should specify the device to be used for kernel debugging, using the kdp_match_name= option. Use the ifconfig command in the Terminal to work out which of the listed devices is your Thunderbolt ethernet adapter (enX), possibly based on the IP address. en0 is typically wifi in Mac laptops, so you're usually looking for X > 0.
So you'll end up with something like kdp_match_name=en1 added to your boot-args. Make sure to reboot the machine cleanly before attempting a debugging session after updating the boot-args setting.
A few more comments:
kext-dev-mode=1
This option no longer has any effect. It only existed in OS X 10.10. You can remove it.
I didn't find the exact KDK version, but I don't think it should be the problem here
Having a KDK version that doesn't match the target's exact kernel binary UUID will not prevent a connection, but it will prevent you from doing any meaningful debugging as the memory layout of threads etc. will not be available.
My debugger is Big Sur, and my debuggee is Catalina
If you ever run Big Sur on your target, make sure to add wdt=-1 to your boot-args or the hung/crashed machine will reboot before you get a chance to connect with the debugger.
I have to use firewire as my kernel extension loads before the target has an IP address.
My kernel extension calls PE_enter_debugger() in its start routine.
I see "waiting for debugger" twice, then just once the console says
"kdp_poll: no debugger device".
I would think that means the nvram boot-args is wrong but I've
followed the instructions:
debug=0x814e kcsuffix=development kdp_match_name=firewire fwkdp=0x8000
The host is a late 2012 Mac Mini, macOS 10.12.4 build 16E195.
The target is a mid 2010 Mac Pro with the same macOS build.
My kernel debug kit matches the macOS build.
Google yields no joy. Have you a clue for me?
The 2010 Mac Pro has built-in Firewire ports and no Thunderbolt, so I think your problem might be the fwkdp=0x8000 setting. As far as I'm aware, you only want to set that if you're debugging through a Thunderbolt-Firewire adapter (or Thunderbolt display's or dock's Firewire port) on the target machine side.
(Sorry, only just seen your question as I have alerts on the 'xnu' and 'kext' tags but 'kernel' and 'osx' are too noisy.)
I learn to use lldb to debug mac IOKit drivers in macOS 10.12.3.
two machine debug.
It's easy to connect to target machine when panic occurs.
I wonder how to show target machine system message?
Is there any command like "dmesg" in lldb?
You can connect the target and debugger machine using a FireWire cable. Set the 0x08 bit in the target machine's debug= kernel argument (DB_KPRT), and anything logged with kprintf (note: not printf/IOLog) will be routed to FireWire. (Firewire is used unless the Mac has a Serial port, which modern Macs do not - virtual machines can, though.)
To view this output, you need to be running the fwkpfv command on the Mac on the other end of the Firewire cable.
This method works fine with Thunderbolt-to-Firewire adapters and docks too, although I suspect not if you hotplug them.
Currently i'm developing a Cocos2d application for Mac OS X using xCode 4.2.1.So my problem is,sometimes while running the program the system get's stuck and show me a message like this- You need to restart your computer.Hold down the power button until it turns off.Then press the power button again. After receiving this message i can't proceed further without restarting the computer. What might be the problem behind this issue. Can anyone help me out.
What You get is called a kernel panic.
Resolution
Restart your Mac with a Safe Boot and see if the kernel panic happens
again
In most cases, kernel panics are not caused by an issue with your Mac.
They are most likely caused by an issue external to your Mac. If the
kernel panic doesn't happen again within a few weeks, you don't need
to troubleshoot further.
Depending on the model of Mac you have, restart one of these ways:
• Press and hold the Power button for several seconds to turn off your Mac. Then, press the Power button to startup your Mac.
• If you have a Restart button, press it.
As soon as your Mac starts up, hold down the Shift key to start up with a Safe Boot into Safe Mode. Note: If you are using a third-party
external keyboard and cannot start with a Safe Boot, try using an
Apple keyboard instead.
If your Mac has a kernel panic starting up, or while in Safe Mode, jump to the "Troubleshooting a recurring kernel panic" section of this
article.
If your Mac starts up without a kernel panic after a Safe Boot, restart your Mac by choosing Apple Menu > Restart…, then let it start
up normally. Run Software Update and install all available updates
until Software Update reports "Your software is up to date". Mac OS X
updates improve the tolerance for external issues such as malformed
network packets. For most kernel panics, this is all you have to do.
Note: It is possible, although very unlikely, that something on your network is sending your Mac malformed network packets which could cause recurring kernel panics. If the hardware and software on your Mac checks out as OK, check the devices on your network. Make sure your router's firmware is up-to-date, and that the router is not malfunctioning. Refer to your router's manufacturer for service and support.
And You also can try to find the problem in kernel.log. Go to the console app in the utilities folder and then type this:
tail -f /var/log/kernel.log
It will print kernel.log file to Your console.
More information:
Kernel Logs from the Command Line in Mac OS X.
How to log a kernel panic.
Kernel Panic.