In D52166#1273749, @kenrap_kennethraplee.com wrote:

In D52166#1273524, @aokblast wrote:

In D52166#1196957, @kenrap_kennethraplee.com wrote:

In D52166#1196949, @aokblast wrote:

Hello, I think I need to at least get a usb 3 hub to test this feature since I haven’t had any super speed device. I will take a look at the candidates hub. However, I am occupied by other stuff recently. Maybe you won’t get any feedback very soon (Maybe a months afterI promise that I will be back ASAP since I would like to finish this feature. Sorry for your inconvenience on helping me test this!

Appreciate the heads up. I'll be on standby.

Hello, I am back and I suspect that https://reviews.freebsd.org/D55289 fixes the problem.
I have rebased the patch to the HEAD.
Could you please check if it actually works?

Welcome back! 👋

And thanks for rebasing too. I upgraded my base for the updated patch and others as well.

Sadly the non-detection problem still persists...

I got question though. Is there a way to passthru with a specific ugen number of the same vendor and product IDs?

I'm using multiple of these adapters and they have the same IDs. Only the earliest ugen device gets passthru'd when I need a later one instead.

I've been out of the loop with this so I'm trying to recall what I've forgotten. 🙂

jhb@'s patch is much better.

In D52166#1196957, @kenrap_kennethraplee.com wrote:

In D52166#1196949, @aokblast wrote:

Hello, I think I need to at least get a usb 3 hub to test this feature since I haven’t had any super speed device. I will take a look at the candidates hub. However, I am occupied by other stuff recently. Maybe you won’t get any feedback very soon (Maybe a months afterI promise that I will be back ASAP since I would like to finish this feature. Sorry for your inconvenience on helping me test this!

Appreciate the heads up. I'll be on standby.

Rebase to main

Thanks for all yours review:).

Minor fixes.

Delete the base commit

In D55603#1272290, @lwhsu wrote:

Quick response:

1. also need to add to sys/modules/Makefile
2. Do you have a plan to write a short man page?

Fix indentation

Fix Makefile and use recursive lock to make witness happy

Remove debug print

Support numa node report

Fix sysctl

I did some experiment and you are right, the compiler optimize it above O1.
Also, my assumption is wrong since reminder in aarch64 actually convert into udiv + msub, which is not faster than what we previous have.
Thanks!

Cache and free acpi_cppc_ctx immediately since we only use readonly field.
Also, use roundup to prevent duplicate frequency.

Use readonly struct to reduce memory consumption

Use uint64_t instead of platform dependent register_t

Don't implement FFH in generic bus driver since it is not widely used.

In D55477#1270996, @gallatin wrote:

I tried this on 3 EPYC generations at Netflix. The most recent (AMD EPYC 8434P, AMD EPYC 9535) behaved as expected. There was an dev.hwpstate_amd. node for each CPU, and a lot more freqs were exposed (from 3 to roughly a dozen).
On the oldest EPYC we have is EPYC 7502P, where it didn't change anything. We still only have 3 frequencies exposed. On this machine, we see just a single node from dev.hwpstate:
dev.hwpstate_amd.0.freq_settings: 2500/2750 2200/2200 1500/1350
dev.hwpstate_amd.0.%iommu:
dev.hwpstate_amd.0.%parent: cpu0
dev.hwpstate_amd.0.%pnpinfo:
dev.hwpstate_amd.0.%location:
dev.hwpstate_amd.0.%driver: hwpstate_amd
dev.hwpstate_amd.0.%desc: Cool`n'Quiet 2.0
dev.hwpstate_amd.%parent:

That contrasts to the other machines were we see something like this:

dev.hwpstate_amd.0.freq_settings: 400/-1 522/-1 644/-1 766/-1 888/-1 1010/-1 1132/-1 1255/-1 1377/-1 1499/-1 1621/-1 1743/-1 1865/-1 1987/-1 2110/-1 2232/-1 2354/-1 2476/-1 2598/-1 2720/-1 2843/-1 2965/-1 3087/-1
dev.hwpstate_amd.0.desired_performance: 33
dev.hwpstate_amd.0.maximum_performance: 255
dev.hwpstate_amd.0.minimum_performance: 33
dev.hwpstate_amd.0.epp: 0
dev.hwpstate_amd.0.%iommu:
dev.hwpstate_amd.0.%parent: cpu0
dev.hwpstate_amd.0.%pnpinfo:
dev.hwpstate_amd.0.%location:
dev.hwpstate_amd.0.%driver: hwpstate_amd
dev.hwpstate_amd.0.%desc: AMD Collaborative Processor Performance Control (CPPC)

I'm assuming its a BIOS setting to enable hwpstate, but I don't see it anywhere..

Fix GENERIC build

Return EOPNOTSUPP instead of ENOSUPP

Have rebased to main. Thanks!

Rebase to main

Mark FFH resource as 1 byte to prevent resource overlap

Set min max when something bad happens

Don't free when not possible

Abandon since we have 4.0.3 port.

LGTM for me but I think we should merge the intel's one at the same time.

Ok I see it is reused in other patch

LGTM with a comment.

Delete content instead of removing the whole directory

In D54757#1251289, @jrtc27 wrote:

In D54757#1251288, @aokblast wrote:

In D54757#1251272, @jrtc27 wrote:

I don’t understand, other than it sounding like bear is broken

Sorry, the commit message is not clear. I try to explain with more detail. Please tell me if you need anymore information.

When

pwd == $OBJTOP

, and after

run rm -rf "$OBJTOP"

getcwd(3) will return with error since the directory is deleted.

Under this condition:

When shell is executing:

mkdir -p "$OBJTOP"

bear intercepts the libc exec(3) function call and call getcwd in here. As a result, it causes an error.

So... bear makes assumptions that are false and breaks perfectly fine build system code

In D54757#1251272, @jrtc27 wrote:

I don’t understand, other than it sounding like bear is broken