WITHOUT_CASPER ghost?
All, The WITHOUT_CASPER build option was deprecated in main and 14-stable branches but is still showing up and will trip up the build option survey: sh src/tools/tools/build_option_survey/listallopts.sh | grep CASPER WITHOUT_CASPER --- all_subdir_sbin/mdconfig --- ===> sbin/mdconfig (all) make[4]: "/b/stable/14/src/share/mk/bsd.mkopt.mk" line 62: warning: WITHOUT_CAPSICUM option ignored: it is no longer supported make[4]: "/b/stable/14/src/share/mk/bsd.mkopt.mk" line 62: warning: WITHOUT_CASPER option ignored: it is no longer supported --- .depend --- echo mdconfig: /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libc.a /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libutil.a /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libgeom.a /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libbsdxml.a /b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/lib/libsbuf.a >> depend --- mdconfig.o --- cc -target x86_64-unknown-freebsd14.0 --sysroot=/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp -B/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DNDEBUG -MD -MF.depend.mdconfig.o -MTmdconfig.o -std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter /usr/lib/clang/16/include -Qunused-arguments -c /b/stable/14/src/sbin/mdconfig/mdconfig.c -o mdconfig.o --- all_subdir_sbin/md5 --- 4 warnings generated. --- md5 --- cc -target x86_64-unknown-freebsd14.0 --sysroot=/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp -B/b/stable/14/obj/b/stable/14/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common -DHAVE_CAPSICUM -DWITH_CASPER -DNDEBUG -std=gnu99 -Wno-format-zero-length -nobuiltininc -idirafter /usr/lib/clang/16/include -Qunused-arguments -Wl,-znorelro -static -o md5 md5.o -lmd -lcasper -lnv -lcap_fileargs -lnv ld: error: unable to find library -lcasper ld: error: unable to find library -lcap_fileargs cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [md5] Error code 1 make[4]: stopped in /b/stable/14/src/sbin/md5 1 error I am tracking the build options here: https://callfortesting.org/results/bos-ci/ My apologies if this is a false positive. Michael
Re: 42fdcd9fd917 broke my snd_uaudio(4)
Hi Lexi,
On Thursday, February 22, 2024 6:47:26 PM CET Lexi Winter wrote:
> hi Florian,
>
> Florian Walpen:
> > I have a Scarlett 18i20 myself, but maybe a different generation - it has
> > 18 recording channels as its name suggests. Is 20 recording channels
> > correct for your device?
>
> this is a 3rd generation 18i20; as well the usual physical inputs it has
> a stereo loopback channel that can be configured in the built-in mixer
> and which appears as an additional two recording channels. i think
> (although i'm not certain) that loopback functionality is new in the 3rd
> generation model.
That makes sense, I have the previous generation with no loopback channels.
> > > FreeBSD Audio Driver (64bit 2009061500/amd64)
> > > Installed devices:
> > > pcm0: on uaudio0 (1p:0v/1r:0v) default
> > >
> > > snddev
> > >
> > > flags=0x3e6
> > > [pcm0:play:dsp0.p0]: spd 48000, fmt 0x01401000, flags 0x2000110c,
> > > 0x0001, pid 22326 (virtual_oss) interrupts 115908, underruns 0, feed
> > > 115907, ready 123440 [b:30720/15360/2|bs:131040/65520/2] channel
> > > flags=0x2000110c {userland}
> > > ->
> > > feeder_root(0x01401000) -> {hardware}
> > >
> > > [pcm0:record:dsp0.r0]: spd 48000, fmt 0x01401000, flags 0x2000112c,
> > >
> > > 0x0001, pid 22326 (virtual_oss) interrupts 115930, overruns 97, feed
> > > 229796, hfree 30720, sfree 65440 [b:30720/15360/2|bs:65440/32720/2]
> > > channel
> > > flags=0x2000112c
> > > {hardware} -> feeder_root(0x01401000) -> {userland}
> > > Installed devices from userspace:
> > > dsp.full: (play/rec)
> > > dsp.record: (play/rec)
> > > dsp: (play/rec)
> >
> > I see that there's a lot of recording overruns and the recording software
> > side buffer of the pcm device is unusually small. Does recording work
> > well for you?
> i haven't had a chance to test recording yet beyond a single work
> conference call, as i've only just got playback working well (that
> required a lot of fiddling with various options until i settled on
> virtual_oss).
Yes, virtual_oss is currently the best option to break up multi-channel
interfaces into smaller pcm devices, for general use.
>
> if you can suggset any obvious changes i'd appreciate that - maybe it's
> just a case of increasing the virtual_oss buffer? i did have to
> increase the playback buffer a bit as the virtual_oss default is rather
> small.
That was more like a general remark referring to this part of sndstat:
[b:30720/15360/2|bs:65440/32720/2]
The bs values show the buffer size of the pcm device, where the application
(here virtual_oss) reads from. I just skimmed the source code, virtual_oss
does set this buffer size according to its own buffer size. Here the buffer
can hold 818 samples (~17ms), and the virtual_oss buffer should fit in there
twice. As I recommend a multiple of the sound card period (4ms, from dmesg),
I'd guess 384 (8ms) would make a good setting for the virtual_oss buffer
parameter here.
Maybe you can post your virtual_oss settings in the PR too.
>
> > Apart from that, I'd be interested in the exact circumstances this problem
> > occurs. Could you provide the dmesg and sndstat output as above, but with
> > the settings in loader.conf applied and playback hanging?
> >
> > Since you're using virtual_oss, I suppose it produces an error log
> > somewhere? And then maybe the output of the following commands, also
> > while playback is hanging:
> >
> > sysctl hw.snd
> > sysctl dev.pcm.0
>
> i'll open a bug with this and the other details once i get a chance to
> reboot again to test, probably later today.
Perfect, thank you. I have some ideas already, we'll see.
Regards
Florian
Re: sanitizers broken (was RE: libc/libsys split coming soon) [errno in libsys: any analogy to __elf_aux_vector ?]
On Thu, Feb 22, 2024 at 10:16:30AM -0800, Mark Millard wrote: > Brooks Davis wrote on > Date: Thu, 22 Feb 2024 02:03:09 UTC : > > > On Thu, Feb 22, 2024 at 02:57:13AM +0200, Konstantin Belousov wrote: > > > On Wed, Feb 21, 2024 at 08:20:25PM +, Brooks Davis wrote: > > > > That's probably worth a shot. Static linking will work anyway because > > > > libc.a in effect embeds libsys to retain compatability. > > > Please do not add libsys.so to the ABI. Right now it is an implementation > > > detail of libthr and libc, and it is preferable to not change it, at least > > > not yet, and definitely not to solve some minor internal issues. > > > > Indeed, on further reflection I agree. Another option occured to me > > which I intend to persue tomorrow: explicitly link the sanitizer .so > > files with libsys. At least in the base system that should be straight > > foward. > > Does the errno move to libsys have any problems similar to > the __elf_aux_vector move to libsys --that might also lead > to needing -lsys (for things as the are now)? I don't think so. With errno, there is still a copy in libc, it's just not used because the libsys on takes precidence. With __elf_aux_vector we were working around a different issue where the wrong copy was being updated by rtld which I resolved by moving it entierly. It's worth noting that any software that links with the errno symbol is buggy as errno is defined as a macro that calls a function as permitted by POSIX. I'm not convinced we should be exposing it for linkage at all. -- Brooks
Re: sanitizers broken (was RE: libc/libsys split coming soon) [errno in libsys: any analogy to __elf_aux_vector ?]
Brooks Davis wrote on Date: Thu, 22 Feb 2024 02:03:09 UTC : > On Thu, Feb 22, 2024 at 02:57:13AM +0200, Konstantin Belousov wrote: > > On Wed, Feb 21, 2024 at 08:20:25PM +, Brooks Davis wrote: > > > That's probably worth a shot. Static linking will work anyway because > > > libc.a in effect embeds libsys to retain compatability. > > Please do not add libsys.so to the ABI. Right now it is an implementation > > detail of libthr and libc, and it is preferable to not change it, at least > > not yet, and definitely not to solve some minor internal issues. > > Indeed, on further reflection I agree. Another option occured to me > which I intend to persue tomorrow: explicitly link the sanitizer .so > files with libsys. At least in the base system that should be straight > foward. Does the errno move to libsys have any problems similar to the __elf_aux_vector move to libsys --that might also lead to needing -lsys (for things as the are now)? For reference: https://lists.freebsd.org/archives/dev-commits-src-main/2024-February/022025.html === Mark Millard marklmi at yahoo.com
Re: 42fdcd9fd917 broke my snd_uaudio(4)
hi Florian,
Florian Walpen:
> I have a Scarlett 18i20 myself, but maybe a different generation - it has 18
> recording channels as its name suggests. Is 20 recording channels correct for
> your device?
this is a 3rd generation 18i20; as well the usual physical inputs it has
a stereo loopback channel that can be configured in the built-in mixer
and which appears as an additional two recording channels. i think
(although i'm not certain) that loopback functionality is new in the 3rd
generation model.
this is (very briefly) documented in the manual, which doesn't really
add anything to what i just said but does show a screenshot of Ableton
with 20 channels on p.16, which matches how the interface appeared in
Logic when i used it there:
https://fael-downloads-prod.focusrite.com/customer/prod/downloads/scarlett_18i20_3rd_gen_user_guide_v3_english_en.pdf
> > FreeBSD Audio Driver (64bit 2009061500/amd64)
> > Installed devices:
> > pcm0: on uaudio0 (1p:0v/1r:0v) default
> > snddev
> > flags=0x3e6
> > [pcm0:play:dsp0.p0]: spd 48000, fmt 0x01401000, flags 0x2000110c,
> > 0x0001, pid 22326 (virtual_oss) interrupts 115908, underruns 0, feed
> > 115907, ready 123440 [b:30720/15360/2|bs:131040/65520/2] channel
> > flags=0x2000110c {userland} ->
> > feeder_root(0x01401000) -> {hardware}
> > [pcm0:record:dsp0.r0]: spd 48000, fmt 0x01401000, flags 0x2000112c,
> > 0x0001, pid 22326 (virtual_oss) interrupts 115930, overruns 97, feed
> > 229796, hfree 30720, sfree 65440 [b:30720/15360/2|bs:65440/32720/2] channel
> > flags=0x2000112c
> > {hardware} -> feeder_root(0x01401000) -> {userland}
> > Installed devices from userspace:
> > dsp.full: (play/rec)
> > dsp.record: (play/rec)
> > dsp: (play/rec)
>
> I see that there's a lot of recording overruns and the recording software
> side
> buffer of the pcm device is unusually small. Does recording work well for you?
i haven't had a chance to test recording yet beyond a single work
conference call, as i've only just got playback working well (that
required a lot of fiddling with various options until i settled on
virtual_oss).
if you can suggset any obvious changes i'd appreciate that - maybe it's
just a case of increasing the virtual_oss buffer? i did have to
increase the playback buffer a bit as the virtual_oss default is rather
small.
> Apart from that, I'd be interested in the exact circumstances this problem
> occurs. Could you provide the dmesg and sndstat output as above, but with the
> settings in loader.conf applied and playback hanging?
> Since you're using virtual_oss, I suppose it produces an error log somewhere?
> And then maybe the output of the following commands, also while playback is
> hanging:
>
> sysctl hw.snd
> sysctl dev.pcm.0
i'll open a bug with this and the other details once i get a chance to
reboot again to test, probably later today.
thanks, lexi.
signature.asc
Description: PGP signature
Re: 42fdcd9fd917 broke my snd_uaudio(4)
Hi Lexi,
On Thursday, February 22, 2024 2:45:07 AM CET Lexi Winter wrote:
> hello,
>
> since the commit:
>
> 42fdcd9fd917 snd_uaudio(4): Fix config detection with defaults set.
>
> my snd_uaudio(4) no longer works. the symptom is that applications
> attempting to play audio hang forever, and no audio is produced.
> reverting this commit fixed the problem.
>
> the issue only occurs if i have this set in /boot/loader.conf:
>
> hw.usb.uaudio.default_bits=32
> hw.usb.uaudio.default_rate=48000
>
> removing these two settings makes audio work correctly again.
Thanks for reporting this. While I don't see the need to set these lines in
loader.conf, at least not for your particular audio device, it certainly
shouldn't break anything.
I think it might be helpful to handle this case in a PR on bugs.freebsd.org,
if you don't mind? We probably need more info and logs.
>
> my audio device:
>
> ugen3.2: at usbus3
> uaudio0 on uhub1
> uaudio0:
> on usbus3 uaudio0: Play[0]: 48000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 192000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 176400 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 96000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 88200 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 48000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Play[0]: 44100 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 48000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 192000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 176400 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 96000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 88200 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 48000 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: Record[0]: 44100 Hz, 20 ch, 32-bit S-LE PCM format, 2x4ms
> buffer. uaudio0: MIDI sequencer.
> pcm0 on uaudio0
> uaudio0: No HID volume keys found.
I have a Scarlett 18i20 myself, but maybe a different generation - it has 18
recording channels as its name suggests. Is 20 recording channels correct for
your device?
>
> and /dev/sndstat:
>
> FreeBSD Audio Driver (64bit 2009061500/amd64)
> Installed devices:
> pcm0: on uaudio0 (1p:0v/1r:0v) default
> snddev
> flags=0x3e6
> [pcm0:play:dsp0.p0]: spd 48000, fmt 0x01401000, flags 0x2000110c,
> 0x0001, pid 22326 (virtual_oss) interrupts 115908, underruns 0, feed
> 115907, ready 123440 [b:30720/15360/2|bs:131040/65520/2] channel
> flags=0x2000110c {userland} ->
> feeder_root(0x01401000) -> {hardware}
> [pcm0:record:dsp0.r0]: spd 48000, fmt 0x01401000, flags 0x2000112c,
> 0x0001, pid 22326 (virtual_oss) interrupts 115930, overruns 97, feed
> 229796, hfree 30720, sfree 65440 [b:30720/15360/2|bs:65440/32720/2] channel
> flags=0x2000112c
> {hardware} -> feeder_root(0x01401000) -> {userland}
> Installed devices from userspace:
> dsp.full: (play/rec)
> dsp.record: (play/rec)
> dsp: (play/rec)
>
> regards, lexi.
I see that there's a lot of recording overruns and the recording software side
buffer of the pcm device is unusually small. Does recording work well for you?
Apart from that, I'd be interested in the exact circumstances this problem
occurs. Could you provide the dmesg and sndstat output as above, but with the
settings in loader.conf applied and playback hanging?
Since you're using virtual_oss, I suppose it produces an error log somewhere?
And then maybe the output of the following commands, also while playback is
hanging:
sysctl hw.snd
sysctl dev.pcm.0
You might also try to change the sample rate in virtual_oss to some other
value, and then back to 48000. That could give us a hint.
Regards,
Florian
Re: sanitizers broken (was RE: libc/libsys split coming soon)
Am 2024-02-21 10:52, schrieb hartmut.bra...@dlr.de: Hi, I updated yesterday and now event a minimal program with cc -fsanitize=address produces ld: error: undefined symbol: __elf_aux_vector referenced by sanitizer_linux_libcdep.cpp:950 (/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:950) sanitizer_linux_libcdep.o:(__sanitizer::ReExec()) in archive /usr/lib/clang/17/lib/freebsd/libclang_rt.asan-x86_64.a cc: error: linker command failed with exit code 1 (use -v to see invocation) I think this is caused by the libsys split. There are other issues too. Discussed in multiple places. I opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277222 this morning, maybe it can be used to centralize the libsys issues (= I don't mind of you add a comment there, but maybe brooks wants to have a separate PR). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: sanitizers broken (was RE: libc/libsys split coming soon)
On 21 Feb 2024, at 20:00, Brooks Davis wrote: > > The sanitizers reach somewhat questionably into libc internals that are > exported to allow rtld to update them. I was unable to find an solution > that didn't break this and I felt that fixing things like closefrom() > using non-deprecated syscalls was more important than avoiding changes > to the sanitizer interface. On Darwin, Apple added a special __interpose section that contains pairs of functions to be replaced and replacements. Within the library supplying the interposer, the symbol is resolved to the next version along, but everything that links to the interposing library sees the wrapped version. I wonder if it’s worth teaching rtld to do something equivalent. It’s a fairly lightweight generic mechanism that avoids a lot of the hacks that the sanitisers (and other things, such as instrumented malloc wrappers) do. David
