Subject: Re: install/37363
To: None <,,>
From: John Nemeth <>
List: netbsd-bugs
Date: 12/04/2007 14:00:10
The following reply was made to PR install/37363; it has been noted by GNATS.

From: (John Nemeth)
Subject: Re: install/37363
Date: Tue, 4 Dec 2007 05:58:18 -0800

 On Mar 21,  9:27pm, 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 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
 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