Waiting for bufdaemon

[Santiago Martinez]

Hi, excellent the patch clear the problem for me when rebooting after a
kern compile, etc, etc.

Also seems that Firefox and pycharm or any other java related tools are
not freezing any more, but its maybe to early to confirm this 100%.

Will keep you posted.

Santiago

On 1/20/21 1:58 PM, Santiago Martinez wrote:
> Hi Everyone, i have exactly the same behavior as Rainer described.
>
> "After a high system load, several programs only react very slowly (e.g.
> Firefox)......"
>
> I will try with the patch and see if it also clear this on my machine
> (AMD R7).
>
> Santiago
>
>
> On 1/20/21 1:52 PM, Konstantin Belousov wrote:
>> On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote:
>>> Am 20.01.21 um 14:12 schrieb Konstantin Belousov:
>>>> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote:
>>>>> Am 20.01.21 um 13:34 schrieb Konstantin Belousov:
>>>>>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote:
>>>>>>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov:
>>>>>>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
>>>>>>>>> This patch hides the problem for me. The system seems to work better now.
>>>>>>>>>
>>>>>>>>> No waiting on reboot, and the webcam works better.
>>>>>>>> I am curious what do you mean by the above reference to webcam.
>>>>>>>> Can you explain it with more details, even if only the impressions?
>>>>>>> I should mention, that beside the already discussed timing problem with
>>>>>>> bufdaemon, I also have problems with several apps:
>>>>>>>
>>>>>>>
>>>>>>> After a high system load, several programs only react very slowly (e.g.
>>>>>>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do
>>>>>>> not update their windows anymore, they freeze. After some time, Firefox
>>>>>>> updates its screen content only after switching back from another window ...
>>>>>>>
>>>>>>> When such frozen programs are killed and restarted, they run normally
>>>>>>> again for an indefinite time before they freeze again.
>>>>>>>
>>>>>>> These symptoms completely disappeared, after I patched the Ryzen box as
>>>>>>> suggested on 01/17:
>>>>>> Do you load latest microcode update from devcpu-data?
>>>>> Yes, sysutils/devcpu-data is installed and the following to lines are in
>>>>> /boot/loader.conf
>>>>>
>>>>> cpu_microcode_load="YES"
>>>>> cpu_microcode_name="/boot/firmware/intel-ucode.bin"
>>>>>
>>>>> But isn't this just for Intel (i387 and amd64), not AMD cpus?
>>>> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode
>>>> update.
>>>>
>>>> I think that early boot update should work on AMD, bit for this you need to
>>>> select and put right blob.  It is enough to load late to answer my question.
>>> Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in
>>> /etc/rc.conf for a late update.
>>>
>>> Should I try again without your patch of sys/x86/tsc.c, whether the
>>> problem still occurs?
>> Yes.
>>
>>> And for the early boot update, how do I know about the right blob?
>> I am not aware of the mechanism.  My best suggestion is that you match
>> the blob against your CPU family/model id manually.
>>
>>>>>> It might be not enough, which means that additionally latest BIOS needs
>>>>>> to be flushed.
>>>>>>
>>>>> I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite"
>>>>> mainboard.
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20210120/4cdec22e/attachment.sig>