Date: Wed, 29 Jan 1997 18:36:30 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dara@salk.edu Cc: terry@lambert.org, current@freebsd.org Subject: Re: installing network cards Message-ID: <199701300136.SAA20688@phaeton.artisoft.com> In-Reply-To: <Pine.SUN.3.95.970129143941.21571F-100000@helmholtz> from "Dara Ghahremani" at Jan 29, 97 02:55:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The machine is a Dell XPS P133c running AMIBIOS A02 with 64 MB RAM. > It's running IDE w/ one disk. The dmesg scrolls too quickly off the screen > for me to tell if it uses CMD640b IDE (neither "more" or any editor is > installed on the local disk). I don't see any reference to the L1 or L2 > cache in the BIOS setup. Hit "scroll lock" on the console. Use "pgup/pgdn" to read the dmesg. You may try booting with the original (non-working ethernet) kernel, as well. > The machine gets to the point where it's pingable from another host and > telneting works until after the password is entered. Then, the system > doesn't respond to control-Cs as I described in a previous message. So it is locking up when execing the shell. This is either a problem with the shell (it makes a DNS call that never returns to look up the host name so it can display it in your prompt, like tcsh), OR a problem with the in-memory image of the shell (the cache contains bogus data for one or more L1 or L2 cache lines because the DMA page invalidate did not occur or the cache is just bad) OR a read from the physical media on behalf of the process, by the kernel, to fault in a page of the shell executable (driver and/or disk bug, potentially the RZ1000 IDE bug [I think that one's worked around] or the CMD 640b bug [that one isn't] or the HiNT chipset bug [that one isn't] or the Saturn I family PCI chipset bug [that one isn't] or a VLB controller in a slave slot [that one isn't], etc.). Either way, turning off your cache would help us tell you which one is the problem, or if none of them are. > By the way, the machine works fine when I change to the previous 3COM 509 > card so I believe there is something about this 3COM 595c card that is > bringing about these problems. Perhaps the author of the vx0 driver for > this card would know what's going on? Possibly; or perhaps you are running an old driver, or the wrong version of the driver for your kernel. It may be that it doesn't work with PCI interrupt sharing because of a driver bug, and reordering the cards will make it not have to share. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701300136.SAA20688>