Post not yet marked as solved
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...
Post not yet marked as solved
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
Post not yet marked as solved
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
Post not yet marked as solved
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?
Post not yet marked as solved
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)
planetf1.