I am getting regular kernel panics. I have a Kern*.panic file, and a .contents.panic These files now contain a 'macOSProcessedStackshotData' and so are encoded. I'm a dev, but not familiar with Apple Kernel debugging (though I've done this before on windows/aix/linux). How can I get some simple info from the panic, such as kernel backtrace, loaded drivers etc? Ideally I'm looking for a few points to specific drivers (maybe I can unplug a device) or situations I can avoid

When using STP 126 on both Monterey beta 1 & Big Sur 11.4, a 'tab group' created in STP is not saved (ie if browser restarts it's gone), nor does it appear to be synced across to iOS or Safari 15 (either direction). There's no indication in the release notes this is intentional. Does anyone have even saving working, let alone sync? The tab groups are a wonderful idea - I played with them for a while on Monterey but need my main dev box on Big Sur for now, so was hoping STP would keep me happy :-) Also raised a feedback: FB9219350

With beta 1, I can go into settings->network->wifi->advanced & have a selectable option per network 'use iCloud Private Relay' I also have an ethernet adapter, Belkin USB-C LAN . If I selet this I see no options for private relay (nor under advanced) I guess it's not implemented for lan?

How do I enable core dumps, persistently, in Big Sur. I am more versed in *nix/linux than macOS. I've had a few apps core dump, and see in the 'Console' that they are not permitted to create core files. I've tried 'ulimit -c unlimited' but this hasn't been perspective - perhaps in part as I'm unsure how to get this persistent for all apps (even outside a login shell) on Big Sur. Is there a simple guide to allowing core dumps ie into /cores as I was able to get that working in previous releases...

Hi, (note I've obfuscated the ping address - it was only an example url! but forums wouldn't let me post!) I have just switched to Zen -ie an Internet provider offering full dual stack IPv4/6 support, using a Fritzbox 7530 and am experiencing a delay , seemingly in name resolution, when using 'ping6'. The same configuration is also supporting iOS, windows, linux, raspberry pi - and these devices all seem to work fine. The symptom is: 'ping www DOT ibm DOT com' -> instant response, start getting icmp request/response ping6 'www DOT ibm DOT com' -> About a 3-4s delay after typing the command before the pings start ie: $ ping6 www DOT ibm DOT com ... delay here ... PING6(56=40+8+8 bytes) 2a02:8010:687f:0:2dbc:1ea2:a301:b111 --> 2a02:26f0:e8:491::b3a 16 bytes from 2a02:26f0:e8:491::b3a, icmp_seq=0 hlim=58 time=11.621 ms 16 bytes from 2a02:26f0:e8:491::b3a, icmp_seq=1 hlim=58 time=10.486 ms 16 bytes from 2a02:26f0:e8:491::b3a, icmp_seq=2 hlim=58 time=11.994 ms The same behaviour is seen for other IPv6 sites such as ipv6.google.com Using 'nslookup' I also get a delay: $ nslookup ... delay actually occurs here ipv6.google.com Server: 192.168.178.1 Address: 192.168.178.1#53 Non-authoritative answer: ipv6.google.com canonical name = ipv6.l.google.com. > That delay is almost as if it's reverse resolving itself - or a localhost issue? All the ipv6 testers I've tried in a browser suggest my IPv6 config is fine, sites reachable I don't notice delays in google chrome If IPv4 is disabled no delays occur The router is set to automatic IPv6 (with fast commit) The macOS Wifi adapter is set to automatic for ipv6 (and dhcp for ipv4) scutil --dns ends with DNS configuration (for scoped queries) resolver #1 search domain[0] : fritz.box nameserver[0] : 192.168.178.1 nameserver[1] : fd00::2e91:abff:fe55:2d26 if_index : 5 (en0) flags : Scoped, Request A records, Request AAAA records reach : 0x00020002 (Reachable,Directly Reachable Address) So ipv6 addresses are being requested /etc/hosts has # Host Database # localhost is used to configure the loopback interface when the system is booting. Do not change this entry. 0.0.1 localhost ::1 localhost fe80::1%lo0 localhost End of section .178.48 pi4 Any ideas why the delay? Once past that ipv6 and ipv4 are both working fine it seems (from limited tests so far)