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

[John-Mark Gurney]

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..

Thanks.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."