From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 23 07:05:56 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5379745 for ; Wed, 23 Jul 2014 07:05:56 +0000 (UTC) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2671D2884 for ; Wed, 23 Jul 2014 07:05:55 +0000 (UTC) Received: from mail-qa0-f43.google.com ([209.85.216.43]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKU89ezZjKz+VcLD7gG5R60BUBUHPJDr3c@postini.com; Wed, 23 Jul 2014 00:05:56 PDT Received: by mail-qa0-f43.google.com with SMTP id w8so840706qac.16 for ; Wed, 23 Jul 2014 00:05:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=mQpY1uPLhXKvyIqAr12RRiuB8XODcrgq4cn0vF7nAt0=; b=gb+noPUNUCNJVTgrqdKFPeyCKGJ8BtyGtKNDb0YTWyIq9TbgcuiV1OHgYo4ej/7vBI SU6VZW+PQD7tBdugi34FqpGocCvdXiyAI9K8WU6qHbTxXEkehPwYce5HM9zFEoE7SK07 rRzAwivg18e+C/bLaaZe6ejTuGtnv+dZUJh0l5DWL6++sZykrxw0jjEmRWVPnEEcNfau NI2vLWEmBOpRB1+E0yx+ollsZEsTqAUQ+NMWFK4BVYlCGXlh51DiRmDTeX8gM1Qr+dbN m+ckGPDDk693M4dj7J6glGnBrNZMK94taFnGB0tsFopJfimSRGlWuzIRNEPgD6s+TLaL 9DvQ== X-Gm-Message-State: ALoCoQn+I7Dr3b+uJXzpbXREDwAehc59MF6uwlxPgyvitbTr78C+4EknsQxXX1neh7YvfEaCKSafRZSg9s26sb8Ai2kwpGZLq6OYJVF8apbau7TSNRYWPSqVHPVR4UnAO2D95ESX3G5I+vAipH5NvE8sTxDIA+jv4g== X-Received: by 10.224.119.198 with SMTP id a6mr67236273qar.39.1406099148671; Wed, 23 Jul 2014 00:05:48 -0700 (PDT) X-Received: by 10.224.119.198 with SMTP id a6mr67236250qar.39.1406099148506; Wed, 23 Jul 2014 00:05:48 -0700 (PDT) From: Sumit Saxena References: <559aba5a124ee1e32ddffb1380399e28@mail.gmail.com> <20140624130840.GK1560@funkthat.com> <6f92e2e229eaea86429826ce5085e495@mail.gmail.com> <20140710092108.GU45513@funkthat.com> c0e8d27445599f47adb6df0eb5465882@mail.gmail.com <0c7840168feaf80c91d4e9067d916998@mail.gmail.com> In-Reply-To: <0c7840168feaf80c91d4e9067d916998@mail.gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrqZ/meEJEiDrDuvx3ccVdJK+lWgGJHJxVAm5QnooB5ICeqgK1uMXUmzCn14A= Date: Wed, 23 Jul 2014 12:35:46 +0530 Message-ID: Subject: RE: Kernel panic: message secondary GPT header is not in the last LBA To: John-Mark Gurney Content-Type: multipart/mixed; boundary=001a11c2e6e0447a7004fed6f857 Cc: freebsd-scsi@freebsd.org, Kashyap Desai X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 07:05:56 -0000 --001a11c2e6e0447a7004fed6f857 Content-Type: text/plain; charset=UTF-8 >-----Original Message----- >From: Sumit Saxena [mailto:sumit.saxena@avagotech.com] >Sent: Wednesday, July 16, 2014 6:03 PM >To: John-Mark Gurney >Cc: Kashyap Desai >Subject: RE: Kernel panic: message secondary GPT header is not in the last >LBA > >>-----Original Message----- >>From: Sumit Saxena [mailto:sumit.saxena@avagotech.com] >>Sent: Monday, July 14, 2014 5:28 PM >>To: 'John-Mark Gurney' >>Subject: RE: Kernel panic: message secondary GPT header is not in the >last LBA >> >> >> >> >> >>>-----Original Message----- >>>From: John-Mark Gurney [mailto:jmg@funkthat.com] >>>Sent: Thursday, July 10, 2014 2:51 PM >>>To: Sumit Saxena >>>Cc: freebsd-scsi@freebsd.org; Kashyap Desai >>>Subject: Re: Kernel panic: message secondary GPT header is not in the >>>last LBA >>> >>>Sumit Saxena wrote this message on Wed, Jul 09, 2014 at 16:09 +0530: >>>> >-----Original Message----- >>>> >From: John-Mark Gurney [mailto:jmg@funkthat.com] >>>> >Sent: Tuesday, June 24, 2014 6:39 PM >>>> >To: Sumit Saxena >>>> >Cc: freebsd-scsi@freebsd.org; Kashyap Desai >>>> >Subject: Re: Kernel panic: message secondary GPT header is not in >>>> >the >>>> last >>>> >LBA >>>> > >>>> >Sumit Saxena wrote this message on Tue, Jun 24, 2014 at 18:27 +0530: >>>> >> Hi All, >>>> >> >>>> >> >>>> >> >>>> >> While doing some testing on driver, I am facing kernel >>>> >> panic inside GEOM module. I am using FreeBSD10.0 64bit, installed >>>> >> on Virtual drive connected behind LSI MegaRAID SAS 9361 >>>> >> controller and two >>>> >> Enclosures- Dell MD1220 with total 39 drives are connected to the >>>> >> controller. As I convert unconfigured drives(connected to >>>> >> Enclosures) to JBOD(plain drive without any RAID configuration >>>> >> exposed to OS), kernel panic is observed inside GEOM module with >>>> >> below traces- >>>> >> >>>> >> >>>> >> >>>> >> =================================================== >>>> >> >>>> >> ses1: phy 0: protocols: Initiator( None ) Target( SSP ) >>>> >> >>>> >> ses1: phy 0: parent 50080e5223c0f03f addr 5000c5001afebe51 >>>> >> >>>> >> ses1: pass30,da26: Element descriptor: 'SLOT 20 ' >>>> >> >>>> >> ses1: pass30,da26: SAS Device Slot Element: 1 Phys at Slot 20, >>>> >> Not All Phys >>>> >> >>>> >> ses1: phy 0: SAS device type 1 id 0 >>>> >> >>>> >> ses1: phy 0: protocols: Initiator( None ) Target( SSP ) >>>> >> >>>> >> ses1: phy 0: parent 50080e5223c0f03f addr 5000c5004cf152f1 >>>> >> >>>> >> ses1: pass37,da33: Element descriptor: 'SLOT 21 ' >>>> >> >>>> >> ses1: pass37,da33: SAS Device Slot Element: 1 Phys at Slot 21, >>>> >> Not All Phys >>>> >> >>>> >> ses1: phy 0: SAS device type 1 id 0 >>>> >> >>>> >> ses1: phy 0: protocols: Initiator( None ) Target( SSP ) >>>> >> >>>> >> ses1: phy 0: parent 50080e5223c0f03f addr 5000c5001afd3659 >>>> >> >>>> >> ses1: pass21,da17: Element descriptor: 'SLOT 22 ' >>>> >> >>>> >> ses1: pass21,da17: SAS Device Slot Element: 1 Phys at Slot 22, >>>> >> Not All Phys >>>> >> >>>> >> ses1: phy 0: SAS device type 1 id 0 >>>> >> >>>> >> ses1: phy 0: protocols: Initiator( None ) Target( SSP ) >>>> >> >>>> >> ses1: phy 0: parent 50080e5223c0f03f addr 5000cca00baf22c1 >>>> >> >>>> >> GEOM: da12: the secondary GPT header is not in the last LBA. >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> Fatal trap 18: integer divide fault while in kernel mode >>>> >> >>>> >> cpuid = 4; apic id = 10 >>>> >> >>>> >> instruction pointer = 0x20:0xffffffff80805045 >>>> >> >>>> >> stack pointer = 0x28:0xfffffe0c23ded9e0 >>>> >> >>>> >> frame pointer = 0x28:0xfffffe0c23deda30 >>>> >> >>>> >> code segment = base 0x0, limit 0xfffff, type 0x1b >>>> >> >>>> >> = DPL 0, pres 1, >>>> >> long 1, >>>> >> def32 0, gran 1 >>>> >> >>>> >> processor eflags = interrupt enabled, resume, IOPL = >0 >>>> >> >>>> >> current process = 13 (g_event) >>>> >> >>>> >> trap number = 18 >>>> >> >>>> >> panic: integer divide fault >>>> >> >>>> >> cpuid = 4 >>>> >> >>>> >> KDB: stack backtrace: >>>> >> >>>> >> #0 0xffffffff808cb220 at kdb_backtrace+0x60 >>>> >> >>>> >> #1 0xffffffff80892d05 at panic+0x155 >>>> >> >>>> >> #2 0xffffffff80c71ae2 at trap_fatal+0x3a2 >>>> >> >>>> >> #3 0xffffffff80c7171f at trap+0x7bf >>>> >> >>>> >> #4 0xffffffff80c587e2 at calltrap+0x8 >>>> >> >>>> >> #5 0xffffffff80803574 at g_label_taste+0x3a4 >>>> >> >>>> >> #6 0xffffffff80802106 at g_new_provider_event+0xb6 >>>> >> >>>> >> #7 0xffffffff807fe1d6 at g_run_events+0x166 >>>> >> >>>> >> #8 0xffffffff80864dda at fork_exit+0x9a >>>> >> >>>> >> #9 0xffffffff80c58d1e at fork_trampoline+0xe >>>> >> >>>> >> Uptime: 4m48s >>>> >> >>>> >> kernel trap 12 with interrupts disabled >>>> > >>>> >Can you run w/ DDB enabled and get a dump? >>>> > >>>> >an integer divide makes me think of a divide by zero error... Are >>>> >you >>>> sure >>>> >things like sector size are set properly? >>>> >>>> Sorry for delay in response, sector size and other disk parameters >>>> are set properly(verified by "diskinfo"), same set of drives works >well on >>linux. >>>> We are not able to collect dump, enabled DDB but dump Is not getting >>>> collected. Partial dump is getting copied sometimes[seen message on >>>> console while dumping]. >>> >>>Can you run: >>>addr2line -e /boot/kernel/kernel.symbols 0xffffffff80803574 >>> >>>This should give us the line number that the panic is happening on, >>>and help debug it.. >>> >>>Also, is this FreeBSD 10.0-R? or is there a patch level associated w/ >>>it? Easiest way to figure out is to include uname -a in the email so >>>we know exactly what kernel source you are using.. > >I am using releases FreeBSD 10.0, no patch on top of that. >> >>Thanks for your help. I am able to capture vmcore on kenel panic, but >can't >>share that over overmail(size is 386MB) and does not have any common >>location to share vmcore with you. >>Do you have any common location, where I can share vmcore. Meanwhile I >>will also do some debugging from my end also. Any pointers from you for >>debugging the vmcore will be highly appreciated, as I am keen to learn >>FreebSD kernel debugging techniques. >> I have attached core.txt for your reference. > >I have observed that the issue hits, if there are some drives with GPT >partition >are attached to the controller. Has anyone observed the same issue, when there are drives present in the setup with GPT partitions? > >> >>> >>>Thanks. >>> >>>-- >>> John-Mark Gurney Voice: +1 415 225 5579 >>> >>> "All that I will do, has been done, All that I have, has not." --001a11c2e6e0447a7004fed6f857 Content-Type: application/octet-stream; name="core.txt.0" Content-Disposition: attachment; filename="core.txt.0" Content-Transfer-Encoding: base64 X-Attachment-Id: 815f8a69d19fdaaa_0.1 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --001a11c2e6e0447a7004fed6f857--