On Mar 21,  9:27pm, randolf+netbsd.org@inter-corporate.com wrote:
}
} >Number:         37475
} >Category:       install
} >Synopsis:       Update to report #37363
} >Arrival-Date:   Tue Dec 04 09:20:01 +0000 2007
} >Originator:     Randolf Richardson
} >Release:        NetBSD v4.0 RC5
} >Environment:
} NetBSD netbsd.guildfordcab.com 4.0_RC5 NetBSD 4.0_RC5 (GENERIC.MP) #0: Wed Nov 28 14:15:53 PST 2007  builds@wb34:/home/builds/ab/netbsd-4-0-RC5/i386/200711280522Z-obj/home/builds/ab/netbsd-4-0-RC5/src/sys/arch/i386/compile/GENERIC.MP i386
} >Description:
} This is an update to report 37363.  Please delete this report after merging it into 37363.

     Please see http://www.netbsd.org/support/send-pr.html#appending
for instructions on how to update an existing PR.

} >How-To-Repeat:
} Same problem occurs in NetBSD v4.0 RC5 -- "pf" still doesn't start when "GENERIC.MP" is selected during installation (instead of the default "GENERIC" where it does work).
} 
} >Fix:
} One solution I've found is to specify the "-f" option in /etc/lkm.conf which causes the module to be loaded anyway.  Although this solution seems to be working, I've not tested it in a high-volume network scenario so I don't know if system instability can occur.
} 
} The best solution would be for "pf" to be compiled for multi-processor mode when "GENERIC.MP" is selected during the installation.

     Nothing gets compiled at installation time.  Fixing this would
require shipping a pf lkm compiled for multi-processor mode, or fixing
lkms so that they aren't dependent on this.  It is too late to make
this change for 4.0, perhaps a later version of 4.x.  As for the
future, as I understand it, the non-multi-processor version of the
kernel will be going away, thus eliminating this particular problem.

}-- End of excerpt from randolf+netbsd.org@inter-corporate.com