Date: Mon, 30 Oct 2000 14:39:11 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: brueggma@snoopie.yi.org Cc: freebsd-stable@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: df -h Message-ID: <39FD097F.FCFDEF4A@newsguy.com> References: <20001026072311.A765@snoopie.yi.org> <Pine.NEB.3.96L.1001027112657.18670D-100000@fledge.watson.org> <20001027140128.A90763@snoopie.yi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Brueggmann wrote: > > Yes sir: > > # ls -la smbfs-1.3.0.tar > -rw-r--r-- 1 root samba 716800 Oct 19 22:58 smbfs-1.3.0.tar > > # uname -a > FreeBSD dsl-64-193-123-121.telocity.com 4.1.1-STABLE FreeBSD 4.1.1-STABLE #0: Th > u Oct 26 23:36:44 CDT 2000 root@dsl-64-193-123-121.telocity.com:/usr/src/sys > /compile/BEAST i386 > > Since the previous post, I have found out that df, du, and quota all > cause the machine to reboot. But the machine only reboots using the above > commands after X mins of uptime. > > Eric B. > > Please let me know if you need more info. Well, this is not my bailiwick, but I must point out that this is _not_ enough info. Please excuse me if I appear to be rude, for I'm only trying to help you get _results_ when you have a problem. You won't get results if the feedback you provide is not adequate. You see, maybe the problem is with your computer. Maybe it's some specific option in your setup. There is a huge number of possible causes to the problem, which result in the problem not being reproducable elsewhere. Besides, committers are busy people, and spending hours trying to reproduce a bug is an unlikely proposition. So, the first problem with the above is that the instructions on reproducing it _are not clear_. For instance, "X minutes". Well, suppose I try to reproduce the problem without success. It might be that "X minutes" is more than I waited. It might be that "X minutes" depends on how much the fs is used, not the actual uptime. It might be that the problem is a hardware problem on your computer that is only exercised by some exoteric code. It might be all sorts of things. So, at that point, I don't know what to do. Of course, I _could_ give it a try, and ask for more information if I can't reproduce it at first try. But I won't. I have features I want to code, I have clear bug reports to look into, and I even have a Life (well, actually, I don't, but some of us do :). So, when I see a bug report like this, I'll simply ignore it in favor of something which I won't be wasting my time with. So, how do you go about it? First, try to find out what *DOESN'T* cause the problem to manifest itself. It fails with smbfs, right? Does it fail without smbfs? Does it fail with a GENERIC kernel instead of whatever specific kernel you are using? If it doesn't fail at first, what makes a difference? Some specific amount of time? Network usage? FS usage? Try to track down what's the last straw that causes it to start rebooting. If you think that's too time consuming for you, well, it is. But I have news for you. It's time consuming for us too, and we are _not_ being paid to look into it. Then you report the exact conditions necessary for the problem to manifest itself, as well as what doesn't cause the problem. And this is only the very minimum. Hardware descriptions, dmesg, kernel configuration file, configuration files and hardware description related to whatever you have having problem with, etc are all useful. If the problem happened to everyone, it stands to reason the author of the code would have found it already. So, generally speaking, you must assume the problem is NOT happening to everyone, and is related to something specific in your system. And this still isn't a *good* problem report, just an acceptable one. A *good* problem report is one in which you go to the trouble of making a kernel with the debug and extra checks options available, such as INVARIANTS and DDB, and then getting a backtrace of whatever panic you have. And while you might not be getting panics now, maybe you'll get them with INVARIANTS and DIAGNOSE. Maybe you are already using those options but, you see, you didn't mention that, so I have no way of knowing. HTH. HAND. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@world.wide.bsdconspiracy.net He has been convicted of criminal possession of a clue with intent to distribute. 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?39FD097F.FCFDEF4A>