Subject: Re: install/37363
To: None <gnats-bugs@NetBSD.org, install-manager@NetBSD.org,>
From: John Nemeth <firstname.lastname@example.org>
Date: 12/04/2007 05:58:18
On Mar 21, 9:27pm, email@example.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
} 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
} 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.
} 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).
} 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 firstname.lastname@example.org