Kernel panic: message secondary GPT header is not in the last LBA
Sumit Saxena
sumit.saxena at avagotech.com
Wed Jul 23 07:05:56 UTC 2014
>-----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?
>
>>
>>>
>>>Thanks.
>>>
>>>--
>>> John-Mark Gurney Voice: +1 415 225 5579
>>>
>>> "All that I will do, has been done, All that I have, has not."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: core.txt.0
Type: application/octet-stream
Size: 38 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20140723/340adbce/attachment.obj>
More information about the freebsd-scsi
mailing list