From owner-freebsd-smp Wed Mar 29 9: 6:34 2000 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 677DF37B6B9 for ; Wed, 29 Mar 2000 09:06:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA63514; Wed, 29 Mar 2000 09:06:30 -0800 (PST) (envelope-from dillon) Date: Wed, 29 Mar 2000 09:06:30 -0800 (PST) From: Matthew Dillon Message-Id: <200003291706.JAA63514@apollo.backplane.com> To: Arun Sharma Cc: freebsd-smp@freebsd.org Subject: Re: SMP and vn References: <20000327183911.18682.qmail@web124.yahoomail.com> <20000329132919.A10781@relativity.student.utwente.nl> <200003291604.IAA63016@apollo.backplane.com> <200003291654.IAA22036@sharmas.dhs.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> F2) before you leave for the day. If it crunches while you are :> accessing it remotely, when you come in the next day you should see a :> DDB prompt and a panic message and be able to 'trace', 'ps', and then :> 'panic' the system. : :I've had freezes when not running X and it didn't drop into DDB on the :console. Will adding more asserts in suspected places help ? : : -Arun Depends how good your suspicions are. I think there are two possibilities: First, since the disk light is left on there is a good chance that the problem is in the UDMA66 code, try compiling the kernel up with that disabled (i.e. if you have the ATA_ENABLE_ATAPI_DMA kernel config option set, comment it out and recompile). Second, when your machine locks up and you aren't in X, try CTL-ALT-ESC to break into DDB and, if that works, type 'trace' and 'ps' and we may be able to determine where it locked up. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message