Date: Fri, 1 Aug 2014 10:45:45 +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: <cb8d20db6a1daae961c630d6b4429118@mail.gmail.com> In-Reply-To: c3f72a4da049262aa68d61cf6ddab59b@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> c3f72a4da049262aa68d61cf6ddab59b@mail.gmail.com
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: Sumit Saxena [mailto:sumit.saxena@avagotech.com] >Sent: Wednesday, July 23, 2014 12:36 PM >To: 'John-Mark Gurney' >Cc: Kashyap Desai; 'freebsd-scsi@freebsd.org' >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: 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? Gentle ping!! > >> >>> >>>> >>>>Thanks. >>>> >>>>-- >>>> John-Mark Gurney Voice: +1 415 225 5579 >>>> >>>> "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cb8d20db6a1daae961c630d6b4429118>