Kernel panic: message secondary GPT header is not in the last LBA
Sumit Saxena
sumit.saxena at avagotech.com
Fri Aug 1 05:15:49 UTC 2014
>-----Original Message-----
>From: Sumit Saxena [mailto:sumit.saxena at avagotech.com]
>Sent: Wednesday, July 23, 2014 12:36 PM
>To: 'John-Mark Gurney'
>Cc: Kashyap Desai; 'freebsd-scsi at freebsd.org'
>Subject: RE: Kernel panic: message secondary GPT header is not in the last
>LBA
>
>
>
>>-----Original Message-----
>>From: Sumit Saxena [mailto:sumit.saxena at 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 at 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 at funkthat.com]
>>>>Sent: Thursday, July 10, 2014 2:51 PM
>>>>To: Sumit Saxena
>>>>Cc: freebsd-scsi at 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 at funkthat.com]
>>>>> >Sent: Tuesday, June 24, 2014 6:39 PM
>>>>> >To: Sumit Saxena
>>>>> >Cc: freebsd-scsi at 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."
More information about the freebsd-scsi
mailing list