I'm deploying this to one or two of the machines that we see panics from this every few days.

In D25630#569409, @neel_neelc.org wrote:

I think this broke the build on r363327 with if_an.

Looks good to me. EFI is already in kern.opts.mk, so I think this is good to go.

Did you add this to the kernel options makefile too?

Love it...

bump date

Update example
Soften the wording a little

looks good to me... one might quibble over the extra newline after the if, but it's fine either way imho.

In D25601#566410, @markj wrote:

In D25601#566409, @imp wrote:

I don't think this is a good idea....

Setting sysctl values multiple times may be unwise.

We already do that today, via /etc/rc.d/sysctl and /etc/rc.d/securelevel.

For modules, I think, we should document tunables in loader.conf not in sysctl.conf, even though many tuneables are now exported there and often writable.

I don't think this is a good idea....

Awesome thanks

In D25312#564662, @jhb wrote:

I think the rule to only use initializers when the value is constant is probably a good compromise.

Update to match what I think the conensus is in this review. Please
tell me how well I did :)

So other than the 1MB issue, these changes are better. We should commit all but that one detail, imho.

1MB is a lot better in terms of performance. I'd keep it. 4k makes no sense to me how it could possibly be faster: there's a lot more system calls, there's a lot more churn at each layer. While maxphys is only 128k by default, the reduction in system calls will help. 4k is way way too small. It's the exact opposite of my experience.....

I only looked at mpr, but this looks good to me. It's good you have a way to recreate it. I have random machines failing with this (about ~0.001%/day), but can't find one to recreate it. I like this approach, and is similar to the one I took with other commands and target reset. thanks for fixing.

In D25406#563589, @fernape wrote:

In D25406#563533, @gbe wrote:

In D25406#563515, @0mp wrote:

In D25406#563509, @fernape wrote:

In D25406#563478, @gbe wrote:

Thanks for the patch!

Everything looks good except the manpage date, which should be bumped. :)

Hi Gordon,

Thanks for reviewing this!
I usually bump .Dd when I commit the review (although I know it is a risk because I could forget it). As a general rule, should the manpage date and the commit date be equal?

The manual page date should match the commit date.

@0mp I usually tend to not hand edit my "commit ready" tree.

Don't we have a commit-hook that checks for .Dd? Would it be difficult to implement?

I'll echo Simon here: any change of this size could always be a bit better, but given the level of nits I'm finding most of them can be addressed by being a little more explicit about the points I've questioned in the commit message.

I can't easily review the ZFS parts of this, so just a couple of questions...

In D25492#563565, @carlavilla wrote:

I don't know how I couldn't remember ... you just have to escape the character, instead of _ use \_

Current changes are good.

In D25492#563079, @carlavilla wrote:

@imp and @bcr can you please review the new diff again.
Thanks :)

All the nanobsd changes are wrong.

Either of the proposed text changes sound good to me.

love it

Thanks for the earlier cleanups. Mostly minor stuff, and much of it is questions or leading questions...

Lots of repetition in the module makefiles should be cleaned up. Normally I wouldn't fuss too much, but in this case it's very pervasive.

Sent a similar thing to Kirk and he agrees.

Personally, I'd land this in -current and then MFC it into 12.2, but have it on by default in -current and off by default in 12.2.

This is what Netflix has been using for the past 2 years.

Love it

Thanks Colin!

This was a silly idea, born of uber frustration.

Thanks for finding this. We went round and round when it went in. Might not hurt to make sure it still works on other boards
.

In D25324#559405, @tsoome wrote:

In D25324#559399, @jhb wrote:

FWIW, my hope had been to have a single gptboot that does both UFS + ZFS. I don't envy the logic to figure out which one to boot from if both are present though. :) What is the current size bsdinstall uses for freebsd-boot and how long ago has it been 128k?

merging those bits will take some time. The current freebsd-boot is created 512k and the zfsldr code is reading 256k, so with current code, we are actually well within the limits. The question is about old setups.

Summary so far:

1. there's overwhelming support for this, at least in theory
2. the devil is in the details.

In D25312#558130, @rpokala wrote:

Please clarify that declaring a variable within the parens of the for is permissible.

These look great. You could do a few of them as separate commits, if you wanted (like the arm param.h), but it's not big deal either way.
I didn't pedantically audit all the new assembler (git is confused about where it came from :).

The only thing that we need to do is the relative vs absolute link. The FreeBSD.org thing would be nice as well, but not urgent.

Cool script. It would be better to add the alias with devfs. Then it would disappear w/o devd needing all the info...

Seems same to me.. wouldn't hurt to get mav@'s nod too

This looks decent to me with the changes. I'd test it, but I have no ciss hardware

I think think this is fine, assuming that 'now' is updated often enough to be meaningful for fast bus speeds. Though the old code has issues > 500KHz too...
I think this is a better method in general. Some devices don't like to be polled that fast, but they are rather the exception than the rule (and I'm not aware of any GPIOish device that can't cope). Polling faster should give a better response time than the fixed delays.

OMAP4 will probably not work at current state.