Date: Wed, 4 Apr 2001 19:31:13 -0400 From: Barney Wolff <barney@tp.databus.com> To: "T. William Wells" <bill@twwells.com> Cc: Barney Wolff <barney@tp.databus.com>, stable@freebsd.org Subject: Re: possible problem with dc driver Message-ID: <20010404193113.A43291@tp.databus.com> In-Reply-To: <E14kw6F-000Ghc-00@twwells.com>; from bill@twwells.com on Wed, Apr 04, 2001 at 06:50:03PM -0400 References: <20010404140222.A42396@tp.databus.com> <E14kw6F-000Ghc-00@twwells.com>
next in thread | previous in thread | raw e-mail | index | archive | help
If the machine actually locks up, rather than the transfer just running slowly while other things on the machine run normally, then it's either h/w or s/w on the machine itself. The full list of possibilities includes cables, the hub, the cards, the motherboards, the disk controllers, the disks. And of course, it might actually be a driver bug. To elminate the disks, either run ttcp (from ports) or make sure the file is cached and ftp it to /dev/null. You might also try moving the card to a different slot, where it doesn't share an irq with something else (if dmesg.boot shows that it does that). If you need to start swapping components, start with the cheapest and keep going until the problem is gone. Try to enjoy this :) Barney On Wed, Apr 04, 2001 at 06:50:03PM -0400, T. William Wells wrote: > > I really didn't think it was anyway -- I can lock up the problem > machine with bulk data transfers. So I really do think it's a > driver problem. > > I suppose I ought to build a debugging kernel and see what I can > break.... Do you think it might be worthwhile swapping the cards > to see if the problem moves with the card or stays with the > machine? This would be a bit of a pain for me to do, though. 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?20010404193113.A43291>