#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
b498331b |
|
26-May-2023 |
John Reimer <John_Reimer@Dell.com> |
netgdb: Fix netgdb double ack, print proxy address - Fixes netgdb's double ack - Moving ack responsibility to debugnet, decision to ack made by netdump/netgdb. - Finish responsibility moved to debugnet, new finish handler. - netgdb now prints the address to connect to in case the user doesn't have access to the proxy machine. Sponsored by: Dell EMC Reviewed By: markj, bdrewery (earlier version) Differential Revision: https://reviews.freebsd.org/D40064
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
|
#
258958b3 |
|
05-Jul-2022 |
Mitchell Horne <mhorne@FreeBSD.org> |
ddb: use _FLAGS command macros where appropriate Some command definitions were forced to use DB_FUNC in order to specify their required flags, CS_OWN or CS_MORE. Use the new macros to simplify these. Reviewed by: markj, jhb MFC after: 3 days Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D35582
|
#
7029da5c |
|
26-Feb-2020 |
Pawel Biernacki <kaktus@FreeBSD.org> |
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many) r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718
|
#
879e0604 |
|
11-Jan-2020 |
Mateusz Guzik <mjg@FreeBSD.org> |
Add KERNEL_PANICKED macro for use in place of direct panicstr tests
|
#
6310546d |
|
17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
gdb(4): Implement support for NoAckMode When the underlying debugport transport is reliable, GDB's additional checksums and acknowledgements are redundant. NoAckMode eliminates the the acks and allows us to skip checking RX checksums. The GDB packet framing does not change, so unfortunately (valid) checksums are still included as message trailers. The gdb(4) stub in FreeBSD advertises support for the feature in response to the client's 'qSupported' request IFF the current debugport has the gdb_dbfeatures flag GDB_DBGP_FEAT_RELIABLE set. Currently, only netgdb(4) supports this feature. If the remote GDB client supports the feature and does not have it disabled via a GDB configuration knob, it may instruct our gdb(4) stub to enter NoAckMode. Unless and until it issues that command, we must continue to transmit acks as usual (and for now, we continue to wait until we receive them as well, even if we know the debugport is on a reliable transport). In the kernel sources, the sense of the flag representing the state of the feature is reversed from that of the GDB command. (I.e., it is 'gdb_ackmode', not 'gdb_noackmode.') This is to avoid confusing double- negative conditions. For reference, see: * https://sourceware.org/gdb/onlinedocs/gdb/Packet-Acknowledgment.html * https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#QStartNoAckMode Reviewed by: jhb, markj (both earlier version) Differential Revision: https://reviews.freebsd.org/D21761
|
#
dda17b36 |
|
17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Implement NetGDB(4) NetGDB(4) is a component of a system using a panic-time network stack to remotely debug crashed FreeBSD kernels over the network, instead of traditional serial interfaces. There are three pieces in the complete NetGDB system. First, a dedicated proxy server must be running to accept connections from both NetGDB and gdb(1), and pass bidirectional traffic between the two protocols. Second, the NetGDB client is activated much like ordinary 'gdb' and similarly to 'netdump' in ddb(4) after a panic. Like other debugnet(4) clients (netdump(4)), the network interface on the route to the proxy server must be online and support debugnet(4). Finally, the remote (k)gdb(1) uses 'target remote <proxy>:<port>' (like any other TCP remote) to connect to the proxy server. The NetGDB v1 protocol speaks the literal GDB remote serial protocol, and uses a 1:1 relationship between GDB packets and sequences of debugnet packets (fragmented by MTU). There is no encryption utilized to keep debugging sessions private, so this is only appropriate for local segments or trusted networks. Submitted by: John Reimer <john.reimer AT emc.com> (earlier version) Discussed some with: emaste, markj Relnotes: sure Differential Revision: https://reviews.freebsd.org/D21568
|