From owner-freebsd-scsi Thu Jun 4 10:39:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21075 for freebsd-scsi-outgoing; Thu, 4 Jun 1998 10:39:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21069; Thu, 4 Jun 1998 10:39:44 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id LAA06499; Thu, 4 Jun 1998 11:39:21 -0600 (MDT) Message-Id: <199806041739.LAA06499@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Mark Murray cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Error: "Timedout SCB handled by another timeout" In-reply-to: Your message of "Wed, 03 Jun 1998 08:38:53 +0200." <199806030638.IAA00337@greenpeace.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jun 1998 11:34:51 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hi > >I am still getting the error "Timedout SCB handled by another timeout", >which only happens in SMP mode. I ran for 8 days in UP mode, and the >machine was rock-steady. Can you change that printf into a panic and poke around the timeout code when it occurs. You'll probably want to have remote GDB setup for this. I really think that the problem has little to do with CAM, but is some kind of race in the processing of clock interrupts that causes the timeout queues to become corrupted. Just going up the stack should bring you into the generic timeout facility code and hopefully something will be obviously corrupted. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message