Date: Sun, 01 Oct 2000 23:36:13 +0200 (IST) From: Roman Shterenzon <roman@harmonic.co.il> To: BSD <bsd@shell-server.com> Cc: freebsd-stable@freebsd.org Subject: Re: Another 4.1-S panic (full report) Message-ID: <970436173.39d7ae4d3a4de@webmail.harmonic.co.il> In-Reply-To: <Pine.BSF.4.10.10010011401380.70294-100000@marvin.shell-server.com> References: <Pine.BSF.4.10.10010011401380.70294-100000@marvin.shell-server.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting BSD <bsd@shell-server.com>: > On Sun, 1 Oct 2000, Jeffrey J. Mountin wrote: > > This looks very similar to some crashing I had months back. An older > drive > > didn't seem to like it at all and stopped using it for that drive. > Panics > > continued and removing the drive physically didn't help. Turning off > > softupdates for all drives did eliminate the panic and later commits > at > > some point fixed the problem and it could be turned back on, even on > the > > drive it didn't like. No need to recompile, just 'tunefs -n disable' > worked. > > So...given these later commits, I should be fine with softupdates > now, no? > > > >cpu I686_CPU # aka Pentium Pro(tm) > > >options NO_F00F_HACK > > > > The F00F problem is only with Pentiums. > > Exactly why I disable the work-around code with NO_F00F_HACK > option :) I686_CPU implies NO_F00F_HACK. In the code F00F_HACK is enabled only if I586_CPU is enabled. Thus, this option is usefull on AMD and alike processors which are "586" class. I wonder if your crashes has something to do with recently MFCed uipc_socket stuff. --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?970436173.39d7ae4d3a4de>