update sysctl descriptions.

I appreciate your comment, Vladlen. Precisely at this point in my learning curve, your message is encouraging.
I’m focused on learning more and staying active in the project. Thank you for your guidance and your feedback.

This is triggered by pointing an IRQ at lapic > 256, e.g. cpuset -l 193 -x 4 on an r8i.96xlarge system (note that on this system, CPUs 192--383 have APIC IDs 256--447).

In D55789#1276669, @jfree wrote:

In D55789#1276630, @markj wrote:

A bit tangential, but: we found a while back that it was possible to trivially livelock a core by scheduling timeouts of 1ns using EVFILT_TIMER or setitimer(). Basically, it takes longer than the callout interval to execute the callout handler, so the callout handler ends up running in a loop.

I should note that the current timerfd implementation fails to pass the timerfd__periodic_timer_performance test, which expects 400000000 individual nanosecond timeouts. I usually see 360000000 - 380000000 timeouts printed by the test case. I'm not sure if this performance issue is related to the core livelock in some way. The callout routine (timerfd_expire()) is fairly lightweight, specifying absolute expiration time with maximum precision (no C_PREL() or pr specified).

In D55670#1276909, @christos wrote:

In D55670#1276620, @markj wrote:

In D55670#1276311, @christos wrote:

I'm thinking about this again and I'm suspecting this will make things very inflexible. I think that instead of patching virtual_oss, it might be better to have an environment variable that specifies the control device name, and let devd use that. @markj What do you think?

As I understand it, the basic problem is that virtual_oss is providing a virtual audio device, and there's an associated control device, and there is no mechanism to figure out the control device name from the audio device name, aside from looking at whatever's configured in rc.conf.

Can virtual_oss create files under /var/run which provide this mapping? Similar to a pidfile, it could create /var/run/virtual_oss.dsp at startup, and the file would contain the path to the control device. Then snd.conf would contain something like action "/usr/sbin/virtual_oss_cmd $(cat /var/run/virtual_oss.${cdev}) -R /dev/${cdev}". I'm pretty sure devd can perform substitutions like that, the devd.conf man page has an example of it.

The thing is that if we want to be flexible, we cannot know which control device the user wants to use. Perhaps the user wants to use a control device for a virtual_oss instance that does not replace /dev/dsp, hence why an environment variable that is easily modifiable might be simpler. Not sure yet.

I also tried to replace the TAILQ with STAILQ to avoid this line:

panic: /usr/src/sys/netinet6/nd6_nbr.c:1665: nd6_queue_rel: Bad link elm 0xfffff80028a00900 prev->next != elm

But the actual problem is the data is already freed and this is not just a consistency check failure from TAILQ (prev->next != elm).

Please look at the panic below produced by this patch when you have time.
I already reverted the delayed proxy address changes from the main branch, so this won't happen in production.
Honestly, delayed proxy addresses aren't that important.
However, it looks like we need to use a different lock to handle delayed proxy addresses.

Thank you!
@ocle done.

Yes, I like this version better.

In D55828#1277603, @pouria wrote:

In D55828#1277300, @zlei wrote:

Ah, I have WIP to fix the race condition between if_detach() and if_vmove(). See PR 292993 .

Oh, I was working on that problem too.
I thought you had seen D55777 earlier, you're on the reviewers list.
I can release the PR and assign it to you to avoid duplicating effort, if you want.

How about this? I think keeping the static_cast instead is more consistent with the rest of this source file.

I didn’t know about Coreboot until you posted this differential.