Finally some success with suspend/resume

Snurg

Daemon

Reaction score: 588
Messages: 1,349

Then I'd suggest to first reduce the convoluted configuration to the absolute minimum (the only really necessary setting is probably zfs ashift).
If that does not fix the issue, then open a new thread with a concise title "Upgrade to 12.2: Audio no longer works after suspend/resume", which indicates that you had it working, and that the problem is possibly-probably caused by the upgrade, and include your configuration in spoilers (see the editor menu, click the hamburger, then choose spoiler).
 

Mjölnir

Daemon

Reaction score: 1,507
Messages: 2,114

OK so this is the working set of configs of your X230 laptop, suspend/resume works, but you're not happy with your sound setup, it's not doing what you expect. Correct?
  • The default kern.hz=1000, olli@ recommends setting that to a common multiple of video frequencies, thus my recommendation is 1200 or 1800, and
  • the general guideline is to keep loader.conf(5) as minimal as possible, only load kernel modules from there that are needed to boot the BeaSD (reasonable exception: cpu_microcode_load="YES"), and the sysctl(8) knobs that can't be set @runtime later. So you should move most of your knobs to either sysctl.conf(5) or rc.conf(5) (foreach xxx_load do sysrc kld_list+=" xxx")
Then, the sound issues should go to a new or continue an existent thread IMHO.
 

Mjölnir

Daemon

Reaction score: 1,507
Messages: 2,114

PS I want to maintain some structure in my rc.conf(5), thus I'm doing in each commented section like this:
kld_list="$kld_list cuse" # cuse(4) needed by webcamd(8)
instead of having all kernel modules in one long kld_list.
 

olli@

Daemon
Developer

Reaction score: 1,233
Messages: 1,125

The default kern.hz=1000, olli@ recommends setting that to a common multiple of video frequencies, thus my recommendation is 1200 or 1800
Actually, I would rather advise to decrease it to 600 or even 300, especially on a mobile machine (laptop, notebook) that may potentially run on battery, in order to give the CPU more opportunity to enter power-saving P-states. I even run my normal desktop workstation with HZ=300. Increasing the HZ value does not improve interactivity for a normal desktop machine.
 

Snurg

Daemon

Reaction score: 588
Messages: 1,349

Actually, I would rather advise to decrease it to 600 or even 300, especially on a mobile machine (laptop, notebook) that may potentially run on battery, in order to give the CPU more opportunity to enter power-saving P-states. I even run my normal desktop workstation with HZ=300. Increasing the HZ value does not improve interactivity for a normal desktop machine.
Wasn't the default HZ=100 on earlier FreeBSD versions?
I only had to increase that a bit for playing Diablo 2 in a window, back in the 32bit age, to avoid the mouse cursor getting jerky.

1000 is really extreme...
Damn good suggestion to reduce this. 👍
Maybe a hint to this could be added to the Environmentalist thread...
 

Mjölnir

Daemon

Reaction score: 1,507
Messages: 2,114

Actually, I would rather advise to decrease it to 600 or even 300, especially on a mobile machine (laptop, notebook) that may potentially run on battery, in order to give the CPU more opportunity to enter power-saving P-states. I even run my normal desktop workstation with HZ=300. Increasing the HZ value does not improve interactivity for a normal desktop machine.
Ok took me some time to get that... is this correct?
  • the interactivity/responsiveness is mainly affected by the sysctl(8) knobs kern.sched.{static_boost,preempt_thresh,interact,slice}.
  • the accuracy of timings for multimedia is (can be set) better with a higher kern.hz.
  • if you want to enable polling(4) on a network iface, the recommendation is to set kern.hz >= 1000; polling(4) saves IRQs, thus it helps with interactivity.
 

olli@

Daemon
Developer

Reaction score: 1,233
Messages: 1,125

Actually, I would not touch any of those settings. FreeBSD works pretty well out of the box for desktop systems. The only thing that might help somewhat is setting kern.sched.preempt_thresh=224, but even this is not strictly necessary if you have adequate hardware.

I should also mention that the polling(4) manual page might be somewhat unclear. Polling was designed to improve responsiveness for heavy-loaded servers that are running > 90 % on IRQ for I/O, potentially even deadlocking the system. It was not designed for desktop machines, and I doubt that it improves interactivity at all. When your system does not have a high IRQ load, then polling won’t help at all. Check the output from vmstat -i – If you get 5 digit numbers or larger in the last column (i.e. >= 10,000), then you might benefit from polling. Otherwise don’t bother.
 

Mjölnir

Daemon

Reaction score: 1,507
Messages: 2,114

  • Then why was the default kern.hz increased from 100 to 1000 at all?
  • What about the timings for multimedia stuff?
  • Can I use dev.pcm.*.bitperfect=1 with kern.hz < 1000
Sidenote: maybe I "tuned" & managed to mess up some of my hw.snd, dev.pcm & timing (kern.timecounter.alloweddeviation) sysctl(8) knobs, because I suspected sub-optimal default settings, but now I found out my 3m long audio cable has a slack joint... :(
 

Snurg

Daemon

Reaction score: 588
Messages: 1,349

On the 8088 PC with 4.77MHz the 18 ticks/sec already was a considerable load, depending on the chain of installed interrupt handlers.
Nowadays with GHz clocks and modern processors, 1000 are not much.

The issue is more with the constant waking up from sleep, usually not necessary with normal desktop usage.
But on laptop on battery you care about a few minutes more capacity.
 
Top