[Bug 261707] panic: vm_page_free_prep: freeing mapped page 0xfffffe0006f80170 on 14-Current(master-n252892-e30fceb89b7)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261707 Kubilay Kocak changed: What|Removed |Added Status|New |In Progress Keywords||crash, needs-patch Assignee|b...@freebsd.org|k...@freebsd.org Flags||mfc-stable13?, ||mfc-stable12? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261291] ESX NFS4.1 client hangs, server never responds to EXCHANGE_ID/CREATE_SESSION
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261291 --- Comment #20 from Alan Somers --- Created attachment 231735 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=231735&action=edit Workaround ESXi's CREATE_SESSION sequence_id bug Thanks for that idea. Attached is what I'm testing right now. It works for my simple reproduction case, and I'll find out by Monday if it works for real. What it does is to check the nii_domain of the client. If it's "vmware.com", then it simply ignores sequence_id during CREATE_SESSION. It also adds a sysctl to switch that behavior on or off. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 226510] panic: Re-refing for reason 5, cnt = 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable13+, ||mfc-stable12? Keywords|patch |crash Severity|Affects Only Me |Affects Some People See Also||https://reviews.freebsd.org ||/D27735 Assignee|b...@freebsd.org|r...@freebsd.org --- Comment #24 from Kubilay Kocak --- ^Triage: Assign to committer that resolved (last reference) and track stable/* merge (so far). Does this need to go to stable/12? This issue was a report against 12.0 (CURRENT). Will leave this issue closed, but if/when merged, please set mfc-stable12 flag to + and reference this issue in merge commit log so the merge is tracked in all issues -- You are receiving this mail because: You are the assignee for the bug.
[Bug 226510] panic: Re-refing for reason 5, cnt = 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510 Kubilay Kocak changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2265 ||78 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 226578] panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /usr/home/trasz/svn-ssh/head/sys/cam/scsi/scsi_da.c:2042
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226578 Kubilay Kocak changed: What|Removed |Added Severity|Affects Only Me |Affects Some People Assignee|b...@freebsd.org|r...@freebsd.org URL||https://reviews.freebsd.org ||/D27735 Flags||mfc-stable13+, ||mfc-stable12? Keywords|patch |crash --- Comment #6 from Kubilay Kocak --- ^Triage: Assign to committer that resolves and track stable/* merge. Does this need to go to stable/12? Unclear from OP what 'CURRENT' was at the time. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261291] ESX NFS4.1 client hangs, server never responds to EXCHANGE_ID/CREATE_SESSION
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261291 --- Comment #19 from Rick Macklem --- Created attachment 231733 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=231733&action=edit admin revoke client when create_session seqid not equal exchange_id's You could try this patch, which essentially does an nfsrevoke(8) when the seqid error is received. It probably should not go in FreeBSD, since it pretty clearly violates RFC8881. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 226578] panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /usr/home/trasz/svn-ssh/head/sys/cam/scsi/scsi_da.c:2042
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226578 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=583480174ee7f4af92f0c5302884a7eece5b12f3 commit 583480174ee7f4af92f0c5302884a7eece5b12f3 Author: Robert Wing AuthorDate: 2022-01-04 01:21:58 + Commit: Robert Wing CommitDate: 2022-02-10 19:43:18 + cam: don't lock while handling an AC_UNIT_ATTENTION Don't take the device_mtx lock in daasync() when handling an AC_UNIT_ATTENTION. Instead, assert the lock is held before modifying the periph's softc flags. The device_mtx lock is taken in xptdevicetraverse() before daasync() is eventually called in xpt_async_bcast(). PR: 240917, 226510, 226578 Reviewed by:imp MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D27735 (cherry picked from commit bb8441184bab60cd8a07c2b94bd6c4ae8b56ec25) sys/cam/scsi/scsi_da.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 226510] panic: Re-refing for reason 5, cnt = 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226510 --- Comment #23 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=583480174ee7f4af92f0c5302884a7eece5b12f3 commit 583480174ee7f4af92f0c5302884a7eece5b12f3 Author: Robert Wing AuthorDate: 2022-01-04 01:21:58 + Commit: Robert Wing CommitDate: 2022-02-10 19:43:18 + cam: don't lock while handling an AC_UNIT_ATTENTION Don't take the device_mtx lock in daasync() when handling an AC_UNIT_ATTENTION. Instead, assert the lock is held before modifying the periph's softc flags. The device_mtx lock is taken in xptdevicetraverse() before daasync() is eventually called in xpt_async_bcast(). PR: 240917, 226510, 226578 Reviewed by:imp MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D27735 (cherry picked from commit bb8441184bab60cd8a07c2b94bd6c4ae8b56ec25) sys/cam/scsi/scsi_da.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261866] ixgbe(4) with optics not setting media type
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261866 Bug ID: 261866 Summary: ixgbe(4) with optics not setting media type Product: Base System Version: 12.3-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: brian90...@gmail.com Hello, I am testing FreeBSD-12.3 using an '82599ES 10-Gigabit SFI/SFP+ Network Connection' with an 10Gbase-LR transceiver. A similar box at a remote location was unable to establish a 10GbE link and fell back to 1GbE. I wanted to force the 1000baseLX media type to see if that could be established reliably. After my testing, I believe ixgbe resets the media type to autoselect immediately after setting any other type - making the 'ifconfig ixl0 media 1000baseLX' command useless. I believe it is revision r312544 that causes this behavior. I am interested if ixgbe can be reworked so that fixed media types can be applied. Thank you! When linked at 10G, the output of 'ifconfig ixl0' includes: media: Ethernet autoselect (10Gbase-LR ) My understanding is the first 'Ethernet autoselect' reflects what is configured while the section in parenthesis '10Gbase-LR' is what is negotiated. I can try to force the negotiated speed but ifconfig still reports 'Ethernet autoselect': # ifconfig ixl0 media 10Gbase-LR media: Ethernet autoselect (10Gbase-LR ) Note if I try this on a 1GbE igb driver, the configured media type is displayed: # ifconfig igb0 media 100baseTX media: Ethernet 100baseTX (100baseTX ) Next, I built the kernel using options 'IFMEDIA_DEBUG' and after booting set 'sysctl debug.ifmedia=1'. I added additional logging before the two ifmedia_set() calls in the if_ix.c - in ixgbe_setup_interface() and ixgbe_handl_msf(). Testing showed that after setting a new mode, the link goes down then comes back up, and the handle_msf() function is called. That function clears and reloads the available media types then sets the interface to auto. That cancels out the forced media type. I traced this problem to r312544 where ifmedia_set() was added to avoid an invalid memory access. Is there a way to retain the configured media state and attempt to use it after reloading the available types? Otherwise, at least when using optics, it seems like I am unable to set a media type. I see ixl and ice drivers don't support setting a media type - perhaps it is related to this problem? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261707] panic: vm_page_free_prep: freeing mapped page 0xfffffe0006f80170 on 14-Current(master-n252892-e30fceb89b7)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261707 --- Comment #6 from Masachika ISHIZUKA --- (In reply to Tijl Coosemans from comment #2) Thank you for patch. This patch seems to solve my problem. It works well on master-n253071-79f5d19890c with this patch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261707] panic: vm_page_free_prep: freeing mapped page 0xfffffe0006f80170 on 14-Current(master-n252892-e30fceb89b7)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261707 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3261dea72c24aa7b33eb90aeae95d82078cfc5e4 commit 3261dea72c24aa7b33eb90aeae95d82078cfc5e4 Author: Konstantin Belousov AuthorDate: 2022-02-10 14:50:42 + Commit: Konstantin Belousov CommitDate: 2022-02-10 14:56:15 + Revert "vm_pageout_scans: correct detection of active object" This reverts commit 3de96d664aaaf8e3fb1ca4fc4bd864d2cf734b24. PR: 261707 (cherry picked from commit b51927b7b018d268c91b2127d82786caf68254de) sys/vm/vm_pageout.c | 56 + 1 file changed, 18 insertions(+), 38 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261707] panic: vm_page_free_prep: freeing mapped page 0xfffffe0006f80170 on 14-Current(master-n252892-e30fceb89b7)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261707 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b51927b7b018d268c91b2127d82786caf68254de commit b51927b7b018d268c91b2127d82786caf68254de Author: Konstantin Belousov AuthorDate: 2022-02-10 14:50:42 + Commit: Konstantin Belousov CommitDate: 2022-02-10 14:55:10 + Revert "vm_pageout_scans: correct detection of active object" This reverts commit 3de96d664aaaf8e3fb1ca4fc4bd864d2cf734b24. Problem is that it is possible to reach the state with ref_count == 1 for the mapped non-anonymous object. For instance, anonymous posix shmfd or linux shmfs object could be mapped, and then corresponding file descriptor closed, dropping the object reference owned by the shmfd/shmfs file. Then the check in inactive scan assumes that the object and page are not mapped and frees the page, while they are not. PR: 261707 Discussed with: markj Sponsored by: The FreeBSD Foundation MFC after: now sys/vm/vm_pageout.c | 56 + 1 file changed, 18 insertions(+), 38 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261707] panic: vm_page_free_prep: freeing mapped page 0xfffffe0006f80170 on 14-Current(master-n252892-e30fceb89b7)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261707 --- Comment #3 from Konstantin Belousov --- (In reply to Aleksander Slomka from comment #1) vmcore is useless without the matching kernel.full. Place it somewhere as well. Or do from kgdb: p *m p *(m->object) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261707] panic: vm_page_free_prep: freeing mapped page 0xfffffe0006f80170 on 14-Current(master-n252892-e30fceb89b7)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261707
Tijl Coosemans changed:
What|Removed |Added
Blocks||261773
CC||k...@freebsd.org,
||ma...@freebsd.org,
||t...@freebsd.org
--- Comment #2 from Tijl Coosemans ---
Probably caused by base 3de96d664aaa. You can try the following hack which
essentially reverts that commit. In bug 261773 it is also visible as corrupted
icons in Firefox. There must be non-anonymous swap objects with ref_count == 1
and active mappings.
--- sys/vm/vm_pageout.c
+++ sys/vm/vm_pageout.c
@@ -732,8 +732,8 @@ vm_pageout_clean(vm_page_t m, int *numpagedout)
static bool
vm_pageout_object_act(vm_object_t object)
{
- return (object->ref_count >
- ((object->flags & (OBJ_SWAP | OBJ_ANON)) == OBJ_SWAP ? 1 : 0));
+ return (object->ref_count > 0);
+// ((object->flags & (OBJ_SWAP | OBJ_ANON)) == OBJ_SWAP ? 1 : 0));
}
static int
Referenced Bugs:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261773
[Bug 261773] graphics/drm-fbsd13-kmod: Instability and artifacts after
5.4.144.g20220128 update (Intel GM45)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 261855] /etc/periodic/daily/800.scrub-zfs is using `zpool history`
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261855 Bug ID: 261855 Summary: /etc/periodic/daily/800.scrub-zfs is using `zpool history` Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: l...@lapo.it Daily scrub periodic task is currently using `zpool history` to check the last time a `zpool scrub` was started (note: not completed, or executed, just started). On my system, which has a lots of filesystems and hourly snapshot/send/recv/destroy jobs in order to replicate it to/from another system my `zpool history` only covers 48h of data and thus periodic scrub (configured to 35 days as per default) gets executed every 3 days (this is the reason I looked into it in the first place). Right now the logic is more or less: 1. check last scrub start in `zpool history` 2. calculate diff, if < 35 just stop 3. check "scan:" line from `zpool status` and do different stuff I would suggest to remove the usage of `zpool history` and replace it with a parsing of the `zpool status` "scan:" line, which can be done with `LANG=C date -j -f '%a %b %d %T %Y'`. % zpool status | fgrep 'scan:' scan: scrub canceled on Thu Feb 10 08:40:04 2022 scan: scrub repaired 0B in 00:00:26 with 0 errors on Sun Jan 23 19:09:50 2022 This can be easily integrated in the existing `case` by adding a new match like `*"scrub repaired"*|*"scrub canceled"*)` and calculate the end of last scrub based on that. Caveat: `zpool status` gets reset each time a (manual) scrub or pause or cancel is done. But the current method has caveats too (using start time instead of end time, using a hisotry command which can not be very trustworthy in some situations) so I think this would be an overall better solution. What do you think? I can prepare a diff for this. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261641] drm-kmod: Launch message is written into (possibly random) memory locations on kldload with vt console
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261641 Stefan B. changed: What|Removed |Added Summary|radeonkms: Incorrect|drm-kmod: Launch message is |message cursor positioning |written into (possibly |on kldload with vt console |random) memory locations on ||kldload with vt console -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261641] radeonkms: Incorrect message cursor positioning on kldload with vt console
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261641 --- Comment #3 from Stefan B. --- Update: I found the i915kms driver "works" the same way. It appears like that it depends on how much the scrollback ring buffer is filled, where the kms loading message appears on the screen (if at all). Sometimes it does not appear on the visible area of the screen, which I find somewhat concerning, as one does not know where in memory the output is written to. So I have to change the bug description accordingly. -- You are receiving this mail because: You are the assignee for the bug.
