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

[John-Mark Gurney]

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?

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

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