User Details
- User Since
- Mar 11 2014, 8:46 PM (566 w, 1 d)
Today
@markj can you test this change on your Ampere box?
Hmm, Warner notes that this does not resolve his reported issue, but his reported issue is also not a regression? (I had been waiting to MFC all my rman changes to stable/14 under the impression it introduced a regression)
Yesterday
This seems sensible to me.
Rebase
Reduce diff
Generate dle from connected socket, avoiding duplicate sockets
Add a note about other threads being stopped
Mon, Jan 13
Ping
I've created a PR to do an exp-run both this and D43237 at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284039
Sat, Jan 11
Fri, Jan 10
It would be tempting to hoist the pages calculation out of the this inner loop and just doing if ((bz->map_count + 1) * pages < bz->bz_total_pages && bz->bz_total_pages < maxpages) as the condition. You'd have to basically add 1 more to the map count if BUS_DMA_MIN_ALLOC_COMP was set (and then stop setting the flag in the else). That would avoid continuously reserving pages up to the bz_total_pages limit if you just keep destroying and freeing maps (e.g. if a NIC driver destroyed all its rings and maps for ifconfig down/up). However, if multiple tags share the same zone you can perhaps get starvation across tags. If we wanted to avoid that problem, we could instead track how many pages a tag has allocated so far, and then the expression would be if ((bz->map_count + 1) * pages < dmat->bounce_pages && bz->bz_total_pages < maxpages). That also nicely handles the BUS_DMA_MIN_ALLOC_COMP case and we could drop that flag entirely.
Fix build and rebase
I'm fine with this. Don't the locking implementations just bail without panicking though if a panic is already active, or is the nested panic not inside a lock but elsewhere?
I do not know how to actually test this but it builds again. I had to do a hack to build tools/sysinit and then symlink that into my path to get stand/usb to actually build. I can run the test program but it doesn't do anything (and I'm not sure how to get it to do anything).
Push curthread check out to callers
Thu, Jan 9
Indeed, it is listed for 14.0 through 14.2, and we failed to mention the removal of twe(4) in the 14.0 release notes (we did mention twa(4) and several other drivers)
Not sure if we need to retroactively fix any release notes? It was removed in 14.0 and later.
@allanjude, @kevans, @markj in reference to testing on large arm64 boxes with multiple top-level pcibX devices
stand/usb still does not build though. Removing devclass from DRIVER_MODULE has broken the kshim bits quite a bit and needs some reworking.
@kib btw while documenting this, I do wonder if we shouldn't just merge bus_print_child_domain into bus_print_child_footer?
Adjust stale Xr in DRIVER_ATTACH
Fix sort order of Xrefs
The patch probably fails to apply because earlier patches in this stack already patch share/man/man9/Makefile
Drop quotes from .Nd
Testing locally I found that I did not need the changes to linuxkpi, I only needed the zstd change. For that, I also made the header include <sys/kassert.h> rather than <sys/systm.h> as we define all the assertion macros for the kernel in <sys/kassert.h>.
Also, the only contrib things I could find that are using c99 explicitly is ZFS. I wonder if those can use c17?
I'm working on trying to merge this and have the following candidate commit message:
I vote for just outputting the size in bytes as a single value as well ("x MB")
Supporting the GNU ls option (--group-directories-first) as a long option seems fine to me. For the FreeBSD-specific extension the similar long option is probably ok. If -G wasn't already claimed by color ls perhaps that would have been a good candidate, but there are very few remaining single-letter options.
Note my comment in the other review. The kmalloc_node family of functions needs the same fix.
This seems certainly fine. This is the semantics required for kcalloc and kmalloc_array
Why not use a taskqueue? That is what every other driver that needs this functionality does.
Wed, Jan 8
Tue, Jan 7
Possibly device_delete_children should also be in this manpage, but that also highlights that it probably should be renamed (or that all of these functions should be renamed to device_*).