User Details
- User Since
- Jun 6 2015, 10:46 PM (540 w, 2 d)
Today
I think this would be useful for driver developers, but we'd need to document is suitably so people know to look for it.
Wed, Oct 8
Looks good thanks for chasing it down
Sat, Oct 4
The deletions seem fine. The convention is probably up to you if you are changing to this.
Holding until Tuesday on this, FreeBSD-ports-kmods still isn't receiving pkgs for nvidia-kmod and @bapt needs some time before looking at it.
Wed, Oct 1
Sat, Sep 27
Sep 12 2025
Sep 10 2025
Sep 9 2025
Sep 8 2025
Sep 5 2025
There are two possible concerns that come to mind:
Sep 4 2025
Sep 3 2025
Sep 2 2025
Sep 1 2025
overall looks fine
Aug 27 2025
Aug 26 2025
@zlei do you know if all the consumer ifdi_get_counter implementations will still have been initialized correctly, for instance not making invalid references? It seems fine as long as there are no implicit initialization issues that relied on the current behavior.
Aug 19 2025
Committed in 9dbf8452e1fbb8e075b0f8d978fe9be9d0df9355
Aug 18 2025
LGTM, it's out of the way aside from a branch and the change to iflib_encap (is this change strictly necessary for simple or can it be committed separately?).
Aug 17 2025
Aug 15 2025
Aug 13 2025
Aug 9 2025
@imp if I recall this was something we were looking at on my team at LLNW, if it were in Bugzilla I'd say "Close - OBE" is appropriate.
Aug 8 2025
Aug 6 2025
Aug 5 2025
Aug 4 2025
Aug 2 2025
@kgalazka Nothing jumping out to me here for feedback on the code. I don't have an E610 so I can't do anything with this.. it looks like this is maybe a support tool where the file is sent to Intel for assistance, but if we can embellish anything as to how an end user might use any of this on their own that would be a worthwhile followup.
@kgalazka I'm ok with this, go ahead. Please think about budgeting some time for tinderbox, lint, and early user feedback issues that may come up, and by extension when you want to send it in, i.e. a Monday would be good.
Jul 31 2025
'nvidia-drm' would also be belong in this list
Jul 27 2025
@kevans were you able to get any reaction from portmgr@?
Jul 25 2025
@markj I think this behavior is identical to OpenBSD so adding part of their man doc.
Jul 24 2025
Jul 22 2025
I would remove the phrase 'change will not fix anything but' in the commit message and I think this is good.
Jul 21 2025
In the commit message do you mean to say there is something else double counting?
Jul 18 2025
Jul 17 2025
Pushed as 9302fb05a0c6599bbe8963ff5201fd3b99994535
Although I suppose the existing change is fine and maybe preferable
1500052 was just allocated for this in ff2dc0bca372
Jul 16 2025
Jul 15 2025
Jul 4 2025
Jun 26 2025
Jun 18 2025
Jun 14 2025
Jun 13 2025
Jun 9 2025
Jun 8 2025
May 30 2025
Generally ok with this. I would like to know if the malloc thing can be addressed during init or if that is required by your upcoming changes.
I'm planning to commit this soon unless a serious objection is raised.
May 28 2025
May 25 2025
May 24 2025
Is there a way to vendor the alt toolchains? It is imperative this doesn't start downloading from the internet outside of the fetch step, the same standards things like Cargo, Maven, etc have in ports. As long as that is addressed I think the overall concept is fine now -- it will be awkward if we have to patch Go but hopefully that is not common.
May 23 2025
May 20 2025
@markj go ahead and commit the initialization and style changes. I need a moment to think about the threading, so I would ask that goes in a separate commit, which you are free to do as well. Is there any reason not to use _int variant over long? This should MFC back to 32 bit platforms which seem to generate different code vs x86 for whatever it's worth. The driver is also "upstream" for RTEMS and other smaller systems.
May 17 2025
May 16 2025
Please reupload with context (git diff -U9999). It also seems to not be based on FreeBSD main.
May 14 2025
To add to what @erj said, multi-arch build is a requirement the same as on other OS projects. We have to provide some advance notice to drop things and this should be MFC'd back to 13 and 14. See build(7), 'make universe' or 'make kernels' is enough. I don't see anything off hand that is problematic, and there is no expectation on Intel for validation for odd platforms. But it has to build everywhere it currently does.
May 12 2025
I do see the improvement here for the drm maintainers not having to deal with all this, but I'd like someone with more ports infra experience to evaluate the implementation.
The first change seems sensible.
May 11 2025
I'm generally fine with what is here, it seems logical to me.
May 10 2025
I would be somewhat curious why we need to serialize like this. Note that nothing else prodding the swfw in ixgbe is explicitly locked or asserted.
May 9 2025
Fix DBUS, reported as https://github.com/bitcoin/bitcoin/issues/32464
May 7 2025
Looks good
See the actual commit message from that https://reviews.freebsd.org/R9:a52de44df1a6534adec66174ee68d03444738907
It will be helpful, especially early on, to add a fully formatted commit message to the review description so we can have a look and make sure you have the git config right.