Date: Wed, 29 Jan 1997 19:21:42 -0800 (PST) From: Dara Ghahremani <dara@salk.edu> To: Terry Lambert <terry@lambert.org> Cc: current@freebsd.org Subject: Re: installing network cards Message-ID: <Pine.SUN.3.95.970129191739.21571T-100000@helmholtz> In-Reply-To: <199701300136.SAA20688@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The problem on this machine seems to be with connecting to the NFS server: marr /kernel: nfs not responding # marr is the machine name But this problem doesn't occur when I switch this 3COM 3c595 net card w/ the older 509 card. Any ideas? Dara On Wed, 29 Jan 1997, Terry Lambert wrote: > > 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?Pine.SUN.3.95.970129191739.21571T-100000>