Date: Wed, 22 Jul 1998 23:40:48 +0930 From: Matthew Thyer <thyerm@camtech.net.au> To: Christoph Kukulies <kuku@gilberto.physik.RWTH-Aachen.DE> Cc: freebsd-current@freefall.cdrom.com Subject: Re: panic in one year old 3.0-current Message-ID: <35B5F2E8.5818B999@camtech.net.au> References: <199807220830.KAA05011@gilberto.physik.RWTH-Aachen.DE> <35B5D5AE.4801C673@camtech.net.au> <19980722153930.A6043@gil.physik.rwth-aachen.de>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] The attached messages will give you some idea on how recently NFS has been a major problem. It is so much better now that I think your should upgrade your machines to current as of now. There are still some rumours (not just rumours I think) of the odd niggling VM bug but overall current is in quite good shape as of a few hours ago (when I last built the world). I'm not one to comment on internals I'm just going on daily use (and abuse) of two current systems which I regularly update. Ask Peter Wemm for his opinion on the current state of NFS. I suspect there are still some problems in abnormal situations (NFS server crash may still be confusing the NFS client). Christoph Kukulies wrote: > > On Wed, Jul 22, 1998 at 09:36:06PM +0930, Matthew Thyer wrote: > > NFS had lots of problems until quite recently. > > Sigh. Tell this a person to whom you always argued "I'm using FreeBSD > over Linux for it's stability what networking is concerned" :-) > Maybe things are even worse under Linux. > > NFS was indeed involved in my case alse (see below). > > > > > I was restricting my NFS use to the version 2 protocol until very > > recently. > > > > Now it seems to work very well with version 3 on recent current. > -- > --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de -- /=====================================================================\ |Work: Matthew.Thyer@dsto.defence.gov.au | Home: thyerm@camtech.net.au| \=====================================================================/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 [-- Attachment #2 --] > I've got a series of large NFS commits coming up shortly. 'cvs diff -u | > wc -l sys/nfs' is in the order of 6000 lines, so I'll try and break it up > into smaller components where practical. > > This means that while things are in transit, the kernel and/or utilities > may well not compile. Don't be too suprised if your world falls over if > you try and build from sources mid-commit. (I have not checked all the > userland stuff yet, amd in particular). > > One of the bigger components is a long -> int32_t change for Alpha and > other 64 bit support. > It is *wonderful* that you are making progress on NFS. That is one of our major problems, and making progress on that is a major contribution. A personal thank you!!! John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message [-- Attachment #3 --] Stephen McKay wrote... > NFS is eating my .depend files during a make world. I can confirm this, but not from make world. I've got a source tree here that blows up when I compile over NFS. > The client is a Compaq Prolinea 486SX33 with 12Mb ram and 2 small SCSI-1 > disks on an Adaptec 1542b. The server is a pentium 133 with 32Mb ram and > 2 4Gb IBM UW SCSI disks on a FirePort 40 (ncr 875). > > The source and objects are on the server and NFS mounted to the client. The > client mounts src readonly and obj read-write (and async, if that does > anything under NFS). I have a similar setup, except the source and objects are in the same place, and the mount is r/w and not async. > The client kernel (and userland) is -current from April 19 (April 18 US time), > and has DIAGNOSTIC set. The server is -current from March 12, just before > the big VM changes. In my case, the client is from a week or two ago, and the server kernel was built from yesterday's sources. > Memory is short on the client, so paging is brisk. There is plenty of > swap space free. I don't run CAM or softupdates. I'm running CAM, I don't think that has anything to do with it. The client only has 24MB of memory, but it doesn't look like I'm running into swap at all: Device 1K-blocks Used Avail Capacity Type /dev/da0b 122880 0 122752 0% Interleaved > I ran 'make -j2 buildworld' and several hours later observed unusual error > messages complaining about garbage in .depend files. Many .depend files > were affected. Each .depend file was broken similarly. They would start > normally, then the corruption would start on a page boundary (multiple of > 0x1000), but *not* extend as far as the next page boundary. The corruption > was either C source, or C preprocessor output overwriting the normal contents. Right, I have the same problem. The corruption in the .depend files starts exactly at 0x1000, and continues on for a while, but not for a full page. From what Karl says, John is already aware of the problem. I just thought I'd confirm your findings... Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message [-- Attachment #4 --] >I ran 'make -j2 buildworld' and several hours later observed unusual error >messages complaining about garbage in .depend files. Many .depend files >were affected. Each .depend file was broken similarly. They would start >normally, then the corruption would start on a page boundary (multiple of >0x1000), but *not* extend as far as the next page boundary. The corruption >was either C source, or C preprocessor output overwriting the normal contents. I have similar results, on 2.2.6-STABLE. I have also in the past seen the .depend's full of nulls. The only major difference is that my entire .depend is preprocessor output, and not just a page-worth. Mounting with nfsv2 seemed to have fixed that problem, but then I ran in to dead .nfs* files being left around, which caused grief elsewhere. I haven't been able to build over NFS since at least March, possibly even January or February. Evan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35B5F2E8.5818B999>