- User Since
- Sep 28 2014, 7:22 PM (282 w, 1 d)
With this patch both riscv64 and riscv64sf TARGET_ARCH build result in something that can build ports. They both report the expected hw.machine_arch, and both have the correct MACHINE_ARCH set in bmake.
I've also had to apply this patch, but that's an issue that was already present:
Sun, Feb 23
There's certainly still something missing. When I build with make TARGET_ARCH=riscv64sf it builds with MACHINE_ARCH = riscv64, and that breaks ports builds (because we set the wrong flags).
Sat, Feb 22
Fri, Feb 21
Thu, Feb 20
https://github.com/riscv/riscv-toolchain-conventions defines __riscv_float_abi_soft as well, so I don't know if that helps us.
It's also not explicit about what the value will set to if neither F nor D extensions are present (although yes, I'd expect it to be unset or 0).
The previous version was an incomple fix.
It did ensure that the hw.machine_arch was correct, but bmake uses the
MACHINE_ARCH define if it exists. As it includes sys/params.h this was the
case. In other words: we need to ensure that MACHINE_ARCH is set correctly for
userspace builds as well.
Wed, Feb 19
Tue, Feb 18
Mon, Feb 17
I'm not sure why we care about CTLFLAG_MPSAFE on nodes with no handler (pf, pfsync), but I have no objections.
Sun, Feb 16
- sort test list in Makefile
- rename test case
Sat, Feb 15
Thu, Feb 13
Wed, Feb 5
Tue, Feb 4
Hmm. I wonder if it's not better the actually add the cleanup call to the atf_test_case definition.
It's not needed if the test passes, but perhaps it makes sense to try to restore the volume if the test should fail.
Sat, Feb 1
Fri, Jan 31
Thu, Jan 30
Wed, Jan 29
This patch series is happy on my SiFive FU540 board, and I'm happy with the patches.
Tue, Jan 28
At first glance this looks good.
I have a SiFive FU540 I can test with tomorrow.
Mon, Jan 27
Unloading the IPFW module seems like a bad idea. The netpfil/common tests rely on the module being loaded to run IPFW tests.
I believe the module is loaded because the test/build scripts explicitly load it, just like pf.
Jan 25 2020
Jan 23 2020
Thanks for the review.
Jan 22 2020
Jan 18 2020
Jan 7 2020
uma_zone_reserve() asserts that the keg is cold (no allocations done from it). I can only assume there's a good reason for that, but I can't say that I know why.
Dec 25 2019
Dec 13 2019
With all three of these patches I now see this panic running the pf tests:
Dec 12 2019
There's another call to if_vmove() in vnet_if_return(). We probably can't handle errors there (and I expect that D22691 will ensure it can't fail), but we should at least assert that it succeeded.
Still haven't looked at it, but it seems to fix PR 238870. No more panics (in a couple of runs of) pf:names / pf:synproxy tests, so as far as I'm concerned this cannot get merged quickly enough.
This seems to break the build:
Dec 11 2019
Improve error messages
Dec 10 2019
This affects the number of items (not just tables) that can be processed in a single ioctl() operation, not the number of entries we allow in a table.
pfctl by and large only works on a single table at a time, but might try to add/delete/modify/... multiple IP addresses at a time. It's generally possible to do this in multiple requests, so having more items in a table than the request_maxcount isn't a critical problem.
Dec 9 2019
Dec 4 2019
I have plans (and minor in-progress work) to do bridge tests with if_epair. I've not really found if_epair to be burdensome to write test withs (aside from its tendency to expose locking issues in the network stack).
Dec 3 2019
Nov 19 2019
Nov 13 2019
Nov 12 2019
Oct 25 2019
Oct 17 2019
Oct 15 2019
Oct 13 2019
Oct 12 2019
Minor nit: Mention where this is mentioned (i.e. the comments to the function).
Other than that this looks like a good idea to me.
Oct 5 2019
Oct 4 2019
This happens on a riscv machine, running from an mdroot (although I'm not sure if that's relevant to trigger it), not running devd during the aio_test:md_waitcomplete regression test.
That test opens /dev/mdX and tries to perform an aio write on it, which ends up failing. I'm not sure I fully understand the intent behind the test, but it revealed that the aio code considered that to be an unsafe. The safety check code thinks that mp->mnt_stat.f_iosize is relevant, and because of the lack of VFS_STATFS call that was still set to 0 for devfs.
Sep 25 2019
Sep 11 2019
Sep 8 2019
Other than the typo this looks good to me.
Sep 5 2019
Sep 4 2019
Aug 16 2019
This probably also wants this:
Aug 15 2019
Aug 14 2019
Aug 12 2019
And this is wrong, or at least very confusing, in firewall_init():
Aug 11 2019
I seem to run into issues running the ipfw_basic test:
Jul 31 2019
Jul 29 2019
I think I'm happy with this.
I'll give Tom a bit of time to add any more remarks he might have, but I think we can commit this soon.