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
> <dil...@backplane.com>
>
> :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: cro...@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 majord...@freebsd.org
> :with "unsubscribe freebsd-hackers" in the body of the message
> :
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
