Analyzing kernel panic from VIMAGE/Netgraph takedown

[Peter]

Stopping a VIMAGE+Netgraph jail in 12.2 in the same way as it
did work with Rel. 11.4, crashes the kernel after 2 or 3 start/stop
iterations.

Specifically. this does not work:

  exec.poststop = "/usr/sbin/ngctl shutdown ${ifname1l}:";

Also this new option from Rel.12 does not work either, it just
gives a few more iterations:

  exec.release = "/usr/sbin/ngctl shutdown ${ifname1l}:";

What seems to work is adding a delay:

  exec.poststop = "
  sleep 2 ;
  /usr/sbin/ngctl shutdown ${ifname1l}: ;
  ";

The big question now is: how long should the delay be?

This example did run a test with 100 start/stop iterations. But then,
on a loaded machine stopping a jail that had been running for a few
months, is an entirely different matter: in such a case the jail will
spend hours in "dying" state, while in this test the jid became
instantly free for restart.

In any case, as all this did work flawlessly with Rel. 11.4, there
is now something broken in the code, and should be fixed.

PMc
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic in zfs code; 12-STABLE

[Karl Denninger]

On 7/18/2019 15:35, Karl Denninger wrote:
> On 7/18/2019 15:19, Eugene Grosbein wrote:
>> 19.07.2019 3:13, Karl Denninger wrote:
>>
>>> FreeBSD 12.0-STABLE #2 r349024M: Thu Jun 13 18:01:16 CDT 2019
>>> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP
>>>
>>> Note -- no patches of any sort in the ZFS code; I am NOT running any of
>>> my former patch set.
>>>
>>> NewFS.denninger.net dumped core - see /var/crash/vmcore.8
>>>
>>> Thu Jul 18 15:02:54 CDT 2019
>>>
>>> FreeBSD NewFS.denninger.net 12.0-STABLE FreeBSD 12.0-STABLE #2 r349024M:
>>> Thu Jun 13 18:01:16 CDT 2019
>>> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP  amd64
>>>
>>> panic: double fault
>> [skip]
>>
>>> #283 0x82748d91 in zio_vdev_io_done (zio=0xf8000b8b8000)
>>> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3376
>>> #284 0x82744eac in zio_execute (zio=0xf8000b8b8000)
>>> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1786
>>> #285 0x80c3b7f4 in taskqueue_run_locked (queue=0xf801a8b35100)
>>> at /usr/src/sys/kern/subr_taskqueue.c:467
>>> #286 0x80c3cb28 in taskqueue_thread_loop (arg=)
>>> at /usr/src/sys/kern/subr_taskqueue.c:773
>>> #287 0x80b9ab23 in fork_exit (
>>> callout=0x80c3ca90 ,
>>> arg=0xf801a0577520, frame=0xfe009d4edc00)
>>> at /usr/src/sys/kern/kern_fork.c:1063
>>> #288 0x810b367e in fork_trampoline ()
>>> at /usr/src/sys/amd64/amd64/exception.S:996
>>> #289 0x in ?? ()
>>> Current language:  auto; currently minimal
>>> (kgdb)
>> You have "double fault" and completely insane number of stack frames in the 
>> trace.
>> This is obviously infinite recursion resulting in kernel stack overflow and 
>> panic.
> Yes, but why and how?
>
> What's executing at the time is this command:
>
> zfs send -RI $i@zfs-old $i@zfs-base | zfs receive -Fudv $BACKUP
>
> Which in turn results in the old snapshots on the target not on the
> source being deleted, then the new ones being sent.  It never gets to
> the sending part; it blows up during the delete of the OLD snapshots.
>
> The one(s) it deletes, however, it DOES delete.  When the box is
> rebooted those two snapshots on the target are indeed gone.
>
> That is, it is NOT getting "stuck" on one (which would imply there's an
> un-detected fault in the filesystem on the target in the metadata for
> that snapshot, resulting in a recursive call that blows up the stack)
> and it never gets to send the new snapshot, so whatever is going on is
> NOT on the source filesystem.  Neither source or destination shows any
> errors on the filesystem; both pools are healthy with zero error counts.
>
> Therefore the question -- is the system queueing enough work to blow the
> stack *BUT* the work it queues is all legitimate?  If so there's a
> serious problem in the way the code now functions in that an "ordinary"
> operation can result in what amounts to kernel stack exhaustion.
>
> One note -- I haven't run this backup for the last five days, as I do it
> manually and I've been out of town.  Previous running it on a daily
> basis completed without trouble.  This smells like a backlog of "things
> to do" when the send runs that results in the allegedly-infinite
> recursion (that isn't really infinite) that runs the stack out of space
> -- and THAT implies that the system is trying to queue a crazy amount of
> work on a recursive basis for what is a perfectly-legitimate operation
> -- which it should *NOT* do.

Update: This looks like an OLD bug that came back.

Previously the system would go absolutely insane on the first few
accesses to spinning rust during a snapshot delete and ATTEMPT to send
thousands of TRIM requests -- which spinning rust does not support.  On
a system with mixed vdevs, where some pools are rust and some are SSD,
this was a problem since you can't turn TRIM off because you REALLY want
it on those disks.

The FIX for this was to do this on the import of said pool comprised of
spinning rust:

#
# Now try to trigger TRIM so that we don't have a storm of them
#
# echo "Attempting to disable TRIM on spinning rust"

mount -t zfs $BACKUP/no-trim /mnt
dd if=/dev/random of=/mnt/kill-trim bs=128k count=2
echo "Performed 2 writes"
sleep 2
rm /mnt/kill-trim
echo "Performed delete of written file; wait"
sleep 35
umount /mnt
echo "Unmounted temporary filesystem"
sleep 2
echo "TRIM disable theoretically done"

This would cause ZFS to "figure out" that TRIM doesn't work on the VDEVs
on that pool and not send them.  You were then ok.

When this went away I commented those out.

I just un-commented them -- and the backup is now running, and appears
to be ok -- it's well past where it blew up before, and no panic.

So it APPEARS that ZFS (still) doesn't figure out that TRIM doesn't work
on those disks on a pool import quickly enough and this leads to a CRAZY
number of queued requests which 

Re: Kernel panic in zfs code; 12-STABLE

[Karl Denninger]

On 7/18/2019 15:19, Eugene Grosbein wrote:
> 19.07.2019 3:13, Karl Denninger wrote:
>
>> FreeBSD 12.0-STABLE #2 r349024M: Thu Jun 13 18:01:16 CDT 2019
>> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP
>>
>> Note -- no patches of any sort in the ZFS code; I am NOT running any of
>> my former patch set.
>>
>> NewFS.denninger.net dumped core - see /var/crash/vmcore.8
>>
>> Thu Jul 18 15:02:54 CDT 2019
>>
>> FreeBSD NewFS.denninger.net 12.0-STABLE FreeBSD 12.0-STABLE #2 r349024M:
>> Thu Jun 13 18:01:16 CDT 2019
>> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP  amd64
>>
>> panic: double fault
> [skip]
>
>> #283 0x82748d91 in zio_vdev_io_done (zio=0xf8000b8b8000)
>> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3376
>> #284 0x82744eac in zio_execute (zio=0xf8000b8b8000)
>> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1786
>> #285 0x80c3b7f4 in taskqueue_run_locked (queue=0xf801a8b35100)
>> at /usr/src/sys/kern/subr_taskqueue.c:467
>> #286 0x80c3cb28 in taskqueue_thread_loop (arg=)
>> at /usr/src/sys/kern/subr_taskqueue.c:773
>> #287 0x80b9ab23 in fork_exit (
>> callout=0x80c3ca90 ,
>> arg=0xf801a0577520, frame=0xfe009d4edc00)
>> at /usr/src/sys/kern/kern_fork.c:1063
>> #288 0x810b367e in fork_trampoline ()
>> at /usr/src/sys/amd64/amd64/exception.S:996
>> #289 0x in ?? ()
>> Current language:  auto; currently minimal
>> (kgdb)
> You have "double fault" and completely insane number of stack frames in the 
> trace.
> This is obviously infinite recursion resulting in kernel stack overflow and 
> panic.

Yes, but why and how?

What's executing at the time is this command:

zfs send -RI $i@zfs-old $i@zfs-base | zfs receive -Fudv $BACKUP

Which in turn results in the old snapshots on the target not on the
source being deleted, then the new ones being sent.  It never gets to
the sending part; it blows up during the delete of the OLD snapshots.

The one(s) it deletes, however, it DOES delete.  When the box is
rebooted those two snapshots on the target are indeed gone.

That is, it is NOT getting "stuck" on one (which would imply there's an
un-detected fault in the filesystem on the target in the metadata for
that snapshot, resulting in a recursive call that blows up the stack)
and it never gets to send the new snapshot, so whatever is going on is
NOT on the source filesystem.  Neither source or destination shows any
errors on the filesystem; both pools are healthy with zero error counts.

Therefore the question -- is the system queueing enough work to blow the
stack *BUT* the work it queues is all legitimate?  If so there's a
serious problem in the way the code now functions in that an "ordinary"
operation can result in what amounts to kernel stack exhaustion.

One note -- I haven't run this backup for the last five days, as I do it
manually and I've been out of town.  Previous running it on a daily
basis completed without trouble.  This smells like a backlog of "things
to do" when the send runs that results in the allegedly-infinite
recursion (that isn't really infinite) that runs the stack out of space
-- and THAT implies that the system is trying to queue a crazy amount of
work on a recursive basis for what is a perfectly-legitimate operation
-- which it should *NOT* do.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Kernel panic in zfs code; 12-STABLE

[Eugene Grosbein]

19.07.2019 3:13, Karl Denninger wrote:

> FreeBSD 12.0-STABLE #2 r349024M: Thu Jun 13 18:01:16 CDT 2019
> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP
> 
> Note -- no patches of any sort in the ZFS code; I am NOT running any of
> my former patch set.
> 
> NewFS.denninger.net dumped core - see /var/crash/vmcore.8
> 
> Thu Jul 18 15:02:54 CDT 2019
> 
> FreeBSD NewFS.denninger.net 12.0-STABLE FreeBSD 12.0-STABLE #2 r349024M:
> Thu Jun 13 18:01:16 CDT 2019
> k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP  amd64
> 
> panic: double fault

[skip]

> #283 0x82748d91 in zio_vdev_io_done (zio=0xf8000b8b8000)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:3376
> #284 0x82744eac in zio_execute (zio=0xf8000b8b8000)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1786
> #285 0x80c3b7f4 in taskqueue_run_locked (queue=0xf801a8b35100)
> at /usr/src/sys/kern/subr_taskqueue.c:467
> #286 0x80c3cb28 in taskqueue_thread_loop (arg=)
> at /usr/src/sys/kern/subr_taskqueue.c:773
> #287 0x80b9ab23 in fork_exit (
> callout=0x80c3ca90 ,
> arg=0xf801a0577520, frame=0xfe009d4edc00)
> at /usr/src/sys/kern/kern_fork.c:1063
> #288 0x810b367e in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:996
> #289 0x in ?? ()
> Current language:  auto; currently minimal
> (kgdb)

You have "double fault" and completely insane number of stack frames in the 
trace.
This is obviously infinite recursion resulting in kernel stack overflow and 
panic.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Kernel panic in zfs code; 12-STABLE

[Karl Denninger]

FreeBSD 12.0-STABLE #2 r349024M: Thu Jun 13 18:01:16 CDT 2019
k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP

Note -- no patches of any sort in the ZFS code; I am NOT running any of
my former patch set.

NewFS.denninger.net dumped core - see /var/crash/vmcore.8

Thu Jul 18 15:02:54 CDT 2019

FreeBSD NewFS.denninger.net 12.0-STABLE FreeBSD 12.0-STABLE #2 r349024M:
Thu Jun 13 18:01:16 CDT 2019
k...@newfs.denninger.net:/usr/obj/usr/src/amd64.amd64/sys/KSD-SMP  amd64

panic: double fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:

Fatal double fault
rip 0x8271eeec rsp 0xfe009d4e7f60 rbp 0xfe009d4e8450
rax 0xf801b5b68000 rdx 0xababe19 rbx 0xf801ac399000
rcx 0x6f598 rsi 0xf801b5b68740 rdi 0xf801ac2a2668
r8 0xf801ac2a2668 r9 0 r10 0xf801ac7cf250
r11 0 r12 0xf801b5b685b8 r13 0xf801b5b68000
r14 0xfe0082dfb000 r15 0xf801b5b685b8 rflags 0x10286
cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b
fsbase 0x8002328d0 gsbase 0x8202a100 kgsbase 0
cpuid = 11; apic id = 35
panic: double fault
cpuid = 11
time = 1563479881
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe000338edb0
vpanic() at vpanic+0x19d/frame 0xfe000338ee00
panic() at panic+0x43/frame 0xfe000338ee60
dblfault_handler() at dblfault_handler+0x1de/frame 0xfe000338ef30
Xdblfault() at Xdblfault+0xc3/frame 0xfe000338ef30
--- trap 0x17, rip = 0x8271eeec, rsp = 0xfe009d4e7f60, rbp =
0xfe009d4e8450 ---
vdev_queue_io_to_issue() at vdev_queue_io_to_issue+0x2c/frame
0xfe009d4e8450
vdev_queue_io_done() at vdev_queue_io_done+0xc8/frame 0xfe009d4e84a0
zio_vdev_io_done() at zio_vdev_io_done+0x151/frame 0xfe009d4e84e0
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8530
zio_vdev_io_start() at zio_vdev_io_start+0x2a7/frame 0xfe009d4e8590
zio_execute() at zio_execute+0xac/frame 0xfe009d4e85e0
vdev_queue_io_done() at vdev_queue_io_done+0x115/frame 0xfe009d4e8630
zio_vdev_io_done() at zio_vdev_io_done+0x151/frame 0xfe009d4e8670
zio_execute() at zio_execute+0xac/frame 0xfe009d4e86c0
zio_vdev_io_start() at zio_vdev_io_start+0x2a7/frame 0xfe009d4e8720
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8770
vdev_queue_io_done() at vdev_queue_io_done+0x115/frame 0xfe009d4e87c0
zio_vdev_io_done() at zio_vdev_io_done+0x151/frame 0xfe009d4e8800
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8850
zio_vdev_io_start() at zio_vdev_io_start+0x2a7/frame 0xfe009d4e88b0
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8900
vdev_queue_io_done() at vdev_queue_io_done+0x115/frame 0xfe009d4e8950
zio_vdev_io_done() at zio_vdev_io_done+0x151/frame 0xfe009d4e8990
zio_execute() at zio_execute+0xac/frame 0xfe009d4e89e0
zio_vdev_io_start() at zio_vdev_io_start+0x2a7/frame 0xfe009d4e8a40
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8a90
vdev_queue_io_done() at vdev_queue_io_done+0x115/frame 0xfe009d4e8ae0
zio_vdev_io_done() at zio_vdev_io_done+0x151/frame 0xfe009d4e8b20
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8b70
zio_vdev_io_start() at zio_vdev_io_start+0x2a7/frame 0xfe009d4e8bd0
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8c20
vdev_queue_io_done() at vdev_queue_io_done+0x115/frame 0xfe009d4e8c70
zio_vdev_io_done() at zio_vdev_io_done+0x151/frame 0xfe009d4e8cb0
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8d00
zio_vdev_io_start() at zio_vdev_io_start+0x2a7/frame 0xfe009d4e8d60
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8db0
vdev_queue_io_done() at vdev_queue_io_done+0x115/frame 0xfe009d4e8e00
zio_vdev_io_done() at zio_vdev_io_done+0x151/frame 0xfe009d4e8e40
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8e90
zio_vdev_io_start() at zio_vdev_io_start+0x2a7/frame 0xfe009d4e8ef0
zio_execute() at zio_execute+0xac/frame 0xfe009d4e8f40
vdev_queue_io_done() at vdev_queue_io_done+0x115/frame 0xfe009d4e8f90
zio_vdev_io_done() at zio_vdev_io_done+0x151/frame 0xfe009d4e8fd0
zio_execute() at zio_execute+0xac/frame 0xfe009d4e9020
zio_vdev_io_start() at zio_vdev_io_start+0x2a7/frame 0xfe009d4e9080
zio_execute() at zio_execute+0xac/frame 0xfe009d4e90d0
vdev_queue_io_done() at vdev_queue_io_done+0x115/frame 0xfe009d4e9120
zio_vdev_io_done() at zio_vdev_io_done+0x151/frame 0xfe009d4e9160
zio_execute() at zio_execute+0xac/frame 0xfe009d4e91b0
zio_vdev_io_start() at zio_vdev_io_start+0x2a7/frame 0xfe009d4e9210
zio_execute() at zio_execute+0xac/frame 

Re: Kernel panic on 12-STABLE-r348203 amd64

[Mark Saad]

All
  I am going to try to reset the box to factory defaults and try to make it 
crash again today . I’ll update you with my outcome . 

---
Mark Saad | nones...@longcount.org

> On Jun 11, 2019, at 1:15 AM, Kubilay Kocak  wrote:
> 
>> On 6/06/2019 5:04 am, Mark Saad wrote:
>>> On Wed, Jun 5, 2019 at 2:42 PM Mark Saad  wrote:
>>> 
>>>> On Wed, Jun 5, 2019 at 12:29 PM Mark Saad  wrote:
>>>> 
>>>> All
>>>>  I was wondering if anyone could shed some light on this boot panic I
>>>> saw yesterday. This is on a Dell R630 with Bios 2.9.1  booting
>>>> 12.0-STABLE-r348203 amd64.
>>>> I reverted this back to 12.0-RELEASE-p4 and its fine .
>>>> 
>>>> The only custom options I had were in loader.conf
>>>> 
>>>> kern.geom.label.gptid.enable="0"
>>>> ipmi_load="YES"
>>>> boot_multicons="YES"
>>>> boot_serial="YES"
>>>> console="comconsole,vidconsole"
>>>> net.inet.tcp.tso="0"
>>>> cc_htcp_load="YES"
>>>> autoboot_delay="5"
>>>> hw.mfi.mrsas_enable="1"
>>>> hw.usb.no_pf="1"# Disable USB packet filtering
>>>> hw.usb.no_shutdown_wait="1"
>>>> hw.vga.textmode="1" # Text mode
>>>> machdep.hyperthreading_allowed="0"
>>>> 
>>>> Any ideas ?
>>>> 
>>>> Screen shot here
>>>> https://imgur.com/a/nGvHtIs
>>>> 
>>>> --
>>>> mark saad | nones...@longcount.org
>>> 
>>> Plain text version of the crash
>>> 
>>> Loading kernel...
>>> /boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80
>>> syms=[0x8+0x1778e8+0x8   /
>>> +0x194f1d]
>>> Loading configured modules...
>>> /boot/kernel/ipmi.ko size 0x11e10 at 0x2645000
>>> loading required module 'smbus'
>>> /boot/kernel/smbus.ko size 0x2ef0 at 0x2657000
>>> /boot/entropy size=0x1000
>>> /boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000
>>> ---<>---c_hmodule 'smbus'
>>> Copyright (c) 1992-2019 The FreeBSD Project.
>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>> The Regents of the University of California. All rights reserved.
>>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>>> FreeBSD 12.0-STABLE r348693 GENERIC amd64
>>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on
>>> LLVM 8.0.0)
>>> panic: UMA zone "UMA Zones": Increase vm.boot_pages
>>> cpuid = 0
>>> time = 1
>>> KDB: stack backtrace:
>>> #0 0x80c16df7 at ??+0
>>> #1 0x80bcaccd at ??+0
>>> #2 0x80bcab23 at ??+0
>>> #3 0x80f0b03c at ??+0
>>> #4 0x80f08d8d at ??+0
>>> #5 0x80f0bb3d at ??+0
>>> #6 0x80f0b301 at ??+0
>>> #7 0x80f0b3d1 at ??+0
>>> #8 0x80f066c4 at ??+0
>>> #9 0x80f0543f at ??+0
>>> #10 0x80f23aef at ??+0
>>> #11 0x80f1133b at ??+0
>>> #12 0x80b619c8 at ??+0
>>> #13 0x8036a02c at ??+0
>>> Uptime: 1s
>>> 
>>> 
>>> Also increasing the vm.boot_pages to 128 in the loader works. Anyone
>>> know why ? This box has 64G ram.
>>> 
>>> --
>>> mark saad | nones...@longcount.org
>> So after some poking in the bios this has to do with how the Dell NUMA
>> options are set. If the system is set Cluster On Die mode, you get a
>> kernel panic
>> Home Snoop or Early Snoop no issue.
> 
> Hi Mark,
> 
> Could you report this bug (Bugzilla) if you haven't already, providing:
> 
> - exact freebsd version(s) reproducible with
> - panic/backtrace output as an attachment. Ideally with a debug kernel
> - /var/run/dmesg.boot output (as an attachment) in a verbose boot
> - if you can test a current snapshot, that would be great
> - any other system information you believe might be helpful in isolating root 
> cause(s) or potential fixes
> 
> Thanks!
> Feel free to CC me on it
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic on 12-STABLE-r348203 amd64

[Kubilay Kocak]

On 6/06/2019 5:04 am, Mark Saad wrote:

On Wed, Jun 5, 2019 at 2:42 PM Mark Saad  wrote:


On Wed, Jun 5, 2019 at 12:29 PM Mark Saad  wrote:


All
  I was wondering if anyone could shed some light on this boot panic I
saw yesterday. This is on a Dell R630 with Bios 2.9.1  booting
12.0-STABLE-r348203 amd64.
I reverted this back to 12.0-RELEASE-p4 and its fine .

The only custom options I had were in loader.conf

kern.geom.label.gptid.enable="0"
ipmi_load="YES"
boot_multicons="YES"
boot_serial="YES"
console="comconsole,vidconsole"
net.inet.tcp.tso="0"
cc_htcp_load="YES"
autoboot_delay="5"
hw.mfi.mrsas_enable="1"
hw.usb.no_pf="1"# Disable USB packet filtering
hw.usb.no_shutdown_wait="1"
hw.vga.textmode="1" # Text mode
machdep.hyperthreading_allowed="0"

Any ideas ?

Screen shot here
https://imgur.com/a/nGvHtIs

--
mark saad | nones...@longcount.org


Plain text version of the crash

Loading kernel...
/boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80
syms=[0x8+0x1778e8+0x8   /
+0x194f1d]
Loading configured modules...
/boot/kernel/ipmi.ko size 0x11e10 at 0x2645000
loading required module 'smbus'
/boot/kernel/smbus.ko size 0x2ef0 at 0x2657000
/boot/entropy size=0x1000
/boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000
---<>---c_hmodule 'smbus'
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-STABLE r348693 GENERIC amd64
FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on
LLVM 8.0.0)
panic: UMA zone "UMA Zones": Increase vm.boot_pages
cpuid = 0
time = 1
KDB: stack backtrace:
#0 0x80c16df7 at ??+0
#1 0x80bcaccd at ??+0
#2 0x80bcab23 at ??+0
#3 0x80f0b03c at ??+0
#4 0x80f08d8d at ??+0
#5 0x80f0bb3d at ??+0
#6 0x80f0b301 at ??+0
#7 0x80f0b3d1 at ??+0
#8 0x80f066c4 at ??+0
#9 0x80f0543f at ??+0
#10 0x80f23aef at ??+0
#11 0x80f1133b at ??+0
#12 0x80b619c8 at ??+0
#13 0x8036a02c at ??+0
Uptime: 1s


Also increasing the vm.boot_pages to 128 in the loader works. Anyone
know why ? This box has 64G ram.

--
mark saad | nones...@longcount.org


So after some poking in the bios this has to do with how the Dell NUMA
options are set. If the system is set Cluster On Die mode, you get a
kernel panic
Home Snoop or Early Snoop no issue.




Hi Mark,

Could you report this bug (Bugzilla) if you haven't already, providing:

- exact freebsd version(s) reproducible with
- panic/backtrace output as an attachment. Ideally with a debug kernel
- /var/run/dmesg.boot output (as an attachment) in a verbose boot
- if you can test a current snapshot, that would be great
- any other system information you believe might be helpful in isolating 
root cause(s) or potential fixes


Thanks!
Feel free to CC me on it
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic on 12-STABLE-r348203 amd64

[Mark Saad]

On Wed, Jun 5, 2019 at 2:42 PM Mark Saad  wrote:
>
> On Wed, Jun 5, 2019 at 12:29 PM Mark Saad  wrote:
> >
> > All
> >  I was wondering if anyone could shed some light on this boot panic I
> > saw yesterday. This is on a Dell R630 with Bios 2.9.1  booting
> > 12.0-STABLE-r348203 amd64.
> > I reverted this back to 12.0-RELEASE-p4 and its fine .
> >
> > The only custom options I had were in loader.conf
> >
> > kern.geom.label.gptid.enable="0"
> > ipmi_load="YES"
> > boot_multicons="YES"
> > boot_serial="YES"
> > console="comconsole,vidconsole"
> > net.inet.tcp.tso="0"
> > cc_htcp_load="YES"
> > autoboot_delay="5"
> > hw.mfi.mrsas_enable="1"
> > hw.usb.no_pf="1"# Disable USB packet filtering
> > hw.usb.no_shutdown_wait="1"
> > hw.vga.textmode="1" # Text mode
> > machdep.hyperthreading_allowed="0"
> >
> > Any ideas ?
> >
> > Screen shot here
> > https://imgur.com/a/nGvHtIs
> >
> > --
> > mark saad | nones...@longcount.org
>
> Plain text version of the crash
>
> Loading kernel...
> /boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80
> syms=[0x8+0x1778e8+0x8   /
> +0x194f1d]
> Loading configured modules...
> /boot/kernel/ipmi.ko size 0x11e10 at 0x2645000
> loading required module 'smbus'
> /boot/kernel/smbus.ko size 0x2ef0 at 0x2657000
> /boot/entropy size=0x1000
> /boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000
> ---<>---c_hmodule 'smbus'
> Copyright (c) 1992-2019 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-STABLE r348693 GENERIC amd64
> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on
> LLVM 8.0.0)
> panic: UMA zone "UMA Zones": Increase vm.boot_pages
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> #0 0x80c16df7 at ??+0
> #1 0x80bcaccd at ??+0
> #2 0x80bcab23 at ??+0
> #3 0x80f0b03c at ??+0
> #4 0x80f08d8d at ??+0
> #5 0x80f0bb3d at ??+0
> #6 0x80f0b301 at ??+0
> #7 0x80f0b3d1 at ??+0
> #8 0x80f066c4 at ??+0
> #9 0x80f0543f at ??+0
> #10 0x80f23aef at ??+0
> #11 0x80f1133b at ??+0
> #12 0x80b619c8 at ??+0
> #13 0x8036a02c at ??+0
> Uptime: 1s
>
>
> Also increasing the vm.boot_pages to 128 in the loader works. Anyone
> know why ? This box has 64G ram.
>
> --
> mark saad | nones...@longcount.org

So after some poking in the bios this has to do with how the Dell NUMA
options are set. If the system is set Cluster On Die mode, you get a
kernel panic
Home Snoop or Early Snoop no issue.


-- 
mark saad | nones...@longcount.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic on 12-STABLE-r348203 amd64

[Mark Saad]

On Wed, Jun 5, 2019 at 12:29 PM Mark Saad  wrote:
>
> All
>  I was wondering if anyone could shed some light on this boot panic I
> saw yesterday. This is on a Dell R630 with Bios 2.9.1  booting
> 12.0-STABLE-r348203 amd64.
> I reverted this back to 12.0-RELEASE-p4 and its fine .
>
> The only custom options I had were in loader.conf
>
> kern.geom.label.gptid.enable="0"
> ipmi_load="YES"
> boot_multicons="YES"
> boot_serial="YES"
> console="comconsole,vidconsole"
> net.inet.tcp.tso="0"
> cc_htcp_load="YES"
> autoboot_delay="5"
> hw.mfi.mrsas_enable="1"
> hw.usb.no_pf="1"# Disable USB packet filtering
> hw.usb.no_shutdown_wait="1"
> hw.vga.textmode="1" # Text mode
> machdep.hyperthreading_allowed="0"
>
> Any ideas ?
>
> Screen shot here
> https://imgur.com/a/nGvHtIs
>
> --
> mark saad | nones...@longcount.org

Plain text version of the crash

Loading kernel...
/boot/kernel/kernel text=0x168d811 data=0x1cf968+0x768c80
syms=[0x8+0x1778e8+0x8   /
+0x194f1d]
Loading configured modules...
/boot/kernel/ipmi.ko size 0x11e10 at 0x2645000
loading required module 'smbus'
/boot/kernel/smbus.ko size 0x2ef0 at 0x2657000
/boot/entropy size=0x1000
/boot/kernel/cc_httcp.ko size 0x2330 at 0x265b000
---<>---c_hmodule 'smbus'
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-STABLE r348693 GENERIC amd64
FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on
LLVM 8.0.0)
panic: UMA zone "UMA Zones": Increase vm.boot_pages
cpuid = 0
time = 1
KDB: stack backtrace:
#0 0x80c16df7 at ??+0
#1 0x80bcaccd at ??+0
#2 0x80bcab23 at ??+0
#3 0x80f0b03c at ??+0
#4 0x80f08d8d at ??+0
#5 0x80f0bb3d at ??+0
#6 0x80f0b301 at ??+0
#7 0x80f0b3d1 at ??+0
#8 0x80f066c4 at ??+0
#9 0x80f0543f at ??+0
#10 0x80f23aef at ??+0
#11 0x80f1133b at ??+0
#12 0x80b619c8 at ??+0
#13 0x8036a02c at ??+0
Uptime: 1s


Also increasing the vm.boot_pages to 128 in the loader works. Anyone
know why ? This box has 64G ram.

-- 
mark saad | nones...@longcount.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Kernel panic on 12-STABLE-r348203 amd64

[Mark Saad]

All
 I was wondering if anyone could shed some light on this boot panic I
saw yesterday. This is on a Dell R630 with Bios 2.9.1  booting
12.0-STABLE-r348203 amd64.
I reverted this back to 12.0-RELEASE-p4 and its fine .

The only custom options I had were in loader.conf

kern.geom.label.gptid.enable="0"
ipmi_load="YES"
boot_multicons="YES"
boot_serial="YES"
console="comconsole,vidconsole"
net.inet.tcp.tso="0"
cc_htcp_load="YES"
autoboot_delay="5"
hw.mfi.mrsas_enable="1"
hw.usb.no_pf="1"# Disable USB packet filtering
hw.usb.no_shutdown_wait="1"
hw.vga.textmode="1" # Text mode
machdep.hyperthreading_allowed="0"

Any ideas ?

Screen shot here
https://imgur.com/a/nGvHtIs

-- 
mark saad | nones...@longcount.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

[Rob Belics]

This morning, RELEASE-p5 came about. I did a freebsd-update without issue.
However, as I said, I am running amd64 and not i386 on my server. So there
must be something more involved here.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

[Rob Belics]

Possibly same issue on amd64 server in my VPS but my laptop updated just
fine.

vm_fault_hold: fault on nofault entry, addr: 0
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

[Ed Maste]

On Wed, 15 May 2019 at 00:03, Ed Maste  wrote:
>
> On Wed, 15 May 2019 at 15:09, wintellect Auser  
> wrote:
> >
> > Hi all,
> >
> > Wanted to make you aware of an issue I have encountered, sorry if this is
> > the wrong list.
>
> This is the right place and thank you for reporting. Looking into it.

It looks like a new update for 12.0 i386 will be needed and will be
rolled out as soon as possible.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

[Ed Maste]

On Wed, 15 May 2019 at 15:09, wintellect Auser  wrote:
>
> Hi all,
>
> Wanted to make you aware of an issue I have encountered, sorry if this is
> the wrong list.

This is the right place and thank you for reporting. Looking into it.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 12.0-RELEASE-p4 kernel panic on i386 boot

[Dan Langille]

> Hi all,
> 
> Wanted to make you aware of an issue I have encountered, sorry if this is
> the wrong list.
> 
> I upgraded from FreeBSD 12.0-RELEASE-p3 to p4 using:
> 
> freebsd-fetch update
> freebsd-fetch install
> 
> and use the GENERIC kernel. Upon reboot the system kernel panics when
> attempting to mount the filesystem read-write. This also happens in
> single-user mode if selected at boot.
> 
> Selecting the kernel.old from the boot menu boots the system with 12-p3 and
> all works fine. I have uploaded a screenshot here:
> 
> https://imagebin.ca/v/4hCc2Kk5YqCX
> 
> The computer is an i386 system.

I also upgraded using "freebsd-update fetch install".

I also went from -p3 to -p4 on an i386.

My screen shot is here: https://twitter.com/DLangille/status/1128734141569208320

Hope this helps.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

12.0-RELEASE-p4 kernel panic on boot

[wintellect Auser]

Hi all,

Wanted to make you aware of an issue I have encountered, sorry if this is
the wrong list.

I upgraded from FreeBSD 12.0-RELEASE-p3 to p4 using:

freebsd-fetch update
freebsd-fetch install

and use the GENERIC kernel. Upon reboot the system kernel panics when
attempting to mount the filesystem read-write. This also happens in
single-user mode if selected at boot.

Selecting the kernel.old from the boot menu boots the system with 12-p3 and
all works fine. I have attached a screenshot.

The computer is an i386 system.

Thanks

wintellect
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

12.0-RELEASE-p4 kernel panic on i386 boot

[wintellect Auser]

Hi all,

Wanted to make you aware of an issue I have encountered, sorry if this is
the wrong list.

I upgraded from FreeBSD 12.0-RELEASE-p3 to p4 using:

freebsd-fetch update
freebsd-fetch install

and use the GENERIC kernel. Upon reboot the system kernel panics when
attempting to mount the filesystem read-write. This also happens in
single-user mode if selected at boot.

Selecting the kernel.old from the boot menu boots the system with 12-p3 and
all works fine. I have uploaded a screenshot here:

https://imagebin.ca/v/4hCc2Kk5YqCX

The computer is an i386 system.

Thanks

wintellect
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

[Miroslav Lachman]

Lee Damon wrote on 2019/03/02 01:36:

On 3/1/19 15:38 , Miroslav Lachman wrote:

Did you tried to boot "safe mode"? (selectable in boot menu).


I completely forgot about safe mode.

Yep. It boots. I'm going to finish the freebsd-update process then 
reboot into safe mode again. I'm out of time to work on this today and 
am only in this lab on Fridays so I'll have to pick up working on this 
problem next Friday.


Glad to know something finally works :)

You can look in to /boot/menu-commands.4th there is definition what Safe 
Mode disable



: safemode_enabled? ( -- flag )
s" kern.smp.disabled" getenv -1 <> dup if
swap drop ( c-addr flag -- flag )
then
;

: safemode_enable ( -- )
s" set kern.smp.disabled=1" evaluate
s" set hw.ata.ata_dma=0" evaluate
s" set hw.ata.atapi_dma=0" evaluate
s" set hw.ata.wc=0" evaluate
s" set hw.eisa_slots=0" evaluate
s" set kern.eventtimer.periodic=1" evaluate
s" set kern.geom.part.check_integrity=0" evaluate
;

You can play with these items one by one to find what is the root cause 
in your case.


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

[Lee Damon via freebsd-stable]

On 3/1/19 15:38 , Miroslav Lachman wrote:

Did you tried to boot "safe mode"? (selectable in boot menu).


I completely forgot about safe mode.

Yep. It boots. I'm going to finish the freebsd-update process then 
reboot into safe mode again. I'm out of time to work on this today and 
am only in this lab on Fridays so I'll have to pick up working on this 
problem next Friday.


Thanks for the help,
nomad
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

[Miroslav Lachman]

Lee Damon wrote on 2019/03/02 00:06:


Darn it. I get the same kernel panic with that one.

I'm compiling locally but I don't expect that to make any difference. 
I'll need to go pawing through the release notes and see if there are 
any references to deprecated hardware that might be involved.


I'm attaching a copy of dmesg output from a successful boot into 
10.4-STABLE. The kernel panic appears to happen around 15% of the way 
into the output, around


I am running 11.2 on SunFire X2100 M2 but according to your dmesg it 
uses different chips. X2100 M2 has nVidia nForce MCP55 chipset for ATA 
devices, nfe for 2 NICs and Broadcom bge for the other 2 NIC's.


Did you tried to boot "safe mode"? (selectable in boot menu).
Or you can try to disable / enable some settings in the BIOS. Something 
related to USB or onboard VGA etc. may help.


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

[Lee Damon via freebsd-stable]

On 3/1/19 14:19 , Miroslav Lachman wrote:
If you can boot with the old 10.4 kernel and go online, just fetch 
kernel.txz from the net: 
http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/11.2-RELEASE/kernel.txz and 
unpack it to /boot/kernel112 then you can try to reboot a manually 
select to boot this kernel instead of default /boot/kernel.


Darn it. I get the same kernel panic with that one.

I'm compiling locally but I don't expect that to make any difference. 
I'll need to go pawing through the release notes and see if there are 
any references to deprecated hardware that might be involved.


I'm attaching a copy of dmesg output from a successful boot into 
10.4-STABLE. The kernel panic appears to happen around 15% of the way 
into the output, around


...
mvsch13:  at channel 5 on mvs1
mvsch14:  at channel 6 on mvs1
mvsch15:  at channel 7 on mvs1
pcib3:  at device 6.0 on pci0
pci3:  on pcib3
ohci0:  mem 0xfd1fe000-0xfd1fefff irq 19 
at device 0.0 on pci3

usbus0 on ohci0
ohci1:  mem 0xfd1fd000-0xfd1fdfff irq 19 
at device 0.1 on pci3

usbus1 on ohci1
...

(Just before it enumerates vgapci0)

but I can't be sure because the screen moves so fast that even slow-mo 
video is just a blur.


nomad
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.4-STABLE #25 r342947: Fri Jan 11 14:17:40 PST 2019
l...@goose.ee.washington.edu:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: Dual Core AMD Opteron(tm) Processor 290 (2792.11-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x20f12  Family=0xf  Model=0x21  Stepping=2
  
Features=0x178bfbff
  Features2=0x1
  AMD Features=0xe2500800
  AMD Features2=0x3
real memory  = 17179869184 (16384 MB)
avail memory = 16418484224 (15657 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 2 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
random:  initialized
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-30 on motherboard
ioapic2  irqs 31-37 on motherboard
ioapic3  irqs 38-44 on motherboard
ioapic4  irqs 45-51 on motherboard
ioapic5  irqs 52-58 on motherboard
ioapic6  irqs 59-65 on motherboard
ioapic7  irqs 66-72 on motherboard
ioapic8  irqs 73-79 on motherboard
ioapic9  irqs 80-86 on motherboard
ioapic10  irqs 87-93 on motherboard
kbd1 at kbdmux0
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
attimer0:  port 0x40-0x43 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x71 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
hpet0:  iomem 0xfec01000-0xfec013ff irq 0,8 on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
pcib0:  on acpi0
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
mvs0:  port 0x7c00-0x7cff mem 
0xfae0-0xfaef irq 24 at device 1.0 on pci1
mvs0: Gen-II, 8 3Gbps ports, Port Multiplier supported
mvsch0:  at channel 0 on mvs0
mvsch1:  at channel 1 on mvs0
mvsch2:  at channel 2 on mvs0
mvsch3:  at channel 3 on mvs0
mvsch4:  at channel 4 on mvs0
mvsch5:  at channel 5 on mvs0
mvsch6:  at channel 6 on mvs0
mvsch7:  at channel 7 on mvs0
pcib2:  at device 2.0 on pci0
pci2:  on pcib2
mvs1:  port 0x8c00-0x8cff mem 
0xfb00-0xfb0f irq 32 at device 1.0 on pci2
mvs1: Gen-II, 8 3Gbps ports, Port Multiplier supported
mvsch8:  at channel 0 on mvs1
mvsch9:  at channel 1 on mvs1
mvsch10:  at channel 2 on mvs1
mvsch11:  at channel 3 on mvs1
mvsch12:  at channel 4 on mvs1
mvsch13:  at channel 5 on mvs1
mvsch14:  at channel 6 on mvs1
mvsch15:  at channel 7 on mvs1
pcib3:  at device 6.0 on pci0
pci3:  on pcib3
ohci0:  mem 0xfd1fe000-0xfd1fefff irq 19 at 
device 0.0 on pci3
usbus0 on ohci0
ohci1:  mem 0xfd1fd000-0xfd1fdfff irq 19 at 
device 0.1 on pci3
usbus1 on ohci1
vgapci0:  port 0x9800-0x98ff mem 
0xfc00-0xfcff,0xfd1ff000-0xfd1f irq 16 at device 3.0 on pci3
vgapci0: Boot video device
ohci2:  mem 0xfd1fc000-0xfd1fcfff irq 17 at device 
4.0 on pci3
usbus2 on ohci2
ohci3:  mem 0xfd1fb000-0xfd1fbfff irq 18 at device 
4.1 on pci3
usbus3 on ohci3
ehci0:  mem 0xfd1fac00-0xfd1facff irq 19 at 
device 4.2 on pci3
usbus4: EHCI version 1.0
usbus4 on ehci0
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 7.1 on pci0
ata0:  at channel 0 on atapci0
at

Re: more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

[Miroslav Lachman]

Lee Damon via freebsd-stable wrote on 2019/03/01 22:53:
After discussion with Bob Bishop (thanks for the help!) I've tried to do 
the following to upgrade one of the old boxes I mentioned previously.


cd /usr/src
tar ... .
rm -rf .??* *
svn checkout httpg://svn.freebsd.org/base/releng/10.3 /usr/src
compile, installkernel, installworld...

Now that the host is running RELENG the next step was to update from 
10.4 to 11.2 via freebsd-update


freebsd-update
freebsd-install
freebsd-update upgrade -r 11.2-RELEASE
freebsd-update install

so far, so good. Now it all falls apart

shutdown -r now
... why isn't the host coming back? Oh look, kernel panic.

   Fatal trap 12: page fault while in kernel mode
   cpuid = 1; apci id = 01
   fault virtual address = 0x84
   fault code = supervisor read data, page not present


I went back from freebsd-update to source upgrades few years ago and now 
use exclusively source builds (build it on powerful build machine and 
distribute it to clients thru NFS so clients can just run make 
installkernel and make installworld) because I was bitten by failed 
freebsd-update upgrade many times...


Google searches find references to the same panic type in VMs running 
11.1, including https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220923


The differences are, that's 11.1 not 11.2 (I would presume the fix made 
it into 11.2 but maybe not) and most notably, that's against VMs and the 
host I'm doing this on is bare iron (Sun x4500).


Still, I gave the two entries in /boot/loader.conf a try, no joy. 
Exactly the same panic. Recording the boot with slow-mo shows the panic 
happening just after the USB devices are enumerated by the kernel. It 
never even tries to mount root.


I am able to boot to kernel.old, which appears to be my old 10.4-STABLE 
kernel. So now I'm kind of stuck. The update has already modified the 
config files as part of the first pass so rolling back may be a problem 
and moving forward seems unwise.


I have only one x4500 but I have three x4540s running 11.2-STABLE (also 
installed from source) just fine.


Anyone have any brilliant suggestions? I'm thinking of trying to compile 
11.2-RELENG in /usr/src so I can try installing that kernel but that'll 
take several hours at least (it's an old box).


If you can boot with the old 10.4 kernel and go online, just fetch 
kernel.txz from the net: 
http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/11.2-RELEASE/kernel.txz 
and unpack it to /boot/kernel112 then you can try to reboot a manually 
select to boot this kernel instead of default /boot/kernel.

If you cannot access the boot loader prompt you can try "nextboot" command.
1) unpack the kernel
2) set nextboot: nextboot -k kernel112
3) shutdown -r now and hope for a luck

If your machine boots fine with 11.2 kernel, you can fetch sources and 
rebuild kernel and userland for 11.2 as usual.
Or you can try to fetch and unpack base.txz 
http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/11.2-RELEASE/base.txz 
over your current files. It can make a mess but you can always clean it 
with "make delete-old & make delete-old-libs"


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

more fun, upgrading from 10.3-STABLE 10.4-RELENG to 11.2-RELENG - kernel panic

[Lee Damon via freebsd-stable]

After discussion with Bob Bishop (thanks for the help!) I've tried to do 
the following to upgrade one of the old boxes I mentioned previously.


cd /usr/src
tar ... .
rm -rf .??* *
svn checkout httpg://svn.freebsd.org/base/releng/10.3 /usr/src
compile, installkernel, installworld...

Now that the host is running RELENG the next step was to update from 
10.4 to 11.2 via freebsd-update


freebsd-update
freebsd-install
freebsd-update upgrade -r 11.2-RELEASE
freebsd-update install

so far, so good. Now it all falls apart

shutdown -r now
... why isn't the host coming back? Oh look, kernel panic.

  Fatal trap 12: page fault while in kernel mode
  cpuid = 1; apci id = 01
  fault virtual address = 0x84
  fault code = supervisor read data, page not present

Google searches find references to the same panic type in VMs running 
11.1, including https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220923


The differences are, that's 11.1 not 11.2 (I would presume the fix made 
it into 11.2 but maybe not) and most notably, that's against VMs and the 
host I'm doing this on is bare iron (Sun x4500).


Still, I gave the two entries in /boot/loader.conf a try, no joy. 
Exactly the same panic. Recording the boot with slow-mo shows the panic 
happening just after the USB devices are enumerated by the kernel. It 
never even tries to mount root.


I am able to boot to kernel.old, which appears to be my old 10.4-STABLE 
kernel. So now I'm kind of stuck. The update has already modified the 
config files as part of the first pass so rolling back may be a problem 
and moving forward seems unwise.


I have only one x4500 but I have three x4540s running 11.2-STABLE (also 
installed from source) just fine.


Anyone have any brilliant suggestions? I'm thinking of trying to compile 
11.2-RELENG in /usr/src so I can try installing that kernel but that'll 
take several hours at least (it's an old box).


nomad
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

Rodney W. Grimes  changed:

   What|Removed |Added

 CC|sta...@freebsd.org  |

--- Comment #15 from Rodney W. Grimes  ---
Please do not put bugs on stable@, current@, hackers@, etc

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #14 from Andrey V. Elsukov  ---
(In reply to Sergey Anokhin from comment #13)
> (In reply to Andrey V. Elsukov from comment #11)
> 
> I'd preferred to try to rebuild kernel if it's no difference between turning
> off VIMAGE from kernel config and applying patch because kernel building
> more faster then "world" building. As far as I understand, you are propose
> patch for "world" component, right?

No, the patch is for kernel.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #13 from Sergey Anokhin  ---
(In reply to Andrey V. Elsukov from comment #11)

I'd preferred to try to rebuild kernel if it's no difference between turning
off VIMAGE from kernel config and applying patch because kernel building more
faster then "world" building. As far as I understand, you are propose patch for
"world" component, right?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #12 from Sergey Anokhin  ---
(In reply to Andrey V. Elsukov from comment #9)

Sure, now I'm building kernel without VIMAGE. I'll let you know about testing
result

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #11 from Andrey V. Elsukov  ---
Created attachment 201968
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201968=edit
Proposed patch

Also, you can test this patch instead, it should fix panic with VIMAGE option.
The problem is due to introduced deferred PCB destroying via epoch_call().
Since this code is executed from gtaskqueue, it has no VNET context.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #10 from Sergey Anokhin  ---
(In reply to Jan Bramkamp from comment #6)

Will it ok?

(pts/1)[root@server:~]# sysctl kern.maxssiz=1073741824
kern.maxssiz: 536870912 -> 1073741824
(pts/1)[root@server:~]# /usr/local/etc/rc.d/racoon onestart
Starting racoon.
(pts/1)[root@server:~]# /usr/local/etc/rc.d/racoon onestop
Stopping racoon.
Waiting for PIDS: 5662

kernel panic

btw, I've noticed that kernel panic during stopping racoon.

# kgdb kernel /var/crash/vmcore.last
GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from kernel...Reading symbols from
/usr/obj/usr/src/amd64.amd64/sys/SERVER/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x28
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ecd31d
stack pointer   = 0x28:0xfe003fca7a40
frame pointer   = 0x28:0xfe003fca7a60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (softirq_2)
trap number = 12
panic: page fault
cpuid = 2
time = 1550009599
KDB: stack backtrace:
#0 0x80c531c7 at kdb_backtrace+0x67
#1 0x80c07143 at vpanic+0x1a3
#2 0x80c06f93 at panic+0x43
#3 0x8118d9ff at trap_fatal+0x35f
#4 0x8118da59 at trap_pfault+0x49
#5 0x8118d07e at trap+0x29e
#6 0x81168ac5 at calltrap+0x8
#7 0x80eca240 at ipsec_delete_pcbpolicy+0x20
#8 0x80dbaeec at in_pcbfree_deferred+0x6c
#9 0x80c4db1a at epoch_call_task+0x1ca
#10 0x80c51a54 at gtaskqueue_run_locked+0x144
#11 0x80c516b8 at gtaskqueue_thread_loop+0x98
#12 0x80bc6f23 at fork_exit+0x83
#13 0x81169abe at fork_trampoline+0xe
Uptime: 8m33s
Dumping 950 out of 8077 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at ./machine/pcpu.h:230
230 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(OFFSETOF_CURTHREAD));
(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0x80c06d2b in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:446
#3  0x80c071a3 in vpanic (fmt=, ap=0xfe003fca7790)
at /usr/src/sys/kern/kern_shutdown.c:872
#4  0x80c06f93 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:799
#5  0x8118d9ff in trap_fatal (frame=0xfe003fca7980, eva=40) at
/usr/src/sys/amd64/amd64/trap.c:929
#6  0x8118da59 in trap_pfault (frame=0xfe003fca7980, usermode=0) at
/usr/src/sys/amd64/amd64/trap.c:765
#7  0x8118d07e in trap (frame=0xfe003fca7980) at
/usr/src/sys/amd64/amd64/trap.c:441
#8  
#9  0x80ecd31d in key_freesp (spp=0xf80211241880) at
/usr/src/sys/netipsec/key.c:1199
#10 0x80eca240 in ipsec_delete_pcbpolicy (inp=0xf800151aa1e8) at
/usr/src/sys/netipsec/ipsec_pcb.c:176
#11 0x80dbaeec in in_pcbfree_deferred (ctx=0xf800151aa3c0) at
/usr/src/sys/netinet/in_pcb.c:1576
#12 0x80c4db1a in epoch_call_task (arg=) at
/usr/src/sys/kern/subr_epoch.c:507
#13 0x80c51a54 in gtaskqueue_run_locked (queue=0xf80003363c00) at
/usr/src/sys/kern/subr_gtaskqueue.c:376
#14 0x80c516b8 in gtaskqueue_thread_loop (arg=) at
/usr/src/sys/kern/subr_gtaskqueue.c:557
#15 0x80bc6f23 in fork_exit (callout=0x80c51620
, arg=0xfe00025f5038, frame=0xfe003fca7c00)
at /usr/src/sys/kern/kern_fork.c:1059
#16 
(kgdb) frame 9
#9  0x80ecd31d in key_freesp (spp=0xf80211241880) at
/usr/src/sys/netipsec/key.c:1199
1199KEYDBG(IPSEC_STAMP,
(kgdb)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #9 from Andrey V. Elsukov  ---
Can you try to remove `option VIMAGE` from your kernel config? It looks like
the problem is similar to the one described in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235699

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #8 from Sergey Anokhin  ---
(In reply to Jan Bramkamp from comment #6)

Did you mean try to set kern.maxssiz into /boot/loader.conf?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #7 from Sergey Anokhin  ---
btw, perhaps it can be helpful: if port security/ipsec-tools was built with
default options (make rmconfig), so the bug doesn't reproduced

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

Jan Bramkamp  changed:

   What|Removed |Added

 CC||cr...@bultmann.eu

--- Comment #6 from Jan Bramkamp  ---
Can you try again with IPSEC_DEBUG and a doubled kernel stack size?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #5 from Andrey V. Elsukov  ---
(In reply to Sergey Anokhin from comment #4)
> (In reply to Andrey V. Elsukov from comment #3)
> 
> There is a mind that if turn off
> 
> options IPSEC_DEBUG
> 
> kernel panic will disappear

Disabling IPSEC_DEBUG also reduces the requirement to kernel stack size.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #4 from Sergey Anokhin  ---
(In reply to Andrey V. Elsukov from comment #3)

There is a mind that if turn off

options IPSEC_DEBUG

kernel panic will disappear

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #3 from Andrey V. Elsukov  ---
KEYDBG() macro executed only when net.key.debug is set to non-zero value. It
looks like your sysctl.conf didn't set it. Also, it looks impossible to get
page fault with fault address 0x28 in this line of code. I suspect, that you
have some sort of memory corruption. Not sure, is it hardware related or it is
overwritten by some code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

--- Comment #2 from Sergey Anokhin  ---
(In reply to Andrey V. Elsukov from comment #1)

kernel config:

(pts/2)[root@server:~]# cat /usr/src/sys/amd64/conf/SERVER
#
# GENERIC -- Generic kernel configuration file for FreeBSD/amd64
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#   
https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (https://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: stable/12/sys/amd64/conf/GENERIC 340695 2018-11-20 19:37:09Z
zeising $

cpu HAMMER
ident   SERVER

makeoptions DEBUG=-g# Build kernel with gdb(1) debug
symbols
makeoptions WITH_CTF=1  # Run ctfconvert(1) for DTrace support

options SCHED_ULE   # ULE scheduler
options NUMA# Non-Uniform Memory Architecture
support
options PREEMPTION  # Enable kernel thread preemption
options VIMAGE  # Subsystem virtualization, e.g. VNET
options INET# InterNETworking
options INET6   # IPv6 communications protocols
options IPSEC   # IP (v4/v6) security
options IPSEC_SUPPORT   # Allow kldload of ipsec and tcpmd5
options TCP_OFFLOAD # TCP offload
options TCP_BLACKBOX# Enhanced TCP event logging
options TCP_HHOOK   # hhook(9) framework for TCP
options TCP_RFC7413 # TCP Fast Open
options SCTP# Stream Control Transmission Protocol
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big
directories
options UFS_GJOURNAL# Enable gjournal-based UFS journaling
options QUOTA   # Enable disk quotas for UFS
options MD_ROOT # MD is a potential root device
options NFSCL   # Network Filesystem Client
options NFSD# Network Filesystem Server
options NFSLOCKD# Network Lock Manager
options NFS_ROOT# NFS usable as /, requires NFSCL
options MSDOSFS # MSDOS Filesystem
options CD9660  # ISO 9660 Filesystem
options PROCFS  # Process filesystem (requires
PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_RAID   # Soft RAID functionality.
options GEOM_LABEL  # Provides labelization
options EFIRT   # EFI Runtime Services support
options COMPAT_FREEBSD32# Compatible with i386 binaries
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options COMPAT_FREEBSD6 # Compatible with FreeBSD6
options COMPAT_FREEBSD7 # Compatible with FreeBSD7
options COMPAT_FREEBSD9 # Compatible with FreeBSD9
options COMPAT_FREEBSD10# Compatible with FreeBSD10
options COMPAT_FREEBSD11# Compatible with FreeBSD11
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
options KTRACE  # ktrace(1) support
options STACK   # stack(9) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
extensions
options PRINTF_BUFR_SIZE=128# Prevent printf output being
interspersed.
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4)
options AUDIT   # Security event auditing
options CAPABILITY_MODE # Capsicum capability mode
options CAPABILITIES# Capsicum capabilities
options MAC # TrustedBSD MAC Framework
options KDTRACE_FRAME   # Ensure frames are 

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

Andrey V. Elsukov  changed:

   What|Removed |Added

 CC||a...@freebsd.org

--- Comment #1 from Andrey V. Elsukov  ---
(In reply to Sergey Anokhin from comment #0)
> I see kernel panic during racoon restart.
> 
> # uname -rv
> 12.0-STABLE FreeBSD 12.0-STABLE r343904 SERVER

Please, show the content of your kernel config and what sysctl variables do you
changed against default configuration.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235684] security/ipsec-tools kernel panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235684

Sergey Anokhin  changed:

   What|Removed |Added

 CC||b...@freebsd.org,
   ||sta...@freebsd.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 235683] ZFS kernel panic when access to data or scrub

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235683

Sergey Anokhin  changed:

   What|Removed |Added

 CC||sta...@freebsd.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Repeated kernel panic on 11.2-RELEASE-p7

[Jurij Kovačič via freebsd-stable]

Dear list,

After some time, I have again experienced a kernel panic on a (physical)
server, running Freebsd 11.2-RELEASE-p7 with custom/debug kernel, ZFS root.

Fatal trap 9: general protection fault while in kernel mode
cpuid = 2; apic id = 02
instruction pointer= 0x20:0x82299013
stack pointer= 0x28:0xfe0352893ad0
frame pointer= 0x28:0xfe0352893b10
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process= 9 (dbuf_evict_thread)
trap number= 9
panic: general protection fault
cpuid = 2
KDB: stack backtrace:
#0 0x80b3d567 at kdb_backtrace+0x67
#1 0x80af6b07 at vpanic+0x177
#2 0x80af6983 at panic+0x43
#3 0x80f77fdf at trap_fatal+0x35f
#4 0x80f7759e at trap+0x5e
#5 0x80f5807c at calltrap+0x8
#6 0x8229c049 at dbuf_evict_one+0xe9
#7 0x82297a15 at dbuf_evict_thread+0x1a5
#8 0x80aba083 at fork_exit+0x83
#9 0x80f58f9e at fork_trampoline+0xe
Uptime: 20d6h13m55s
Dumping 2593 out of 12248
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

I have used "crashinfo" utility to generate the text file which is
available at this URL: http://www.ocpea.com/dump/core-3.txt.

All advice is deeply appreciated as this is a production server. :)

Kind regards,
Jurij
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Kernel panic going multiuser under 12 ( was Re: More CARP issues under 12 (maybe not CARP after all))

[Pete French]

Just to get the subject correct, as I tested this disabling CARP and I 
still see the panic when going multi-user. It netwprking related as the 
panic is in the ARP code, and seems to happen when the network 
interfaces are configured. The machine was using a mix of em and igb 
interfaces, but is now igb only.


-pete.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic on 11.2-RELEASE-p7

[Jurij Kovačič via freebsd-stable]

Dear list,

About a week ago, we had a kernel panic on Freebsd 11.2-RELEASE-p7 with
GENERIC kernel, ZFS root. As the kernel was not compiled with debug support
enabled, the resulting "vmcore" files were of little use. Consequently, I
recompiled kernel with debug support:

--- GENERIC 2018-12-29 08:03:04.786846000 +0100
+++ DEBUG   2018-12-29 08:23:36.522966000 +0100
@@ -19,11 +19,16 @@
 # $FreeBSD: releng/11.2/sys/amd64/conf/GENERIC 333417 2018-05-09 16:14:12Z
sbruno $

 cpuHAMMER
-ident  GENERIC
+ident  DEBUG

 makeoptionsDEBUG=-g# Build kernel with gdb(1) debug
symbols
 makeoptionsWITH_CTF=1  # Run ctfconvert(1) for DTrace
support

+# kernel debugging
+optionsKDB
+optionsKDB_UNATTENDED
+optionsKDB_TRACE
+
 optionsSCHED_ULE   # ULE scheduler
 optionsPREEMPTION  # Enable kernel thread preemption
 optionsINET# InterNETworking

and installed it.

After running for about a week, the server crashed again this night.
Unfortunately, there are no "vmcore" files on "/var/crash" this time.

The server has 12GB of RAM installed:
 # sysctl hw.physmem
hw.physmem: 12843053056

and uses 2 swap partitions (2G each):
# swapinfo -h
Device  1K-blocks UsedAvail Capacity
/dev/ada0p2   2097152 642M 1.4G31%
/dev/ada1p2   2097152 638M 1.4G31%
Total 4194304 1.3G 2.7G31%

Dump device is set in /etc/rc.conf:
# grep dump /etc/rc.conf
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"

There seems to be enough space left in "/var/crash":
 # zfs list | grep crash
zroot/var/crash  857M  17.2G   857M  /var/crash

and like I said earlier, the system DID create "vmcore" files when crashing
with GENERIC kernel. Is it possible that swap partition(s) are too small
for the memory dump, now that the kernel is compiled with debug support? Or
is some additional configuration needed to make the system save vmcore
files?

Please advise.

Kind regards,
Jurij

On Tue, Dec 25, 2018 at 7:57 AM Jurij Kovačič 
wrote:

> Dear list,
>
> I hope I am posting this to the correct list - if not, I apologize (and
> please advise where to post this instead).
>
> Today I experienced a kernel panic on a (physical) server, running Freebsd
> 11.2-RELEASE-p7 with GENERIC kernel, ZFS root:
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer= 0x20:0x82299013
> stack pointer= 0x28:0xfe0352893ad0
> frame pointer= 0x28:0xfe0352893b10
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process= 9 (dbuf_evict_thread)
> trap number= 9
> panic: general protection fault
> cpuid = 0
> KDB: stack backtrace:
> #0 0x80b3d577 at kdb_backtrace+0x67
> #1 0x80af6b17 at vpanic+0x177
> #2 0x80af6993 at panic+0x43
> #3 0x80f77fdf at trap_fatal+0x35f
> #4 0x80f7759e at trap+0x5e
> #5 0x80f5808c at calltrap+0x8
> #6 0x8229c049 at dbuf_evict_one+0xe9
> #7 0x82297a15 at dbuf_evict_thread+0x1a5
> #8 0x80aba093 at fork_exit+0x83
> #9 0x80f58fae at fork_trampoline+0xe
>
> I have used "crashinfo" utility to generate the text file which is
> available at this URL: http://www.ocpea.com/dump/core.txt
>
> At the time of the crash, the server was probably under more intensive I/O
> load (scheduled backup with rsync).
>
> This is a production server, so naturally, all advice is deeply
> appreciated. :)
>
> Kind regards,
> Jurij
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic on 11.2-RELEASE-p7

[Jurij Kovačič via freebsd-stable]

Hi Andriy,

Upon further investigation - I take it the kernel options should probably
be:
...
makeoptionsDEBUG=-g
options KDB
options KDB_UNATTENDED
...
?

Thank you!

Kind regards,
Jurij


On Fri, Dec 28, 2018 at 12:07 PM Jurij Kovačič 
wrote:

> Hi Andriy,
>
> Thank you for your reply.
>
> Is what you are suggesting I build and install GENERIC kernel WITH debug
> symbols?
>
> I presume I just update the sources to 11.2 release and build and install
> the GENERIC kernel with added
>
> makeoptions   DEBUG=-g ?
>
>
> Kind regards,
>
> Jurij
>
>
>
> On Fri, Dec 28, 2018 at 11:34 AM Andriy Gapon  wrote:
>
>> On 28/12/2018 12:07, Jurij Kovačič via freebsd-stable wrote:
>> > Dear list,
>> >
>> > This morning the server mentioned in my previous e-mail (Freebsd
>> > 11.2-RELEASE-p7 with GENERIC kernel, ZFS root) experienced another
>> kernel
>> > panic:
>> >
>> > Fatal trap 9: general protection fault while in kernel mode
>> > cpuid = 0; apic id = 00
>> > instruction pointer= 0x20:0x82299013
>> > stack pointer= 0x28:0xfe0352893ad0
>> > frame pointer= 0x28:0xfe0352893b10
>> > code segment= base 0x0, limit 0xf, type 0x1b
>> > = DPL 0, pres 1, long 1, def32 0, gran 1
>> > processor eflags= interrupt enabled, resume, IOPL = 0
>> > current process= 9 (dbuf_evict_thread)
>> > trap number= 9
>> > panic: general protection fault
>> > cpuid = 0
>> > KDB: stack backtrace:
>> > #0 0x80b3d577 at kdb_backtrace+0x67
>> > #1 0x80af6b17 at vpanic+0x177
>> > #2 0x80af6993 at panic+0x43
>> > #3 0x80f77fdf at trap_fatal+0x35f
>> > #4 0x80f7759e at trap+0x5e
>> > #5 0x80f5808c at calltrap+0x8
>> > #6 0x8229c049 at dbuf_evict_one+0xe9
>> > #7 0x82297a15 at dbuf_evict_thread+0x1a5
>> > #8 0x80aba093 at fork_exit+0x83
>> > #9 0x80f58fae at fork_trampoline+0xe
>> >
>> > I have used the "crashinfo" utility to (again) generate the text file
>> which
>> > is available at this URL: http://www.ocpea.com/dump/core-2.txt
>> > <http://www.ocpea.com/dump/core.txt>
>>
>> This is useless because you do not have debug symbols for the kernel.
>>
>> > Does anyone have any idea how we can go about discovering the cause for
>> > this? We would appreciate any suggestion ...
>>
>>
>>
>> --
>> Andriy Gapon
>>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic on 11.2-RELEASE-p7

[Jurij Kovačič via freebsd-stable]

Hi Andriy,

Thank you for your reply.

Is what you are suggesting I build and install GENERIC kernel WITH debug
symbols?

I presume I just update the sources to 11.2 release and build and install
the GENERIC kernel with added

makeoptions DEBUG=-g ?


Kind regards,

Jurij



On Fri, Dec 28, 2018 at 11:34 AM Andriy Gapon  wrote:

> On 28/12/2018 12:07, Jurij Kovačič via freebsd-stable wrote:
> > Dear list,
> >
> > This morning the server mentioned in my previous e-mail (Freebsd
> > 11.2-RELEASE-p7 with GENERIC kernel, ZFS root) experienced another kernel
> > panic:
> >
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 0; apic id = 00
> > instruction pointer= 0x20:0x82299013
> > stack pointer= 0x28:0xfe0352893ad0
> > frame pointer= 0x28:0xfe0352893b10
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags= interrupt enabled, resume, IOPL = 0
> > current process= 9 (dbuf_evict_thread)
> > trap number= 9
> > panic: general protection fault
> > cpuid = 0
> > KDB: stack backtrace:
> > #0 0x80b3d577 at kdb_backtrace+0x67
> > #1 0x80af6b17 at vpanic+0x177
> > #2 0x80af6993 at panic+0x43
> > #3 0x80f77fdf at trap_fatal+0x35f
> > #4 0x80f7759e at trap+0x5e
> > #5 0x80f5808c at calltrap+0x8
> > #6 0x8229c049 at dbuf_evict_one+0xe9
> > #7 0x82297a15 at dbuf_evict_thread+0x1a5
> > #8 0x80aba093 at fork_exit+0x83
> > #9 0x80f58fae at fork_trampoline+0xe
> >
> > I have used the "crashinfo" utility to (again) generate the text file
> which
> > is available at this URL: http://www.ocpea.com/dump/core-2.txt
> > <http://www.ocpea.com/dump/core.txt>
>
> This is useless because you do not have debug symbols for the kernel.
>
> > Does anyone have any idea how we can go about discovering the cause for
> > this? We would appreciate any suggestion ...
>
>
>
> --
> Andriy Gapon
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic on 11.2-RELEASE-p7

[Andriy Gapon]

On 28/12/2018 12:07, Jurij Kovačič via freebsd-stable wrote:
> Dear list,
> 
> This morning the server mentioned in my previous e-mail (Freebsd
> 11.2-RELEASE-p7 with GENERIC kernel, ZFS root) experienced another kernel
> panic:
> 
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer= 0x20:0x82299013
> stack pointer= 0x28:0xfe0352893ad0
> frame pointer= 0x28:0xfe0352893b10
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process= 9 (dbuf_evict_thread)
> trap number= 9
> panic: general protection fault
> cpuid = 0
> KDB: stack backtrace:
> #0 0x80b3d577 at kdb_backtrace+0x67
> #1 0x80af6b17 at vpanic+0x177
> #2 0x80af6993 at panic+0x43
> #3 0x80f77fdf at trap_fatal+0x35f
> #4 0x80f7759e at trap+0x5e
> #5 0x80f5808c at calltrap+0x8
> #6 0x8229c049 at dbuf_evict_one+0xe9
> #7 0x82297a15 at dbuf_evict_thread+0x1a5
> #8 0x80aba093 at fork_exit+0x83
> #9 0x80f58fae at fork_trampoline+0xe
> 
> I have used the "crashinfo" utility to (again) generate the text file which
> is available at this URL: http://www.ocpea.com/dump/core-2.txt
> <http://www.ocpea.com/dump/core.txt>

This is useless because you do not have debug symbols for the kernel.

> Does anyone have any idea how we can go about discovering the cause for
> this? We would appreciate any suggestion ...



-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic on 11.2-RELEASE-p7

[Jurij Kovačič via freebsd-stable]

Dear list,

This morning the server mentioned in my previous e-mail (Freebsd
11.2-RELEASE-p7 with GENERIC kernel, ZFS root) experienced another kernel
panic:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer= 0x20:0x82299013
stack pointer= 0x28:0xfe0352893ad0
frame pointer= 0x28:0xfe0352893b10
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process= 9 (dbuf_evict_thread)
trap number= 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0x80b3d577 at kdb_backtrace+0x67
#1 0x80af6b17 at vpanic+0x177
#2 0x80af6993 at panic+0x43
#3 0x80f77fdf at trap_fatal+0x35f
#4 0x80f7759e at trap+0x5e
#5 0x80f5808c at calltrap+0x8
#6 0x8229c049 at dbuf_evict_one+0xe9
#7 0x82297a15 at dbuf_evict_thread+0x1a5
#8 0x80aba093 at fork_exit+0x83
#9 0x80f58fae at fork_trampoline+0xe

I have used the "crashinfo" utility to (again) generate the text file which
is available at this URL: http://www.ocpea.com/dump/core-2.txt
<http://www.ocpea.com/dump/core.txt>

Does anyone have any idea how we can go about discovering the cause for
this? We would appreciate any suggestion ...

Kind regards,
Jurij Kovacic


On Tue, Dec 25, 2018 at 7:57 AM Jurij Kovačič 
wrote:

> Dear list,
>
> I hope I am posting this to the correct list - if not, I apologize (and
> please advise where to post this instead).
>
> Today I experienced a kernel panic on a (physical) server, running Freebsd
> 11.2-RELEASE-p7 with GENERIC kernel, ZFS root:
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer= 0x20:0x82299013
> stack pointer= 0x28:0xfe0352893ad0
> frame pointer= 0x28:0xfe0352893b10
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process= 9 (dbuf_evict_thread)
> trap number= 9
> panic: general protection fault
> cpuid = 0
> KDB: stack backtrace:
> #0 0x80b3d577 at kdb_backtrace+0x67
> #1 0x80af6b17 at vpanic+0x177
> #2 0x80af6993 at panic+0x43
> #3 0x80f77fdf at trap_fatal+0x35f
> #4 0x80f7759e at trap+0x5e
> #5 0x80f5808c at calltrap+0x8
> #6 0x8229c049 at dbuf_evict_one+0xe9
> #7 0x82297a15 at dbuf_evict_thread+0x1a5
> #8 0x80aba093 at fork_exit+0x83
> #9 0x80f58fae at fork_trampoline+0xe
>
> I have used "crashinfo" utility to generate the text file which is
> available at this URL: http://www.ocpea.com/dump/core.txt
>
> At the time of the crash, the server was probably under more intensive I/O
> load (scheduled backup with rsync).
>
> This is a production server, so naturally, all advice is deeply
> appreciated. :)
>
> Kind regards,
> Jurij
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Kernel panic on 11.2-RELEASE-p7

[Jurij Kovačič via freebsd-stable]

Dear list,

I hope I am posting this to the correct list - if not, I apologize (and
please advise where to post this instead).

Today I experienced a kernel panic on a (physical) server, running Freebsd
11.2-RELEASE-p7 with GENERIC kernel, ZFS root:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer= 0x20:0x82299013
stack pointer= 0x28:0xfe0352893ad0
frame pointer= 0x28:0xfe0352893b10
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process= 9 (dbuf_evict_thread)
trap number= 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
#0 0x80b3d577 at kdb_backtrace+0x67
#1 0x80af6b17 at vpanic+0x177
#2 0x80af6993 at panic+0x43
#3 0x80f77fdf at trap_fatal+0x35f
#4 0x80f7759e at trap+0x5e
#5 0x80f5808c at calltrap+0x8
#6 0x8229c049 at dbuf_evict_one+0xe9
#7 0x82297a15 at dbuf_evict_thread+0x1a5
#8 0x80aba093 at fork_exit+0x83
#9 0x80f58fae at fork_trampoline+0xe

I have used "crashinfo" utility to generate the text file which is
available at this URL: http://www.ocpea.com/dump/core.txt

At the time of the crash, the server was probably under more intensive I/O
load (scheduled backup with rsync).

This is a production server, so naturally, all advice is deeply
appreciated. :)

Kind regards,
Jurij
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)

[Trond Endrestøl]

On Thu, 6 Dec 2018 09:38-0800, Navdeep Parhar wrote:

> Can you please file a bug at https://bugs.freebsd.org/bugzilla/ and 
> assign it to me?

See PR 233851.

-- 
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)

[Navdeep Parhar]

Can you please file a bug at https://bugs.freebsd.org/bugzilla/ and
assign it to me?

Regards,
Navdeep

On 12/6/18 4:02 AM, Trond Endrestøl wrote:
> After booting stable/12 r341604, running a custom kernel including 
> cxgbe(4), cxgbev(4), and ccr(4), and running swapon -a in SU mode:
> 
> GEOM_ELI: Device gpt/swap0.eli created.
> GEOM_ELI: Encryption: AES-XTS 256
> GEOM_ELI: Crypto: hardware
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 06
> fault virtual address   = 0x0
> fault code  = supervisor write data, page not present
> instruction pointer = 0x20:0x805be1b2
> stack pointer   = 0x28:0xfe00a6253770
> frame pointer   = 0x28:0xfe00a6253770
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 65 (g_eli[3] gpt/swap0)
> trap number = 12
> panic: page fault
> cpuid = 3
> time = 1544087308
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x8055d9eb = 
> db_trace_self_wrapper+0x2b/frame 0xfe00a6253420
> vpanic() at 0x808754d3 = vpanic+0x1a3/frame 0xfe00a6253480
> panic() at 0x80875323 = panic+0x43/frame 0xfe00a62534e0
> trap_fatal() at 0x80bd745f = trap_fatal+0x35f/frame 0xfe00a6253530
> trap_pfault() at 0x80bd74b9 = trap_pfault+0x49/frame 
> 0xfe00a4b7f590
> trap() at 0x80bd6ade = trap+0x29e/frame 0xfe00a4b7f6a0
> calltrap() at 0x80bb3935 = calltrap+0x8/frame 0xfe00a4b7f6a0
> --- trap 0xc, rip = 0x805be1b2, rsp = 0xfe00a4b7f770, rbp = 
> 0xfe00a4b7f770
> t4_wrq_tx_locked() at 0x805be1b2 = t4_wrq_tx_locked+0x12/frame 
> 0xfe00a6253770
> ccr_process() at 0x805e3fc3 = ccr_process+0x1953/frame 
> 0xfe00a4b7f970
> crypto_dispatch() at 0x80ae3fa4 = crypto_dispatch+0x144/frame 
> 0xfe00a4b7f9b0
> g_eli_crypto_run() at 0x807b5cb3 = g_eli_crypto_run+0x273/frame 
> 0xfe00a4b7fa10
> g_eli_worker() at 0x807aebc8 = g_eli_worker+0x3c8/frame 
> 0xfe00a4b7fa70
> fork_exit() at 0x80834d93 = fork_exit+0x83/frame 0xfe00a4b7fab0
> fork_trampoline() at 0x80bb491e = fork_trampoline+0xe/frame 
> 0xfe00a4b7fab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> Uptime: 14s
> Automatic reboot in 15 seconds - press a key on the console to abort
> --> Press a key on the console to reboot,
> 
> The Chelsio NIC is a T6225-CR.
> 
> Kernel config is 
> https://ximalas.info/~trond/create-zfs/canmount/ENTERPRISE-amd64-stable-12
> 
> I tried stable/12 r341623 with ccr(4) removed from the kernel, and I 
> had no problems engaging geli encrypted swap in SU mode nor in normal 
> mode.
> 
> Has anyone else tried ccr(4) on recent stable/12?
> Are we discouraged from using ccr(4)?
> I was hoping to take advantage of the crypto accelerator.
> 


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)

[Trond Endrestøl]

After booting stable/12 r341604, running a custom kernel including 
cxgbe(4), cxgbev(4), and ccr(4), and running swapon -a in SU mode:

GEOM_ELI: Device gpt/swap0.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI: Crypto: hardware


Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 06
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x805be1b2
stack pointer   = 0x28:0xfe00a6253770
frame pointer   = 0x28:0xfe00a6253770
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 65 (g_eli[3] gpt/swap0)
trap number = 12
panic: page fault
cpuid = 3
time = 1544087308
KDB: stack backtrace:
db_trace_self_wrapper() at 0x8055d9eb = 
db_trace_self_wrapper+0x2b/frame 0xfe00a6253420
vpanic() at 0x808754d3 = vpanic+0x1a3/frame 0xfe00a6253480
panic() at 0x80875323 = panic+0x43/frame 0xfe00a62534e0
trap_fatal() at 0x80bd745f = trap_fatal+0x35f/frame 0xfe00a6253530
trap_pfault() at 0x80bd74b9 = trap_pfault+0x49/frame 0xfe00a4b7f590
trap() at 0x80bd6ade = trap+0x29e/frame 0xfe00a4b7f6a0
calltrap() at 0x80bb3935 = calltrap+0x8/frame 0xfe00a4b7f6a0
--- trap 0xc, rip = 0x805be1b2, rsp = 0xfe00a4b7f770, rbp = 
0xfe00a4b7f770
t4_wrq_tx_locked() at 0x805be1b2 = t4_wrq_tx_locked+0x12/frame 
0xfe00a6253770
ccr_process() at 0x805e3fc3 = ccr_process+0x1953/frame 
0xfe00a4b7f970
crypto_dispatch() at 0x80ae3fa4 = crypto_dispatch+0x144/frame 
0xfe00a4b7f9b0
g_eli_crypto_run() at 0x807b5cb3 = g_eli_crypto_run+0x273/frame 
0xfe00a4b7fa10
g_eli_worker() at 0x807aebc8 = g_eli_worker+0x3c8/frame 
0xfe00a4b7fa70
fork_exit() at 0x80834d93 = fork_exit+0x83/frame 0xfe00a4b7fab0
fork_trampoline() at 0x80bb491e = fork_trampoline+0xe/frame 
0xfe00a4b7fab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 14s
Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot,

The Chelsio NIC is a T6225-CR.

Kernel config is 
https://ximalas.info/~trond/create-zfs/canmount/ENTERPRISE-amd64-stable-12

I tried stable/12 r341623 with ccr(4) removed from the kernel, and I 
had no problems engaging geli encrypted swap in SU mode nor in normal 
mode.

Has anyone else tried ccr(4) on recent stable/12?
Are we discouraged from using ccr(4)?
I was hoping to take advantage of the crypto accelerator.

-- 
Trond.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

[Oliver Pinter]

On Monday, August 20, 2018, Oliver Pinter 
wrote:

> On 8/3/18, Bjoern A. Zeeb  wrote:
> > On 3 Aug 2018, at 20:42, Oliver Pinter wrote:
> >
> >> On 8/3/18, Bjoern A. Zeeb  wrote:
> >>> On 3 Aug 2018, at 18:48, Oliver Pinter wrote:
> >>>
> >>>> Hi all!
> >>>>
> >>>> One of out users observed an VNET related kernel panic with epairs
> >>>> in
> >>>> a jail. Seems like some of the
> >>>
> >>> Well would be great for a start to (a) email virtualisation@ as well,
> >>> (b) include a panic message, backtrace or other related information
> >>> to
> >>> deduce anything about the possible bug, (c) and not to conflate it
> >>> with
> >>> another totally unrelated MFC request.
> >>>
> >>> So what makes you think it’s related to tcp fast open?
> >>
> >> Every required detail is in HardenedBSD's github issue, but I copy the
> >> kernel panic here:
> >
> > Ah sorry my bad;  the issue said ZFS in the subject and I thought it
> > refers to something else.
> >
> > Thanks! Looking at the backtrace it seems it is happening on teardown
> > and not on startup but indeed in the fast open code and that PR 216613
> > indeed fixed this in head, good :)  Hope Patrick will do the mfc for
> > you.
>
> Hi!
>
> Could you please you or Patrick MFC the above commits?
>
>
So from HardenedBSD's point of view, we don't care about these MFCs,
because we already MFCd them, but from FreeBSD users PoV it would be nice
to get in at least before the next 11.X release...

This was my last mail in this context.

Have a better day. ;)



> >
> > /bz
> >
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

[Oliver Pinter]

On 8/3/18, Bjoern A. Zeeb  wrote:
> On 3 Aug 2018, at 20:42, Oliver Pinter wrote:
>
>> On 8/3/18, Bjoern A. Zeeb  wrote:
>>> On 3 Aug 2018, at 18:48, Oliver Pinter wrote:
>>>
>>>> Hi all!
>>>>
>>>> One of out users observed an VNET related kernel panic with epairs
>>>> in
>>>> a jail. Seems like some of the
>>>
>>> Well would be great for a start to (a) email virtualisation@ as well,
>>> (b) include a panic message, backtrace or other related information
>>> to
>>> deduce anything about the possible bug, (c) and not to conflate it
>>> with
>>> another totally unrelated MFC request.
>>>
>>> So what makes you think it’s related to tcp fast open?
>>
>> Every required detail is in HardenedBSD's github issue, but I copy the
>> kernel panic here:
>
> Ah sorry my bad;  the issue said ZFS in the subject and I thought it
> refers to something else.
>
> Thanks! Looking at the backtrace it seems it is happening on teardown
> and not on startup but indeed in the fast open code and that PR 216613
> indeed fixed this in head, good :)  Hope Patrick will do the mfc for
> you.

Hi!

Could you please you or Patrick MFC the above commits?

>
> /bz
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

[Bjoern A. Zeeb]

On 3 Aug 2018, at 20:42, Oliver Pinter wrote:


On 8/3/18, Bjoern A. Zeeb  wrote:

On 3 Aug 2018, at 18:48, Oliver Pinter wrote:


Hi all!

One of out users observed an VNET related kernel panic with epairs 
in

a jail. Seems like some of the


Well would be great for a start to (a) email virtualisation@ as well,
(b) include a panic message, backtrace or other related information 
to
deduce anything about the possible bug, (c) and not to conflate it 
with

another totally unrelated MFC request.

So what makes you think it’s related to tcp fast open?


Every required detail is in HardenedBSD's github issue, but I copy the
kernel panic here:


Ah sorry my bad;  the issue said ZFS in the subject and I thought it 
refers to something else.


Thanks! Looking at the backtrace it seems it is happening on teardown 
and not on startup but indeed in the fast open code and that PR 216613 
indeed fixed this in head, good :)  Hope Patrick will do the mfc for 
you.


/bz
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

[Oliver Pinter]

On 8/3/18, Bjoern A. Zeeb  wrote:
> On 3 Aug 2018, at 18:48, Oliver Pinter wrote:
>
>> Hi all!
>>
>> One of out users observed an VNET related kernel panic with epairs in
>> a jail. Seems like some of the
>
> Well would be great for a start to (a) email virtualisation@ as well,
> (b) include a panic message, backtrace or other related information to
> deduce anything about the possible bug, (c) and not to conflate it with
> another totally unrelated MFC request.
>
> So what makes you think it’s related to tcp fast open?

Every required detail is in HardenedBSD's github issue, but I copy the
kernel panic here:

Aug  2 17:52:00 test2 syslogd: kernel boot file is /boot/kernel/kernel
Aug  2 17:52:00 test2 kernel: [205] epair3314a: promiscuous mode enabled
Aug  2 17:52:00 test2 kernel: [205] panic: lock 0xfe00078e8fd8 is
not initialized
Aug  2 17:52:00 test2 kernel: [205] cpuid = 0
Aug  2 17:52:00 test2 kernel: [205] __HardenedBSD_version = 1100056
__FreeBSD_version = 1102501
Aug  2 17:52:00 test2 kernel: [205] version = FreeBSD 11.2-STABLE-HBSD
#0 : Thu Aug  2 02:27:22 CEST 2018
Aug  2 17:52:00 test2 kernel: [205] root@hb67:/λ/obj/λ/src/11/sys/VerKnowSys
Aug  2 17:52:00 test2 kernel: [205] KDB: stack backtrace:
Aug  2 17:52:00 test2 kernel: [205] db_trace_self_wrapper() at
db_trace_self_wrapper+0x2b/frame 0xfe011fbed750
Aug  2 17:52:00 test2 kernel: [205] vpanic() at vpanic+0x17c/frame
0xfe011fbed7b0
Aug  2 17:52:00 test2 kernel: [205] doadump() at doadump/frame
0xfe011fbed830
Aug  2 17:52:00 test2 kernel: [205] lock_destroy() at
lock_destroy+0x32/frame 0xfe011fbed850
Aug  2 17:52:00 test2 kernel: [205] rm_destroy() at
rm_destroy+0x33/frame 0xfe011fbed870
Aug  2 17:52:00 test2 kernel: [205] tcp_fastopen_destroy() at
tcp_fastopen_destroy+0x44/frame 0xfe011fbed890
Aug  2 17:52:00 test2 kernel: [205] tcp_destroy() at
tcp_destroy+0x10e/frame 0xfe011fbed8c0
Aug  2 17:52:00 test2 kernel: [205] vnet_destroy() at
vnet_destroy+0x12c/frame 0xfe011fbed8f0
Aug  2 17:52:00 test2 kernel: [205] prison_deref() at
prison_deref+0x29d/frame 0xfe011fbed930
Aug  2 17:52:00 test2 kernel: [205] sys_jail_remove() at
sys_jail_remove+0x28a/frame 0xfe011fbed980
Aug  2 17:52:00 test2 kernel: [205] amd64_syscall() at
amd64_syscall+0x6ae/frame 0xfe011fbedab0
Aug  2 17:52:00 test2 kernel: [205] fast_syscall_common() at
fast_syscall_common+0x101/frame 0xfe011fbedab0
Aug  2 17:52:00 test2 kernel: [205] --- syscall (508, FreeBSD ELF64,
sys_jail_remove), rip = 0x507a3545dba, rsp = 0x68533a501528, rbp =
0x68533a5015a0 ---
Aug  2 17:52:00 test2 kernel: [205] KDB: enter: panic

>
>
> /bz
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: VNET related kernel panic on jail startup with epairs on 11-STABLE

[Bjoern A. Zeeb]

On 3 Aug 2018, at 18:48, Oliver Pinter wrote:


Hi all!

One of out users observed an VNET related kernel panic with epairs in
a jail. Seems like some of the


Well would be great for a start to (a) email virtualisation@ as well, 
(b) include a panic message, backtrace or other related information to 
deduce anything about the possible bug, (c) and not to conflate it with 
another totally unrelated MFC request.


So what makes you think it’s related to tcp fast open?


/bz
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

VNET related kernel panic on jail startup with epairs on 11-STABLE

[Oliver Pinter]

Hi all!

One of out users observed an VNET related kernel panic with epairs in
a jail. Seems like some of the
vnet related patches does not gets backported to 11-STABLE (they are
marked as MFC candidate):
SVN r33 and r313168, these are for the panic fix.

https://github.com/HardenedBSD/hardenedBSD/issues/325

https://github.com/HardenedBSD/hardenedBSD/commit/acbbc549618ac96dd2dd461429558f6cf135e31a
https://github.com/HardenedBSD/hardenedBSD/commit/6c91473476ff712b71b6a9b25afa162fa15a5d23

The other nice to have commit would be the r333885 commit, to fix
ctfconvert related build errors.

https://github.com/HardenedBSD/hardenedBSD/commit/3895dd38ecf4dc422d3e1656844a051e0aa5d06c

Thanks,
Oliver
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

11.2-RC1-i386-bootonly.iso new install kernel panic - solved?

[CenturyLink Customer]

I installed a 11.2-RC1-i386-bootonly.iso on a Pentium 4 desktop test 
system.There was a double kernel panic, followed by a single kernel panic.On a 
manual poweroff/power-on (reboot) I edited both:/boot/loader.conf with the 
code: i915_load="YES"and/etc/rc.conf with code: kld_list="i915kms".Following 
editing the files, the system boots okay.(There are some drm messages, 
though.)- cksalexan...@q.com
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 11.2-BETA3 Kernel Panic (Page Fault) when loading kernel module "vboxdrv.ko"

[Kevin Oberman]

See my response of a few minutes ago the another report of this issue.

Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD 11.2-BETA3 Kernel Panic (Page Fault) when loading kernel module "vboxdrv.ko"

[Neo_Chen]

Caused by KBI change (Does not kernel panic after rebuild)
This problem is reproducible

System: FreeBSD 11.2-BETA3
Runs on: Oracle VirtualBox
dmesg: (recorded with script(1) + telnet(1))

===|cut here|===
Script started on Thu May 31 19:49:21 2018
Command: telnet localhost 4997
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.2-BETA3 #0 r334196: Fri May 25 05:32:45 UTC 2018
    r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on 
LLVM 6.0.0)

VT(efifb): resolution 1024x768
CPU: Intel(R) Core(TM) i5-4210Y CPU @ 1.50GHz (1496.61-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x40651  Family=0x6  Model=0x45 Stepping=1
Features=0x783fbff
Features2=0x5eda220b
  AMD Features=0x28100800
  AMD Features2=0x21
  Structured Extended Features=0x2421
  TSC: P-state invariant
real memory  = 1073479680 (1023 MB)
avail memory = 994013184 (947 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
ioapic0: Changing APIC ID to 1
ioapic0  irqs 0-23 on motherboard
Timecounter "TSC" frequency 1496606870 Hz quality 1000
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x80ff4540, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
nexus0
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 
on acpi0

Timecounter "HPET" frequency 14318180 Hz quality 950
cpu0:  on acpi0
attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x71 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  mem 0x8000-0x80ff at device 
2.0 on pci0

vgapci0: Boot video device
em0:  port 
0xc180-0xc187 mem 0x8140-0x8141 irq 19 at device 3.0 on pci0

em0: Ethernet address: 08:00:27:5e:70:df
em0: netmap queues/slots: TX 1/256, RX 1/256
pcm0:  port 0xc000-0xc0ff,0xc100-0xc13f irq 21 at 
device 5.0 on pci0

pcm0: 
pci0:  at device 7.0 (no driver attached)
isab0:  at device 31.0 on pci0
isa0:  on isab0
ahci0:  port 
0xc178-0xc17f,0xc18c-0xc18f,0xc170-0xc177,0xc188-0xc18b,0xc160-0xc16f 
mem 0x81424000-0x81425fff at device 31.2 on pci0

ahci0: Failed to allocate MSI/MSI-x, falling back to INTx
ahci0: AHCI v1.10 with 2 3Gbps ports, Port Multiplier not supported
ahcich0:  at channel 0 on ahci0
ahcich1:  at channel 1 on ahci0
ohci0:  mem 
0x81426000-0x81426fff at device 31.4 on pci0

usbus0 on ohci0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (115200,n,8,1)
acpi_acad0:  on acpi0
atkbdc0:  port 0x60,0x64 irq 1 on acpi0
atkbd0:  irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0:  irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model IntelliMouse Explorer, device ID 4
orm0:  at iomem 0xc-0xc7fff on isa0
ppc0: cannot reserve I/O port range
Timecounters tick every 10.000 msec
pcm0: measured ac97 link rate at 77035 Hz
usbus0: 12Mbps Full Speed USB v1.0
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0:  ATA-6 SATA 2.x device
ada0: Serial Number VB5418cc6c-20aa28bc
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 16384MB (33554432 512 byte sectors)
ugen0.1:  at usbus0
uhub0:  on usbus0
cd0 at ahcich0 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SPC-3 SCSI device
cd0: Serial Number VB0-1a2b3c4d
cd0: 300.000MB/s transfers (SATA 2.x, UDMA6, ATAPI 12bytes, PIO 8192bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
Trying to mount root from ufs:/dev/ada0p2 [rw]...
Setting hostuuid: c60b9c00-49a8-47b0-89b3-332b9620fa47.
Setting hostid: 0xe919aad2.
Starting file system checks:
/dev/ada0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ada0p2: clean, 3522780 free (460 frags, 440290 blocks, 0.0% 
fragmentation)

Mounting local filesystems:.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat
random: unblocking device.
32-bit compatibility ldconfig path: /usr/lib32
Setting hostname: TEST_KERNEL_PANIC.
Setting up harvesting: 
[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED

Feeding entropy: uhub0: 12 ports with 12 removable, self powered
.
em0: link state ch

Re: Kernel Panic of 10.2-RELEASE

[Stéphane Dupille via freebsd-stable]

> Le 18 juil. 2017 à 18:47, Daniel Genis  a écrit :
> 
> Hello, 

Hello,

> Take a look at this commit: https://github.com/freebsd/freebsd/commit/d99ba5c
> It might be the issue you're encountering. 

Yes, it is. Here ’s the corresponding PR : 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207464

If I understand comments correctly, we have the same issue in 10.3 as well. So 
the solution is to avoid destroy snapshots, or upgrade to 11.0. Or patch the 
kernel myself.

Thanks.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel Panic of 10.2-RELEASE

[Daniel Genis]

Hello, 

Take a look at this commit: https://github.com/freebsd/freebsd/commit/d99ba5c

It might be the issue you're encountering. 

With kind regards, 

Daniel

On 18 July 2017 18:33:02 CEST, "Stéphane Dupille via freebsd-stable" 
<freebsd-stable@freebsd.org> wrote:
>Hello,
>
>My server is running 10.2-RELEASE (yes, I need to upgrade it, but it
>works like a charm). Today, I launched this command, as root :
># zfs destroy -r zroot@attic
>and the machine crashed :
>
>Jul 18 18:09:40 penitencier syslogd: kernel boot file is
>/boot/kernel/kernel
>Jul 18 18:09:40 penitencier kernel: vputx: negative ref count
>Jul 18 18:09:40 penitencier kernel: 0xf8023037f000: tag zfs, type
>VDIR
>Jul 18 18:09:40 penitencier kernel: usecount 0, writecount 0, refcount
>0 mountedhere 0
>Jul 18 18:09:40 penitencier kernel: flags (VI_FREE)
>Jul 18 18:09:40 penitencier kernel: VI_LOCKedlock type zfs: EXCL by
>thread 0xf8014f242940 (pid 60698, zfs, tid 100747)
>Jul 18 18:09:40 penitencier kernel: panic: vputx: negative ref cnt
>Jul 18 18:09:40 penitencier kernel: cpuid = 1
>Jul 18 18:09:40 penitencier kernel: KDB: stack backtrace:
>Jul 18 18:09:40 penitencier kernel: #0 0x80984ef0 at
>kdb_backtrace+0x60
>Jul 18 18:09:40 penitencier kernel: #1 0x80948aa6 at
>vpanic+0x126
>Jul 18 18:09:40 penitencier kernel: #2 0x80948973 at panic+0x43
>Jul 18 18:09:40 penitencier kernel: #3 0x809eb7d5 at
>vputx+0x2d5
>Jul 18 18:09:40 penitencier kernel: #4 0x809e4f59 at
>dounmount+0x689
>Jul 18 18:09:40 penitencier kernel: #5 0x81a5fdd4 at
>zfs_unmount_snap+0x114
>Jul 18 18:09:40 penitencier kernel: #6 0x81a62fc1 at
>zfs_ioc_destroy_snaps+0xc1
>Jul 18 18:09:40 penitencier kernel: #7 0x81a61ae0 at
>zfsdev_ioctl+0x5f0
>Jul 18 18:09:40 penitencier kernel: #8 0x80830019 at
>devfs_ioctl_f+0x139
>Jul 18 18:09:40 penitencier kernel: #9 0x8099cde5 at
>kern_ioctl+0x255
>Jul 18 18:09:40 penitencier kernel: #10 0x8099cae0 at
>sys_ioctl+0x140
>Jul 18 18:09:40 penitencier kernel: #11 0x80d4b3e7 at
>amd64_syscall+0x357
>Jul 18 18:09:40 penitencier kernel: #12 0x80d30acb at
>Xfast_syscall+0xfb
>Jul 18 18:09:40 penitencier kernel: Uptime: 5d6h0m11s
>
>This is all I found in logs. I have only a remote access to this
>machine so I have no clue of what was printed on console.
>
>I use zfs on top of geom_eli.
>
>Here is a uname -v :
>FreeBSD penitencier.dalton-brothers.org 10.2-RELEASE-p9 FreeBSD
>10.2-RELEASE-p9 #0: Thu Jan 14 01:32:46 UTC 2016
>r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>
>After rebooting, the machine works well, as far as I can see :
>root@penitencier:/var/log # zpool status
>  pool: zboot
> state: ONLINE
>scan: scrub repaired 0 in 0h0m with 0 errors on Wed Nov 12 11:20:33
>2014
>config:
>
>   NAME   STATE READ WRITE CKSUM
>   zboot  ONLINE   0 0 0
> mirror-0 ONLINE   0 0 0
>   gpt/boot0  ONLINE   0 0 0
>   gpt/boot1  ONLINE   0 0 0
>
>errors: No known data errors
>
>  pool: zroot
> state: ONLINE
>scan: resilvered 6,56M in 0h0m with 0 errors on Tue Jul 18 18:13:23
>2017
>config:
>
>   NAME   STATE READ WRITE CKSUM
>   zroot  ONLINE   0 0 0
> mirror-0 ONLINE   0 0 0
>   da0p4.eli  ONLINE   0 0 0
>   da1p4.eli  ONLINE   0 0 0
>
>errors: No known data errors
>
>
>(the pool has been resilvered because I boot once, but put a wrong
>passphrase in geli for one of the two drives, so it booted with only
>one disk)
>
>What should I do now ? launch a zfs scrub ? I’m a bit afraid of making
>it panic again. Should I consider that I got unlucky once ?
>(please don’t tell me to upgrade it : I’m currently trying to install a
>new server, and I will migrate to it very soon).
>
>Thanks.
>
>___
>freebsd-stable@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to
>"freebsd-stable-unsubscr...@freebsd.org"

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Kernel Panic of 10.2-RELEASE

[Stéphane Dupille via freebsd-stable]

Hello,

My server is running 10.2-RELEASE (yes, I need to upgrade it, but it works like 
a charm). Today, I launched this command, as root :
# zfs destroy -r zroot@attic
and the machine crashed :

Jul 18 18:09:40 penitencier syslogd: kernel boot file is /boot/kernel/kernel
Jul 18 18:09:40 penitencier kernel: vputx: negative ref count
Jul 18 18:09:40 penitencier kernel: 0xf8023037f000: tag zfs, type VDIR
Jul 18 18:09:40 penitencier kernel: usecount 0, writecount 0, refcount 0 
mountedhere 0
Jul 18 18:09:40 penitencier kernel: flags (VI_FREE)
Jul 18 18:09:40 penitencier kernel: VI_LOCKedlock type zfs: EXCL by thread 
0xf8014f242940 (pid 60698, zfs, tid 100747)
Jul 18 18:09:40 penitencier kernel: panic: vputx: negative ref cnt
Jul 18 18:09:40 penitencier kernel: cpuid = 1
Jul 18 18:09:40 penitencier kernel: KDB: stack backtrace:
Jul 18 18:09:40 penitencier kernel: #0 0x80984ef0 at kdb_backtrace+0x60
Jul 18 18:09:40 penitencier kernel: #1 0x80948aa6 at vpanic+0x126
Jul 18 18:09:40 penitencier kernel: #2 0x80948973 at panic+0x43
Jul 18 18:09:40 penitencier kernel: #3 0x809eb7d5 at vputx+0x2d5
Jul 18 18:09:40 penitencier kernel: #4 0x809e4f59 at dounmount+0x689
Jul 18 18:09:40 penitencier kernel: #5 0x81a5fdd4 at 
zfs_unmount_snap+0x114
Jul 18 18:09:40 penitencier kernel: #6 0x81a62fc1 at 
zfs_ioc_destroy_snaps+0xc1
Jul 18 18:09:40 penitencier kernel: #7 0x81a61ae0 at zfsdev_ioctl+0x5f0
Jul 18 18:09:40 penitencier kernel: #8 0x80830019 at devfs_ioctl_f+0x139
Jul 18 18:09:40 penitencier kernel: #9 0x8099cde5 at kern_ioctl+0x255
Jul 18 18:09:40 penitencier kernel: #10 0x8099cae0 at sys_ioctl+0x140
Jul 18 18:09:40 penitencier kernel: #11 0x80d4b3e7 at 
amd64_syscall+0x357
Jul 18 18:09:40 penitencier kernel: #12 0x80d30acb at Xfast_syscall+0xfb
Jul 18 18:09:40 penitencier kernel: Uptime: 5d6h0m11s

This is all I found in logs. I have only a remote access to this machine so I 
have no clue of what was printed on console.

I use zfs on top of geom_eli.

Here is a uname -v :
FreeBSD penitencier.dalton-brothers.org 10.2-RELEASE-p9 FreeBSD 10.2-RELEASE-p9 
#0: Thu Jan 14 01:32:46 UTC 2016 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

After rebooting, the machine works well, as far as I can see :
root@penitencier:/var/log # zpool status
  pool: zboot
 state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Wed Nov 12 11:20:33 2014
config:

NAME   STATE READ WRITE CKSUM
zboot  ONLINE   0 0 0
  mirror-0 ONLINE   0 0 0
gpt/boot0  ONLINE   0 0 0
gpt/boot1  ONLINE   0 0 0

errors: No known data errors

  pool: zroot
 state: ONLINE
  scan: resilvered 6,56M in 0h0m with 0 errors on Tue Jul 18 18:13:23 2017
config:

NAME   STATE READ WRITE CKSUM
zroot  ONLINE   0 0 0
  mirror-0 ONLINE   0 0 0
da0p4.eli  ONLINE   0 0 0
da1p4.eli  ONLINE   0 0 0

errors: No known data errors


(the pool has been resilvered because I boot once, but put a wrong passphrase 
in geli for one of the two drives, so it booted with only one disk)

What should I do now ? launch a zfs scrub ? I’m a bit afraid of making it panic 
again. Should I consider that I got unlucky once ?
(please don’t tell me to upgrade it : I’m currently trying to install a new 
server, and I will migrate to it very soon).

Thanks.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

11.1-RC1 kernel panic (zfs recv)

[John Kennedy]

I've had a kernel crash with 3 different RC1 kernels.

kernel: FreeBSD 11.1-RC1 #71 r313908+b08656c3ba28(releng/11.1): Sun Jul  2 
23:15:23 PDT 2017
kernel: FreeBSD 11.1-RC1 #72 r313908+64e0abde4c70(releng/11.1): Mon Jul  3 
07:43:42 PDT 2017
kernel: FreeBSD 11.1-RC1 #73 r313908+ff3a058c4f83(releng/11.1): Mon Jul  3 
11:56:29 PDT 2017

# kldstat
Id Refs AddressSize Name
 1   42 0x8020 1f67128  kernel
 21 0x82169000 3161c0   zfs.ko
 32 0x8248 c9e8 opensolaris.ko
 41 0x8248d000 21c68geom_eli.ko
 51 0x824af000 bc68 aesni.ko
 61 0x824bb000 114f58   nvidia-modeset.ko
 73 0x825d ab7f8linux.ko
 83 0x8267c000 ddc0 linux_common.ko
 92 0x8268a000 1056708  nvidia.ko
101 0x83821000 3602 ums.ko
111 0x83825000 3c35clinux64.ko
121 0x83862000 eb0d iscsi.ko

Excuse human-induced typos in stack-trace:

panic: avl_find() succeeded inside avl_add()
cpuid=5
KDB: stack backgrace:
#0 0x80aad9c7 at kdb_backtrace+0x67
#1 0x80a6baa6 at vpanic+0x186
#2 0x80a6b913 at panic+0x43
#3 0x82169df4 at avl_add+0x134
#4 0x821a9bed at dmu_recv_end+0x16d
#5 0x82231e0f at zfs_ioc_recv+0xb1f
#6 0x82233c36 at zfsdev_ioctl+0x6d6
#7 0x8093ad38 at devfs_ioctl_f+0x128
#8 0x80ac9315 at kern_ioctl+0x255
#9 0x80ac904f at sys_ioctl+0x16f
#10 0x80ee0394 at amd64_syscall+0x6c4
#11 0x80ec35cb at Xfast_syscall+0xfb

It is reproducible.  Initially saw it with zfs send | zfs recv (kernel #71),
reproduced outside of X so I could see the panic, installed kernel #72 to be
more current (had it compiled but not installed since I was doing lots of I/O).
Didn't happen with zfs send to file, happened on zfs recv from file, grabbed
#73 since it looked like it might apply since I have a da* via ISCSI, and
can still reproduce the problem.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic

[Kevin Oberman]

On Wed, Jun 21, 2017 at 2:10 PM, Efraín Déctor <efraindec...@motumweb.com>
wrote:

> Hello.
>
> I found that link too, however gjournal is disabled on all of my
> filesystems, apart from that I only have trim enabled on one of my
> filesystem but when the error happened I was writing on another filesystem.
>
> Maybe WinSCP did something that FreeBSD didnt like, I am really clueless
> about this error.
>
> If it happens again I am going to update this system like you guys have
> been suggesting.
>
> Thank you very much for your help.
>
>
> El 21/06/2017 a las 03:18 p. m., Holger Kipp escribió:
>
>> I only found the following reference:
>>
>> https://forums.freebsd.org/threads/37824/
>>
>> which contains some additional links and references, especially regarding
>> journaling and softupdates, for your error message.
>>
>> Maybe this is helpful in your case?
>>
>> Apart from that - checking if the error is still there on a supported
>> more current version like 10.3 or 11 might indeed be the better option.
>>
>> Best regards,
>> Holger
>>
>> On 21. Jun 2017, at 21:56, Steven Hartland <kill...@multiplay.co.uk> o:kill...@multiplay.co.uk>> wrote:
>>
>> Given how old 9.1 is, even if you did investigate its unlikely it would
>> get fixed.
>>
>> I'd recommend updating to 11.0-RELEASE and see if the panic still happens.
>>
>> On 21/06/2017 17:35, Efraín Déctor wrote:
>> Hello.
>>
>> Today one of my servers crashed with a kernel panic. I got this message:
>>
>> panic: cancel_mkdir_dotdot: Lost inodedep
>>
>> I was just moving some files using WinSCP and then the server crashed.
>>
>> How can I trace the root of the problem?. I check and the raid seems to
>> be ok:
>>
>> mfi0 Volumes:
>>   Id SizeLevel   Stripe  State   Cache   Name
>> mfid0 (  278G) RAID-1  64k OPTIMAL Disabled 
>> mfid1 ( 1905G) RAID-1  64k OPTIMAL Disabled 
>>
>> Thanks in advance.
>>
>> uname -a
>> FreeBSD server 9.1-RELEASE-p22 FreeBSD 9.1-RELEASE-p22 #0: Mon Nov  3
>> 18:22:10 UTC 2014 r...@amd64-builder.daemonology.net<mailto:root@amd64-
>> builder.daemonology.net>:/usr/obj/usr/src/sys/GENERIC amd64
>>
>> ___
>>
>>
>>
>> Diplom-Mathematiker
>> Holger Kipp
>> Senior Consultant   [When logistics needs SAP competence] <
>> https://www.alogis.com/>
>>
>> Fon: +49 30 436 58 114
>> Fax: +49 30 436 58 214
>> Mobil:?+49 178 36 58 114
>>  alogis AG
>> Alt-Moabit 90 B
>> 10559 Berlin
>>
>>
>> holger.k...@alogis.com  www.alogis.com<http://www.alogis.com/>
>>
>> alogis AG
>> Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484
>> Vorstand: Arne Friedrichs, Joern Samuelson
>> Aufsichtsratsvorsitzender: Dr. Christian Volkmann
>>
>> [Besuchen Sie uns auf dem SAP EAM 2017 vom 27. - 28. Juni, Potsdam!]<
>> https://www.alogis.com>
>
>
This is probably not the issue, but I have had consistent issues using scp
and sftp to copy files to FUSE based file systems (or, possibly, just
NTFS). I have not had any issues with copies to/from UFS2 systems. I'm
guessing that your local file system is UFS2 or it would have been
mentioned. I should also mention that FUSE has had at least two versions
released since I had the problems. It's not something I do often and far
less often since I moved one of the file systems, the one I most commonly
used, to UFS2.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic

[Efraín Déctor]

Hello.

I found that link too, however gjournal is disabled on all of my 
filesystems, apart from that I only have trim enabled on one of my 
filesystem but when the error happened I was writing on another filesystem.


Maybe WinSCP did something that FreeBSD didnt like, I am really clueless 
about this error.


If it happens again I am going to update this system like you guys have 
been suggesting.


Thank you very much for your help.


El 21/06/2017 a las 03:18 p. m., Holger Kipp escribió:

I only found the following reference:

https://forums.freebsd.org/threads/37824/

which contains some additional links and references, especially regarding 
journaling and softupdates, for your error message.

Maybe this is helpful in your case?

Apart from that - checking if the error is still there on a supported more 
current version like 10.3 or 11 might indeed be the better option.

Best regards,
Holger

On 21. Jun 2017, at 21:56, Steven Hartland 
<kill...@multiplay.co.uk<mailto:kill...@multiplay.co.uk>> wrote:

Given how old 9.1 is, even if you did investigate its unlikely it would get 
fixed.

I'd recommend updating to 11.0-RELEASE and see if the panic still happens.

On 21/06/2017 17:35, Efraín Déctor wrote:
Hello.

Today one of my servers crashed with a kernel panic. I got this message:

panic: cancel_mkdir_dotdot: Lost inodedep

I was just moving some files using WinSCP and then the server crashed.

How can I trace the root of the problem?. I check and the raid seems to be ok:

mfi0 Volumes:
  Id SizeLevel   Stripe  State   Cache   Name
mfid0 (  278G) RAID-1  64k OPTIMAL Disabled 
mfid1 ( 1905G) RAID-1  64k OPTIMAL Disabled 

Thanks in advance.

uname -a
FreeBSD server 9.1-RELEASE-p22 FreeBSD 9.1-RELEASE-p22 #0: Mon Nov  3 18:22:10 UTC 
2014 
r...@amd64-builder.daemonology.net<mailto:r...@amd64-builder.daemonology.net>:/usr/obj/usr/src/sys/GENERIC
 amd64

___



Diplom-Mathematiker
Holger Kipp
Senior Consultant   [When logistics needs SAP competence] 
<https://www.alogis.com/>

Fon: +49 30 436 58 114
Fax: +49 30 436 58 214
Mobil:?+49 178 36 58 114
 alogis AG
Alt-Moabit 90 B
10559 Berlin


holger.k...@alogis.com  www.alogis.com<http://www.alogis.com/>

alogis AG
Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484
Vorstand: Arne Friedrichs, Joern Samuelson
Aufsichtsratsvorsitzender: Dr. Christian Volkmann

[Besuchen Sie uns auf dem SAP EAM 2017 vom 27. - 28. Juni, 
Potsdam!]<https://www.alogis.com>


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic

[Holger Kipp]

I only found the following reference:

https://forums.freebsd.org/threads/37824/

which contains some additional links and references, especially regarding 
journaling and softupdates, for your error message.

Maybe this is helpful in your case?

Apart from that - checking if the error is still there on a supported more 
current version like 10.3 or 11 might indeed be the better option.

Best regards,
Holger

On 21. Jun 2017, at 21:56, Steven Hartland 
<kill...@multiplay.co.uk<mailto:kill...@multiplay.co.uk>> wrote:

Given how old 9.1 is, even if you did investigate its unlikely it would get 
fixed.

I'd recommend updating to 11.0-RELEASE and see if the panic still happens.

On 21/06/2017 17:35, Efraín Déctor wrote:
Hello.

Today one of my servers crashed with a kernel panic. I got this message:

panic: cancel_mkdir_dotdot: Lost inodedep

I was just moving some files using WinSCP and then the server crashed.

How can I trace the root of the problem?. I check and the raid seems to be ok:

mfi0 Volumes:
 Id SizeLevel   Stripe  State   Cache   Name
mfid0 (  278G) RAID-1  64k OPTIMAL Disabled 
mfid1 ( 1905G) RAID-1  64k OPTIMAL Disabled 

Thanks in advance.

uname -a
FreeBSD server 9.1-RELEASE-p22 FreeBSD 9.1-RELEASE-p22 #0: Mon Nov  3 18:22:10 
UTC 2014 
r...@amd64-builder.daemonology.net<mailto:r...@amd64-builder.daemonology.net>:/usr/obj/usr/src/sys/GENERIC
 amd64

___



Diplom-Mathematiker
Holger Kipp
Senior Consultant   [When logistics needs SAP competence] 
<https://www.alogis.com/>

Fon: +49 30 436 58 114
Fax: +49 30 436 58 214
Mobil:?+49 178 36 58 114
alogis AG
Alt-Moabit 90 B
10559 Berlin


holger.k...@alogis.com  www.alogis.com<http://www.alogis.com/>

alogis AG
Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484
Vorstand: Arne Friedrichs, Joern Samuelson
Aufsichtsratsvorsitzender: Dr. Christian Volkmann

[Besuchen Sie uns auf dem SAP EAM 2017 vom 27. - 28. Juni, 
Potsdam!]<https://www.alogis.com>


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic

[Steven Hartland]

Given how old 9.1 is, even if you did investigate its unlikely it would 
get fixed.


I'd recommend updating to 11.0-RELEASE and see if the panic still happens.

On 21/06/2017 17:35, Efraín Déctor wrote:

Hello.

Today one of my servers crashed with a kernel panic. I got this message:

panic: cancel_mkdir_dotdot: Lost inodedep

I was just moving some files using WinSCP and then the server crashed.

How can I trace the root of the problem?. I check and the raid seems 
to be ok:


mfi0 Volumes:
  Id SizeLevel   Stripe  State   Cache   Name
 mfid0 (  278G) RAID-1  64k OPTIMAL Disabled 
 mfid1 ( 1905G) RAID-1  64k OPTIMAL Disabled 

Thanks in advance.

uname -a
FreeBSD server 9.1-RELEASE-p22 FreeBSD 9.1-RELEASE-p22 #0: Mon Nov  3 
18:22:10 UTC 2014 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Kernel panic

[Efraín Déctor]

Hello.

Today one of my servers crashed with a kernel panic. I got this message:

panic: cancel_mkdir_dotdot: Lost inodedep

I was just moving some files using WinSCP and then the server crashed.

How can I trace the root of the problem?. I check and the raid seems to 
be ok:


mfi0 Volumes:
  Id SizeLevel   Stripe  State   Cache   Name
 mfid0 (  278G) RAID-1  64k OPTIMAL Disabled 
 mfid1 ( 1905G) RAID-1  64k OPTIMAL Disabled 

Thanks in advance.

uname -a
FreeBSD server 9.1-RELEASE-p22 FreeBSD 9.1-RELEASE-p22 #0: Mon Nov  3 
18:22:10 UTC 2014 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic in smp rendezvous

[Olivier Cinquin]

> On May 11, 2017, at 3:01 AM, Konstantin Belousov  wrote:
> 
> On Wed, May 10, 2017 at 03:29:39PM -0700, Olivier Cinquin wrote:
>> Hi,
>> I'm getting the following kernel panics on recent 11-STABLE (r317883):
>> 
>> spin lock 0x81df43d0 (smp rendezvous) held by 0xf8019c7a7000 
>> (tid 100845) too long
>> timeout stopping cpus
>> panic: spin lock held too long
>> cpuid = 12
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> 0xfe3e64caf2a0
>> vpanic() at vpanic+0x186/frame 0xfe3e64caf320
>> panic() at panic+0x43/frame 0xfe3e64caf380
>> _mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x311/frame 
>> 0xfe3e64caf3f0
>> smp_targeted_tlb_shootdown() at smp_targeted_tlb_shootdown+0x101/frame 
>> 0xfe3e64caf470
>> smp_masked_invlpg_range() at smp_masked_invlpg_range+0x50/frame 
>> 0xfe3e64caf4a0
>> pmap_invalidate_range() at pmap_invalidate_range+0x196/frame 
>> 0xfe3e64caf4e0
>> vm_thread_stack_dispose() at vm_thread_stack_dispose+0x2f/frame 
>> 0xfe3e64caf530
>> thread_free() at thread_free+0x39/frame 0xfe3e64caf550
>> thread_reap() at thread_reap+0x10e/frame 0xfe3e64caf570
>> proc_reap() at proc_reap+0x6bd/frame 0xfe3e64caf5b0
>> proc_to_reap() at proc_to_reap+0x48c/frame 0xfe3e64caf600
>> kern_wait6() at kern_wait6+0x49e/frame 0xfe3e64caf6b0
>> sys_wait4() at sys_wait4+0x78/frame 0xfe3e64caf8a0
>> amd64_syscall() at amd64_syscall+0x6c4/frame 0xfe3e64cafa30
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe3e64cafa30
>> 
>> 
>> The panics occur sporadically and seemingly randomly. They occur on
>> multiple machines with the same configuration, and on older revisions of
>> 11-STABLE as well as r317883 (I cannot easily bisect this down to a
>> specific commit given that it can take days or sometimes weeks for the
>> panic to occur). Note that my kernel is compiled with "options IPSEC", but
>> that does not seem to be relevant.
>> 
>> My understanding of the overall problem is that an IPI is sent to all cores
>> by smp_rendezvous_cpus, but that some of the cores do not respond to it (or
>> at least do not respond to it correctly and in time). More specifically, I
>> can find 61 threads that seem to be blocked in cpustop_handler on an atomic
>> operation to indicate that they have stopped in response to the IPI. This
>> operation is CPU_SET_ATOMIC(cpu, _cpus); CPU_SET_ATOMIC boils down
>> to a call to "atomic_set_long" (not sure where that is itself defined for
>> amd64). Either there is a line numbering problem, or this suggests that
>> perhaps there is a deadlock at this step (unless there's some sort of
>> livelock and CPU_SET_ATOMIC is the place where the threads spend most of
>> their time).
>> 
>> Looking at the thread backtraces as a whole, I can see the one that
>> triggered the panic, the 61 that are in cpustop_handler, and a lot of
>> sleeping threads. I guess each core should have an active thread, and this
>> is an architecture with 64 cores, so that leaves 64 - (1 + 61) = 2 cores
>> that are unaccounted for. Interestingly, for 2 different panics for which I
>> have a vmcore file these numbers are the same. For these two panics, the
>> IDs of the cores that are neither in cpustop_handler nor calling the smp
>> rendez vous are not the same (#18 and #19 in one instance, #44 and #45 in
>> the other instance) but in both instances the IDs are consecutive; perhaps
>> that's relevant.
>> 
>> I've uploaded a full set of backtraces at
>> https://gist.github.com/cinquin/d63cdf9de01b0b8033c47128868f2d38 and a
>> dmesg at https://gist.github.com/cinquin/17c0cf6ac7832fd1b683488d08d3e69b
>> (in short, the machine is a 4 processor Opteron 6274 system). I'm pasting 
>> below
>> an example backtrace of the threads in stopcpu_handler.
>> 
>> Any suggestions as to what the problem might be and how to solve it? I've
>> saved the core and can provide further information.
>> 
>> Thanks
>> Olivier Cinquin
>> 
>> A total of 61 threads are along the lines of
>> 
>> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275
>> #1  0x8105a6f5 in ipi_nmi_handler () at 
>> /usr/src/sys/x86/x86/mp_x86.c:1231
>> #2  0x80ef740a in trap (frame=0xfe3e687f7f30) at 
>> /usr/src/sys/amd64/amd64/trap.c:185
>> #3  0x80edbd03 in nmi_calltrap () at 
>> /usr/src/sys/amd64/amd64/exception.S:510
>> ...
>> (kgdb) frame 0
>> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275
>> 1275 CPU_SET_ATOMIC(cpu, _cpus);
>> (kgdb) list
>> 1270 cpu = PCPU_GET(cpuid);
>> 1271 
>> 1272 savectx([cpu]);
>> 1273 
>> 1274 /* Indicate that we are stopped */
>> 1275 CPU_SET_ATOMIC(cpu, _cpus);
>> 1276 
>> 1277 /* Wait for restart */
>> 1278 while (!CPU_ISSET(cpu, _cpus))
>> 1279 ia32_pause();
>> (kgdb) p stopped_cpus
>> $1 = {__bits = 0x81df4368}
>> (kgdb) p started_cpus
>> $2 = {__bits = 0x81df4418}
>> 
> 

Re: Kernel panic in smp rendezvous

[Konstantin Belousov]

On Wed, May 10, 2017 at 03:29:39PM -0700, Olivier Cinquin wrote:
> Hi,
> I'm getting the following kernel panics on recent 11-STABLE (r317883):
> 
> spin lock 0x81df43d0 (smp rendezvous) held by 0xf8019c7a7000 (tid 
> 100845) too long
> timeout stopping cpus
> panic: spin lock held too long
> cpuid = 12
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe3e64caf2a0
> vpanic() at vpanic+0x186/frame 0xfe3e64caf320
> panic() at panic+0x43/frame 0xfe3e64caf380
> _mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x311/frame 
> 0xfe3e64caf3f0
> smp_targeted_tlb_shootdown() at smp_targeted_tlb_shootdown+0x101/frame 
> 0xfe3e64caf470
> smp_masked_invlpg_range() at smp_masked_invlpg_range+0x50/frame 
> 0xfe3e64caf4a0
> pmap_invalidate_range() at pmap_invalidate_range+0x196/frame 
> 0xfe3e64caf4e0
> vm_thread_stack_dispose() at vm_thread_stack_dispose+0x2f/frame 
> 0xfe3e64caf530
> thread_free() at thread_free+0x39/frame 0xfe3e64caf550
> thread_reap() at thread_reap+0x10e/frame 0xfe3e64caf570
> proc_reap() at proc_reap+0x6bd/frame 0xfe3e64caf5b0
> proc_to_reap() at proc_to_reap+0x48c/frame 0xfe3e64caf600
> kern_wait6() at kern_wait6+0x49e/frame 0xfe3e64caf6b0
> sys_wait4() at sys_wait4+0x78/frame 0xfe3e64caf8a0
> amd64_syscall() at amd64_syscall+0x6c4/frame 0xfe3e64cafa30
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe3e64cafa30
> 
> 
> The panics occur sporadically and seemingly randomly. They occur on
> multiple machines with the same configuration, and on older revisions of
> 11-STABLE as well as r317883 (I cannot easily bisect this down to a
> specific commit given that it can take days or sometimes weeks for the
> panic to occur). Note that my kernel is compiled with "options IPSEC", but
> that does not seem to be relevant.
> 
> My understanding of the overall problem is that an IPI is sent to all cores
> by smp_rendezvous_cpus, but that some of the cores do not respond to it (or
> at least do not respond to it correctly and in time). More specifically, I
> can find 61 threads that seem to be blocked in cpustop_handler on an atomic
> operation to indicate that they have stopped in response to the IPI. This
> operation is CPU_SET_ATOMIC(cpu, _cpus); CPU_SET_ATOMIC boils down
> to a call to "atomic_set_long" (not sure where that is itself defined for
> amd64). Either there is a line numbering problem, or this suggests that
> perhaps there is a deadlock at this step (unless there's some sort of
> livelock and CPU_SET_ATOMIC is the place where the threads spend most of
> their time).
> 
> Looking at the thread backtraces as a whole, I can see the one that
> triggered the panic, the 61 that are in cpustop_handler, and a lot of
> sleeping threads. I guess each core should have an active thread, and this
> is an architecture with 64 cores, so that leaves 64 - (1 + 61) = 2 cores
> that are unaccounted for. Interestingly, for 2 different panics for which I
> have a vmcore file these numbers are the same. For these two panics, the
> IDs of the cores that are neither in cpustop_handler nor calling the smp
> rendez vous are not the same (#18 and #19 in one instance, #44 and #45 in
> the other instance) but in both instances the IDs are consecutive; perhaps
> that's relevant.
> 
> I've uploaded a full set of backtraces at
> https://gist.github.com/cinquin/d63cdf9de01b0b8033c47128868f2d38 and a
> dmesg at https://gist.github.com/cinquin/17c0cf6ac7832fd1b683488d08d3e69b
> (in short, the machine is a 4 processor Opteron 6274 system). I'm pasting 
> below
> an example backtrace of the threads in stopcpu_handler.
> 
> Any suggestions as to what the problem might be and how to solve it? I've
> saved the core and can provide further information.
> 
> Thanks
> Olivier Cinquin
> 
> A total of 61 threads are along the lines of
> 
> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275
> #1  0x8105a6f5 in ipi_nmi_handler () at 
> /usr/src/sys/x86/x86/mp_x86.c:1231
> #2  0x80ef740a in trap (frame=0xfe3e687f7f30) at 
> /usr/src/sys/amd64/amd64/trap.c:185
> #3  0x80edbd03 in nmi_calltrap () at 
> /usr/src/sys/amd64/amd64/exception.S:510
> ...
> (kgdb) frame 0
> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275
> 1275  CPU_SET_ATOMIC(cpu, _cpus);
> (kgdb) list
> 1270  cpu = PCPU_GET(cpuid);
> 1271  
> 1272  savectx([cpu]);
> 1273  
> 1274  /* Indicate that we are stopped */
> 1275  CPU_SET_ATOMIC(cpu, _cpus);
> 1276  
> 1277  /* Wait for restart */
> 1278  while (!CPU_ISSET(cpu, _cpus))
> 1279  ia32_pause();
> (kgdb) p stopped_cpus
> $1 = {__bits = 0x81df4368}
> (kgdb) p started_cpus
> $2 = {__bits = 0x81df4418}
> 

It would be interesting to see only the backtraces for threads which are
on CPUs, i.e. all nmi_stop_handler()-threads and others.

>From your description, it looks like that there are 

Re: FreeBSD Vagrant Box Kernel Panic

[Patrick M. Hausen]

Hello,

> Am 10.05.2017 um 21:24 schrieb Robert Simmons :
> It appears that the maintainer of the boxes should create a
> 11.0-RELEASE-p10 box and revoke the -p1 box.

The official Hashicorp boxes have been invoking freebsd-update on startup
for a while, now. So every box automatically updates itself to the latest
patchlevel.

We have started to roll our own boxes, so I'm not perfectly up-to-date.

Patrick


signature.asc
Description: Message signed with OpenPGP

Kernel panic in smp rendezvous

[Olivier Cinquin]

Hi,
I'm getting the following kernel panics on recent 11-STABLE (r317883):

spin lock 0x81df43d0 (smp rendezvous) held by 0xf8019c7a7000 (tid 
100845) too long
timeout stopping cpus
panic: spin lock held too long
cpuid = 12
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe3e64caf2a0
vpanic() at vpanic+0x186/frame 0xfe3e64caf320
panic() at panic+0x43/frame 0xfe3e64caf380
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x311/frame 0xfe3e64caf3f0
smp_targeted_tlb_shootdown() at smp_targeted_tlb_shootdown+0x101/frame 
0xfe3e64caf470
smp_masked_invlpg_range() at smp_masked_invlpg_range+0x50/frame 
0xfe3e64caf4a0
pmap_invalidate_range() at pmap_invalidate_range+0x196/frame 0xfe3e64caf4e0
vm_thread_stack_dispose() at vm_thread_stack_dispose+0x2f/frame 
0xfe3e64caf530
thread_free() at thread_free+0x39/frame 0xfe3e64caf550
thread_reap() at thread_reap+0x10e/frame 0xfe3e64caf570
proc_reap() at proc_reap+0x6bd/frame 0xfe3e64caf5b0
proc_to_reap() at proc_to_reap+0x48c/frame 0xfe3e64caf600
kern_wait6() at kern_wait6+0x49e/frame 0xfe3e64caf6b0
sys_wait4() at sys_wait4+0x78/frame 0xfe3e64caf8a0
amd64_syscall() at amd64_syscall+0x6c4/frame 0xfe3e64cafa30
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe3e64cafa30


The panics occur sporadically and seemingly randomly. They occur on
multiple machines with the same configuration, and on older revisions of
11-STABLE as well as r317883 (I cannot easily bisect this down to a
specific commit given that it can take days or sometimes weeks for the
panic to occur). Note that my kernel is compiled with "options IPSEC", but
that does not seem to be relevant.

My understanding of the overall problem is that an IPI is sent to all cores
by smp_rendezvous_cpus, but that some of the cores do not respond to it (or
at least do not respond to it correctly and in time). More specifically, I
can find 61 threads that seem to be blocked in cpustop_handler on an atomic
operation to indicate that they have stopped in response to the IPI. This
operation is CPU_SET_ATOMIC(cpu, _cpus); CPU_SET_ATOMIC boils down
to a call to "atomic_set_long" (not sure where that is itself defined for
amd64). Either there is a line numbering problem, or this suggests that
perhaps there is a deadlock at this step (unless there's some sort of
livelock and CPU_SET_ATOMIC is the place where the threads spend most of
their time).

Looking at the thread backtraces as a whole, I can see the one that
triggered the panic, the 61 that are in cpustop_handler, and a lot of
sleeping threads. I guess each core should have an active thread, and this
is an architecture with 64 cores, so that leaves 64 - (1 + 61) = 2 cores
that are unaccounted for. Interestingly, for 2 different panics for which I
have a vmcore file these numbers are the same. For these two panics, the
IDs of the cores that are neither in cpustop_handler nor calling the smp
rendez vous are not the same (#18 and #19 in one instance, #44 and #45 in
the other instance) but in both instances the IDs are consecutive; perhaps
that's relevant.

I've uploaded a full set of backtraces at
https://gist.github.com/cinquin/d63cdf9de01b0b8033c47128868f2d38 and a
dmesg at https://gist.github.com/cinquin/17c0cf6ac7832fd1b683488d08d3e69b
(in short, the machine is a 4 processor Opteron 6274 system). I'm pasting below
an example backtrace of the threads in stopcpu_handler.

Any suggestions as to what the problem might be and how to solve it? I've
saved the core and can provide further information.

Thanks
Olivier Cinquin

A total of 61 threads are along the lines of

#0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275
#1  0x8105a6f5 in ipi_nmi_handler () at 
/usr/src/sys/x86/x86/mp_x86.c:1231
#2  0x80ef740a in trap (frame=0xfe3e687f7f30) at 
/usr/src/sys/amd64/amd64/trap.c:185
#3  0x80edbd03 in nmi_calltrap () at 
/usr/src/sys/amd64/amd64/exception.S:510
...
(kgdb) frame 0
#0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1275
1275CPU_SET_ATOMIC(cpu, _cpus);
(kgdb) list
1270cpu = PCPU_GET(cpuid);
1271
1272savectx([cpu]);
1273
1274/* Indicate that we are stopped */
1275CPU_SET_ATOMIC(cpu, _cpus);
1276
1277/* Wait for restart */
1278while (!CPU_ISSET(cpu, _cpus))
1279ia32_pause();
(kgdb) p stopped_cpus
$1 = {__bits = 0x81df4368}
(kgdb) p started_cpus
$2 = {__bits = 0x81df4418}


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD Vagrant Box Kernel Panic

[Robert Simmons]

I was reading the previous thread about the current Vagrant box for FreeBSD
11.0-STABLE on atlas.hashicorp.com. The broken box is still not updated.
Who is the maintainer of these boxes?

On a side note, the reason freebsd/FreeBSD-11.0-RELEASE is revoked is there
is a newer -p1 box:
https://atlas.hashicorp.com/freebsd/boxes/FreeBSD-11.0-RELEASE-p1

It appears that the maintainer of the boxes should create a
11.0-RELEASE-p10 box and revoke the -p1 box.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Kernel panic on production system - what now?

[Eric van Gyzen]

On 03/24/2017 03:28, Patrick M. Hausen wrote:
> Hi all,
> 
> Mar 24 02:39:36 ph001 kernel: kernel trap 12 with interrupts disabled
> Mar 24 02:39:36 ph001 kernel: 
> Mar 24 02:39:36 ph001 kernel: 
> Mar 24 02:39:36 ph001 kernel: Fatal trap 12: page fault while in kernel mode
> Mar 24 02:39:37 ph001 kernel: cpuid = 8; apic id = 08
> Mar 24 02:39:37 ph001 kernel: fault virtual address   = 0x0
> Mar 24 02:39:37 ph001 kernel: fault code  = supervisor read data, 
> page not present
> Mar 24 02:39:37 ph001 kernel: instruction pointer = 
> 0x20:0x809a4330
> 
> I must admit that this is a "first" for me. So where do I go from here?
> There is "stuff" in /var/crash that has got the right timestamps, it seems ...

Start with:

# pkg install gdb
# kgdb712 /boot/kernel/kernel /var/crash/vmcore.0

The "712" above is the GDB version number, so it might be different on your
system.  In GDB:

(gdb) bt full

Post that output to this list, along with "uname -a".

Eric
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Kernel panic on production system - what now?

[Patrick M. Hausen]

Hi all,

Mar 24 02:39:36 ph001 kernel: kernel trap 12 with interrupts disabled
Mar 24 02:39:36 ph001 kernel: 
Mar 24 02:39:36 ph001 kernel: 
Mar 24 02:39:36 ph001 kernel: Fatal trap 12: page fault while in kernel mode
Mar 24 02:39:37 ph001 kernel: cpuid = 8; apic id = 08
Mar 24 02:39:37 ph001 kernel: fault virtual address = 0x0
Mar 24 02:39:37 ph001 kernel: fault code= supervisor read data, 
page not present
Mar 24 02:39:37 ph001 kernel: instruction pointer   = 
0x20:0x809a4330

I must admit that this is a "first" for me. So where do I go from here?
There is "stuff" in /var/crash that has got the right timestamps, it seems ...

Thanks,
Patrick
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: unionfs or tmpfs Kernel Panic on 10.2-BETA1

[David Wolfskill]

On Sat, Jul 18, 2015 at 11:54:59AM -0400, Shawn Webb wrote:
 Looks like there's some locking issues in 10.2-BETA1/amd64. I'm at revision 
 bf2d0b176566519b95f21d01cc101f4b60247ab8 in this repo:
 
 https://github.com/HardenedBSD/hardenedBSD/tree/hardened/experimental/opnsense-10-stable
 
 === Begin Log ===
 Trying to mount root from ufs:/dev/ufs/HardenedBSD_Install [ro,noatime]...
 Mounting filesystems...
 tunefs: soft updates set
 tunefs: file system reloaded
 camcontrol: subcommand identify requires a valid device identifier
 panic: __lockmgr_args: recursing on non recursive lockmgr tmpfs @ 
 /usr/src/sys/kern/vfs_subr.c:2174
 ...
 If there's anything you need from me, please let me know. It's 100% 
 reproducible at bootup on one of my systems.
 ...

I mount /tmp as a tmpfs on all of my FreeBSD systems, and have been
tracking stable/10 daily for some time (ref.
http://www.catwhisker.org/~david/FreeBSD/history/).

I have not seen anything like the above.

I am presently running:

FreeBSD g1-245.catwhisker.org 10.2-BETA2 FreeBSD 10.2-BETA2 #96  
r285668M/285670:1001519: Sat Jul 18 04:07:25 PDT 2015 
r...@g1-245.catwhisker.org:/common/S2/obj/usr/src/sys/CANARY  amd64

on my laptop; on the system where I'm reading  writing mail, it's:

FreeBSD albert.catwhisker.org 10.2-BETA1 FreeBSD 10.2-BETA1 #418  
r285410M/285418:1001519: Sun Jul 12 04:37:35 PDT 2015 
r...@freebeast.catwhisker.org:/common/S2/obj/usr/src/sys/ALBERT  amd64

I am, however, not using unionfs.

I have a test system available, if that might help (e.g., for trying
to reproduce the problem).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpJhWnxU2pWP.pgp
Description: PGP signature

unionfs or tmpfs Kernel Panic on 10.2-BETA1

[Shawn Webb]

Looks like there's some locking issues in 10.2-BETA1/amd64. I'm at revision 
bf2d0b176566519b95f21d01cc101f4b60247ab8 in this repo:

https://github.com/HardenedBSD/hardenedBSD/tree/hardened/experimental/opnsense-10-stable

=== Begin Log ===
Trying to mount root from ufs:/dev/ufs/HardenedBSD_Install [ro,noatime]...
Mounting filesystems...
tunefs: soft updates set
tunefs: file system reloaded
camcontrol: subcommand identify requires a valid device identifier
panic: __lockmgr_args: recursing on non recursive lockmgr tmpfs @ 
/usr/src/sys/kern/vfs_subr.c:2174
cpuid = 1
KDB: enter: panic
[ thread pid 20959 tid 100107 ]
Stopped at  kdb_enter+0x3e: movq$0,kdb_why
db bt
Tracing pid 20959 tid 100107 td 0xf8000668
kdb_enter() at kdb_enter+0x3e/frame 0xfe00fd9c3200
vpanic() at vpanic+0x146/frame 0xfe00fd9c3240
panic() at panic+0x43/frame 0xfe00fd9c32a0
__lockmgr_args() at __lockmgr_args+0x1151/frame 0xfe00fd9c33b0
vop_stdlock() at vop_stdlock+0x3c/frame 0xfe00fd9c33d0
VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe00fd9c3400
_vn_lock() at _vn_lock+0xaa/frame 0xfe00fd9c3470
vget() at vget+0x67/frame 0xfe00fd9c34b0
tmpfs_alloc_vp() at tmpfs_alloc_vp+0x207/frame 0xfe00fd9c3530
tmpfs_lookup() at tmpfs_lookup+0x3d5/frame 0xfe00fd9c3590
VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xf1/frame 0xfe00fd9c35c0
vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfe00fd9c3620
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfe00fd9c3650
relookup() at relookup+0xa1/frame 0xfe00fd9c36b0
unionfs_relookup() at unionfs_relookup+0x102/frame 0xfe00fd9c3710
unionfs_relookup_for_delete() at unionfs_relookup_for_delete+0x56/frame 
0xfe00fd9c37a0
unionfs_rmdir() at unionfs_rmdir+0xce/frame 0xfe00fd9c3800
VOP_RMDIR_APV() at VOP_RMDIR_APV+0xf7/frame 0xfe00fd9c3830
kern_rmdirat() at kern_rmdirat+0x1b9/frame 0xfe00fd9c39a0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfe00fd9c3ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00fd9c3ab0
--- syscall (137, FreeBSD ELF64, sys_rmdir), rip = 0x156d6ae08ca, rsp = 
0x7be2c988, rbp = 0x7be2c9b0 ---
=== End Log ===

If there's anything you need from me, please let me know. It's 100% 
reproducible at bootup on one of my systems.

-- 
Shawn Webb
HardenedBSD

GPG Key ID:0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

signature.asc
Description: This is a digitally signed message part.

Re: unionfs or tmpfs Kernel Panic on 10.2-BETA1

[Shawn Webb]

On Saturday, 18 July 2015 09:12:52 David Wolfskill wrote:
 On Sat, Jul 18, 2015 at 11:54:59AM -0400, Shawn Webb wrote:
  Looks like there's some locking issues in 10.2-BETA1/amd64. I'm at
  revision bf2d0b176566519b95f21d01cc101f4b60247ab8 in this repo:
  
  https://github.com/HardenedBSD/hardenedBSD/tree/hardened/experimental/opns
  ense-10-stable
  
  === Begin Log ===
  Trying to mount root from ufs:/dev/ufs/HardenedBSD_Install [ro,noatime]...
  Mounting filesystems...
  tunefs: soft updates set
  tunefs: file system reloaded
  camcontrol: subcommand identify requires a valid device identifier
  panic: __lockmgr_args: recursing on non recursive lockmgr tmpfs @
  /usr/src/sys/kern/vfs_subr.c:2174 ...
  If there's anything you need from me, please let me know. It's 100%
  reproducible at bootup on one of my systems. ...
 
 I mount /tmp as a tmpfs on all of my FreeBSD systems, and have been
 tracking stable/10 daily for some time (ref.
 http://www.catwhisker.org/~david/FreeBSD/history/).
 
 I have not seen anything like the above.
 
 I am presently running:
 
 FreeBSD g1-245.catwhisker.org 10.2-BETA2 FreeBSD 10.2-BETA2 #96 
 r285668M/285670:1001519: Sat Jul 18 04:07:25 PDT 2015
 r...@g1-245.catwhisker.org:/common/S2/obj/usr/src/sys/CANARY  amd64
 
 on my laptop; on the system where I'm reading  writing mail, it's:
 
 FreeBSD albert.catwhisker.org 10.2-BETA1 FreeBSD 10.2-BETA1 #418 
 r285410M/285418:1001519: Sun Jul 12 04:37:35 PDT 2015
 r...@freebeast.catwhisker.org:/common/S2/obj/usr/src/sys/ALBERT  amd64
 
 I am, however, not using unionfs.
 
 I have a test system available, if that might help (e.g., for trying
 to reproduce the problem).
 
 Peace,
 david

Good to know. I'm working on creating a new experimental build of OPNSense + 
HardenedBSD.

I've uploaded the memstick image that exhibits the faulty behavior at 
https://hardenedbsd.org/~shawn/opnsense/bad_buids/

Thanks,

-- 
Shawn Webb
HardenedBSD

GPG Key ID:0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

signature.asc
Description: This is a digitally signed message part.

Re: unionfs or tmpfs Kernel Panic on 10.2-BETA1

[Shawn Webb]

On Saturday, 18 July 2015 12:24:37 Shawn Webb wrote:
 On Saturday, 18 July 2015 09:12:52 David Wolfskill wrote:
  On Sat, Jul 18, 2015 at 11:54:59AM -0400, Shawn Webb wrote:
   Looks like there's some locking issues in 10.2-BETA1/amd64. I'm at
   revision bf2d0b176566519b95f21d01cc101f4b60247ab8 in this repo:
   
   https://github.com/HardenedBSD/hardenedBSD/tree/hardened/experimental/op
   ns
   ense-10-stable
   
   === Begin Log ===
   Trying to mount root from ufs:/dev/ufs/HardenedBSD_Install
   [ro,noatime]...
   Mounting filesystems...
   tunefs: soft updates set
   tunefs: file system reloaded
   camcontrol: subcommand identify requires a valid device identifier
   panic: __lockmgr_args: recursing on non recursive lockmgr tmpfs @
   /usr/src/sys/kern/vfs_subr.c:2174 ...
   If there's anything you need from me, please let me know. It's 100%
   reproducible at bootup on one of my systems. ...
  
  I mount /tmp as a tmpfs on all of my FreeBSD systems, and have been
  tracking stable/10 daily for some time (ref.
  http://www.catwhisker.org/~david/FreeBSD/history/).
  
  I have not seen anything like the above.
  
  I am presently running:
  
  FreeBSD g1-245.catwhisker.org 10.2-BETA2 FreeBSD 10.2-BETA2 #96
  r285668M/285670:1001519: Sat Jul 18 04:07:25 PDT 2015
  r...@g1-245.catwhisker.org:/common/S2/obj/usr/src/sys/CANARY  amd64
  
  on my laptop; on the system where I'm reading  writing mail, it's:
  
  FreeBSD albert.catwhisker.org 10.2-BETA1 FreeBSD 10.2-BETA1 #418
  r285410M/285418:1001519: Sun Jul 12 04:37:35 PDT 2015
  r...@freebeast.catwhisker.org:/common/S2/obj/usr/src/sys/ALBERT  amd64
  
  I am, however, not using unionfs.
  
  I have a test system available, if that might help (e.g., for trying
  to reproduce the problem).
  
  Peace,
  david
 
 Good to know. I'm working on creating a new experimental build of OPNSense +
 HardenedBSD.
 
 I've uploaded the memstick image that exhibits the faulty behavior at
 https://hardenedbsd.org/~shawn/opnsense/bad_buids/
 
 Thanks,

I've also filed a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201677

Thanks,

-- 
Shawn Webb
HardenedBSD

GPG Key ID:0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

signature.asc
Description: This is a digitally signed message part.

Re: 10.1 NVMe kernel panic

[Jim Harris]

On Thu, May 21, 2015 at 8:33 AM, Sean Kelly smke...@smkelly.org wrote:

 Greetings.

 I have a Dell R630 server with four of Dell’s 800GB NVMe SSDs running
 FreeBSD 10.1-p10. According to the PCI vendor, they are some sort of
 rebranded Samsung drive. If I boot the system and then load nvme.ko and
 nvd.ko from a command line, the drives show up okay. If I put
 nvme_load=“YES”
 nvd_load=“YES”
 in /boot/loader.conf, the box panics on boot:
 panic: nexus_setup_intr: NULL irq resource!

 If I boot the system with “Safe Mode: ON” from the loader menu, it also
 boots successfully and the drives show up.

 You can see a full ‘boot -v’ here:
 http://smkelly.org/stuff/nvme-panic.txt 
 http://smkelly.org/stuff/nvme-panic.txt

 Anyone have any insight into what the issue may be here? Ideally I need to
 get this working in the next few days or return this thing to Dell.


Hi Sean,

Can you try adding hw.nvme.force_intx=1 to /boot/loader.conf?

I suspect you are able to load the drivers successfully after boot because
interrupt assignments are not restricted to CPU0 at that point - see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321 for a related
issue.  Your logs clearly show that vectors were allocated for the first 2
NVMe SSDs, but the third could not get its full allocation.  There is a bug
in the INTx fallback code that needs to be fixed - you do not hit this bug
when loading after boot because bug #199321 only affects interrupt
allocation during boot.

If the force_intx test works, would you able to upgrade your nvme drivers
to the latest on stable/10?  There are several patches (one related to
interrupt vector allocation) that have been pushed to stable/10 since 10.1
was released, and I will be pushing another patch for the issue you have
reported shortly.

Thanks,

-Jim





 Thanks!

 --
 Sean Kelly
 smke...@smkelly.org
 http://smkelly.org

 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 10.1 NVMe kernel panic

[Sean Kelly]

Jim,

Thanks for the reply. I set hw.nvme.force_intx=1 and get a new form of kernel 
panic:
http://smkelly.org/stuff/nvme_crash_force_intx.txt 
http://smkelly.org/stuff/nvme_crash_force_intx.txt

It looks like the NVMes are just failing to initialize at all now. As long as 
that tunable is in the kenv, I get this behavior. If I kldload them after boot, 
the init fails as well. But if I kldunload, kenv -u, kldload, it then works 
again. The only difference is kldload doesn’t result in a panic, just timeouts 
initializing them all.

I also compiled and tried stable/10 and it crashed in a similar way, but i’ve 
not captured the panic yet. It crashes even without the tunable in place. I’ll 
see if I can capture it.

-- 
Sean Kelly
smke...@smkelly.org
http://smkelly.org

 On Jun 2, 2015, at 6:10 PM, Jim Harris jim.har...@gmail.com wrote:
 
 
 
 On Thu, May 21, 2015 at 8:33 AM, Sean Kelly smke...@smkelly.org 
 mailto:smke...@smkelly.org wrote:
 Greetings.
 
 I have a Dell R630 server with four of Dell’s 800GB NVMe SSDs running FreeBSD 
 10.1-p10. According to the PCI vendor, they are some sort of rebranded 
 Samsung drive. If I boot the system and then load nvme.ko and nvd.ko from a 
 command line, the drives show up okay. If I put
 nvme_load=“YES”
 nvd_load=“YES”
 in /boot/loader.conf, the box panics on boot:
 panic: nexus_setup_intr: NULL irq resource!
 
 If I boot the system with “Safe Mode: ON” from the loader menu, it also boots 
 successfully and the drives show up.
 
 You can see a full ‘boot -v’ here:
 http://smkelly.org/stuff/nvme-panic.txt 
 http://smkelly.org/stuff/nvme-panic.txt 
 http://smkelly.org/stuff/nvme-panic.txt 
 http://smkelly.org/stuff/nvme-panic.txt
 
 Anyone have any insight into what the issue may be here? Ideally I need to 
 get this working in the next few days or return this thing to Dell.
 
 Hi Sean,
 
 Can you try adding hw.nvme.force_intx=1 to /boot/loader.conf?
 
 I suspect you are able to load the drivers successfully after boot because 
 interrupt assignments are not restricted to CPU0 at that point - see 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199321 for a related 
 issue.  Your logs clearly show that vectors were allocated for the first 2 
 NVMe SSDs, but the third could not get its full allocation.  There is a bug 
 in the INTx fallback code that needs to be fixed - you do not hit this bug 
 when loading after boot because bug #199321 only affects interrupt allocation 
 during boot.
 
 If the force_intx test works, would you able to upgrade your nvme drivers to 
 the latest on stable/10?  There are several patches (one related to interrupt 
 vector allocation) that have been pushed to stable/10 since 10.1 was 
 released, and I will be pushing another patch for the issue you have reported 
 shortly.
 
 Thanks,
 
 -Jim
 
 
   
 
 Thanks!
 
 --
 Sean Kelly
 smke...@smkelly.org mailto:smke...@smkelly.org
 http://smkelly.org http://smkelly.org/
 
 ___
 freebsd-stable@freebsd.org mailto:freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable 
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org 
 mailto:freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

10.1 NVMe kernel panic

[Sean Kelly]

Greetings.

I have a Dell R630 server with four of Dell’s 800GB NVMe SSDs running FreeBSD 
10.1-p10. According to the PCI vendor, they are some sort of rebranded Samsung 
drive. If I boot the system and then load nvme.ko and nvd.ko from a command 
line, the drives show up okay. If I put
nvme_load=“YES”
nvd_load=“YES”
in /boot/loader.conf, the box panics on boot:
panic: nexus_setup_intr: NULL irq resource!

If I boot the system with “Safe Mode: ON” from the loader menu, it also boots 
successfully and the drives show up.

You can see a full ‘boot -v’ here:
http://smkelly.org/stuff/nvme-panic.txt 
http://smkelly.org/stuff/nvme-panic.txt

Anyone have any insight into what the issue may be here? Ideally I need to get 
this working in the next few days or return this thing to Dell.

Thanks!

-- 
Sean Kelly
smke...@smkelly.org
http://smkelly.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)

[Will Green]

Thanks Steven. I’ll hold off releasing the updated tutorials for now.

 On 21 Apr 2015, at 17:45, Steven Hartland kill...@multiplay.co.uk wrote:
 
 I did actually request this back in November, but I don't seem to have had a 
 reply so I'll chase.
 
 On 21/04/2015 16:23, Will Green wrote:
 Hello,
 
 I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow 
 users to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 
 they cause a kernel panic.
 
 For example a simple command like the following causes a panic: zpool create 
 /tmp/zfstut/disk1
 
 This issue was identified in PR 195061: 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061
 And fixed in r274619 (2014-11-17): 
 https://svnweb.freebsd.org/base?view=revisionrevision=274619
 
 However, even on 10.1-RELEASE-p9 the kernel panic still occurs (but doesn’t 
 on 11-CURRENT).
 
 Are there any plans to patch this in 10.1? I note it’s not in the errata.
 
 My tutorials are not the only ones that use file-backed ZFS: new users 
 experimenting with ZFS on FreeBSD are likely to encounter this issue.
 
 Thanks,
 Will
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
 
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)

[Steven Hartland]

Looks like it got lost in the tubes, sitting with me to get info across 
to re@


On 26/04/2015 16:29, Will Green wrote:

Thanks Steven. I’ll hold off releasing the updated tutorials for now.


On 21 Apr 2015, at 17:45, Steven Hartland kill...@multiplay.co.uk wrote:

I did actually request this back in November, but I don't seem to have had a 
reply so I'll chase.

On 21/04/2015 16:23, Will Green wrote:

Hello,

I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow users 
to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 they cause 
a kernel panic.

For example a simple command like the following causes a panic: zpool create 
/tmp/zfstut/disk1

This issue was identified in PR 195061: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061
And fixed in r274619 (2014-11-17): 
https://svnweb.freebsd.org/base?view=revisionrevision=274619

However, even on 10.1-RELEASE-p9 the kernel panic still occurs (but doesn’t on 
11-CURRENT).

Are there any plans to patch this in 10.1? I note it’s not in the errata.

My tutorials are not the only ones that use file-backed ZFS: new users 
experimenting with ZFS on FreeBSD are likely to encounter this issue.

Thanks,
Will
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)

[Will Green]

Hello,

I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow users 
to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 they cause 
a kernel panic. 

For example a simple command like the following causes a panic: zpool create 
/tmp/zfstut/disk1

This issue was identified in PR 195061: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061 
And fixed in r274619 (2014-11-17): 
https://svnweb.freebsd.org/base?view=revisionrevision=274619 

However, even on 10.1-RELEASE-p9 the kernel panic still occurs (but doesn’t on 
11-CURRENT).

Are there any plans to patch this in 10.1? I note it’s not in the errata.

My tutorials are not the only ones that use file-backed ZFS: new users 
experimenting with ZFS on FreeBSD are likely to encounter this issue.

Thanks,
Will
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: File-Backed ZFS Kernel Panic still in 10.1-RELEASE (PR 195061)

[Steven Hartland]

I did actually request this back in November, but I don't seem to have 
had a reply so I'll chase.


On 21/04/2015 16:23, Will Green wrote:

Hello,

I have been updating my ZFS tutorials for use on FreeBSD 10.1. To allow users 
to experiment with ZFS I use file-backed ZFS pools. On FreeBSD 10.1 they cause 
a kernel panic.

For example a simple command like the following causes a panic: zpool create 
/tmp/zfstut/disk1

This issue was identified in PR 195061: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195061
And fixed in r274619 (2014-11-17): 
https://svnweb.freebsd.org/base?view=revisionrevision=274619

However, even on 10.1-RELEASE-p9 the kernel panic still occurs (but doesn’t on 
11-CURRENT).

Are there any plans to patch this in 10.1? I note it’s not in the errata.

My tutorials are not the only ones that use file-backed ZFS: new users 
experimenting with ZFS on FreeBSD are likely to encounter this issue.

Thanks,
Will
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Kernel Panic on vm_page_insert

[Thomas Laus]

This one is slightly different than the other item thread in this list.  This 
panic occurred when my weekly cron job fired to svn up my STABLE system to 
r255294.  I did not find a core file.  The panic and reboot happened in the 
middle of the night and I just noticed it this morning when I went to perform 
a build world.  My system is also an AMD64.

Sep 28 05:47:48 host kernel: panic: vm_page_insert: offset already allocated
Sep 28 05:47:48 host kernel: cpuid = 1
Sep 28 05:47:48 host kernel: KDB: stack backtrace:
Sep 28 05:47:48 host kernel: #0 0x80489c66 at kdb_backtrace+0x66
Sep 28 05:47:48 host kernel: #1 0x804511ce at panic+0x1ce
Sep 28 05:47:48 host kernel: #2 0x80639f65 at vm_page_insert+0x185
Sep 28 05:47:48 host kernel: #3 0x8063b58e at vm_page_alloc+0x27e
Sep 28 05:47:48 host kernel: #4 0x8063bb66 at vm_page_grab+0x86
Sep 28 05:47:48 host kernel: #5 0x804cf1eb at allocbuf+0x36b
Sep 28 05:47:48 host kernel: #6 0x804d2e2c at getblk+0x60c
Sep 28 05:47:48 host kernel: #7 0x804d33f0 at breadn_flags+0x40
Sep 28 05:47:48 host kernel: #8 0x805e42b2 at ffs_update+0x102
Sep 28 05:47:48 host kernel: #9 0x8060f1d3 at ufs_inactive+0x1a3
Sep 28 05:47:48 host kernel: #10 0x8069fbe8 at VOP_INACTIVE_APV+0x78
Sep 28 05:47:48 host kernel: #11 0x804e9836 at vinactive+0x86
Sep 28 05:47:48 host kernel: #12 0x804ed5c8 at vputx+0x2d8
Sep 28 05:47:48 host kernel: #13 0x804fb827 at vn_close+0xa7
Sep 28 05:47:48 host kernel: #14 0x804fb90d at vn_closefile+0x5d
Sep 28 05:47:48 host kernel: #15 0x8040db63 at _fdrop+0x23
Sep 28 05:47:48 host kernel: #16 0x8040eebc at closef+0x4c

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

RE: kernel panic: ffs_valloc: dup alloc

[Andriy Kornatskyy]

A part of core.txt file is here:
http://pastebin.com/gygnMh6G

Andriy

- info --

Dump header from device /dev/ada0s1b
  Architecture: i386
  Architecture Version: 2
  Dump Length: 232882176B (222 MB)
  Blocksize: 512
  Dumptime: Fri May 10 15:39:57 2013
  Hostname: freex
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29 18:11:52 UTC 2013
    r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
  Panic String: ffs_valloc: dup alloc
  Dump Parity: 4278856205
  Bounds: 0
  Dump Status: good



 To: freebsd-stable@freebsd.org; andriy.kornats...@live.com
 Subject: Re: kernel panic: ffs_valloc: dup alloc
 Date: Mon, 13 May 2013 14:14:09 +0200
 From: ronald-freeb...@klop.yi.org

 On Mon, 13 May 2013 11:10:04 +0200, Andriy Kornatskyy
 andriy.kornats...@live.com wrote:

  The core.txt and info files can be found in attached archive (there are
  2 crash reports there). If you need vmcores, just let me know where I
  can upload them.
 
  ASUS K73E
  Architecture: i386
  OS: FreeBSD 9.1-RELEASE-p3
 
  Please let me know should you need some other information.
 
  Thanks.
 
  Andriy

 Attachments are stripped by the mailinglist. Put them inline or on
 something like http://pastebin.com/.

 Ronald.
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org 
   
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

kernel panic: ffs_valloc: dup alloc

[Andriy Kornatskyy]

The core.txt and info files can be found in attached archive. If you need 
vmcore, just let me know where I can upload it.

ASUS K73E
Architecture: i386
OS: FreeBSD 9.1-RELEASE-p3

Please let me know should you need some other information.

Thanks.

Andriy___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

kernel panic: ffs_valloc: dup alloc

[Andriy Kornatskyy]

The core.txt and info files can be found in attached archive (there are 2 crash 
reports there). If you need vmcores, just let me know where I can upload them.

ASUS K73E
Architecture: i386
OS: FreeBSD 9.1-RELEASE-p3

Please let me know should you need some other information.

Thanks.

Andriy___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: kernel panic: ffs_valloc: dup alloc

[Ronald Klop]

On Mon, 13 May 2013 11:10:04 +0200, Andriy Kornatskyy  
andriy.kornats...@live.com wrote:


The core.txt and info files can be found in attached archive (there are  
2 crash reports there). If you need vmcores, just let me know where I  
can upload them.


ASUS K73E
Architecture: i386
OS: FreeBSD 9.1-RELEASE-p3

Please let me know should you need some other information.

Thanks.

Andriy  


Attachments are stripped by the mailinglist. Put them inline or on  
something like http://pastebin.com/.


Ronald.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[John Baldwin]

On Monday, April 01, 2013 12:29:46 pm Xin Li wrote:
 Yes, this is a bandaid and the right fix should be refactor the code a
 little bit to make sure that no interrupt handler is installed before
 the driver have done other initializations but I don't have hardware
 that can reproduce this issue handy to validate changes like that.

It is not that easy.  I instrumented the crap out of the igb driver on the
one machine where I could reliably reproduce this and kept clearing the
interrupt cause register during attach multiple times and still got a
spurious interrupt.  I believe this is a chip bug of some sort, but I've
no idea whose fault it is.  It has only been reported on SuperMicro *8*
boards to date.

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

9.1-REL Supermicro H8DCL-iF kernel panic

[Ryan McIntosh]

This has been brought up before for a different board, none specifically
mentioned this one nor the if_em driver (it was if_igb before on a X8DTU-6+
board).

References:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113

Panic image from H8DCl-iF:
http://nitemail.net/img/crash91-h8dcl-if.png

Original image from X8DTU-6+:
http://www.grosbein.net/img/crash-91rc.png

While I'd love to try out some fixes myself however I don't have a ton of
time with this system in my hands to be developed on. Jack (as referenced
in the kernel pr) felt that it was too few system specific to go further
with the issue as per the last response.

I would be more than happy to assist or even lend remote access to this
machine to figure out just what's causing the problem if anyone is up for
the task, but I will only have about 3-4 days with it. I have confirmed
dumping msix on the boot loader will permit the system to boot up and
function, however horridly slow (6gbps drives pushing 8mbyte/sec isnt even
usable). Maybe there's a grander problem here.. with supermicro? Let me
know, I'll happily test whatever if it benefits the community.

Ryan McIntosh
e: rmcint...@nitemare.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 4/1/13 12:04 AM, Ryan McIntosh wrote:
 This has been brought up before for a different board, none
 specifically mentioned this one nor the if_em driver (it was if_igb
 before on a X8DTU-6+ board).
 
 References: 
 http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html

 
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113
 
 Panic image from H8DCl-iF: 
 http://nitemail.net/img/crash91-h8dcl-if.png
 
 Original image from X8DTU-6+: 
 http://www.grosbein.net/img/crash-91rc.png
 
 While I'd love to try out some fixes myself however I don't have a
 ton of time with this system in my hands to be developed on. Jack
 (as referenced in the kernel pr) felt that it was too few system
 specific to go further with the issue as per the last response.
 
 I would be more than happy to assist or even lend remote access to
 this machine to figure out just what's causing the problem if
 anyone is up for the task, but I will only have about 3-4 days with
 it. I have confirmed dumping msix on the boot loader will permit
 the system to boot up and function, however horridly slow (6gbps
 drives pushing 8mbyte/sec isnt even usable). Maybe there's a
 grander problem here.. with supermicro? Let me know, I'll happily
 test whatever if it benefits the community.

I tend to agree with John's patch (on Feb 21, 2013 on kern/172113),
will you have a chance to test it?

(My thought is that we should probably just initialize
adapter-rx_mbuf_sz = MCLBYTES; in _attach() right after adapter-dev
assignment?)

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRWTe/AAoJEG80Jeu8UPuzMf8IALPmOclwXEwLHSzVX8BEDbq7
YOgCsyNAa9Yi3aeSjDkH3Hvqi3XZzc5FtIeXODUMoU9+vTtI9KQSh4As3UsIYJG5
rGAS9dyT8hJ/VNVAzDNAPRmOTaeSRyXCughfCd5MCJXMTG/6KtVkJ2z/js9VpP4r
sqA3qD21p9q88wfPJIhCj7hHFRLa5emv5Ir76pnZHrQ7ORerwtHEbTosWBWQdG7+
9gREoMl0VB28Zoh8Ai1+TvB79MsUklB4F/XZ63sM2ccJ0Uk1Egn6shI9VMBqbh75
tkMSsjenxbM6/BgK86cyNS+NA8Nyh9hGrpNfab5qj79usJKFskSxUpP/iszHCJc=
=xUCH
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[Ryan McIntosh]

I could try that patch, however that was intended for if_igb.c which for my
system (and the panic's are almost identical except if_em for me) I'd have
to apply that fix to if_em.c and I haven't looked at the source just yet.
If you can give me a patch I'll do apply and test it shortly though.

Ryan


On Mon, Apr 1, 2013 at 3:31 AM, Xin Li delp...@delphij.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 4/1/13 12:04 AM, Ryan McIntosh wrote:
  This has been brought up before for a different board, none
  specifically mentioned this one nor the if_em driver (it was if_igb
  before on a X8DTU-6+ board).
 
  References:
 
 http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html
 
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113
 
  Panic image from H8DCl-iF:
  http://nitemail.net/img/crash91-h8dcl-if.png
 
  Original image from X8DTU-6+:
  http://www.grosbein.net/img/crash-91rc.png
 
  While I'd love to try out some fixes myself however I don't have a
  ton of time with this system in my hands to be developed on. Jack
  (as referenced in the kernel pr) felt that it was too few system
  specific to go further with the issue as per the last response.
 
  I would be more than happy to assist or even lend remote access to
  this machine to figure out just what's causing the problem if
  anyone is up for the task, but I will only have about 3-4 days with
  it. I have confirmed dumping msix on the boot loader will permit
  the system to boot up and function, however horridly slow (6gbps
  drives pushing 8mbyte/sec isnt even usable). Maybe there's a
  grander problem here.. with supermicro? Let me know, I'll happily
  test whatever if it benefits the community.

 I tend to agree with John's patch (on Feb 21, 2013 on kern/172113),
 will you have a chance to test it?

 (My thought is that we should probably just initialize
 adapter-rx_mbuf_sz = MCLBYTES; in _attach() right after adapter-dev
 assignment?)

 Cheers,
 -BEGIN PGP SIGNATURE-

 iQEcBAEBCAAGBQJRWTe/AAoJEG80Jeu8UPuzMf8IALPmOclwXEwLHSzVX8BEDbq7
 YOgCsyNAa9Yi3aeSjDkH3Hvqi3XZzc5FtIeXODUMoU9+vTtI9KQSh4As3UsIYJG5
 rGAS9dyT8hJ/VNVAzDNAPRmOTaeSRyXCughfCd5MCJXMTG/6KtVkJ2z/js9VpP4r
 sqA3qD21p9q88wfPJIhCj7hHFRLa5emv5Ir76pnZHrQ7ORerwtHEbTosWBWQdG7+
 9gREoMl0VB28Zoh8Ai1+TvB79MsUklB4F/XZ63sM2ccJ0Uk1Egn6shI9VMBqbh75
 tkMSsjenxbM6/BgK86cyNS+NA8Nyh9hGrpNfab5qj79usJKFskSxUpP/iszHCJc=
 =xUCH
 -END PGP SIGNATURE-

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 4/1/13 12:34 AM, Ryan McIntosh wrote:
 I could try that patch, however that was intended for if_igb.c
 which for my system (and the panic's are almost identical except
 if_em for me) I'd have to apply that fix to if_em.c and I haven't
 looked at the source just yet. If you can give me a patch I'll do
 apply and test it shortly though.

Try this:
http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch

Cheers,
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRWTu4AAoJEG80Jeu8UPuzPnkIAIMgnUYgzXTdEt93aQVpK38v
IKH54G8iU7xR98V5auokFqGAuy3wqnbT4GQGsQCZWl+Lu7lmrbvIVufuB04Zjmyp
YO7gRNHeBVThp53nkDaPBjwLsEeGrFR11zLLq0nHJCDOFf+SgvPROuBEEMIBvzUR
LeHWKZUOcMOHdkADfAm3T1QIZ6F/K5iJdr6OB+r86b+nxV9Z+whEO2Tzk87XodTD
39+9t4EdkM4BgMDBoheS74SWK+vHhsmXbX7PPFXJZ/Zrasp6GMYLk8AAcWDm0IZ4
7s7lmx0xqckzwhaJZzKfO+DWtlaIrE+LIQwQmg5QVeZBDxlDU0orsLGO55zSlAo=
=B1sL
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[Ryan McIntosh]

I can confirm that works as intended. I appreciate the prompt response and
it looks like there's a real fix.

For google reference for anyone else searching..

Motherboard: Supermicro H8DCL-iF
OS: FreeBSD 9.1-RELEASE

Boot message:
panic: m_getzone: m_getjcl: invalid cluster type
cpuid = 0
KBD: stack backtrace:
#0 0x809208a6 at kdb_backtrace+0x66
#1 0x808ea8be at panic+0x1ce
#2 0x804ad5a7 at em_refresh_mbufs+0x207
#3 0x804adb7f at em_rxeof+0x47f
#4 0x804adca4 at em_msix_rx+0x24
#5 0x808be8d4 at intr_event_execute_handlers+0x104
#6 0x808c0076 at ithread_loop+0xa6
#7 0x808bb9ef at fork_exit+0x11f
#8 0x80bc368e at fork_trampoline+0xe

Panic image from H8DCl-iF:
http://nitemail.net/img/crash91-h8dcl-if.png

Original image from X8DTU-6+:
http://www.grosbein.net/img/crash-91rc.png

As per Xin Li, which seems to work:
http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch

References:
http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113


Thanks again,

Ryan McIntosh
e: rmcint...@nitemare.net


On Mon, Apr 1, 2013 at 3:48 AM, Xin Li delp...@delphij.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 4/1/13 12:34 AM, Ryan McIntosh wrote:
  I could try that patch, however that was intended for if_igb.c
  which for my system (and the panic's are almost identical except
  if_em for me) I'd have to apply that fix to if_em.c and I haven't
  looked at the source just yet. If you can give me a patch I'll do
  apply and test it shortly though.

 Try this:

 http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch

 Cheers,
 -BEGIN PGP SIGNATURE-

 iQEcBAEBCAAGBQJRWTu4AAoJEG80Jeu8UPuzPnkIAIMgnUYgzXTdEt93aQVpK38v
 IKH54G8iU7xR98V5auokFqGAuy3wqnbT4GQGsQCZWl+Lu7lmrbvIVufuB04Zjmyp
 YO7gRNHeBVThp53nkDaPBjwLsEeGrFR11zLLq0nHJCDOFf+SgvPROuBEEMIBvzUR
 LeHWKZUOcMOHdkADfAm3T1QIZ6F/K5iJdr6OB+r86b+nxV9Z+whEO2Tzk87XodTD
 39+9t4EdkM4BgMDBoheS74SWK+vHhsmXbX7PPFXJZ/Zrasp6GMYLk8AAcWDm0IZ4
 7s7lmx0xqckzwhaJZzKfO+DWtlaIrE+LIQwQmg5QVeZBDxlDU0orsLGO55zSlAo=
 =B1sL
 -END PGP SIGNATURE-

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[Jeremy Chadwick]

On Mon, Apr 01, 2013 at 05:45:48AM -0400, Ryan McIntosh wrote:
 I can confirm that works as intended. I appreciate the prompt response and
 it looks like there's a real fix.
 
 For google reference for anyone else searching..
 
 Motherboard: Supermicro H8DCL-iF
 OS: FreeBSD 9.1-RELEASE
 
 Boot message:
 panic: m_getzone: m_getjcl: invalid cluster type
 cpuid = 0
 KBD: stack backtrace:
 #0 0x809208a6 at kdb_backtrace+0x66
 #1 0x808ea8be at panic+0x1ce
 #2 0x804ad5a7 at em_refresh_mbufs+0x207
 #3 0x804adb7f at em_rxeof+0x47f
 #4 0x804adca4 at em_msix_rx+0x24
 #5 0x808be8d4 at intr_event_execute_handlers+0x104
 #6 0x808c0076 at ithread_loop+0xa6
 #7 0x808bb9ef at fork_exit+0x11f
 #8 0x80bc368e at fork_trampoline+0xe
 
 Panic image from H8DCl-iF:
 http://nitemail.net/img/crash91-h8dcl-if.png
 
 Original image from X8DTU-6+:
 http://www.grosbein.net/img/crash-91rc.png
 
 As per Xin Li, which seems to work:
 http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch
 
 References:
 http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113
 
 
 Thanks again,
 
 Ryan McIntosh
 e: rmcint...@nitemare.net
 
 
 On Mon, Apr 1, 2013 at 3:48 AM, Xin Li delp...@delphij.net wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  On 4/1/13 12:34 AM, Ryan McIntosh wrote:
   I could try that patch, however that was intended for if_igb.c
   which for my system (and the panic's are almost identical except
   if_em for me) I'd have to apply that fix to if_em.c and I haven't
   looked at the source just yet. If you can give me a patch I'll do
   apply and test it shortly though.
 
  Try this:
 
  http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch

Jack Vogel has stated it's not a real fix (your words) but rather a
bandaid, for both igb(4) and em(4).  The commit messages (for r238214
and r239304) contain details:

http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev238214
http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev239304

-- 
| Jeremy Chadwick   j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-REL Supermicro H8DCL-iF kernel panic

[Xin Li]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 4/1/13 5:25 AM, Jeremy Chadwick wrote:
 On Mon, Apr 01, 2013 at 05:45:48AM -0400, Ryan McIntosh wrote:
 I can confirm that works as intended. I appreciate the prompt
 response and it looks like there's a real fix.
 
 For google reference for anyone else searching..
 
 Motherboard: Supermicro H8DCL-iF OS: FreeBSD 9.1-RELEASE
 
 Boot message: panic: m_getzone: m_getjcl: invalid cluster type 
 cpuid = 0 KBD: stack backtrace: #0 0x809208a6 at
 kdb_backtrace+0x66 #1 0x808ea8be at panic+0x1ce #2
 0x804ad5a7 at em_refresh_mbufs+0x207 #3
 0x804adb7f at em_rxeof+0x47f #4 0x804adca4 at
 em_msix_rx+0x24 #5 0x808be8d4 at
 intr_event_execute_handlers+0x104 #6 0x808c0076 at
 ithread_loop+0xa6 #7 0x808bb9ef at fork_exit+0x11f #8
 0x80bc368e at fork_trampoline+0xe
 
 Panic image from H8DCl-iF: 
 http://nitemail.net/img/crash91-h8dcl-if.png
 
 Original image from X8DTU-6+: 
 http://www.grosbein.net/img/crash-91rc.png
 
 As per Xin Li, which seems to work: 
 http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch


 
References:
 http://lists.freebsd.org/pipermail/freebsd-stable/2011-September/063958.html

 
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/172113
 
 
 Thanks again,
 
 Ryan McIntosh e: rmcint...@nitemare.net
 
 
 On Mon, Apr 1, 2013 at 3:48 AM, Xin Li delp...@delphij.net
 wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 On 4/1/13 12:34 AM, Ryan McIntosh wrote:
 I could try that patch, however that was intended for
 if_igb.c which for my system (and the panic's are almost
 identical except if_em for me) I'd have to apply that fix to
 if_em.c and I haven't looked at the source just yet. If you
 can give me a patch I'll do apply and test it shortly
 though.
 
 Try this:
 
 http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c?r1=238214r2=239304view=patch

 
 Jack Vogel has stated it's not a real fix (your words) but rather
 a bandaid, for both igb(4) and em(4).  The commit messages (for
 r238214 and r239304) contain details:
 
 http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev238214

 
http://svnweb.freebsd.org/base/head/sys/dev/e1000/if_em.c#rev239304

Hm why 238214 is related, or did you mean the change between 238214
and 239304?

Yes, this is a bandaid and the right fix should be refactor the code a
little bit to make sure that no interrupt handler is installed before
the driver have done other initializations but I don't have hardware
that can reproduce this issue handy to validate changes like that.

Cheers,

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJRWbX6AAoJEG80Jeu8UPuzfR4IAID80wE0vCg+AyunRBLusue3
zBXNVwbAwxUFcJ2HcFRFLXVGj2kNsYnHGEp2KGJbYxX/zYJN6Kvv0nXhDIFM0IvJ
dsyC9f/vAay4EtKn9bSz6DmB57KUuhdy5v+40uGQIcoAaQ3/7My06RYcY2dm2PVM
XzLrEz3K5kEC+0dCRIRFi61yZAAPp4/FkHzrDud1AyQ+M03VnbXszzR7J6QIOYbQ
pN2I7RZfIMQXX9Qc+kqX6fFSCYrI7MzZmZkZPIQguWj/x+TUjk5pt5kyuNbum+YF
mqut0VyKAkwVRnsZMIJUXYEXfVtPorDlKRG4dlJdloF1Hz/xP02NpZoDzaK72GU=
=7Wll
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org