From owner-freebsd-hackers Thu Jun 3 12:52: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp3.mindspring.com (smtp3.mindspring.com [207.69.200.33]) by hub.freebsd.org (Postfix) with ESMTP id 6B28A159A0 for ; Thu, 3 Jun 1999 12:52:00 -0700 (PDT) (envelope-from ahasty@mindspring.com) Received: from mindspring.com (user-33qso9g.dialup.mindspring.com [199.174.97.48]) by smtp3.mindspring.com (8.8.5/8.8.5) with ESMTP id PAA27312; Thu, 3 Jun 1999 15:51:49 -0400 (EDT) Message-ID: <3756DD11.3F943D5F@mindspring.com> Date: Thu, 03 Jun 1999 12:52:49 -0700 From: Amancio Hasty X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu Subject: Re: 3.2-stable, panic #12 References: <199906031735.NAA37037@cs.rpi.edu> <199906031938.MAA99463@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Silly me , I was wondering what happen to you . I vote that your commit priviliges should not be taken away by the "Dark Side" of core and should be re-instated. Also wondering if this is perhaps a good time to split up FreeBSD along commercial / professional lines -- we can leave the silly core group along and proceed forward with a business model. Cheers, Amancio Matthew Dillon wrote: > I'm not surprised. I think this is similar to the other known NFS panics. > I haven't had a chance to reproduce it yet ( may not be able to until > after USENIX ). > > I have to say, though, that in order to fix these bugs I really do need > my commit privs back. If people want these things fixed, complain to core. > I have the time to fix the bugs with commit privs, but I just don't have > the time or inclination to fix them without. It is just too much stress > keeping a patch that should be committed in a day or two on the table for > two weeks and then have to beg people to deal with it. I am getting > wholely sick and tired of it, and I have better things to do then try > to maintain a pipeline of fixes that constantly get stopped up. I *want* > to fix these and other bugs, but I am effectively being prevented from > doing so because some core members freak out over the speed at which I > program and the amount of rewriting I sometimes do. I will point out that > all the rewriting I've done so far has been to the ultimate benefit of > the project in hind sight, resulting in better commented, cleaner, > and more reliable code and catching more bugs. > > -Matt > Matthew Dillon > > > :Our home directory NFS server went down again today, "same bat-panic". > :This time it went down on ".Maillock" (usually it goes down on a netscape > :cache file or .Xauthorit-c. Piecing some more together I modified my old > :"crash_patoot.c" file (which didn't cause any problems), to the new and > :improved version that does. > : > :This is our environment: > :FreeBSD NFS server running 3.2-STABLE from 1.5 to 2 weeks ago. Multiple > :client machines of multiple architectures (Solaris 2.6, Irix 6.5.2+, FreeBSB > :3.2+). These crashes were all reproduced with a Solaris client, I do not know > :if it is reproduceable with other clients. Below is the short code segment > :that will cause the crash, the additions I added to it to cause the crash > :were rename(2) and unlink(2), without those I could not get a crash. > : > :Also, available upon request is a packet dump of all traffic to/from that > :machine leading to the crash (it is only 198336 bytes long, it was > :captured with '-s 1500' with tcpdump). > : > :Without further ado crash_patoot.c: > :int main(int argc, char **argv) > :{ > : int fd; > : int counter; > : char newfilename[1024]; > : > : strcpy(newfilename,argv[1]); > : strcat(newfilename,".old"); > : for(counter=0;counter<1000000;counter++) { > : fd=open(argv[1], O_CREAT, 600); > : write(fd, &counter,4); > : rename(argv[1], newfilename); > : close(fd); > : rename(newfilename, argv[1]); > : fd=open(newfilename, O_CREAT,600); > : unlink(newfilename); > : close(fd); > : fd=open(newfilename, O_CREAT,600); > : close(fd); > : unlink(newfilename); > : } > : return 0; > :} > : > :If you are able to reproduce this panic please let me know. I want to be > :assured I am not going out of my mind. I am attempting to dig through the NFS > :code to try to find the bug myself, but it is a daunting task. > : > :-- > :David Cross | email: crossd@cs.rpi.edu > :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd > :Rensselaer Polytechnic Institute, | Ph: 518.276.2860 > :Department of Computer Science | Fax: 518.276.4033 > :I speak only for myself. | WinNT:Linux::Linux:FreeBSD > : > : > :To Unsubscribe: send mail to majordomo@FreeBSD.org > :with "unsubscribe freebsd-hackers" in the body of the message > : > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message