Kernel panic: message secondary GPT header is not in the last LBA

[Sumit Saxena]

>-----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].
>
>--
>  John-Mark Gurney				Voice: +1 415 225 5579
>
>     "All that I will do, has been done, All that I have, has not."