Co-author by: meka@tilda.center
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Details
Details
- Reviewers
meka_tilda.center markj kib emaste imp
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
Running polling:poll_select for the first time in VM exposes LOR while polling:poll_kqueue panics the kernel. The reason I added oss.h is to be able to use those common functions and structures in mmap based test that I have yet to write.
Comment Actions
The LOR is known and I think we have already tried to address it, but without much luck yet. I will look into it again. Also all known panics are fixed in D53029.
The reason I added oss.h is to be able to use those common functions and structures in mmap based test that I have yet to write.
For the purposes of these tests I think we actually do not need anything from oss.h, except maybe the initialization stuff, which is the same for all tests. We can clean it up (no need to do full-blown initialization IMHO) and put in a small function inside the test file. That being said, we could re-use some parts of oss.h to implement new tests for other areas of the sound subsystem. Ideas are welcome. :-)
Also it would be good to test both read and write for every polling mechanism.
Comment Actions
So, if I understand right, I should move oss_init into the test file and simplify it. What does it mean "simplify"? I guess mmap parts can be removed, but what else do you want gone? The thing is that I don't know what is the minimum that we can work with. Maybe just set sample format and remove all the rest? Also, what should I do with oss.h then? I mean, everything in that file is made just so the oss_init would work.
Comment Actions
- Take over, contacted Meka in private.
- Rewrite and simplify code.
- Test read and write for all polling mechanisms.
- Use the /dev/dsp.dummy device introduced in D53237.
This comment was removed by christos.
Comment Actions
Fix select(2) initialization.
The write tests work fine, however the read ones do not. I'm currently
debugging this, but it seems to be that at first run we return 0 "ready" bytes
for reading, and as a result, the kqueue(2) test blocks there indefinitely, and
the select(2) and poll(2) simply never call read() because they do not get any
notification. I am trying to see whether this is a problem with how we set up
recording channels. If I fill the recording with silence (i.e., zeroes) after
the channel is set up, things work fine, but I'm not sure yet if filling with
silence is a good tactic. I will need some more time with this.
That being said, the review here can continue normally.
| tests/sys/sound/polling.c | ||
|---|---|---|
| 96 ↗ | (On Diff #164738) | |
| tests/sys/sound/polling.c | ||
|---|---|---|
| 96 ↗ | (On Diff #164738) | Just added this a few minutes ago. :-) |
Comment Actions
- Call SNDCTL_DSP_SETTRIGGER to trigger recording and playback, otherwise the read tests block indefinitely.
- Perform one read and one write for each polling mechanism, and make sure we read/write more than 0 bytes each time.
All tests pass.
Comment Actions
# kyua -v parallelism=8 test sys/sound sys/sound/pcm_read_write:pcm_write -> passed [0.014s] sys/sound/pcm_read_write:pcm_read -> passed [0.018s] sys/sound/pcm_read_write:pcm_format_bits -> passed [0.020s] sys/sound/polling:poll_select -> passed [0.118s] sys/sound/polling:poll_poll -> passed [0.120s] sys/sound/polling:poll_kqueue -> passed [0.122s] sys/sound/sndstat:sndstat_nv -> passed [0.116s] sys/sound/sndstat:sndstat_udev -> passed [0.115s] Results file id is usr_tests.20251103-125623-132968 Results saved to /root/.kyua/store/results.usr_tests.20251103-125623-132968.db 8/8 passed (0 broken, 0 failed, 0 skipped)