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

In D54551#1248714, @markj wrote:

Looks ok, but I'd use int in the function signature.

Minor fixes

Remove License message

Move commit back

Move commit back

Seperate differential

Minor fixes

Use x86_msr_op

Simplify dump_sysctl_cb
Add helper functions for single cpu

Thanks! Thought I sucessfully booted up on a AMD64 machine, this patch touches the basic logic of smp so I will think twice before landing it.

In D54466#1244696, @ziaee wrote:

Thanks aokblast!

This belongs in DESCRIPTION section.
The mdoc(7) manual specifies what goes in SYNOPSIS.

Also, each new sentence starts on a new line.

Minor fixes

Trust sc->req in set_epp and add () in KASSERT

Use hwpstate_amd instead of hwpstate
Not short-circuiting for cpu

In D54173#1238612, @unitrunker_unitrunker.net wrote:

Now I have a dilemma.

I can add exclusivity inside libusb20.c or push down one more layer and add this to the backend in libusb20_ugen20.c. To do this in the backend, device_open_t gets a third parameter for the flag. It's a six-for-one, half-dozen-for-the-other kind of decision.

The scope for this change is exclusivity. No plans to touch existing enumeration behavior.

I'll have to create a separate review. Everything will link back to the same bug.

Minor fixes

Haven't test it. But I have a comment. It would be great if we can solve multiple device issue like this.

Thanks for the comments! Hope it looks better now.

1. Fix indentation
2. Remove hwpstate_cppc_settings structure
3. Update sc->req in all cpu cores
4. Fix sc->req style nits
5. Consistent CAPS and REQUESTS macro

In D49587#1235795, @olce wrote:

In D49587#1235740, @aokblast wrote:

@olce I think exposing the epp setting interface only in only cpu0 makes sence and therefore I make some changes.

Mmm... It's not that providing it only on CPU 0 does not make sense, but actually having a different knob for each CPU can be useful (admittedly in corner cases), and would be consistent with hwpstate_intel. But that's of course not a blocker, this can be added back later on.

Going to review the new version.

@markj Please also help me review it when you have time, thanks! Also, I remember that you have told me that it is better to send ipi instead of binding the CPU, but I forget the url of your sample code. Could you please provide it in here?

If Mark gives no answer in a few days, I'll suggest something.

Minor fixes

@olce I think exposing the epp setting interface only in only cpu0 makes sence and therefore I make some changes. @markj Please also help me review it when you have time, thanks! Also, I remember that you have told me that it is better to send ipi instead of binding the CPU, but I forget the url of your sample code. Could you please provide it in here?

Expose the epp interface in only cpu 0 and modify all cpu value.

Make sense to me.

In D52166#1232521, @bz wrote:

It's gotten silent here. May I ask what the plan is? Is there a chance to get this work into 16?