MP 1,1-5,1 Mac OS 11.3 has broken support for older Mac Pros

[nekton1]

You are welcome, but I can assure you it's not new. I found it myself over one year ago in https://github.com/ameyrupji/thunderbolt-macpro-5-1/blob/master/GC-TitanRidge.md. There's a more modern Titan Ridge TB 3 card now, one sporting USB C 3.2. Mine is only 3.1.

Thanks for the links Peter. I have all the required kit and will try on a cMP 3,1.

 

[Dayo]

One way to cause a deadlock is to have multiple processes that use locks in a different order.
Process 1: lock A -> lock B -> do stuff
Process 2: lock B -> lock A -> do stuff
If Process 1 locks A and Process 2 locks B, then Process 1 can't lock B so it's stuck. Process 2 can't lock A so it's stuck. The locks have to be used in the same order

They might just need the resources in a different order and typically there are intervening steps. You see similar sometimes in applications that need to lock database tables. You could try to refactor the code to force everything to assess resources in one particular sequence as you propose but it might just not be possible.

In such cases, the thing to do is to acquire both locks together. For instance, Process A will actually lock Resource A and Resource B before starting work needing Resource A. If it can't lock both, unlock any successful locks, wait and try again.

Process 1: lock A & lock B -> do stuff if both locks succeed, otherwise, unlock, wait, try again.
Process 2: lock B & lock A -> do stuff if both locks succeed, otherwise, unlock, wait, try again

This can still fluke into a deadlock if the wait periods are the same. very low probability but can be eliminated by having different wait times. Process A waits for 0.5 sec and Process B waits for 0.7 sec for instance.

 

[PeterHolbrook]

Has a method been discovered to cause the 11.3+boot process to consistently fail at the same spot on any Mac Pro 5,1? If this has been achieved, is it possible to further alter the boot process, even if it fails immediately somewhere else? On the other hand, if systems are halted in several unpredictable locations, wouldn't that be a symptom of the Xeon's predictive execution branching? If so, is there a way to force an Intel processor to run in a more linear way (i.e., without predictive branching)?

 

[startergo]

Ok so I started debugging the 12.0 Kernel following:

Debugging macOS Kernel For Fun

Hi there! It’s GeoSn0w. Debugging the damn kernel is a very entertaining thing to do (until you provoke a serious exception, that is, and the kernel crawls into a corner from which it refuses to get out). Unfortunately, it’s not an easy task nowadays and Apple seems to want to make it harder and...

geosn0w.github.io

Unfortunately there is a syntax error in one of the files:

Spoiler: Syntax Error

on ttys002
MBP113@MBP113 ~ % xcrun lldb /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development
(lldb) target create "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development"
warning: 'kernel' contains a debug script. To run this script in this debug session:

    command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py"

To run all discovered debug scripts in this session:

    settings set target.load-script-from-symbol-file true

Current executable set to '/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development' (x86_64).
(lldb) settings set target.load-script-from-symbol-file true
##############################
WARNING! Python version 3 is not supported for xnu lldbmacros.
Please restart your debugging session with the following workaround

defaults write com.apple.dt.lldb LegacyPythonVersion 2


OR relaunch lldb session with env LLDB_DEFAULT_PYTHON_VERSION=2

##############################


Loading kernel debugging from /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py
LLDB version lldb-1205.0.27.3
Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55)
settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py"
settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec
command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py"
error: module importing failed: Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py", line 123
    print "Execution interrupted by user"
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Execution interrupted by user")?
settings set target.process.optimization-warnings false


(lldb)

But strangely it does not hang on boot. Also I get the infamous

The added boot arguments are:

debug=0x8146 kdp_match_name=firewire fwdebug=0x40 pmuflags=1 -v

I am using the firewire port on the cMP and the thunderbolt 2 to firewire on my MBP11,3. Not sure which one of the boot arguments should I use but I tried both (the one on the top and added fwkdp=0x8000)
Still the syntax error prevents debugging.

 

[cdf]

But strangely it does not hang on boot.

Interesting. Is this just with the debugging setup or in general with Monterey?

 

[startergo]

Interesting. Is this just with the debugging setup or in general with Monterey?

I don't know really what caused it. Perhaps any of these 2 flags or both:

• fwdebug=0x40 -> Enables more verbose output from the AppleFWOHCI_KDP driver, it is useful for troubleshooting.
• pmuflags=1 -> This one disables the Watchdog timer.

I know for sure that as long I get "You shut down your computer because of a problem" after boot it will not hang on boot. This is what previously happened to @TECK when he did not have issues with booting.

Edit:
My full boot arguments are:

-v -no_compat_check keepsyms=1 debug=0x8146 kdp_match_name=firewire fwkdp=0x8000 fwdebug=0x40 pmuflags=1 -lilubetaall -liludbgall

Also please note Lilu has been updated:

Lilu patcher: @ previous plugin had short jump type on a multiroute function, this is not allowed · Issue #1698 · acidanthera/bugtracker

Panic Log panic(cpu 22 caller 0xffffff801be46199): Lilu patcher: @ previous plugin had short jump type on a multiroute function, this is not allowed Backtrace (CPU 22), Frame : Return Address 0xfff...

github.com

Fix race condition in kext patching on macOS 11 · acidanthera/Lilu@f69a972

Arbitrary kext and process patching on macOS. Contribute to acidanthera/Lilu development by creating an account on GitHub.

github.com

You can get the latest debug Lilu here:
Artifacts

 

[cdf]

I don't know really what caused it. Perhaps any of these 2 flags or both:

It would be interesting to try these flags on Big Sur. The beta of Monterey might be compiled without certain optimizations: this could explain the bootability.

 

[PeterHolbrook]

Fix race condition in kext patching on macOS 11 · acidanthera/Lilu@f69a972

Arbitrary kext and process patching on macOS. Contribute to acidanthera/Lilu development by creating an account on GitHub.

github.com

Isn't this precisely what we have all been waiting for? Or is this a different race condition?

 

[tsialex]

Isn't this precisely what we have all been waiting for? Or is this a different race condition?

Nope. We don't even need kext patching.

Has a method been discovered to cause the 11.3+boot process to consistently fail at the same spot on any Mac Pro 5,1? If this has been achieved, is it possible to further alter the boot process, even if it fails immediately somewhere else? On the other hand, if systems are halted in several unpredictable locations,

Wrong, it's fairly consistent.

wouldn't that be a symptom of the Xeon's predictive execution branching? If so, is there a way to force an Intel processor to run in a more linear way (i.e., without predictive branching)?

Nothing to do with the issue. All Intel processors are branch predictive since Pentium MMX.

 

[startergo]

Isn't this precisely what we have all been waiting for? Or is this a different race condition?

But the race condition exists even without OC just with -no_compat_check

 

[Chung123]

My pollyanna streak with 11.4 on my 5,1 finally ended I had an issue with a restart this morning.

Just before this happened, the system itself started to not feel right. Pages were loading slow in Safari and then became unresponsive. Proceeded to reboot, but Safari was busy or hung. Had to force quit Safari and then Mac proceeded to reboot.

This time:

1) I got the no symbol with link to support.apple.com/mac/startup
(I did not notice my camera was connected via USB which I then disconnected--not sure if related to this reboot hang.)

2) Pressed the power button to shut down and then performed another reboot and white progress bar slowed and hung during this attempt. (Normally its fairly fast)

3) Shut down again. Connected wired keyboard and Command+Option+P+R 3x in a row and it then started up correctly back into 11.4

 

[startergo]

It would be interesting to try these flags on Big Sur. The beta of Monterey might be compiled without certain optimizations: this could explain the bootability.

I have already upgraded 11.5 beta 6 BS to Monterey. Someone else can test them on BS.

 

[joevt]

Ok so I started debugging the 12.0 Kernel following:

Debugging macOS Kernel For Fun

Hi there! It’s GeoSn0w. Debugging the damn kernel is a very entertaining thing to do (until you provoke a serious exception, that is, and the kernel crawls into a corner from which it refuses to get out). Unfortunately, it’s not an easy task nowadays and Apple seems to want to make it harder and...

geosn0w.github.io

Unfortunately there is a syntax error in one of the files:

Spoiler: Syntax Error

on ttys002
MBP113@MBP113 ~ % xcrun lldb /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development
(lldb) target create "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development"
warning: 'kernel' contains a debug script. To run this script in this debug session:

    command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py"

To run all discovered debug scripts in this session:

    settings set target.load-script-from-symbol-file true

Current executable set to '/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development' (x86_64).
(lldb) settings set target.load-script-from-symbol-file true
##############################
WARNING! Python version 3 is not supported for xnu lldbmacros.
Please restart your debugging session with the following workaround

defaults write com.apple.dt.lldb LegacyPythonVersion 2


OR relaunch lldb session with env LLDB_DEFAULT_PYTHON_VERSION=2

##############################


Loading kernel debugging from /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py
LLDB version lldb-1205.0.27.3
Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55)
settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py"
settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec
command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py"
error: module importing failed: Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py", line 123
    print "Execution interrupted by user"
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Execution interrupted by user")?
settings set target.process.optimization-warnings false


(lldb)

But strangely it does not hang on boot. Also I get the infamous
View attachment 1795998
The added boot arguments are:

debug=0x8146 kdp_match_name=firewire fwdebug=0x40 pmuflags=1 -v

I am using the firewire port on the cMP and the thunderbolt 2 to firewire on my MBP11,3. Not sure which one of the boot arguments should I use but I tried both (the one on the top and added fwkdp=0x8000)
Still the syntax error prevents debugging.

For the syntax error, did you do as suggested and set lldb to use Python 2?

Did you try firewire kprintf at the same time as firewire debug to capture the system log? Run the kprintf thingy in another Terminal window. I don't remember how to do it exactly. I wrote the following 5 years ago. I need to find my other firewire notes (maybe they're on the Hackintosh)

Your motherboard has a COM port header. You can add a COM port header to RS232 adapter to use it as a serial port which you can connect to another computer. To use the serial port, you have to enable it in BIOS. This might cause Mac OS to crash if you don't make a change to kernel extensions, or DSDT, or device-properties (see https://www.tonymacx86.com/threads/...ort-on-gigabyte-z170x-running-10-11-4.191172/)

Or if your computer has a FireWire port (either from a PCIe card or from a Thunderbolt adapter) then you can connect that to another computer.

Then the system log (IOLog) and kernel printf or kprintf debug info can be logged from your Hackintosh to the other computer in realtime, so you can see what's happening even before MacOS has finished booting, or when it's shutting down, or sleep/wake.

To make the system log and kernel printf debug info go to the serial or firewire port, you need to add some boot args. This can easily be done with Clover by editing the config.plist.

debug=0x14e (this sets DB_LOG_PI_SCRN, DB_ARP, DB_KPRT, DB_NMI, DB_PRT. Some of those are optional)
serial=3 (serial console, serial keyboard, though I don't think you'll be using it to send keyboard commands to a console).
serialbaud=115200 (115.2 kbps baud rate)
io=0x00200000 (Optional, sets kIOLogSynchronous which causes IOLog commands to complete synchronously which might help to cleanup some debug output? or maybe not, I'm not sure it's useful. There are lots of other bits for io that might be useful for debugging kernel extensions.)

For Firewire, you would also add these (use "man fwkdp" in Terminal.app to get more information):
kdp_match_name=firewire
fwkpf=0x8000
fwkdp=0x8000

Remember you can google most of these boot arguments by using something like this:
"pe_parse_boot_argn serial" site:apple.com
"pe_parse_boot_argn io" site:apple.com

Then google for the variable used to store the result like this:
"serialmode" site:apple.com
"gIOKitDebug" site:apple.com

Other info:
https://developer.apple.com/library...Driver/DebuggingDrivers/DebuggingDrivers.html

 

[cdf]

My full boot arguments are:

-v -no_compat_check keepsyms=1 debug=0x8146 kdp_match_name=firewire fwkdp=0x8000 fwdebug=0x40 pmuflags=1 -lilubetaall -liludbgall

Also please note Lilu has been updated:

Tried booting 11.3 with these boot arguments and the new Lilu. The hanging persists, so your successful booting is probably due to Monterey.

 

[startergo]

so your successful booting is probably due to Monterey.

It actually hung once. It is much better though.

For the syntax error, did you do as suggested and set lldb to use Python 2?

Yes, but it does not seem to have effect:

Spoiler: Debug log

defaults write com.apple.dt.lldb LegacyPythonVersion 2
MBP113@MBP113 ~ % xcrun lldb /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development
(lldb) target create "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development"
warning: 'kernel' contains a debug script. To run this script in this debug session:

    command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py"

To run all discovered debug scripts in this session:

    settings set target.load-script-from-symbol-file true

Current executable set to '/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development' (x86_64).
(lldb) settings set target.load-script-from-symbol-file true
##############################
WARNING! Python version 3 is not supported for xnu lldbmacros.
Please restart your debugging session with the following workaround

defaults write com.apple.dt.lldb LegacyPythonVersion 2


OR relaunch lldb session with env LLDB_DEFAULT_PYTHON_VERSION=2

##############################


Loading kernel debugging from /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py
LLDB version lldb-1205.0.27.3
Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55)
settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py"
settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec
command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py"
error: module importing failed: Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py", line 123
    print "Execution interrupted by user"
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Execution interrupted by user")?
settings set target.process.optimization-warnings false


(lldb) kdp-remote localhost
error: KDP_REATTACH failed

I got this in another window:

Spoiler: Firewire debug window

fwkdp -v
FireWire KDP Tool (v1.6)
KDP Proxy and CoreDump-Receive dual mode active.
Use 'localhost' as the KDP target in gdb.
Ready.
Matched on device 0x00001603
Created plugin interface 0x7fc29c409378 with result 0x00000000
Created device interface 0x7fc29c409fb8 with result 0x00000000
Opened device interface 0x7fc29c409fb8 with result 0x00000000
Added callback dispatcher with result 0x00000000
Created pseudo address space 0x7fc29c40a328 at 0xf0430000
Address space enabled.
2021-06-21 10:02:07.530 fwkdp[1006:11939] CFSocketSetAddress listen failure: 102
Created KDP socket listener 0x7fc29c40a4f0 with result 0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xe5c3 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xe5c3 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 c3 e5 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 c3 e5
socketRXHandler: Generation (0x2) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xe5c3 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xe5c3 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 c3 e5 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 c3 e5
socketRXHandler: Generation (0x2) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xe5c3 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xe5c3 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 c3 e5 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 c3 e5
socketRXHandler: Generation (0x5) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xb2c0 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xb2c0 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 c0 b2 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 c0 b2
socketRXHandler: Generation (0x6) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xb2c0 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xb2c0 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 c0 b2 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 c0 b2
socketRXHandler: Generation (0x6) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xb2c0 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xb2c0 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 c0 b2 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 c0 b2
socketRXHandler: Generation (0x6) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xdc2 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xdc2 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 c2 0d a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 c2 0d
socketRXHandler: Generation (0x30) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xdc2 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xdc2 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 c2 0d a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 c2 0d
socketRXHandler: Generation (0x30) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xdc2 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xdc2 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 c2 0d a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 c2 0d
socketRXHandler: Generation (0x30) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x61f4 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x61f4 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 f4 61 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 f4 61
socketRXHandler: Generation (0x34) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x61f4 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x61f4 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 f4 61 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 f4 61
socketRXHandler: Generation (0x34) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x61f4 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x61f4 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 f4 61 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 f4 61
socketRXHandler: Generation (0x34) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x4bda sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x4bda uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 da 4b a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 da 4b
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x4bda sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x4bda uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 da 4b a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 da 4b
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x4bda sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x4bda uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 da 4b a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 da 4b
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xc8fd sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xc8fd uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 fd c8 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 fd c8
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xc8fd sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xc8fd uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 fd c8 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 fd c8
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xc8fd sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xc8fd uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 fd c8 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 fd c8
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x93cb sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x93cb uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 cb 93 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 cb 93
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x93cb sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x93cb uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 cb 93 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 cb 93
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x93cb sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x93cb uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 cb 93 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 cb 93
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xbdd3 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xbdd3 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 d3 bd a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 d3 bd
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xbdd3 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xbdd3 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 d3 bd a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 d3 bd
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xbdd3 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xbdd3 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 d3 bd a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 d3 bd
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xa7d2 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xa7d2 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 d2 a7 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 d2 a7
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xa7d2 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xa7d2 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 d2 a7 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 d2 a7
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xa7d2 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xa7d2 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 d2 a7 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 d2 a7
socketRXHandler: Generation (0x36) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xd7ea sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xd7ea uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 ea d7 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 ea d7
socketRXHandler: Generation (0x38) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xd7ea sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xd7ea uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 ea d7 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 ea d7
socketRXHandler: Generation (0x38) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xd7ea sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xd7ea uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 ea d7 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 ea d7
socketRXHandler: Generation (0x38) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x59d2 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x59d2 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 d2 59 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 d2 59
socketRXHandler: Generation (0x42) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x59d2 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x59d2 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 d2 59 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 d2 59
socketRXHandler: Generation (0x43) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0x59d2 sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0x59d2 uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 d2 59 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 d2 59
socketRXHandler: Generation (0x43) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xe6fb sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xe6fb uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 fb e6 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 fb e6
socketRXHandler: Generation (0x43) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xe6fb sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xe6fb uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 fb e6 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 fb e6
socketRXHandler: Generation (0x43) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xb2df sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xb2df uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 df b2 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 df b2
socketRXHandler: Generation (0x49) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xb2df sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xb2df uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 df b2 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 df b2
socketRXHandler: Generation (0x49) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
socketRXHandler: 10 bytes received
socketRXHandler: sa_len: 16
socketRXHandler: sin_len 0x10 sin_family 0x2 sin_port 0xb2df sin_addr 0x100007f sin_zer0: 0x0
socketRXHandler: UDP packet ether_type:0x8 ih_vhl:0x45 id_pr:0x11 id_len:0x0 ih_src:0x0100007f ih_dst:0x00000000 uh_sport:0xb2df uh_dport:0xb3a0 uh_ulen:0x1200 uh_csum:0x0
socketRXHandler: NodeID 0xffff addressHi 0x4343 addressLo 0x00000000
socketRXHandler: varLen: 0x00000034
debug_printBuffer (52):
0x 00 00 00 00 00 00 00 00
0x 00 00 00 00 08 00 45 00
0x 00 00 00 00 00 00 00 11
0x 00 00 7f 00 00 01 00 00
0x 00 00 df b2 a0 b3 00 12
0x 00 00 12 00 0a 00 00 00
0x 00 00 df b2
socketRXHandler: Generation (0x49) result 0x0
socketRXHandler: Write sent to node 0xffff with result 0x0
Matched on device 0x00001e03
Created plugin interface 0x7fc29c6042c8 with result 0x00000000
Created device interface 0x7fc29c6044d8 with result 0x00000000
Opened device interface 0x7fc29c6044d8 with result 0x00000000
Added callback dispatcher with result 0x00000000
Created pseudo address space 0x7fc29c704278 at 0xf0430000
Address space enabled.
2021-06-21 13:36:40.209 fwkdp[1006:11939] CFSocketSetAddress bind failure: 48
Created KDP socket listener 0x7fc29c706560 with result -1

Not sure how to force python 2.

 

[JeDiGM]

Wasn't Firewire phased out in 2012 and wasn't BS was the first OS to completely phase out 2012 models? Related or am I completely wrong? Did Apple move from phase out to straight up murder in BS and our helpless cMPs fell victim to the killing spree? If this is obvious or was already talked about somewhere in the last 50 pages I do apologize. I wouldn't want to be perceived as going off topic again in here and risk drowning in the sea of tears that ensues when one does.

 

[lovely666]

Unfortunately there is a syntax error in one of the files:

Hey that's because the debug script is being run on python3 instead of python2 (python3 change the syntax of print statements: eg print "foo" -to-> print("foo"). It says in the warning above how to fix it.

WARNING! Python version 3 is not supported for xnu lldbmacros.
Please restart your debugging session with the following workaround

defaults write com.apple.dt.lldb LegacyPythonVersion 2
OR relaunch lldb session with env LLDB_DEFAULT_PYTHON_VERSION=2

How are you running the kernel debugger? eg how do you start it up (via the terminal?)

--------------

Last night I installed 11.4 kdk, and booted the kasan kernel. (basically it's a kernel that checks all the memory address in use in realtime)

My first boot was greeted by this: which is the cause for one kernel panic I've had before. (I think this is caused by some sort of race condition, because makeUsagable is getting called before Name is set, or it could be a deeper problem with os_log, haven't investigated it fully)

However to get past this, I set io=0x7f (to disable power logging), and now i get this: (haven't had a chance to confirm it multiple times.)

 

[startergo]

It says in the warning above how to fix it.

If you look at my last post you will notice that defaults write com.apple.dt.lldb LegacyPythonVersion 2 is my first line and it still complains afterwards and suggests the same cure.
Now that I think about this I may have to mount writeable the system volume first before defaults write in Catalina, BS, Monterey?

 

[tsialex]

Wasn't Firewire phased out in 2012 and wasn't BS was the first OS to completely phase out 2012 models? Related or am I completely wrong? Did Apple move from phase out to straight up murder in BS and our helpless cMPs fell victim to the killing spree? If this is obvious or was already talked about somewhere in the last 50 pages I do apologize. I wouldn't want to be perceived as going off topic again in here and risk drowning in the sea of tears that ensues when one does.

Firewire here is just being used as a connection to the Mac running the remote debugger (there are also other ways to do it like USB-C/TB/console/serial/ethernet/Apple interfaces connected to LITTLEFRANK) and has nothing to do with the MacPro5,1 problems.

 

[JeDiGM]

Firewire here is just being used as a connection to the Mac running the remote debugger (there are also other ways to do it like USB-C/TB/console/serial/ethernet/Apple interfaces connected to LITTLEFRANK) and has nothing to do with the MacPro5,1 problems.

Thanks @tsialex. I figured it was being used here as a serial type of connection for debugging. I thought I'd ask in case it might help and be relevant. If it were the cause then maybe disabling it somehow might fix the issue. Thanks for clarifying.

 

[joevt]

It actually hung once. It is much better though.

Yes, but it does not seem to have effect:

Spoiler: Debug log

defaults write com.apple.dt.lldb LegacyPythonVersion 2
MBP113@MBP113 ~ % xcrun lldb /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development
(lldb) target create "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development"
warning: 'kernel' contains a debug script. To run this script in this debug session:

    command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py"

To run all discovered debug scripts in this session:

    settings set target.load-script-from-symbol-file true

Current executable set to '/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development' (x86_64).
(lldb) settings set target.load-script-from-symbol-file true
##############################
WARNING! Python version 3 is not supported for xnu lldbmacros.
Please restart your debugging session with the following workaround

defaults write com.apple.dt.lldb LegacyPythonVersion 2


OR relaunch lldb session with env LLDB_DEFAULT_PYTHON_VERSION=2

##############################


Loading kernel debugging from /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py
LLDB version lldb-1205.0.27.3
Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55)
settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py"
settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec
command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py"
error: module importing failed: Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py", line 123
    print "Execution interrupted by user"
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Execution interrupted by user")?
settings set target.process.optimization-warnings false


(lldb) kdp-remote localhost
error: KDP_REATTACH failed

I got this in another window:

Spoiler: Firewire debug window

fwkdp -v
FireWire KDP Tool (v1.6)
KDP Proxy and CoreDump-Receive dual mode active.
Use 'localhost' as the KDP target in gdb.
Ready.
Matched on device 0x00001603
Created plugin interface 0x7fc29c409378 with result 0x00000000
Created device interface 0x7fc29c409fb8 with result 0x00000000
Opened device interface 0x7fc29c409fb8 with result 0x00000000
Added callback dispatcher with result 0x00000000
Created pseudo address space 0x7fc29c40a328 at 0xf0430000
Address space enabled.
2021-06-21 10:02:07.530 fwkdp[1006:11939] CFSocketSetAddress listen failure: 102
Created KDP socket listener 0x7fc29c40a4f0 with result 0

Not sure how to force python 2.

I did some testing from my MacPro3,1 Catalina (the debugger) connected via FireWire to MacMini8,1 Big Sur (the debugee). I used the defaults write com.apple.dt.lldb LegacyPythonVersion 2 to get lldb to work. I invoked lldp without xcrun but I can use xcrun without issue. I am using Catalina as the debugger. Does Big Sur come with Python 2?

MacMini8,1 boot-args were -v debug=0x14e fwkdp=0x8000 fwkpf=0x8000 kdp_match_name=firewire

On the MacPro, start one terminal window with fwkdp, start another window with fwkpfv, start a third window with lldb. Read the man page for fwkdp and fwkpfv for more info. (right click each command name and select "Open man Page".

In the lldb window, you can do:
target create /Library/Developer/KDKs/KDK_11.4_20F71.kdk/System/Library/Kernels/kernel
settings set target.load-script-from-symbol-file true

Then boot the debugee. fwkpfv will start showing log messages when the AppleFWOHCI_KPF is started. This is a little bit later than when you would start seeing log messages from serial kprintf serial=3 serialbaud=115200

You cannot start debugging the debugee until it is waiting for the debugger to connect. You do that with an NMI.
https://developer.apple.com/library/archive/qa/qa1264/_index.html
Hold the left and right command keys and press the power button momentarily. fwkpfv will show a message Waiting for remote debugger connection.. Now you can enter kdp-remote localhost in lldb which will use the fwkdp proxy to transmit and receive kdp commands between the debugee and lldb.

If your boot-args has debug flag DB_NMI_BTN_ENA 0x8000 then you just need to press the power button without the command keys.
https://opensource.apple.com/source/xnu/xnu-7195.101.1/osfmk/kern/debug.h.auto.html

For debugging the startup of macOS, I suppose you'll want to have it wait for the debugger to connect earlier. There's probably a flag for that. I am getting a panic after trying to continue from lldb. Maybe I need that pmuflags=1 to disable some watchdog timer that causes a panic if you stay too long in the debugger.

I think debugging the release kernel lacks symbols. Should follow the KDK instructions in /Library/Developer/KDKs/KDK_11.4_20F71.kdk/KDK_ReadMe.rtfd to use the development kernel like the article at https://geosn0w.github.io/Debugging-macOS-Kernel-For-Fun/ suggests. It's interesting that the KDK readme removed the instructions for FireWire kdp even though it still works (maybe it doesn't work on Apple Silicon?).

 

[joevt]

One thing missing in my debug tests is the part where after you do kdp-remote localhost, it's suppose to load all the symbols for all the kexts even if you're using the normal kernel? This output is from in 2016:

kdp-remote localhost
Version: Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64; UUID=7E7B0822-D2DE-3B39-A7A5-77B40A668BC6; stext=0xffffff800bc00000
Kernel UUID: 7E7B0822-D2DE-3B39-A7A5-77B40A668BC6
Load Address: 0xffffff800bc00000
Kernel slid 0xba00000 in memory.
Loaded kernel file /Library/Developer/KDKs/KDK_10.11.5_15F34.kdk/System/Library/Kernels/kernel
Loading 119 kext modules Target arch: x86_64
Instantiating threads completely from saved state in memory.
.Target arch: x86_64
Instantiating threads completely from saved state in memory.

Where the last two lines repeat approximately 119 times. Then when you type image list, it should show all the kexts and where they're loaded.

 

[startergo]

I used the defaults write com.apple.dt.lldb LegacyPythonVersion 2 to get lldb to work. I invoked lldp without xcrun but I can use xcrun without issue. I am using Catalina as the debugger. Does Big Sur come with Python 2?

It does, but for some reason it is not using it:

Spoiler: lldb

which python
/usr/bin/python
MBP113@MBP113 ~ % python --version
Python 2.7.16
MBP113@MBP113 ~ % lldb
(lldb) target create /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development
warning: 'kernel' contains a debug script. To run this script in this debug session:

    command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py"

To run all discovered debug scripts in this session:

    settings set target.load-script-from-symbol-file true

Current executable set to '/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development' (x86_64).
(lldb) command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py"
##############################
WARNING! Python version 3 is not supported for xnu lldbmacros.
Please restart your debugging session with the following workaround

defaults write com.apple.dt.lldb LegacyPythonVersion 2


OR relaunch lldb session with env LLDB_DEFAULT_PYTHON_VERSION=2

##############################


Loading kernel debugging from /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py
LLDB version lldb-1205.0.27.3
Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55)
settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py"
settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec
command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py"
error: module importing failed: Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py", line 123
    print "Execution interrupted by user"
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Execution interrupted by user")?
settings set target.process.optimization-warnings false


(lldb)

Spoiler: Python version

/usr/bin/lldb -P
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/Python
MBP113@MBP113 ~ % /usr/bin/lldb --version
lldb-1205.0.27.3
Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55)
MBP113@MBP113 ~ % /Library/Developer/CommandLineTools/usr/bin/lldb -P
/Library/Developer/CommandLineTools/Library/PrivateFrameworks/LLDB.framework/Resources/Python
MBP113@MBP113 ~ % /Library/Developer/CommandLineTools/usr/bin/lldb --version
lldb-1205.0.27.3
Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55)
MBP113@MBP113 ~ % /Library/Developer/CommandLineTools/usr/bin/lldb
(lldb) target create /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development
warning: 'kernel' contains a debug script. To run this script in this debug session:

    command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py"

To run all discovered debug scripts in this session:

    settings set target.load-script-from-symbol-file true

Current executable set to '/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development' (x86_64).
(lldb) settings set target.load-script-from-symbol-file true
##############################
WARNING! Python version 3 is not supported for xnu lldbmacros.
Please restart your debugging session with the following workaround

defaults write com.apple.dt.lldb LegacyPythonVersion 2


OR relaunch lldb session with env LLDB_DEFAULT_PYTHON_VERSION=2

##############################


Loading kernel debugging from /Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/kernel.py
LLDB version lldb-1205.0.27.3
Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55)
settings set target.process.python-os-plugin-path "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/core/operating_system.py"
settings set target.trap-handler-names hndl_allintrs hndl_alltraps trap_from_kernel hndl_double_fault hndl_machine_check _fleh_prefabt _ExceptionVectorsBase _ExceptionVectorsTable _fleh_undef _fleh_dataabt _fleh_irq _fleh_decirq _fleh_fiq_generic _fleh_dec
command script import "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py"
error: module importing failed: Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Developer/KDKs/KDK_12.0_21A5248o.kdk/System/Library/Kernels/kernel.development.dSYM/Contents/Resources/Python/lldbmacros/xnu.py", line 123
    print "Execution interrupted by user"
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("Execution interrupted by user")?
settings set target.process.optimization-warnings false


(lldb)

 

[joevt]

It does, but for some reason it is not using it:

Try the env method?
env LLDB_DEFAULT_PYTHON_VERSION=2 lldb

 

[lovely666]

It does, but for some reason it is not using it:

In my system i see two plugin script interpreter, i assume python is 2 and python3 is python3.

ls -la /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A:
drwxr-xr-x 8 root wheel 256 Jan 9 11:06 .
drwxr-xr-x 4 root wheel 128 Jan 29 02:00 ..
-rwxr-xr-x 1 root wheel 209625232 Jan 9 11:06 LLDB
drwxr-xr-x 11 root wheel 352 Jan 9 10:54 Resources
drwxr-xr-x 4 root wheel 128 Jan 9 10:54 XPCServices
drwxr-xr-x 3 root wheel 96 Dec 22 14:39 _CodeSignature
-rwxr-xr-x 1 root wheel 4619568 Jan 9 10:55 liblldbPluginScriptInterpreterPython.dylib
-rwxr-xr-x 1 root wheel 4641152 Jan 9 10:55 liblldbPluginScriptInterpreterPython3.dylib