From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 27 15:52:34 2009 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B28711065676; Fri, 27 Mar 2009 15:52:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 683DD8FC08; Fri, 27 Mar 2009 15:52:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LnEMC-000Cx8-Gs; Fri, 27 Mar 2009 18:52:32 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Scott Long In-reply-to: <49CCDA41.4060101@samsco.org> References: <49CCDA41.4060101@samsco.org> Comments: In-reply-to Scott Long message dated "Fri, 27 Mar 2009 07:53:05 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Mar 2009 18:52:32 +0300 From: Danny Braniss Message-ID: Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: amr driver broken since March 12 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 15:52:35 -0000 > Danny Braniss wrote: > > at least for me :-) > > [and sorry for the cross posting] > > > > old (March 12 , i know need the svn rev number but...) > > None of the commit activity on March 12 is jumping out at me as being > suspicious. However, you are now the second person who has told me > about AMR problems in 7.1 recently. If you have a precise svn change > number, it would help greatly. > > Scott my bad. the last working amr/iir is from March 12. I first detected the problem sometime later, but not later than March 23. So it has to be changes in that time frame. both drivers are showing similar symptoms: waiting for not busy the iir goes on for ever, and it's the cam that eventually panics, run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config (actually not 100% true, depending if WITNESS is on or off, it sometimes just hangs). the amr seems to time out: amr0: adapter is busy thanks for looking into the problem, danny