Hans, can you further explain this "overcurrent not set"? I'm reading the USB 2.0 specifications here http://sdpha2.ucsd.edu/Lab_Equip_Manuals/usb_20.pdf on the last paragraph on page 339 with continuation on page 340.

I wonder why there is an overcurrent event happening in the first place ....

I see.

I'll get back to you tomorrow. Not working today :-)

Maybe you can add a __predict_false() there aswell.

Address come long lines and improve some type asserts.

In D35162#797274, @bz wrote:

I'd probably say "Dragonfly via drm-kmod" as you obtained it from drm-kmod?

@manu: Where was "include/linux/hash.h" obtained from?

Implement suggestions from bz@ and markj@ .

manu@ : Could you do a quick test with graphics drivers ?

I suggest you add a counter which resets on overcurrent not set, and counts to 3 before giving up power on.

Please update your patch! There is an "update diff" selection in the "menu".

• Implement crypto state as enum (as suggested by Gleb)
• Remove an unused variable
• Rebased patch.

LinuxKPI bits are OK.

There are some rc.d / devd scripts in base which needs fixing. Just
grep -ri mixer /usr/src

I have no objections for this patch, specifying percentage with "%" else it is relative to 1.0.

Looks good!

Maybe split the header file inclusions and the addition of new functions before committing.

Rebase patch after @jhb latest crypto additions.

@emaste: I've seen something similar with amdgpu . Testing on 13-stable right now :-)

Sounds good to me. Then only fast IRQ's can interrupt, but those are not used by the LKPI at all, so this should be fine.

Maybe use "const". Else looks good!

@mav: It is user-space I'm most interested in. I have a program that sleeps excatly 1ms and then wakes up to send a UDP packet. It is is very difficult to get it running correctly, because of scheduling taking time (this is my suspect) and I believe HZ=2000 helps.

@mav : This is not about sbt vs HZ.

BTW: Another thing we should do is to bump default hz to 2000, because many applications operate on millisecond granularity and task switching every ms, is the sometimes too slow!

I was just thinking about removing this line:

This will do too:

I suspect you can just remove the new_status . I think it is some leftover.

Just delete those lines. No need to comment out.

Your initial commit message was fine. Ignore my comment about mlx5 -> mlx5en.

FYI: This piece of code is unused.

If you look at:

I think a delmultitask would be appropriate to avoid races on the if_ioctl handler, adding and removing multicast addresses.