User Details
- User Since
- Jun 3 2014, 6:45 PM (632 w, 6 d)
Today
Thu, Jul 16
Wed, Jul 15
I see these errors under low loads, and not always as "1 [mu]secs have passed":
I'm not convinced by the rationale here -- it seems to me that the stronger argument is "processing tx completions frees up space on the tx ring, which we might want when we respond to packets which we received". But the change itself seems reasonable.
Tue, Jul 14
The commit message refers to critical sections, but in fact counter_{enter,exit} are no-ops everywhere except powerpc, and somehow I doubt ENA will ever run on powerpcs. So the win here isn't about critical sections; it's just about reducing the number of atomic operations.
@imp In 824530a5c4fd59427cda0eae0a4ac85212814958 you wrote nda: Assume all cases in ndaasync can sleep and changed a different M_NOWAIT to M_WAITOK, but WITNESS complained about this code path:
Commit message edited for correctness and clarity.
Sun, Jul 12
Fri, Jul 10
Wed, Jul 1
Mon, Jun 29
Sat, Jun 27
Thu, Jun 25
Tue, Jun 23
Jun 21 2026
Jun 18 2026
@ivy Can you add the tweaks from ziaee/markj and commit this? I don't think we need to add the "how to upgrade from 14.4 pkgbase" instructions; that's an unsupported path and would bloat the document too much (and risk confusing users).
Jun 16 2026
Jun 15 2026
Jun 14 2026
Jun 12 2026
LGTM.
Jun 9 2026
Jun 6 2026
Jun 5 2026
Is this ready to go? And do we still need 16f21c5af35002b8361ffb2e83ff3c92cd899a3a ?
Please commit and MFC ASAP. I'm holding RC3 for the loader issue but once that's sorted I'm going ahead and will not wait for this patch.
MFC after: 1 minute
Accelerated MFC requested by: re (cperciva)
Jun 4 2026
Actually, this is a completely harmless bug since the GCE images are built with NO_ROOT so the accidental /etc/rc.d/growfs-e file doesn't get distributed anyway.
Just found @william.a_carrel.org 's phab account.
It's also brittle with pkgbase, FWIW.
May 31 2026
May 29 2026
May 28 2026
May 27 2026
Committed after the script and archetype were updated.
Any chance we can get a version of this which records which other exception is happening? I don't think we want that in production but if we can get someone who is experiencing the issue to run that it would be good to make sure we fully understand the problem.
Looks good to me. I assume you've tested it?
