[Bug 280941] The reboot command considered harmful
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280941 Bug ID: 280941 Summary: The reboot command considered harmful Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: an...@rambler.ru The `reboot' command violates the principle of least astonishment: although named after the common and regular operation, it is /not/ the recommended and graceful way to reboot the machine. For example, it does not invoke rc.shutdown(8). The Handbook therefore recommends initiating a reboot[1] with `shutdown -r now', which is a longer and less obvious command. Because of this, many users (and especially those coming from Linux), have been using `reboot' for years when they should have been using `shutdown -r' instead. To make the interface more logical and intuitive, I propose that a breaking change be introduced that causes `reboot' invoked without parameters to have an effect equivalent to that of `shutdown -r now', and to provide the current `reboot' behavior via `fastboot' and/or a new command-line option, such as -f or --fast. With that change, the bare `reboot' will do what its name suggests: a graceful reboot of the system. This dangerous `reboot' behavior was discussed on #freebsd on the 23rd of July, 2024, where gentler ways to amend the situation were proposed, including improving the documentaion and displaying a warning or error message from `reboot'. 1. https://docs.freebsd.org/en/books/handbook/boot/#boot-shutdown -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280941] The reboot command considered harmful
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280941 --- Comment #1 from Anton Shepelev --- (In reply to Anton Shepelev from comment #0) An important consideration in favor of my proposal is statistical: an overwhelming majority of situations when the user wishes to reboot his machine, call for a normal, graceful reboot, as effected by `shutdown -r [now]', rather than the fast reboot with an incomplete deinitialisation that `reboot' currently performs. It is therefore a matter of economy and elegance to make the more frequent command shorter and easier, and to handle the less frequent one as a special case with explicit activation. Since `reboot' and `halt' are a related pair, probably sharing a lot of the same code, my proposal affects them both in the same way. The existing `fastboot' and `fasthalt' aliases should them be redefined to `reboot -f' and `half -f' respectively. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280942] amdsmn(4), amdtemp(4): add support for AMD Family 19h Models 10h-1Fh.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280942 Bug ID: 280942 Summary: amdsmn(4), amdtemp(4): add support for AMD Family 19h Models 10h-1Fh. Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: o...@freebsd.org Created attachment 252943 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=252943&action=edit Patch for amdsmn.c and amdtemp.c to support AMD Ryzen 7 "Phoenix" The attached patch adds support for AMD Ryzen 7 "Phoenix" processors (family 0x19, model 0x70-0x7f) to the amdsmn(4) and amdtemp(4) drivers, enabling temperature readings of these CPUs via sysctl. The sensors work the same as for the "Raphael" processors (model 0x60-0x6f), only the PCI device ID differs. The patch applies cleanly to (15-) current, 14-stable and 13-stable, including 14.1-RELEASE and 13.4-BETA. However, I have *not* tested it on 13, but I'm fairly certain that it works there, too (as explained above, it's only the PCI device ID). Tested with Ryzen 7 8700G (family 0x19, model 0x75). Kernel messages: CPU: AMD Ryzen 7 8700G w/ Radeon 780M Graphics (4200.20-MHz K8-class CPU) Origin="AuthenticAMD" Id=0xa70f52 Family=0x19 Model=0x75 Stepping=2 [...] amdsmn0: on hostb0 amdtemp0: on hostb0 $ sysctl dev.amdtemp dev.amdtemp.0.core0.sensor0: 32.1C dev.amdtemp.0.sensor_offset: 0 dev.amdtemp.0.%parent: hostb0 dev.amdtemp.0.%pnpinfo: dev.amdtemp.0.%location: dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors dev.amdtemp.%parent: $ sysctl dev.cpu.0 dev.cpu.0.temperature: 32.1C dev.cpu.0.cx_method: C1/hlt C2/io C3/io dev.cpu.0.cx_usage_counters: 931437 0 0 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 1557us dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1/1 C2/2/18 C3/3/350 dev.cpu.0.freq_levels: 4200/5040 2200/2420 1600/1600 dev.cpu.0.freq: 1600 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=ACPI0007 _UID=0 _CID=none dev.cpu.0.%location: handle=\_SB_.PLTF.C000 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280942] amdsmn(4), amdtemp(4): add support for AMD Family 19h Models 70h-7Fh.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280942 Oliver Fromme changed: What|Removed |Added Summary|amdsmn(4), amdtemp(4): add |amdsmn(4), amdtemp(4): add |support for AMD Family 19h |support for AMD Family 19h |Models 10h-1Fh. |Models 70h-7Fh. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280941] The reboot command considered harmful
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280941 bugs.freebsd@aljoscha.vollmerhaus.net changed: What|Removed |Added CC||bugs.freebsd.org@aljoscha.v ||ollmerhaus.net --- Comment #2 from bugs.freebsd@aljoscha.vollmerhaus.net --- I'd like to add my experience here, as I was the reason for that discussion on the IRC channel. While trying to write an rc script for a program of mine, I spent hours trying to figure out why my shutdown procedure didn't work. Only after lengthy debugging, and with help from the kind folks on #freebsd, was I able to determine that the problem wasn't with my rc script but rather with the fact that I had been using "reboot" instead of "shutdown -r now." Although it was quickly pointed out that the behavior of "reboot" is clearly documented, I had no indication that I should even look at the docs for "reboot". Coming from a Linux background, I was under the assumption it would simply reboot the machine. And reboot it did, so nothing gave me any hint that I was doing something wrong. I had been restarting my FreeBSD machines using "reboot" for years at that point. This led me on a wild goose chase for a fault in my script that didn't exist. I was made aware that the meaning of "reboot" as "skip proper procedures" is a very old default and that changing this established behavior could disrupt old scripts and ingrained habits. However, at the very least, I believe a hint - such as printing something like "emergency reboot, skipping proper shutdown!" to stdout or stderr - should be added to the "reboot" command. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280941] The reboot command considered harmful
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280941 --- Comment #3 from Aljoscha Vollmerhaus --- With that said, I'm still in favor of actually changing the meaning of "reboot" to be less surprising for new users. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280817] With DMAR enabled, my laptop panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280817 --- Comment #18 from Konstantin Belousov --- Try https://reviews.freebsd.org/D46382 This should stop the panic (I hope), but still I need verbose dmesg to understand why the attach failing. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280817] With DMAR enabled, my laptop panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280817 --- Comment #19 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0875f3cd74b2f305e82bff4e640c89f891ca84f8 commit 0875f3cd74b2f305e82bff4e640c89f891ca84f8 Author: Ed Maste AuthorDate: 2024-08-20 15:43:11 + Commit: Ed Maste CommitDate: 2024-08-20 15:49:25 + Revert "x86: Enable Intel DMAR by default" A number of people have reported panics with it enabled by default, possibly due to broken ACPI tables, which we do not handle well. D46382 is a potential fix for this issue. Additionally DMAR is currently not compatible with bhyve passthrough (see comment #10 in PR280817), with a draft patch to address that in D25672. Revert to disabling DMAR by default pending the resolution of those two issues. This reverts commit 3192fc30230ae432b80cca783abc2dbea9d3f383. PR: 280817 Sponsored by: The FreeBSD Foundation sys/x86/iommu/intel_drv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280946] Realtek RTS522A recognized at boot but not when plugging a card.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280946 Bug ID: 280946 Summary: Realtek RTS522A recognized at boot but not when plugging a card. Product: Base System Version: 14.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: lorenzotor...@outlook.it I have recently installed FreeBSD 14.1-STABLE on my Thinkpad T14 (Intel), which has a Realtek RTS522A card for the microSD slot. I tried inserting a microSD card in my laptop only to find out it wasn't being recognized by the OS. I tried to reboot and my card was found. I gave a look at https://cgit.freebsd.org/src/tree/sys/dev/rtsx/rtsx.c#n182, and the card is supported indeed. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280946] Realtek RTS522A recognized at boot but not when plugging a card.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280946 --- Comment #1 from Lorenzo Torres --- dmesg when booting with the microSD in the laptop: rtsx0: <2.1g Realtek RTS522A PCIe SD Card Reader> mem 0xeb60-0xeb600fff at device 0.0 on pci1 rtsx0: A card is detected mmc0: on rtsx0 mmcsd0: 64GB at mmc0 50.0MHz/4bit/2048-block dmesg when booting without the microSD in the laptop: rtsx0: <2.1g Realtek RTS522A PCIe SD Card Reader> mem 0xeb60-0xeb600fff at device 0.0 on pci1 rtsx0: A card is detected mmc0: on rtsx0 rtsx0: Controller timeout for CMD8 rtsx0: Controller timeout for CMD8 rtsx0: Controller timeout for CMD8 rtsx0: Controller timeout for CMD8 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD55 rtsx0: Controller timeout for CMD1 rtsx0: Controller timeout for CMD1 rtsx0: Controller timeout for CMD1 rtsx0: Controller timeout for CMD1 mmc0: No compatible cards found on bus devd works since it correctly creates device files when I plug in a usb stick. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280817] With DMAR enabled, my laptop panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280817 Cy Schubert changed: What|Removed |Added CC||c...@freebsd.org --- Comment #20 from Cy Schubert --- hw.dmar.enable="0" in loader.conf is the quick and dirty workaround. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280817] With DMAR enabled, my laptop panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280817 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org Status|New |Open --- Comment #21 from Mark Johnston --- Enabling DMAR also breaks suspend-to-S3 on my framework 13. During resume, the screen doesn't turn on and I can hear fans spinning. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280817] With DMAR enabled, my laptop panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280817 --- Comment #22 from Ed Maste --- (In reply to Mark Johnston from comment #21) > Enabling DMAR also breaks suspend-to-S3 on my framework 13. Oh yeah, from Val Packett: https://reviews.freebsd.org/D22642 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280950] DMAR (hw.dmar.enable=1) breaks resume
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280950 Bug ID: 280950 Summary: DMAR (hw.dmar.enable=1) breaks resume Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ema...@freebsd.org See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280817#c21 and https://reviews.freebsd.org/D22642 > Enabling DMAR also breaks suspend-to-S3 on my framework 13. During resume, > the > screen doesn't turn on and I can hear fans spinning. Split out from PR280817 as that issue is specific to the crash Warner encountered. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280817] With DMAR enabled, my laptop panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280817 Ed Maste changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2809 ||50 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280952] DMAR (hw.dmar.enable=1) incompatible with bhyve passthrough
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280952 Bug ID: 280952 Summary: DMAR (hw.dmar.enable=1) incompatible with bhyve passthrough Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ema...@freebsd.org Split out from PR280817 as that one is specific to the crash that Warner encountered. >From https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280817#c10 > You cannot combine DMAR and bhyve pass-through right now. Draft patch is at https://reviews.freebsd.org/D25672 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280817] With DMAR enabled, my laptop panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280817 Ed Maste changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2809 ||52 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280952] DMAR (hw.dmar.enable=1) incompatible with bhyve passthrough
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280952 Ed Maste changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2809 ||50 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280950] DMAR (hw.dmar.enable=1) breaks resume
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280950 Ed Maste changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2809 ||52 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280959] New FreeBSD EC2 Machines Don't Boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280959 Bug ID: 280959 Summary: New FreeBSD EC2 Machines Don't Boot Product: Base System Version: 13.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ploops...@gmail.com Hi! I *think* this only happens on smaller EC2 instances. If I specify an instance size that doesn't have enough memory for `freebsd-update` to complete, it runs out of memory, the kernel panics, the instance reboots, and the whole thing starts again. When I'm using `freebsd-update` on older instances which are small enough that `freebsd-update` can't run, I just turn on swap and then try again. However, all of the versions of FreeBSD that are current have `firstboot_freebsd_update_enable="YES"`. The instance never comes up completely, so I can't add swap. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280959] New FreeBSD EC2 Machines Don't Boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280959 --- Comment #1 from Sridhar Ayengar --- This happens with machines with 1GB RAM even. I can give a 2GB instance a try, if you want me to. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280959] New FreeBSD EC2 Machines Don't Boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280959 --- Comment #2 from Sridhar Ayengar --- Indeed, it looks like a 2GB RAM machine works fine. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264757] fetch: Show correct port number in -vv output
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264757 Mallory changed: What|Removed |Added Attachment #234771|0 |1 is obsolete|| --- Comment #2 from Mallory --- Created attachment 252969 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=252969&action=edit usr.bin/fetch: Show correct port number in -vv output PATCH v2 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 264757] fetch: Show correct port number in -vv output
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264757 Kyle Evans changed: What|Removed |Added Flags|maintainer-feedback?(kevans |maintainer-feedback?(des@Fr |@freebsd.org) |eeBSD.org) CC||d...@freebsd.org --- Comment #3 from Kyle Evans --- des probably has more of an opinion on this than I would -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280959] New FreeBSD EC2 Machines Don't Boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280959 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|virtualizat...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280965] Typo in comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280965 Bug ID: 280965 Summary: Typo in comment Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ka...@freebsd.org Created attachment 252975 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=252975&action=edit fix typo The attached patch fixes a typo in a comment in lib/msun/src/math_private.h. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280909] Please add the vm.swap_free sysctl variable
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280909 Tatsuki Makino changed: What|Removed |Added CC||tatsuki_mak...@hotmail.com --- Comment #3 from Tatsuki Makino --- swapctl -l seems to be getting it by sysctl. https: //cgit.freebsd.org /src/tree/sbin/swapon/swapon.c#n821 However, vm.swap_info does not appear to be a structure that can be directly displayed by sysctl commands. How about formatting output of swapon using libxo like df? https: //cgit.freebsd.org /src/tree/bin/df/df.c#n458 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280966] sysctl(8) doesn't show some array variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280966 Bug ID: 280966 Summary: sysctl(8) doesn't show some array variables Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: y...@freebsd.org For example, this command succeeds but prints nothing: > sysctl vm.swap_info > sysctl -F vm.swap_info > sysctl -x vm.swap_info In fact, this value is an array of integers, see https://cgit.freebsd.org/src/tree/sbin/swapon/swapon.c#n821 -- You are receiving this mail because: You are the assignee for the bug.
