<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src, branch release/14.3.0</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>Update in preparation for 14.3-RELEASE</title>
<updated>2025-06-06T00:00:00+00:00</updated>
<author>
<name>Colin Percival</name>
<email>cperciva@FreeBSD.org</email>
</author>
<published>2025-06-06T00:00:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=8c9ce319fef765890ce518cab85d3a470b669849'/>
<id>8c9ce319fef765890ce518cab85d3a470b669849</id>
<content type='text'>
- Bump BRANCH to RELEASE
- Add the anticipated RELEASE announcement date
- Set a static __FreeBSD_version

Approved by:	re (implicit)
Sponsored by:	Amazon
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- Bump BRANCH to RELEASE
- Add the anticipated RELEASE announcement date
- Set a static __FreeBSD_version

Approved by:	re (implicit)
Sponsored by:	Amazon
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix incorrect version introduced in manual pages</title>
<updated>2025-06-03T23:47:57+00:00</updated>
<author>
<name>Tom Hukins</name>
<email>tom@FreeBSD.org</email>
</author>
<published>2025-05-02T11:00:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=ffacf114e1313ab610b7ac4ee4714d35d5a035be'/>
<id>ffacf114e1313ab610b7ac4ee4714d35d5a035be</id>
<content type='text'>
Several manual pages for releng/14.3 incorrectly claim that features
were first introduced in FreeBSD 15.0.

I discovered these by running:

  git checkout origin/releng/14.3
  git grep -F '.Fx 15.0'

Approved by:    re (cperciva)
MFC After: 3 days
Reviewed by: imp, ziaee
Pull Request: https://github.com/freebsd/freebsd-src/pull/1685

(cherry picked from commit 5b9660caff69c70c9b6d9df5e04a3f21f8cf7996)
(cherry picked from commit ef4014882ee1413eba75a78f6e307e16123c63d1)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Several manual pages for releng/14.3 incorrectly claim that features
were first introduced in FreeBSD 15.0.

I discovered these by running:

  git checkout origin/releng/14.3
  git grep -F '.Fx 15.0'

Approved by:    re (cperciva)
MFC After: 3 days
Reviewed by: imp, ziaee
Pull Request: https://github.com/freebsd/freebsd-src/pull/1685

(cherry picked from commit 5b9660caff69c70c9b6d9df5e04a3f21f8cf7996)
(cherry picked from commit ef4014882ee1413eba75a78f6e307e16123c63d1)
</pre>
</div>
</content>
</entry>
<entry>
<title>ure.4: add a HARDWARE section + add RTL8156BG as a compatible controller</title>
<updated>2025-06-03T18:35:21+00:00</updated>
<author>
<name>Kenneth Raplee</name>
<email>kenrap@kennethraplee.com</email>
</author>
<published>2025-04-08T18:30:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=cd46420a61508e53c8afd710d54cf8f85547874b'/>
<id>cd46420a61508e53c8afd710d54cf8f85547874b</id>
<content type='text'>
While here, rename all instances of "RealTek" to "Realtek" for
authenticity.

Approved by:	re (cperciva)
Reviewed by: imp, lwshu, zaiee
Pull Request: https://github.com/freebsd/freebsd-src/pull/1649

(cherry picked from commit 76ed6f2db316bf2240d36d3c92316da4d1e5b174)
(cherry picked from commit f336a04960b608d2caeaf964663c3a8425f31d71)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While here, rename all instances of "RealTek" to "Realtek" for
authenticity.

Approved by:	re (cperciva)
Reviewed by: imp, lwshu, zaiee
Pull Request: https://github.com/freebsd/freebsd-src/pull/1649

(cherry picked from commit 76ed6f2db316bf2240d36d3c92316da4d1e5b174)
(cherry picked from commit f336a04960b608d2caeaf964663c3a8425f31d71)
</pre>
</div>
</content>
</entry>
<entry>
<title>ure.4: description consistencies + tag spdx</title>
<updated>2025-06-03T18:35:11+00:00</updated>
<author>
<name>Alexander Ziaee</name>
<email>concussious@runbox.com</email>
</author>
<published>2024-08-14T06:50:18+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=6fe425b4c4a4aa20936d98d820481dd502c56696'/>
<id>6fe425b4c4a4aa20936d98d820481dd502c56696</id>
<content type='text'>
+ consistent document description languague with other USB-BaseT drivers
+ mention newly added adapters from 6ea4d9
+ attempt to mention rgephy(4) phys feed into ure interfaces

Approved by:	re (cperciva)
Fixes:		6ea4d9 (Move RTL8156 from cdce(4) to ure(4))
MFC after:	3 days

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1384

(cherry picked from commit 4c72525953fdf618a3fc0a45f3ef3f071dcc0c52)
(cherry picked from commit b529a06d1db4bb27895465ba8692d6c4427e32d8)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
+ consistent document description languague with other USB-BaseT drivers
+ mention newly added adapters from 6ea4d9
+ attempt to mention rgephy(4) phys feed into ure interfaces

Approved by:	re (cperciva)
Fixes:		6ea4d9 (Move RTL8156 from cdce(4) to ure(4))
MFC after:	3 days

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1384

(cherry picked from commit 4c72525953fdf618a3fc0a45f3ef3f071dcc0c52)
(cherry picked from commit b529a06d1db4bb27895465ba8692d6c4427e32d8)
</pre>
</div>
</content>
</entry>
<entry>
<title>puc.4: Add a HARDWARE section based off device data from pucdata.c</title>
<updated>2025-06-03T18:35:01+00:00</updated>
<author>
<name>Kenneth Raplee</name>
<email>kenrap@kennethraplee.com</email>
</author>
<published>2025-04-14T05:14:48+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=9efdb081e824e288679586d3d891e558b5638b1f'/>
<id>9efdb081e824e288679586d3d891e558b5638b1f</id>
<content type='text'>
While here, change applicable uses of "ports" to "adapters" to be more
precise and improve searchability.

This is a 14.3 candate since it affects (positively) the release notes
generated from the hardware secionts.

Approved by:	re (cperciva)
MFC After: 3 days
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1663

(cherry picked from commit 794ee43e75066bfcbc00545b5bf600b9cda2d5f1)
(cherry picked from commit 827153d21219f76cf006d50af4cdf85f22b75de0)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While here, change applicable uses of "ports" to "adapters" to be more
precise and improve searchability.

This is a 14.3 candate since it affects (positively) the release notes
generated from the hardware secionts.

Approved by:	re (cperciva)
MFC After: 3 days
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1663

(cherry picked from commit 794ee43e75066bfcbc00545b5bf600b9cda2d5f1)
(cherry picked from commit 827153d21219f76cf006d50af4cdf85f22b75de0)
</pre>
</div>
</content>
</entry>
<entry>
<title>Reapply "14.3: Update to RC1"</title>
<updated>2025-05-30T16:02:53+00:00</updated>
<author>
<name>Colin Percival</name>
<email>cperciva@FreeBSD.org</email>
</author>
<published>2025-05-30T16:02:53+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=a7a4742156f9a00fcf7e01deebe6da60d918509a'/>
<id>a7a4742156f9a00fcf7e01deebe6da60d918509a</id>
<content type='text'>
Second attempt at making 14.3-RC1 happen, now that a critical
last-minute MFC has landed.

This reverts commit c5db8f65622ae0be9c65bc57326f787a1b3994f7.

Approved by:	re (cperciva)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Second attempt at making 14.3-RC1 happen, now that a critical
last-minute MFC has landed.

This reverts commit c5db8f65622ae0be9c65bc57326f787a1b3994f7.

Approved by:	re (cperciva)
</pre>
</div>
</content>
</entry>
<entry>
<title>certctl: Split certificate bundles before processing.</title>
<updated>2025-05-30T15:59:32+00:00</updated>
<author>
<name>Dag-Erling Smørgrav</name>
<email>des@FreeBSD.org</email>
</author>
<published>2023-10-05T14:50:01+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=fb33dd91ae8a5a3cc07e2eac5637b96e88e11bd7'/>
<id>fb33dd91ae8a5a3cc07e2eac5637b96e88e11bd7</id>
<content type='text'>
This allows 'certctl rehash' to do the right thing when ca_root_nss is
installed, instead of linking the entire bundle to the hash of the
first certificate it contains.

MFC after:	3 days
Reviewed by:	allanjude
Differential Revision:	https://reviews.freebsd.org/D42087

(cherry picked from commit a401c8cb26b22688087ad7c5ee527718459df15a)

certctl: Fix recent regressions.

- If an untrusted certificate is also found in the list of trusted
  certificate, issue a warning and skip it, but don't fail.
- Split on -+BEGIN CERTIFICATE-+ instead of "Certificate:" since
  that's what we're really looking for.

Also fix a long-standing bug: .crl files are not certificates, so we
should not include them when searching for certificates.

Reported by:	madpilot, netchild, tijl
Reviewed by:	netchild, allanjude
Differential Revision:	https://reviews.freebsd.org/D42276

(cherry picked from commit 87945a082980260b52507ad5bfb3a0ce773a80da)

certctl: Convert line endings before inspecting files.

This ensures that certificate files or bundles with DOS or Mac line
endings are recognized as such and handled identically to those with
Unix line endings.

PR:		274952
Reviewed by:	allanjude
Differential Revision:	https://reviews.freebsd.org/D42490

(cherry picked from commit f7d16a627efa8ba610eb9b8a12dd67b6cdbb2542)

certctl: Revert to symlinks.

Unfortunately tar will not be able to extract base.txz to a system where
/etc and /usr are not on the same filesystem if the certificates are
hard links.

PR:		277828
Reviewed by:	mp
Differential Revision:	https://reviews.freebsd.org/D44496

(cherry picked from commit 3fed4f0db53a66a0135bea5c491431eb3348cf51)
(cherry picked from commit 9c34a6876a60dc10fda6ad6a0cbe8f99a372aadc)

Approved by:	re (cperciva)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows 'certctl rehash' to do the right thing when ca_root_nss is
installed, instead of linking the entire bundle to the hash of the
first certificate it contains.

MFC after:	3 days
Reviewed by:	allanjude
Differential Revision:	https://reviews.freebsd.org/D42087

(cherry picked from commit a401c8cb26b22688087ad7c5ee527718459df15a)

certctl: Fix recent regressions.

- If an untrusted certificate is also found in the list of trusted
  certificate, issue a warning and skip it, but don't fail.
- Split on -+BEGIN CERTIFICATE-+ instead of "Certificate:" since
  that's what we're really looking for.

Also fix a long-standing bug: .crl files are not certificates, so we
should not include them when searching for certificates.

Reported by:	madpilot, netchild, tijl
Reviewed by:	netchild, allanjude
Differential Revision:	https://reviews.freebsd.org/D42276

(cherry picked from commit 87945a082980260b52507ad5bfb3a0ce773a80da)

certctl: Convert line endings before inspecting files.

This ensures that certificate files or bundles with DOS or Mac line
endings are recognized as such and handled identically to those with
Unix line endings.

PR:		274952
Reviewed by:	allanjude
Differential Revision:	https://reviews.freebsd.org/D42490

(cherry picked from commit f7d16a627efa8ba610eb9b8a12dd67b6cdbb2542)

certctl: Revert to symlinks.

Unfortunately tar will not be able to extract base.txz to a system where
/etc and /usr are not on the same filesystem if the certificates are
hard links.

PR:		277828
Reviewed by:	mp
Differential Revision:	https://reviews.freebsd.org/D44496

(cherry picked from commit 3fed4f0db53a66a0135bea5c491431eb3348cf51)
(cherry picked from commit 9c34a6876a60dc10fda6ad6a0cbe8f99a372aadc)

Approved by:	re (cperciva)
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "14.3: Update to RC1"</title>
<updated>2025-05-30T15:53:21+00:00</updated>
<author>
<name>Colin Percival</name>
<email>cperciva@FreeBSD.org</email>
</author>
<published>2025-05-30T15:53:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=c5db8f65622ae0be9c65bc57326f787a1b3994f7'/>
<id>c5db8f65622ae0be9c65bc57326f787a1b3994f7</id>
<content type='text'>
Postponing RC1 slightly to allow one more critical bug fix.

This reverts commit 3383279318c0564d405c64516cdd127bc2a0dd9f.

Approved by:	re (cperciva)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Postponing RC1 slightly to allow one more critical bug fix.

This reverts commit 3383279318c0564d405c64516cdd127bc2a0dd9f.

Approved by:	re (cperciva)
</pre>
</div>
</content>
</entry>
<entry>
<title>14.3: Update to RC1</title>
<updated>2025-05-29T22:54:06+00:00</updated>
<author>
<name>Colin Percival</name>
<email>cperciva@FreeBSD.org</email>
</author>
<published>2025-05-30T00:00:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=3383279318c0564d405c64516cdd127bc2a0dd9f'/>
<id>3383279318c0564d405c64516cdd127bc2a0dd9f</id>
<content type='text'>
Approved by:	re (implicit)
Sponsored by:	Amazon
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Approved by:	re (implicit)
Sponsored by:	Amazon
</pre>
</div>
</content>
</entry>
<entry>
<title>sound: Terminate stream properly when closing vchans</title>
<updated>2025-05-29T22:51:30+00:00</updated>
<author>
<name>Christos Margiolis</name>
<email>christos@FreeBSD.org</email>
</author>
<published>2025-05-29T10:24:17+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=99b8be414cbcb4577859985ef80eb053d761ae5f'/>
<id>99b8be414cbcb4577859985ef80eb053d761ae5f</id>
<content type='text'>
When a channel is closed, dsp_close() either calls vchan_destroy() on vchans,
or chn_abort()/chn_flush() on primary channels. However, the problem with this
is that, when closing a vchan, we end up not terminating the stream properly.

The call sequence we are interested in is the following:

	vchan_destroy(vchan) -&gt; chn_kill(vchan) -&gt; chn_trigger(vchan) -&gt;
	vchan_trigger(vchan) -&gt; chn_notify(parent)

Even though chn_notify() contains codepaths which call chn_abort(parent),
apparently we do not execute any of those codepaths in this case, so the
DMA remains unterminated, hence why we keep seeing the primary
channel(s) being interrupted even once the application has exited:

root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1139
dsp0.record.0.interrupts=0
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1277
dsp0.record.0.interrupts=0
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1394
dsp0.record.0.interrupts=0

The only applications that do not have this issue are those (e.g., mpv) that
manually call ioctls which end up calling chn_abort(), like SNDCTL_DSP_HALT, to
abort the channel(s) during shutdown. For all other applications that do not
manually abort the channel(s), we can confirm that chn_abort()/chn_flush(), or
even chn_trigger(PCMTRIG_ABORT) on the parent, doesn't happen during shutdown.

root@freebsd:~ # dtrace -n 'fbt::chn_abort:entry,fbt::chn_flush:entry { printf("%s", args[0]-&gt;name); stack(); }'
dtrace: description 'fbt::chn_abort:entry,fbt::chn_flush:entry ' matched 2 probes
dtrace: buffer size lowered to 1m
^C

[...]

root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]-&gt;name); stack(); }'
dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe
dtrace: buffer size lowered to 1m
CPU     ID                    FUNCTION:NAME
  0  68037                chn_trigger:entry dsp0.virtual_play.0
	      sound.ko`chn_kill+0x134
	      sound.ko`vchan_destroy+0x94
	      sound.ko`dsp_close+0x39b
	      kernel`devfs_destroy_cdevpriv+0xab
	      kernel`devfs_close_f+0x63
	      kernel`_fdrop+0x1a
	      kernel`closef+0x1e3
	      kernel`closefp_impl+0x76
	      kernel`amd64_syscall+0x151
	      kernel`0xffffffff8103841b1

To fix this, modify dsp_close() to execute the primary channel case on both
primary and virtual channels. While what we really care about are the
chn_abort()/chn_flush() calls, it shouldn't hurt to call the rest of the
functions on the vchans as well, to avoid complicating things; they get deleted
right below, anyway.

With the patch applied:

root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]-&gt;name); stack(); }'
dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe
dtrace: buffer size lowered to 1m
CPU     ID                    FUNCTION:NAME
  1  68037                chn_trigger:entry dsp0.virtual_play.0
              sound.ko`chn_flush+0x2a
              sound.ko`dsp_close+0x330
              kernel`devfs_destroy_cdevpriv+0xab
              kernel`devfs_close_f+0x63
              kernel`_fdrop+0x1a
              kernel`closef+0x1e3
              kernel`closefp_impl+0x76
              kernel`amd64_syscall+0x151
              kernel`0xffffffff8103841b

  0  68037                chn_trigger:entry dsp0.play.0
              sound.ko`chn_notify+0x4ce
              sound.ko`vchan_trigger+0x105
              sound.ko`chn_trigger+0xb4
              sound.ko`chn_flush+0x2a
              sound.ko`dsp_close+0x330
              kernel`devfs_destroy_cdevpriv+0xab
              kernel`devfs_close_f+0x63
              kernel`_fdrop+0x1a
              kernel`closef+0x1e3
              kernel`closefp_impl+0x76
              kernel`amd64_syscall+0x151
              kernel`0xffffffff8103841b

Above we can see a chn_trigger(PCMTRIG_ABORT) on the parent (dsp0.play.0),
which is coming from the chn_abort() (inlined) in chn_notify():

root@freebsd:~ # dtrace -n 'kinst::chn_abort:entry { stack(); }'
dtrace: description 'kinst::chn_abort:entry ' matched 5 probes
dtrace: buffer size lowered to 1m
CPU     ID                    FUNCTION:NAME
  1  72580                  chn_notify:1192
              sound.ko`0xffffffff8296cab4
              sound.ko`vchan_trigger+0x105
              sound.ko`chn_trigger+0xb4
              sound.ko`chn_flush+0x2a
              sound.ko`dsp_close+0x330
              kernel`devfs_destroy_cdevpriv+0xab
              kernel`devfs_close_f+0x63
              kernel`_fdrop+0x1a
              kernel`closef+0x1e3
              kernel`closefp_impl+0x76
              kernel`amd64_syscall+0x151
              kernel`0xffffffff8103841b

We can also confirm the primary channel(s) are not interrupted anymore:

root@freebsd:/mnt/src # sndctl interrupts
dsp0.play.0.interrupts=0
dsp0.record.0.interrupts=0

In collaboration with:	adrian
Tested by:		adrian, christos, thj
Sponsored by:		The FreeBSD Foundation
MFC after:		2 days
Reviewed by:		thj, adrian, emaste
Differential Revision:	https://reviews.freebsd.org/D50488

(cherry picked from commit f6430bc61df78be070209d52b4452ae9cf4cd015)
(cherry picked from commit 0c6aa445ec0c85e7c9653d20562907742569de6f)

Approved by:		re (cperciva)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When a channel is closed, dsp_close() either calls vchan_destroy() on vchans,
or chn_abort()/chn_flush() on primary channels. However, the problem with this
is that, when closing a vchan, we end up not terminating the stream properly.

The call sequence we are interested in is the following:

	vchan_destroy(vchan) -&gt; chn_kill(vchan) -&gt; chn_trigger(vchan) -&gt;
	vchan_trigger(vchan) -&gt; chn_notify(parent)

Even though chn_notify() contains codepaths which call chn_abort(parent),
apparently we do not execute any of those codepaths in this case, so the
DMA remains unterminated, hence why we keep seeing the primary
channel(s) being interrupted even once the application has exited:

root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1139
dsp0.record.0.interrupts=0
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1277
dsp0.record.0.interrupts=0
root@freebsd:~ # sndctl interrupts
dsp0.play.0.interrupts=1394
dsp0.record.0.interrupts=0

The only applications that do not have this issue are those (e.g., mpv) that
manually call ioctls which end up calling chn_abort(), like SNDCTL_DSP_HALT, to
abort the channel(s) during shutdown. For all other applications that do not
manually abort the channel(s), we can confirm that chn_abort()/chn_flush(), or
even chn_trigger(PCMTRIG_ABORT) on the parent, doesn't happen during shutdown.

root@freebsd:~ # dtrace -n 'fbt::chn_abort:entry,fbt::chn_flush:entry { printf("%s", args[0]-&gt;name); stack(); }'
dtrace: description 'fbt::chn_abort:entry,fbt::chn_flush:entry ' matched 2 probes
dtrace: buffer size lowered to 1m
^C

[...]

root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]-&gt;name); stack(); }'
dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe
dtrace: buffer size lowered to 1m
CPU     ID                    FUNCTION:NAME
  0  68037                chn_trigger:entry dsp0.virtual_play.0
	      sound.ko`chn_kill+0x134
	      sound.ko`vchan_destroy+0x94
	      sound.ko`dsp_close+0x39b
	      kernel`devfs_destroy_cdevpriv+0xab
	      kernel`devfs_close_f+0x63
	      kernel`_fdrop+0x1a
	      kernel`closef+0x1e3
	      kernel`closefp_impl+0x76
	      kernel`amd64_syscall+0x151
	      kernel`0xffffffff8103841b1

To fix this, modify dsp_close() to execute the primary channel case on both
primary and virtual channels. While what we really care about are the
chn_abort()/chn_flush() calls, it shouldn't hurt to call the rest of the
functions on the vchans as well, to avoid complicating things; they get deleted
right below, anyway.

With the patch applied:

root@freebsd:~ # dtrace -n 'fbt::chn_trigger:entry /args[1] == -1/ { printf("%s", args[0]-&gt;name); stack(); }'
dtrace: description 'fbt::chn_trigger:entry ' matched 1 probe
dtrace: buffer size lowered to 1m
CPU     ID                    FUNCTION:NAME
  1  68037                chn_trigger:entry dsp0.virtual_play.0
              sound.ko`chn_flush+0x2a
              sound.ko`dsp_close+0x330
              kernel`devfs_destroy_cdevpriv+0xab
              kernel`devfs_close_f+0x63
              kernel`_fdrop+0x1a
              kernel`closef+0x1e3
              kernel`closefp_impl+0x76
              kernel`amd64_syscall+0x151
              kernel`0xffffffff8103841b

  0  68037                chn_trigger:entry dsp0.play.0
              sound.ko`chn_notify+0x4ce
              sound.ko`vchan_trigger+0x105
              sound.ko`chn_trigger+0xb4
              sound.ko`chn_flush+0x2a
              sound.ko`dsp_close+0x330
              kernel`devfs_destroy_cdevpriv+0xab
              kernel`devfs_close_f+0x63
              kernel`_fdrop+0x1a
              kernel`closef+0x1e3
              kernel`closefp_impl+0x76
              kernel`amd64_syscall+0x151
              kernel`0xffffffff8103841b

Above we can see a chn_trigger(PCMTRIG_ABORT) on the parent (dsp0.play.0),
which is coming from the chn_abort() (inlined) in chn_notify():

root@freebsd:~ # dtrace -n 'kinst::chn_abort:entry { stack(); }'
dtrace: description 'kinst::chn_abort:entry ' matched 5 probes
dtrace: buffer size lowered to 1m
CPU     ID                    FUNCTION:NAME
  1  72580                  chn_notify:1192
              sound.ko`0xffffffff8296cab4
              sound.ko`vchan_trigger+0x105
              sound.ko`chn_trigger+0xb4
              sound.ko`chn_flush+0x2a
              sound.ko`dsp_close+0x330
              kernel`devfs_destroy_cdevpriv+0xab
              kernel`devfs_close_f+0x63
              kernel`_fdrop+0x1a
              kernel`closef+0x1e3
              kernel`closefp_impl+0x76
              kernel`amd64_syscall+0x151
              kernel`0xffffffff8103841b

We can also confirm the primary channel(s) are not interrupted anymore:

root@freebsd:/mnt/src # sndctl interrupts
dsp0.play.0.interrupts=0
dsp0.record.0.interrupts=0

In collaboration with:	adrian
Tested by:		adrian, christos, thj
Sponsored by:		The FreeBSD Foundation
MFC after:		2 days
Reviewed by:		thj, adrian, emaste
Differential Revision:	https://reviews.freebsd.org/D50488

(cherry picked from commit f6430bc61df78be070209d52b4452ae9cf4cd015)
(cherry picked from commit 0c6aa445ec0c85e7c9653d20562907742569de6f)

Approved by:		re (cperciva)
</pre>
</div>
</content>
</entry>
</feed>
