[Bug 262335] top(1) doesn't clear battery % display when going from 100% to 99%
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262335 --- Comment #1 from Rajeev Pillai --- Created attachment 232244 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232244=edit patch to make top(1) clear battery % field when going from 100 to 99 % -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262335] top(1) doesn't clear battery % display when going from 100% to 99%
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262335 Bug ID: 262335 Summary: top(1) doesn't clear battery % display when going from 100% to 99% Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: rajeev_v_pil...@yahoo.com -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262334] su(1) does not set correct argv[0]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262334 Bug ID: 262334 Summary: su(1) does not set correct argv[0] Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: rajeev_v_pil...@yahoo.com Created attachment 232243 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232243=edit patch to set correct argv[0] in invoked shell su(1) does not set the correct argv[0]. It should set argv[0] corresponding to the shell that will be invoked instead of always setting it to "su"/"-su"/"_su". $ su Password: root@x202e:/tmp # echo $0 su root@x202e:/tmp # ^D $ su -l Password: root@x202e:~ # echo $0 -su root@x202e:~ # ^D $ The attached patch sets argv[0] to "shell"/"-shell" according to the invoked shell. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262332] libxo: Update to 1.6.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262332 Bug ID: 262332 Summary: libxo: Update to 1.6.0 Product: Base System Version: Unspecified Hardware: Any URL: https://github.com/Juniper/libxo/releases OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: jldu...@gmail.com CC: p...@freebsd.org We have libxo-1.4.0 currently in base, is it possible to update it to the latest 1.6.0? There are a few bugs that were fixed in 1.5.0 and it would be nice to have them integrated. Thank you! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262316] em(4) does not autonegotiate when fixed media is set
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262316 --- Comment #3 from J.R. Oldroyd --- IEEE Std 802.3-2008 Clause 28 Auto-Negotiation Section 28.1.2 ... It is highly recommended that this method alone be utilized to perform the negotiation of the link operation. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261311] loader sets console colors to white on black
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261311 --- Comment #6 from Ed Maste --- kern.vt.color.#.rgb indeed have no effect with vt_vga though, which always uses the standard VGA palette for text and graphics modes - we should note this in vt(4). vt_vga.c configures the attribute registers to map the 16 colors to palette entries, but does not configure the palette entries themselves. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261311] loader sets console colors to white on black
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261311 Ed Maste changed: What|Removed |Added Summary|vt newcons does not respect |loader sets console colors |colors set in kernel|to white on black |configuration file | CC||tso...@freebsd.org --- Comment #5 from Ed Maste --- Try setting these undocumented tunables: teken.fg_color teken.bg_color It appears this is not an issue with vt, but rather an issue with the loader always setting these to provide a white-on-black console. See commits: 3001e0c942d80 233ab015c0d73 a536ed419e6ab -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262316] em(4) does not autonegotiate when fixed media is set
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262316 J.R. Oldroyd changed: What|Removed |Added Resolution|Not A Bug |--- Status|Closed |Open --- Comment #2 from J.R. Oldroyd --- Stefan, I believe you are mis-reading the standard. You are quoting what the standard says to do in the event of autonegotiation failure. In that event, setting half-duplex is indeed the required behavior. However, citing from the same article that you cited, "The Ethernet standards and major Ethernet equipment manufacturers recommend enabling autonegotiation." If both ends of a link are not under common administrative control, it may not be possible to set both ends to matching modes. Clearly, having a device inform the other end what its configured capabilities are is preferable to having a non-working link. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262316] em(4) does not autonegotiate when fixed media is set
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262316 Stefan Eßer changed: What|Removed |Added Resolution|--- |Not A Bug Status|New |Closed CC||s...@freebsd.org --- Comment #1 from Stefan Eßer --- The behavior is correct according to the standard! See: https://en.wikipedia.org/wiki/Duplex_mismatch If a device is set to a fixed speed and media setting, a connecting device configured to perform auto-negotion may detect the speed, but must assume half-duplex mode. This may not be the expected behavior today, but is what the standard demands. Either use auto-negotiation on both interfaces or set both to matching modes. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 241697] i915kms: Kernel panic loading module on custom kernel w/ MAXCPU < 256 (Invalid CPU in callout 256)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241697 --- Comment #6 from Hans Petter Selasky --- At work we simply dump: sysctl kern.conftxt and run configure on that to get all the options correct. --HPS -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259019] kld_list="radeonkms" in /etc/rc.conf -> kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259019 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #3 from Ed Maste --- If you have a panic with kld_list="radeonkms" and success with kld_list="/boot/modules/radeonkms.ko" it sounds to me like there are at least two copies of radeonkms on this system (one in /boot/modules/ perhaps?), one of which is old/broken/incompatible. radeonkms should not panic regardless of whether xf86-video-ati is installed or not - it is perfectly reasonable to install the KMS drivers to have a high-resolution console and so that suspend/resume works, even if X is not in use. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 257291] panic: deadlres_td_sleep_q: possible deadlock detected on 14.0-n248045-76fffd0a865 (in vt_kms_postswitch: sys/modules/drm-current-kmod/drivers/gpu/drm/linux_fb.c)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257291 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #2 from Ed Maste --- Looks like stuck in NFS: 0 3716 3711 1 52 0 22092 6004 nfs D - 0:07.85 [find] -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262241] gpart(8) destroy: option -F seems to not effectively destroy all partitions in some situations
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262241 --- Comment #4 from Ed Maste --- > So "gpart destroy -F geom" does _not_ actually wipe the partition block That's a different from what's being described here, so please add precise details/reproduction steps. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 241697] i915kms: Kernel panic loading module on custom kernel w/ MAXCPU < 256 (Invalid CPU in callout 256)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241697 --- Comment #5 from Ed Maste --- There is a broad issue with out-of-tree kernel modules not picking up kernel configuration options; we need to develop a holistic solution for this. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 194420] unloading i915kms causes black screen and reboot.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194420 Ed Maste changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2123 ||71 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 212371] Screen displays garbage after `kldunload i915kms`
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212371 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=1944 ||20 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 194420] unloading i915kms causes black screen and reboot.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194420 Ed Maste changed: What|Removed |Added Version|10.0-STABLE |CURRENT --- Comment #5 from Ed Maste --- Black screen upon 'kldunload i915kms' still reproducible on 14-CURRENT. Observed hang not panic, perhaps due to different default panic action. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261440] vt newcons breaks suspend/resume for all graphics cards that do not use KMS drivers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261440 Ed Maste changed: What|Removed |Added Keywords||vt -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262316] em(4) does not autonegotiate when fixed media is set
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262316 Bug ID: 262316 Summary: em(4) does not autonegotiate when fixed media is set Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: f...@opal.com Created attachment 232221 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232221=edit patch to enable autonegotiation in em(4) for fixed media settings Following brief discussion on freebsd-net@ [1] ... An em(4) interface configured with fixed media/mediatype settings, as in: ifconfig em0 media 100baseTX mediatype full-duplex does not respond to autonegotiation from the switch it is connected to. (Actually, it does for 1000base but not for 100base or 10base.) As a result, the switch may end up with mismatched configuration. Attached patch enables autonegotiation even when media settings are set to fixed 100base or 10base. The autonegotiation will advertize just the configured media setting. I think there should probably also be: hw->phy.autoneg_wait_to_complete = FALSE; for these 100base and 10base cases to handle the situation where the other end isn't going to autonegotiate either. I have no means to test this. [1] https://lists.freebsd.org/archives/freebsd-net/2022-March/001371.html -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261751] vt mouse pointer background display bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261751 --- Comment #8 from Stefan B. --- Built both the first patch, and the patch posted in the phabricator review. Looks fine so far. The strange red background box seems gone, didn't reappear at my quick test. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262290] After a normal FreeBSD installation and reboot, /etc/resolv.conf will be changed.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262290 Li-Wen Hsu changed: What|Removed |Added CC||lw...@freebsd.org Resolution|FIXED |Works As Intended --- Comment #3 from Li-Wen Hsu --- If you have local_unbound enabled, having 127.0.0.1 /etc/resolv.conf is correct because it supposes to use the local caching resolver. If you cannot "connect to the network" (I guess this means "cannot resolve a hostname"), please check if the local_unbound daemon is really running. (`$ service local_unbound status`) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262290] After a normal FreeBSD installation and reboot, /etc/resolv.conf will be changed.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262290 ykla changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #2 from ykla --- Thanks a lot. -- You are receiving this mail because: You are the assignee for the bug.
