From owner-freebsd-current@FreeBSD.ORG Thu May 23 06:37:40 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEF5038D for ; Thu, 23 May 2013 06:37:40 +0000 (UTC) (envelope-from maillist@turriff.net) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 7F05C818 for ; Thu, 23 May 2013 06:37:40 +0000 (UTC) Received: from 50-78-174-194-static.hfc.comcastbusiness.net ([50.78.174.194] helo=cerberus.turriff.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UfP9f-0004Da-DY; Thu, 23 May 2013 06:37:39 +0000 Received: from freya.private.ad.turriff.net (unknown [127.0.0.1]) by cerberus.turriff.net (Postfix) with ESMTP id 3bGLcJ682MzQQ; Wed, 22 May 2013 23:37:36 -0700 (PDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.78.174.194 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18LiC3a3jtX8uh3R36oQTxLPpijLw414ew= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=turriff.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=default; t= 1369291053; bh=A/nQcWAMCCZq3TknYpRMIKD8nxsfVK4Ch7xJrwsotHQ=; b=u SABoxBWO1cPVWrUKZImU3o83NNm1uMgZPqlID97P/h715xh8CDOYYK/trzG9i3kT WALfxgUQSVizen3i+uc/0wvphaOL3deCMWfGU5y+XkYDwB8nWOpsnWATeOI49Jlw aqmLRoQrUS/eQSBDD7bmRcbkQH0Ua3c9et81y0LF1Q= X-Virus-Scanned: amavisd-new at private.ad.turriff.net Received: from cerberus.turriff.net ([127.0.0.1]) by freya.private.ad.turriff.net (freya.private.ad.turriff.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6fi7z5E1Y0lH; Wed, 22 May 2013 23:37:33 -0700 (PDT) Received: from [172.16.32.1] (hephaistos.private.ad.turriff.net [172.16.32.1]) by cerberus.turriff.net (Postfix) with ESMTP id 3bGLcF2YYNzQH; Wed, 22 May 2013 23:37:33 -0700 (PDT) Message-ID: <519DB92D.9030105@turriff.net> Date: Wed, 22 May 2013 23:37:33 -0700 From: Andreas Turriff User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: tws(4) kernel panic on boot References: <519AD765.3060601@turriff.net> <20130521123306.GD3047@kib.kiev.ua> <519B9FED.8000806@turriff.net> <519D09B2.2030003@turriff.net> <20130523062306.GR3047@kib.kiev.ua> In-Reply-To: <20130523062306.GR3047@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 06:37:40 -0000 On 5/22/2013 11:23 PM, Konstantin Belousov wrote: > On Wed, May 22, 2013 at 11:08:50AM -0700, Andreas Turriff wrote: >> On 5/21/2013 9:25 AM, Andreas Turriff wrote: >>> On 5/21/2013 5:33 AM, Konstantin Belousov wrote: >>>> On Mon, May 20, 2013 at 07:09:41PM -0700, Andreas Turriff wrote: >>>>> On migrating one of my servers to -current, I discovered that the tws >>>>> driver panics on boot; I will follow up with a full backtrace once I >>>>> have a chance to extract it. In the meantime, there is a PR about a >>>>> very >>>>> similar error in twa - 177020. Is it possible those are related, and >>>>> the >>>>> same sort of change needs to be made to tws? >>>> It is possible that the regression was in r246713, but the code is >>>> structured differently, and there were more tws(4) changes since then. >>>> You need to provide data for somebody to start looking into the problem. >>> I know. That's why I said, I'd follow up with more info once I can >>> extract it. >>> >>> The system in question is a Dell PowerEdge 840 server, 8 GiByte RAM, >>> with an Intel NIC driven by em(4) and a 3Ware 9750-4i RAID controller. >>> There is no src.conf >>> >>> /etc/make.conf: >>> CPUTYPE?=core2 >>> >>> Error message: >>> >>> LSI 3ware device driver for SAS/SATA storage controllers, version: >>> 10.80.00.005 >>> tws0: port 0xec00-0xecff mem >>> 0xfe9fc000-0xfe9fffff,0xfe980000-0xfe9bffff irq 16 at device 0.0 o1 >>> tws0: Using MSIng APIC ID to 4 >>> panic: _bus_dmamap_load_ccb: Unsupported func code 0 >>> cpuid = 0Version 2.0> irqs 0-23 on motherboard >>> KDB: enter: panic2.0> irqs 32-55 on motherboard >>> [ thread pid 0 tid 100000 ] >>> Stopped at kdb_enter+0x3e: movq $0,kdb_why >>> >>> Backtrace >>> >>> Tracing pid 0 tid 100000 td 0xffffffff81376610 >>> kdb_enter() at kdb_enter+0x3e/frame 0xffffffff8191a340 >>> panic() at panic+0x175/frame 0xffffffff8191a3c0 >>> _bus_dmamap_load_ccb() at _bus_dmamap_load_ccb+0x1c3/frame >>> 0xffffffff8191a420 >>> bus_dmamap_load_ccb() at bus_dmamap_load_ccb+0x91/frame >>> 0xffffffff8191a480 >>> tws_map_request() at tws_map_request+0x71/frame 0xffffffff8191a4c0 >>> tws_get_param() at tws_get_param+0xdd/frame 0xffffffff8191a520 >>> tws_display_ctlr_info() at tws_display_ctlr_info+0x38/frame >>> 0xffffffff8191a590 >>> tws_init_ctlr() at tws_init_ctlr+0x6b/frame 0xffffffff8191a5b0 >>> tws_attach() at tws_attach+0xd79/frame 0xffffffff8191a670 >>> device_attach() at device_attach+0x396/frame 0xffffffff8191a6c0 >>> bus_generic_attach() at bus_generic_attach+0x2d/frame 0xffffffff8191a6e0 >>> acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0xffffffff8191a730 >>> device_attach() at device_attach+0x396/frame 0xffffffff8191a780 >>> bus_generic_attach() at bus_generic_attach+0x2d/frame 0xffffffff8191a7a0 >>> acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0xffffffff8191a7f0 >>> acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x9f/frame >>> 0xffffffff8191a830 >>> device_attach() at device_attach+0x396/frame 0xffffffff8191a880 >>> bus_generic_attach() at bus_generic_attach+0x2d/frame 0xffffffff8191a8a0 >>> acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0xffffffff8191a8f0 >>> device_attach() at device_attach+0x396/frame 0xffffffff8191a940 >>> bus_generic_attach() at bus_generic_attach+0x2d/frame 0xffffffff8191a960 >>> acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0xffffffff8191a9b0 >>> acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame >>> 0xffffffff8191aa00 >>> device_attach() at device_attach+0x396/frame 0xffffffff8191aa50 >>> bus_generic_attach() at bus_generic_attach+0x2d/frame 0xffffffff8191aa70 >>> acpi_attach() at acpi_attach+0xdd6/frame 0xffffffff8191ab30 >>> device_attach() at device_attach+0x396/frame 0xffffffff8191ab80 >>> bus_generic_attach() at bus_generic_attach+0x2d/frame 0xffffffff8191aba0 >>> nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0xffffffff8191abd0 >>> device_attach() at device_attach+0x396/frame 0xffffffff8191ac20 >>> bus_generic_new_pass() at bus_generic_new_pass+0xe9/frame >>> 0xffffffff8191ac50 >>> bus_set_pass() at bus_set_pass+0x8f/frame 0xffffffff8191ac80 >>> configure() at configure+0xa/frame 0xffffffff8191ac90 >>> mi_startup() at mi_startup+0x118/frame 0xffffffff8191acb0 >>> btext() at btext+0x2c >>> >>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" >> And after taking a very close look at the source code for tws, I spotted >> the problem. Patch included. >> >> ~Andreas >> >> Index: sys/dev/tws/tws.h >> =================================================================== >> --- sys/dev/tws/tws.h (revision 250856) >> +++ sys/dev/tws/tws.h (working copy) >> @@ -137,7 +137,7 @@ >> TWS_DIR_IN = 0x2, >> TWS_DIR_OUT = 0x4, >> TWS_DIR_NONE = 0x8, >> - TWS_DATA_CCB = 0x16, >> + TWS_DATA_CCB = 0x10, >> }; >> >> enum tws_intrs { >> > Do you mean that this change alone fixes your panic and the controller > works after the boot ? > > I started looking at the code, and thought that there some issues > with DATA_CCB flag set too eagerly. I've been running that kernel all day, rebuilding userland (ports) on a 4-drive ZFS RAID-Z on that controller, and not seen a single crash, slowdown, hiccup or untoward log message. ~Andreas