Searched hist:42135 (Results 1 - 7 of 7) sorted by relevance
| /freebsd-10.2-release/sys/i386/i386/ | ||
| H A D | db_interface.c | diff 42135 Mon Dec 28 23:03:00 MST 1998 msmith Improved DDB_UNATTENDED behaviour. From the submitter: There's something that's been bugging me for a while, so I decided to fix it. FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least in my opinion. The behavior change is such that: 1. Nothing changes when debugger_on_panic != 0. 2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the machine will reboot. Also, if a trap occurs, the machine will panic and reboot, unlike how it broke to DDB before. HOWEVER, a trap inside DDB will not cause a panic, allowing full use of DDB without having to worry about the machine being stuck at a DDB prompt if something goes wrong during the day. Patches for this behavior follow my signature, and it would be a boon to anyone (like me) who uses DDB_UNATTENDED, but actually wants the machine to panic on a trap (otherwise, what's the use, if the machine causes a fatal trap rather than a true panic, of debugger_on_panic?). The changes cause no adverse behavior, but do involve two symbols becoming global Submitted by: Brian Feldman <green@unixhelp.org> |
| H A D | trap.c | diff 42135 Mon Dec 28 23:03:00 MST 1998 msmith Improved DDB_UNATTENDED behaviour. From the submitter: There's something that's been bugging me for a while, so I decided to fix it. FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least in my opinion. The behavior change is such that: 1. Nothing changes when debugger_on_panic != 0. 2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the machine will reboot. Also, if a trap occurs, the machine will panic and reboot, unlike how it broke to DDB before. HOWEVER, a trap inside DDB will not cause a panic, allowing full use of DDB without having to worry about the machine being stuck at a DDB prompt if something goes wrong during the day. Patches for this behavior follow my signature, and it would be a boon to anyone (like me) who uses DDB_UNATTENDED, but actually wants the machine to panic on a trap (otherwise, what's the use, if the machine causes a fatal trap rather than a true panic, of debugger_on_panic?). The changes cause no adverse behavior, but do involve two symbols becoming global Submitted by: Brian Feldman <green@unixhelp.org> |
| /freebsd-10.2-release/sys/amd64/amd64/ | ||
| H A D | db_interface.c | diff 42135 Mon Dec 28 23:03:00 MST 1998 msmith Improved DDB_UNATTENDED behaviour. From the submitter: There's something that's been bugging me for a while, so I decided to fix it. FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least in my opinion. The behavior change is such that: 1. Nothing changes when debugger_on_panic != 0. 2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the machine will reboot. Also, if a trap occurs, the machine will panic and reboot, unlike how it broke to DDB before. HOWEVER, a trap inside DDB will not cause a panic, allowing full use of DDB without having to worry about the machine being stuck at a DDB prompt if something goes wrong during the day. Patches for this behavior follow my signature, and it would be a boon to anyone (like me) who uses DDB_UNATTENDED, but actually wants the machine to panic on a trap (otherwise, what's the use, if the machine causes a fatal trap rather than a true panic, of debugger_on_panic?). The changes cause no adverse behavior, but do involve two symbols becoming global Submitted by: Brian Feldman <green@unixhelp.org> |
| H A D | trap.c | diff 42135 Mon Dec 28 23:03:00 MST 1998 msmith Improved DDB_UNATTENDED behaviour. From the submitter: There's something that's been bugging me for a while, so I decided to fix it. FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least in my opinion. The behavior change is such that: 1. Nothing changes when debugger_on_panic != 0. 2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the machine will reboot. Also, if a trap occurs, the machine will panic and reboot, unlike how it broke to DDB before. HOWEVER, a trap inside DDB will not cause a panic, allowing full use of DDB without having to worry about the machine being stuck at a DDB prompt if something goes wrong during the day. Patches for this behavior follow my signature, and it would be a boon to anyone (like me) who uses DDB_UNATTENDED, but actually wants the machine to panic on a trap (otherwise, what's the use, if the machine causes a fatal trap rather than a true panic, of debugger_on_panic?). The changes cause no adverse behavior, but do involve two symbols becoming global Submitted by: Brian Feldman <green@unixhelp.org> |
| /freebsd-10.2-release/sys/kern/ | ||
| H A D | kern_shutdown.c | diff 42135 Mon Dec 28 23:03:00 MST 1998 msmith Improved DDB_UNATTENDED behaviour. From the submitter: There's something that's been bugging me for a while, so I decided to fix it. FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least in my opinion. The behavior change is such that: 1. Nothing changes when debugger_on_panic != 0. 2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the machine will reboot. Also, if a trap occurs, the machine will panic and reboot, unlike how it broke to DDB before. HOWEVER, a trap inside DDB will not cause a panic, allowing full use of DDB without having to worry about the machine being stuck at a DDB prompt if something goes wrong during the day. Patches for this behavior follow my signature, and it would be a boon to anyone (like me) who uses DDB_UNATTENDED, but actually wants the machine to panic on a trap (otherwise, what's the use, if the machine causes a fatal trap rather than a true panic, of debugger_on_panic?). The changes cause no adverse behavior, but do involve two symbols becoming global Submitted by: Brian Feldman <green@unixhelp.org> |
| H A D | subr_syscall.c | diff 42135 Mon Dec 28 23:03:00 MST 1998 msmith Improved DDB_UNATTENDED behaviour. From the submitter: There's something that's been bugging me for a while, so I decided to fix it. FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least in my opinion. The behavior change is such that: 1. Nothing changes when debugger_on_panic != 0. 2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the machine will reboot. Also, if a trap occurs, the machine will panic and reboot, unlike how it broke to DDB before. HOWEVER, a trap inside DDB will not cause a panic, allowing full use of DDB without having to worry about the machine being stuck at a DDB prompt if something goes wrong during the day. Patches for this behavior follow my signature, and it would be a boon to anyone (like me) who uses DDB_UNATTENDED, but actually wants the machine to panic on a trap (otherwise, what's the use, if the machine causes a fatal trap rather than a true panic, of debugger_on_panic?). The changes cause no adverse behavior, but do involve two symbols becoming global Submitted by: Brian Feldman <green@unixhelp.org> |
| H A D | subr_trap.c | diff 42135 Mon Dec 28 23:03:00 MST 1998 msmith Improved DDB_UNATTENDED behaviour. From the submitter: There's something that's been bugging me for a while, so I decided to fix it. FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least in my opinion. The behavior change is such that: 1. Nothing changes when debugger_on_panic != 0. 2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the machine will reboot. Also, if a trap occurs, the machine will panic and reboot, unlike how it broke to DDB before. HOWEVER, a trap inside DDB will not cause a panic, allowing full use of DDB without having to worry about the machine being stuck at a DDB prompt if something goes wrong during the day. Patches for this behavior follow my signature, and it would be a boon to anyone (like me) who uses DDB_UNATTENDED, but actually wants the machine to panic on a trap (otherwise, what's the use, if the machine causes a fatal trap rather than a true panic, of debugger_on_panic?). The changes cause no adverse behavior, but do involve two symbols becoming global Submitted by: Brian Feldman <green@unixhelp.org> |
Completed in 454 milliseconds