From owner-freebsd-fs@FreeBSD.ORG Fri Sep 10 19:08:36 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 277C01065679 for ; Fri, 10 Sep 2010 19:08:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE9F8FC13 for ; Fri, 10 Sep 2010 19:08:35 +0000 (UTC) Received: by bwz20 with SMTP id 20so2986916bwz.13 for ; Fri, 10 Sep 2010 12:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=qn5wC2snOEB+MkCmlgwzuNs8PlcBCJ3b9I73SO9abmc=; b=AjsfT/XGVyEsr+ipCPo6c8xCtzOU5QC71Pis9W5yt0pCgjJJiJpQScAeTNaAyfqcX7 jOV+fCOkJK9lTkPLvoBsfQr9qzMAABX4DcX3LzMVd60TLuGnJbfvqwPQ1+Rk1oSRodtN PIg9bCdiYFVf1UVtJWCHHh4UwcVoHPE5NPPWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=e3Kl3NQRxLuRA4AfkWLioLgne0JaYKlsoU5SdaeNQzgEdlS8whyL2Sk2dMhnJvQa6G FwXONxyM4xMJ4QuHc/fhyYncY/fG/yV+rWSRuTrYxfJQrtxDtyZMM1HZq7cuNJ8QRNUA cKEA1Fr6WCyaY71B8VuhSoK6DC1gJw+F52fRE= Received: by 10.204.126.92 with SMTP id b28mr833046bks.47.1284143923453; Fri, 10 Sep 2010 11:38:43 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id x19sm2213114bkv.9.2010.09.10.11.38.39 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Sep 2010 11:38:40 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8A7B20.7090408@FreeBSD.org> Date: Fri, 10 Sep 2010 21:38:24 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: a.smith@ukgrid.net References: <20100909140000.5744370gkyqv4eo0@webmail2.ukgrid.net> <20100909182318.11133lqu4q4u1mw4@webmail2.ukgrid.net> <4C89D6A8.1080107@icyb.net.ua> <20100910143900.20382xl5bl6oo9as@webmail2.ukgrid.net> <20100910141127.GA13056@icarus.home.lan> <20100910155510.11831w104qjpyc4g@webmail2.ukgrid.net> <20100910152544.GA14636@icarus.home.lan> <20100910173912.205969tzhjiovf8c@webmail2.ukgrid.net> <4C8A6B26.8050305@icyb.net.ua> <20100910184921.16956kbaskhrsmg4@webmail2.ukgrid.net> In-Reply-To: <20100910184921.16956kbaskhrsmg4@webmail2.ukgrid.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Andriy Gapon Subject: Re: ZFS related kernel panic X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 19:08:36 -0000 Hi. a.smith@ukgrid.net wrote: > Quoting Andriy Gapon : >> That's useful information I think. >> For completeness you might also run kgdb and then do: >> (kgdb) info line *siis_end_transaction+0x45 >> and so on for all stack trace lines involving siis. > > Ok, I got this running against the data in /var/crash, is that ok? > > (kgdb) info line *siis_end_transaction+0x45 > Line 1188 of "/usr/src/sys/modules/siis/../../dev/siis/siis.c" > starts at address 0xffffffff80ea5a05 > and ends at 0xffffffff80ea5a13 . > (kgdb) info line *siis_ch_intr_locked+0x3e > Line 809 of "/usr/src/sys/modules/siis/../../dev/siis/siis.c" > starts at address 0xffffffff80ea780e > and ends at 0xffffffff80ea7811 . > (kgdb) info line *siis_intr+0x61 > Line 298 of "/usr/src/sys/modules/siis/../../dev/siis/siis.c" > starts at address 0xffffffff80ea7a61 > and ends at 0xffffffff80ea7a72 . It looks like during timeout handling (it is quite complicated process when port multiplier is used) some request was completed twice. So original problem is probably in hardware (try to check/replace cables, multiplier, ...), that caused timeout, but the fact that drive was unable to handle it is probably a siis(4) driver bug. At this moment I have no idea where to look, except dumb rereading whole error handling logic. It could help much if I could reproduce the problem in realistic time in controlled environment with access to serial (or some other) console and possibility to insert additional debugging. -- Alexander Motin