Expand a comment explaining code.
Fri, Sep 22
PS: Read how to create patches with context for the phabricator. May be it is a problem of phabricator and it modified the diff after you, if I download the raw diff here, there is no even normal diff -p context, which is almost always useful.
While I understand your valid motivation, I can't say that I very much like this in patch for several reasons:
- NGM_ETHER_SET_ENADDR is a control command supposed to be targeted to ng_ether node, not from it, and it is a action request, not notification. I suppose if you connect two ng_ether nodes with lower hooks to create poor mans bridge, this won't work as expected.
- ng_pppoe has method to explicitly set MAC address, and it may get overwritten by this, which may or may not be correct.
- We just fought one locking issue, and here I don't see any hook locks or even references (I understand that your problem is narrower, but still).
Tue, Sep 5
Remove extra directory adds
Not sure where those head/* directories came from...
Mon, Sep 4
Update my tree before updating revision
incorporate some missing changes from dev branch
Commit was reverted
Wed, Aug 30
Tue, Aug 29
Aug 26 2017
move more blocking work to deferred context
Aug 25 2017
Yeah, legacy em(4) device on em2:
Huh .... Testing this review by itself this morning. I see the following startup panic:
Aug 24 2017
- Eliminate remaining mutex use in os independent e1000 code.
- Fold in iflib updates.
@jtl any comments?
Aug 23 2017
@erj I updated the summary - is there anything more I should add?
The busy waiting would cause 10% CPU usage on my system when no cable connected to em0 (traced to em_if_update_admin_status).
This patch also fixes this. I can no longer detect any unusual CPU usage.
Aug 22 2017
With this patch, and kern.ipc.cachespread="1", network traffic stops after some indeterminate time.
Can we also get a description of what this fixes, for future reference?
update to reflect potential for brokenness
Aug 20 2017
Aug 16 2017
Aug 15 2017
Aug 13 2017
I'd say go ahead for now; seems to make life better at least.
Aug 9 2017
Aug 6 2017
Aug 3 2017
I've done a bit more testing, and these debug traces tell the story:
Jul 31 2017
Hmm, good question. I thought I understood the failure flow fully, but now I'm not so sure.
Jul 30 2017
I think your description could be a bit more clear as I got confused. I think after re-reading it I now understand what you mean. Can you try to describe the sequence of events step by step here on how this gets triggered (especially how the new entry appears before we set it to NULL overwriting a new one?)?