[Bug 284130] vt console driver KMS: system console is not working
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284130 --- Comment #2 from Artem Kim --- (In reply to Mark Johnston from comment #1) excuse me. It's really important. vt worked well with the previous version of the port drm-kmod-20220907_3 drm] Radeon Display Connectors [drm] Connector 0: [drm] DP-1 [drm] HPD5 [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] DP-2 [drm] HPD4 [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY2 [drm] Connector 2: [drm] HDMI-A-1 [drm] HPD6 [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [drm] Encoders: [drm] DFP3: INTERNAL_UNIPHY1 [drm] Connector 3: [drm] DVI-D-1 [drm] HPD1 [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [drm] Encoders: [drm] DFP4: INTERNAL_UNIPHY1 [drm] Connector 4: [drm] DVI-I-1 [drm] HPD3 [drm] DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c 0x647c [drm] Encoders: [drm] DFP5: INTERNAL_UNIPHY [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] fb mappable at 0xD0371000 [drm] vram apper at 0xD000 [drm] size 5242880 [drm] fb depth is 24 [drm]pitch is 5120 VT: Driver priority 0 too low. Current 100 fbd0: not attached to vt(4) console; another device has precedence (err=17) [drm] Initialized radeon 2.50.0 20080528 for drmn0 on minor 0 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 285129] netinet(6)/route: uninitialized access of ifp->if_data in ip6_tryforward() with PPPoE/ng interface
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285129
Bug ID: 285129
Summary: netinet(6)/route: uninitialized access of ifp->if_data
in ip6_tryforward() with PPPoE/ng interface
Product: Base System
Version: 14.2-STABLE
Hardware: Any
URL: https://github.com/opnsense/src/issues/207
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: fra...@opnsense.org
Hi,
Looking at a panic in ip6_tryforward() related to PPPoE, for details see the
downstream bug report. Backtrace is:
--- trap 0xc, rip = 0x80ddb5d7, rsp = 0xfe0038bd6840, rbp =
0xfe0038bd6970 ---
ip6_forward() at ip6_forward+0x2a7/frame 0xfe0038bd6970
ip6_input() at ip6_input+0x11f/frame 0xfe0038bd6a50
netisr_dispatch_src() at netisr_dispatch_src+0x9e/frame 0xfe0038bd6aa0
ether_demux() at ether_demux+0x149/frame 0xfe0038bd6ad0
ether_nh_input() at ether_nh_input+0x36a/frame 0xfe0038bd6b30
netisr_dispatch_src() at netisr_dispatch_src+0x9e/frame 0xfe0038bd6b80
ether_input() at ether_input+0x56/frame 0xfe0038bd6bd0
ether_demux() at ether_demux+0x97/frame 0xfe0038bd6c00
ether_nh_input() at ether_nh_input+0x36a/frame 0xfe0038bd6c60
netisr_dispatch_src() at netisr_dispatch_src+0x9e/frame 0xfe0038bd6cb0
ether_input() at ether_input+0x56/frame 0xfe0038bd6d00
iflib_rxeof() at iflib_rxeof+0xc0e/frame 0xfe0038bd6e00
_task_fn_rx() at _task_fn_rx+0x72/frame 0xfe0038bd6e40
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x14e/frame 0xfe0038bd6ec0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xc2/frame
0xfe0038bd6ef0
fork_exit() at fork_exit+0x7f/frame 0xfe0038bd6f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0038bd6f30
--- trap 0x9d9d3e64, rip = 0xb414471ee4b2474b, rsp = 0x3113c21961b5c24c, rbp =
0x5647a54d06e1a518 ---
Got a debug core and here is what it says:
(kgdb) frame 17
#17 0x80e0f6fc in ip6_tryforward (m=0xf80053520d00) at
/usr/src/sys/netinet6/ip6_fastfwd.c:194
194 mtu = IN6_LINKMTU(nifp);
(kgdb) p nifp->if_xname
$1 = "pppoe0\000\000\000\000\000\000\000\000\000"
(kgdb) p nifp->if_afdata
$2 = {0x0 }
(kgdb) p nifp->if_afdata_initialized
$3 = 0
Yes, the code is slightly modified, but it's 100% not self-inflicted. You can
also find a similar panic here:
https://redmine.pfsense.org/issues/15640
To unpack, IN6_LINKMTU() uses if_getifdata() which reaches for if_afdata but
that is not yet initialized (or maybe it's about to be teared down).
I'll put up a review for discussion in a bit. Fixing this one instance seems
trivial but the issue reaching for if_afdata unconditionally seems to be all
over the stack.
Cheers,
Franco
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 285094] handbook/x11/#x-configuration-intel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285094 ni...@protonmail.com changed: What|Removed |Added Status|New |Closed Resolution|--- |Works As Intended -- You are receiving this mail because: You are the assignee for the bug.
[Bug 285129] netinet(6)/route: uninitialized access of ifp->if_data in ip6_tryforward() with PPPoE/ng interface
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285129 --- Comment #1 from Franco Fichtner --- Added a review here: https://reviews.freebsd.org/D49212 It's a POC for discussion, but I can imagine there are a few strong opinions on this approach so please let them be known. Cheers, Franco -- You are receiving this mail because: You are the assignee for the bug.
[Bug 273997] truncate 1 EXAMPLE incorrect description
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273997 Maxim Konovalov changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #2 from Maxim Konovalov --- Created attachment 258146 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=258146&action=edit refactored patch Hello, I re-did the patch. Now it addresses the following issues in the Examples section: - spells "Megabytes" as "megabytes" consistently - removes a stray * from the /boot/kernel/kernel listing - avoids using a shell prompt in the examples consistently - fixes the size parameter - adds an example how to increase the file size -- You are receiving this mail because: You are the assignee for the bug.
[Bug 162860] [zfs] Cannot share ZFS filesystem to hosts with a hyphen in hostname
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162860 m...@valentine.me.uk changed: What|Removed |Added CC||m...@valentine.me.uk --- Comment #4 from m...@valentine.me.uk --- I just hit this old bug too. As a hack workaround, you can script edit /etc/zfs/exports to fix up any known munged hyphens and send SIGHUP to mountd. I'm guessing you'd have to hack /etc/rc.d/zfs to re-apply the edit in zfs_start_main() too, since zfs share will keep generating a bogus exports file. I'm sticking with sharenfs=on for now since it's just my home network... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 162860] [zfs] Cannot share ZFS filesystem to hosts with a hyphen in hostname
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162860 --- Comment #5 from m...@valentine.me.uk --- Can anyone confirm this is fixed in -CURRENT? I only have 14.2 running ZFS at the moment. https://cgit.freebsd.org/src/commit/sys/contrib/openzfs/lib/libshare/os/freebsd/nfs.c?id=7a7741af18d6c8a804cc643cb7ecda9d730c6aa6 #16529 29c9e6c32 Fix handling of DNS names with '-' in them for sharenfs -- You are receiving this mail because: You are the assignee for the bug.
[Bug 285148] [autofs] special_media logger facility should be higher than 'info'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285148 Bug ID: 285148 Summary: [autofs] special_media logger facility should be higher than 'info' Product: Base System Version: 14.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: parakl...@darkreality.org If the relevant fusefs modules are not installed autofs exits with an error after logging to the 'info' facility. Unfortunately those log messages are never delivered anywhere so the reason for the failure is unclear. This should be at least 'notice' so that it appears in `/var/log/messages`, but is probably better if it is 'error'. The `exit 1` from the `special_media` script causes an error log (on console and dmesg) from automountd so the explanatory text might as well appear there as well. -- You are receiving this mail because: You are the assignee for the bug.
