Re: Panic on boot current amd64

On 01/17/17 02:10, O. Hartmann wrote:
> Am Mon, 16 Jan 2017 10:33:35 -0800
> Manfred Antar <null_at_pozo.com> schrieb:
> 
>> From current today after changes to /sys/sys/gtaskqueue.h (r312293) I get panic on boot.
>> reverting to r312235 boot ok
>>
>> random: harvesting attach, 8 bytes (4 bits) from uhub9
>> ugen1.3: <Logitech USB Optical Mouse> at usbus1
>> kernel trap 12 with interrupts disabled
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 2; apic id = 02
>> fault virtual address	= 0x64
>> fault code		= supervisor read data, page not present
>> instruction pointer	= 0x20:0xffffffff80660449
>> stack pointer	        = 0x28:0xfffffe0466aa9010
>> frame pointer	        = 0x28:0xfffffe0466aa9030
>> code segment		= base 0x0, limit 0xfffff, type 0x1b
>> 			= DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags	= resume, IOPL = 0
>> current process		= 60445 (ifconfig)
>> [ thread pid 60445 tid 100131 ]
>> Stopped at      grouptaskqueue_enqueue+0x19:    cmpl    $0,0x64(%rbx)
>> db> bt  
>> Tracing pid 60445 tid 100131 td 0xfffff800088df500
>> grouptaskqueue_enqueue() at grouptaskqueue_enqueue+0x19/frame 0xfffffe0466aa9030
>> em_intr() at em_intr+0x8c/frame 0xfffffe0466aa9060
>> iflib_fast_intr() at iflib_fast_intr+0x2c/frame 0xfffffe0466aa9080
>> intr_event_handle() at intr_event_handle+0x9b/frame 0xfffffe0466aa90d0
>> intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe0466aa9100
>> lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfffffe0466aa9120
>> Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfffffe0466aa9120
>> --- interrupt, rip = 0xffffffff809639ad, rsp = 0xfffffe0466aa91f0, rbp =
>> 0xfffffe0466aa9200 --- spinlock_exit() at spinlock_exit+0x2d/frame 0xfffffe0466aa9200
>> smp_rendezvous_cpus() at smp_rendezvous_cpus+0x272/frame 0xfffffe0466aa9270
>> smp_rendezvous() at smp_rendezvous+0x40/frame 0xfffffe0466aa92a0
>> counter_u64_alloc() at counter_u64_alloc+0x3e/frame 0xfffffe0466aa92c0
>> rtentry_zinit() at rtentry_zinit+0x11/frame 0xfffffe0466aa92e0
>> keg_alloc_slab() at keg_alloc_slab+0x1e3/frame 0xfffffe0466aa9350
>> keg_fetch_slab() at keg_fetch_slab+0x16e/frame 0xfffffe0466aa93a0
>> zone_fetch_slab() at zone_fetch_slab+0x9e/frame 0xfffffe0466aa93e0
>> zone_import() at zone_import+0x52/frame 0xfffffe0466aa9430
>> uma_zalloc_arg() at uma_zalloc_arg+0x450/frame 0xfffffe0466aa94a0
>> rtrequest1_fib() at rtrequest1_fib+0xfc/frame 0xfffffe0466aa95c0
>> rtinit() at rtinit+0x390/frame 0xfffffe0466aa9740
>> in_addprefix() at in_addprefix+0xef/frame 0xfffffe0466aa97b0
>> in_control() at in_control+0x9dc/frame 0xfffffe0466aa9850
>> ifioctl() at ifioctl+0xdcc/frame 0xfffffe0466aa98d0
>> kern_ioctl() at kern_ioctl+0x274/frame 0xfffffe0466aa9950
>> sys_ioctl() at sys_ioctl+0x13c/frame 0xfffffe0466aa9a20
>> amd64_syscall() at amd64_syscall+0x488/frame 0xfffffe0466aa9bb0
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0466aa9bb0
>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x4b194a, rsp = 0x7fffffffe478, rbp =
>> 0x7fffffffe4d0 ---
>> db>   
>>
>>
>>
>>
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 
> 
> Has this been fixed? I bugs mee, too.
> I went back to r312235, too, which doesn't coredump.
> 
> Regards,
> 
> oh
> 

For the time being, I'm suggesting people add EARLY_AP_START to their
kernel configs as is in GENERIC.

We are still debugging this.

sean