Date: Wed, 13 Oct 2004 20:10:13 -0500 From: Jon Noack <noackjr@alumni.rice.edu> To: Andrey Chernov <ache@nagual.pp.ru> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: network slowness/freez-up since update 10/11 Message-ID: <416DD1F5.7060602@alumni.rice.edu> In-Reply-To: <20041014000822.GA30887@nagual.pp.ru> References: <16749.29947.220930.46409@jerusalem.litteratus.org> <Pine.NEB.3.96L.1041013162621.84384S-100000@fledge.watson.org> <20041013232318.GN718@empiric.icir.org> <20041013234411.GA29777@nagual.pp.ru> <20041013235816.GA35652@xor.obsecurity.org> <20041014000822.GA30887@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/13/04 19:08, Andrey Chernov wrote: > On Wed, Oct 13, 2004 at 04:58:16PM -0700, Kris Kennaway wrote: >> On Thu, Oct 14, 2004 at 03:44:12AM +0400, Andrey Chernov wrote: >>> Even with its locking mess it works perfectly in -current until >>> late August. >> >> You mean, until rwatson changed the default to debug.mpsafenet=1? :-) > > Your guess is precisely right! :-) > > (IMHO making such commit without testing major drivers such as if_de was > wrong step) Considering its scope, I believe the mpsafenet project has been handled quite well. Those involved went to great lengths (i.e. did a lot of testing) to ensure networking was usable throughout the process, and for the most part they succeeded. There are still a few rough edges (like if_de locking), but they're being worked on... >> debug.mpsafenet=0 is the known workaround, already mentioned in >> this thread. It hides the locking bugs by running the driver under Giant. > > Thanx, I already figure that out. Now building new kernel... That last sentence may be superfluous, but just in case: There's no need to build a new kernel for this -- debug.mpsafenet is a tunable and can be set in /boot/loader.conf or from the boot loader (still requires a reboot, though). Jon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?416DD1F5.7060602>