Time Saving Tips for problem reporting: o The BSD/OS V2.0 and later release notes have a section on "Problem Reporting Procedures", please refer to them for additional information [everything in this message is in the release notes]. o Include your Customer ID (this is on the invoice and generally looks like B9999, G9999, N9999) with the support request. If you don't know customer ID then include other distinguishing information, e.g., company, postal address, and telephone information. If you don't know it then just state that in the email and we will look it up and give it to you for future use. o Check the release notes for information relevant to your question. o Include OS version information and what patches you have installed (if you don't have all the patches installed please check the current set carefully to see if something might be relevant to your problem). Also, tell us if you are running a source or binary system. If multiple systems are involved please include that information also (e.g., if you are trying to dial into a SunOS 4.1.3 box from a BSD/OS V1.1 box using uucico then it is helpful to know that). Basically, give us as much context as possible. Assuming you have support (if not, call 800-776-BSDI to sign up) and that you are the support contact for your site, then you can get the current patch information by sending email to patches@bsdi.com (``help'' will get you instructions). Remember, you must have registered your email address with us before this will work. Contact us if you need information about who is the support contact for your site. To get the current list of patches use: send index If the system doesn't recognize you by your email address then you can specify your customer ID like so: cust G9999 send index o If the item is really urgent then put `urgent: ' in the subject so we can give it the appropriate priority. o Send detailed problem reports and include the various configuration files that might be related (see below for some tips on that). We get many reports that don't have some of the basic facts in them and that causes a lot of extra work for everyone. If you can, run the software with debugging enabled to gather extra information. The more information you give us, the more likely we can solve your problem first try. o Report the thing that actually failed first (sometimes failures cascade and people report only a secondary failure, unless it is pretty obvious then try to reproduce it a couple of times to make sure that something else didn't fail first). Include the exact error messages reported by the system, sometimes errors are very similar. Use ``ktrace -i program args...; kdump'' to get additional information if needed. o Avoid making assumptions about the problem. The first part of the problem report should be just the facts (``I typed this, the system replied that, here are the configuration files, etc''). Then in the second part you can explain what your thoughts, assumptions, and conclusions are about the problem. Both parts are important but more and more reports seem to tend towards containing only the latter. o Explain in detail what you have done to try and solve the problem. That way we can have a better idea of what it isn't. o Include hardware configuration information (/var/db/dmesg.boot is a good start but not always complete so check it over). Many problems are nothing more than io port or interrupt conflicts. Another source of frustration is the IO memory space. Each 128K segment of IO memory must all be either 8- or 16-bits wide. 8-bit cards will fail if you have a 16-bit card in that segment. The segments are basically 0xa0000-0xbffff, 0xc0000-0xdffff, 0xe0000-0xfffff. Another way this can bite you is say you have an 8-bit BIOS at 0xc0000 and a 16-bit ethernet card at 0xd0000. The 8-bit BIOS will work during system boot because the ethernet card's memory is disabled. Once you start the ethernet card however the BIOS will no longer work, sometimes this is the cause of the "my system won't reboot by itself" problem and sometimes more mysterious problems. o TTY, Modem, login, dialout, uucp, etc, problems: Include relevant portions of /etc/ttys, /etc/gettytab, /etc/remote, UUCP config files. If processes are involved (e.g., hung or running away) include the relevant portions of ``ps axlww'', ``pstat -t'', ``stty -a -f /dev/ttyxx'' (and please be sure to specify the processes or ttys in question). o SCSI problems: These are almost always configuration problems. Hardware things to check are cables and SCSI termination (only the *ends* should be terminated, you should have exactly two terminators on the entire SCSI bus). SCSI BIOS configuration options to try are: disable sync negotiation, disable "fast SCSI", set the DMA transfer rate to 5.0MB/s, make sure that if parity checking is enabled on your host adapter that all devices have parity enabled. Even if it's terminated "properly" you could still have termination problems, try an active terminator. External devices often cause problems and cables are very important for external devices, make sure they are short and SCSI-II compliant. Total of all cables should be less than 5 or 6 feet for best results, keep in mind that external boxes have cables *inside* the box, sometimes 6 inches or more. It's best if you can swap hardware around to try and isolate the problem. Remove things to make the bus simpler. Even if it works under DOS that doesn't mean there isn't a problem. Different drivers do different things and multiuser, multitasking systems make SCSI hardware work much harder. o Network problems: Include output from ``netstat -m'', ``netstat -rn'', ``netstat -ind'', ``netstat -s'', ``netstat -m'', ``vmstat -m'', and ``ifconfig xx0''. And in many cases, tcpdump can be used to gather information about failing network traffic. Also, ping and traceroute can be most helpful [see also the release notes]. Send a description of the network load, e.g. how much PPP, SLIP, etc, traffic, using which devices. Also, any ideas you might have on correlation of system activity at the time the problem begins. For SLIP or PPP problems send the configuration files (/etc/ttys, /etc/ppp.sys, /etc/slip*). o Routing Configuration Questions: Be sure to included details about your entire network. What IP addresses on which networks using what netmasks. Send an ``ifconfig xx0'' for each interface plus a ``netstat -rn'' from each system involved. Be sure to say which systems are running what software. Make sure that ``options GATEWAY'' is enabled in the kernel configuration (see release notes under "Gateways"). PROXY ARP --------- If configuring a SLIP or PPP client using a network address inside your ethernet's network you will need to configure Proxy ARP. This can be done with the command: arp -s 999.999.999.999 88:88:88:88:88:88:88 pub Where 999.999.999.999 is the IP address of the connected machine and 88:88:88:88:88:88:88 is the Ethernet MAC Addresss of the server. [and when you have things working, put this command in /etc/netstart] Get the ethernet address of the server with ``netstat -in''. For example, given: % netstat -ni Name Mtu Network Address ... tn0 1500 0.c0.f2.0.1e.c0 ... ^^^^^^^^^^^^^^^ ... tn0 1500 240.124.135 240.124.135.1 ... lo0 1536 ... lo0 1536 127 127.0.0.1 ... ppp0 1500 ... ppp0 1500 240.124.135 240.124.135.2 ... % pppconfig ppp0 ppp0: flags=9051 inet 240.124.135.2 --> 240.124.135.3 netmask 0xffffff00 ^^^^^^^^^^^^^ You would run: % arp -s 240.124.135.3 0:c0:f2:0:1e:c0 pub o Kernel Hangs or Panics: If you are reporting a kernel hang or panic then please read the section "Kernel Debugging" in the release notes and submit that information. In addition, a ``dmesg -M /var/crash/bsdcore.0'' is most helpful as is the /var/db/dmesg.boot file (which contains your hardware configuration information). -------------------------------------------------------------------------- US Customer Support Voice: +1 800 ITS BSD8 (487 2738) Berkeley Software Design, Inc. Voice: +1 719 260 8114 7759 Delmonico Drive Voice: +1 512 219 5879 Colorado Springs, CO 80919 FAX: +1 719 598 4238 EMAIL: