Date: Wed, 23 Jul 2014 12:35:46 +0530 From: Sumit Saxena <sumit.saxena@avagotech.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-scsi@freebsd.org, Kashyap Desai <kashyap.desai@avagotech.com> Subject: RE: Kernel panic: message secondary GPT header is not in the last LBA Message-ID: <c3f72a4da049262aa68d61cf6ddab59b@mail.gmail.com> In-Reply-To: <0c7840168feaf80c91d4e9067d916998@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <mrsas> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c3f72a4da049262aa68d61cf6ddab59b>