From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 9 10:47:11 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CA0A30F for ; Wed, 9 Jul 2014 10:47:11 +0000 (UTC) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) (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 B5F172CD5 for ; Wed, 9 Jul 2014 10:47:10 +0000 (UTC) Received: from mail-qg0-f54.google.com ([209.85.192.54]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKU70dqMSoE1WwCpE4kcmq+fsIt8vMUjiv@postini.com; Wed, 09 Jul 2014 03:47:10 PDT Received: by mail-qg0-f54.google.com with SMTP id q107so6139300qgd.27 for ; Wed, 09 Jul 2014 03:47:04 -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=kriuWlWptEk3L9LZUu3HUhfhk3Gk8r2AFp0Ca1kh4JU=; b=Pi0t/KzL/DVwDjtKtVm0ZsggjkHjL4FDzKvwPV/LgpzUraNK3HVp1C4oxTYXBhGxjM RXO3bFkHa087WCAuc6WM7NCscULdjaQnLEzbz5MQjQvXG0nlLy4mICU37hEO3+E+eUVQ Qc2cy4H00FcaZ/ZsWrTKeIRsaqhLWvIzybUXS+yuEdnZZ8fNg73FP8QfQ0lpIIGeJsMn xDTfyHKAWfw9N6cuftGVymEI92u7Gk0j+DY1L6Ge2UUDc7Vymra0W3Z2Ngjk6gLiLdjq QbC5w1oqmd0nxismRDh42Vnx26h2FxJ20iaXED4Q1AZzLUYFvWxsVwCbN5mcfmqR8+mt 5fhw== X-Received: by 10.224.129.68 with SMTP id n4mr68321552qas.66.1404902383127; Wed, 09 Jul 2014 03:39:43 -0700 (PDT) X-Gm-Message-State: ALoCoQnf0FVb7JH5zFecooXeSj5/7HBSs80LIKv6ukfPYDjptHzGsUkGzWj0KpG2lUKUdbNxQXOZfTVaU2vqUDHbU8sItqHVjo5Dboi3tNvRrcO8Wmppfyf8kqY7dEZxND6qEEfcSx95qPOf1jNHTaAnO7BzXd2Z8A== X-Received: by 10.224.129.68 with SMTP id n4mr68321532qas.66.1404902382955; Wed, 09 Jul 2014 03:39:42 -0700 (PDT) From: Sumit Saxena References: <559aba5a124ee1e32ddffb1380399e28@mail.gmail.com> <20140624130840.GK1560@funkthat.com> In-Reply-To: <20140624130840.GK1560@funkthat.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrqZ/meEJEiDrDuvx3ccVdJK+lWgGJHJxVm1MmakA= Date: Wed, 9 Jul 2014 16:09:41 +0530 Message-ID: <6f92e2e229eaea86429826ce5085e495@mail.gmail.com> Subject: RE: Kernel panic: message secondary GPT header is not in the last LBA To: John-Mark Gurney Content-Type: text/plain; charset=UTF-8 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, 09 Jul 2014 10:47:11 -0000 >-----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]. > >-- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not."