On Sun, 28 Jan 2018, Paul Goyette wrote: > On Sat, 27 Jan 2018, John D. Baker wrote: > > > What sort of things are telltales of breakage possibly caused by the > > increased BTINFO_MAX? > > Was looking mostly for indications that the increased table size would > end up stomping on something else, with more-or-less unpredictable > results. Since that hasn't happened, I'm guessing that this change > is fairly safe.
I've not tried a pathological case of having lots of modules pushed by the bootloader. The verbosity modules are the only ones I care about at that point and anything else is either built in or loaded on demand. What are all those calls with type 4 and type 0 that preceed the first module load message? The pair immediately before each message seems to correspond with the module being loaded, but there are as many before that as there are modules to be loaded. That seems suspicious to me. > If not, we can always revert it! :) I double-checked my amd64/i386 kernels and none elide "options SCSIVERBOSE", so that module is built in courtesy of the included GENERIC config. Thus for me the quick fix is to not load the scsiverbose module via the bootloader. I have updated the relevant "boot.cfg" files accordingly. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
