Re: panics in network stack in 12-current

2017-04-27 Thread Hamza Sheikh 
On Thu, Apr 27, 2017 at 10:02 AM, Tom Uffner  wrote:
> Andrey V. Elsukov wrote:
>>
>> On 27.04.2017 08:42, Tom Uffner wrote:
>>>
>>> r315956 panicked about 22 min after boot. failed to dump a core.
>>
>>
>> Why not update to the latest revision?
>
>
> I did several times a while ago, but didn't get a panic free system.

I may have encountered something similar on an EdgeRouter Lite running
r317256. It's serving as network gateway at home. After some time the
WAN connection goes dead. It starts working with either (a)
reconnecting the network cable or (b) pinging any IP on the internet
from that box. On rare occasions I had to reboot to get it to work.

I'm still new to FreeBSD and don't know how to collect relevant
information or whether to even determine if my issue is related to
Andrey's. Any help is really appreciated. My setup is documented in
detail in a blog post[0] if it helps.


[0] http://www.codeghar.com/blog/freebsd-network-gateway-on-edgerouter-lite.html

---
Hamza Sheikh
Twitter: @aikchar
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [mdconfig -d not effectively releasing memory?]

2017-04-27 Thread Mark Millard 
[As the text does not really follow from the earlier text
I'd sent directly I'm top posting a hypothesis about where
so much active memory came from to be so low in available
memory to get an reclaim_pv_chunk attempt.]

My hypothesis is that the "mdconfig -d"s from vm_copy_base
(from /usr/src/release/tools/vmimage.subr ) did not actually
release the memory resources involved (from vnode backed
mdconfig use):

vm_copy_base() {
# Creates a new UFS root filesystem and copies the contents of the
# current root filesystem into it.  This produces a "clean" disk
# image without any remnants of files which were created temporarily
# during image-creation and have since been deleted (e.g., downloaded
# package archives).

mkdir -p ${DESTDIR}/old
mdold=$(mdconfig -f ${VMBASE})
mount /dev/${mdold} ${DESTDIR}/old

truncate -s ${VMSIZE} ${VMBASE}.tmp
mkdir -p ${DESTDIR}/new
mdnew=$(mdconfig -f ${VMBASE}.tmp)
newfs -L rootfs /dev/${mdnew}
mount /dev/${mdnew} ${DESTDIR}/new

tar -cf- -C ${DESTDIR}/old . | tar -xUf- -C ${DESTDIR}/new

umount_loop /dev/${mdold}
rmdir ${DESTDIR}/old
mdconfig -d -u ${mdold}

umount_loop /dev/${mdnew}
rmdir ${DESTDIR}/new
tunefs -n enable /dev/${mdnew}
mdconfig -d -u ${mdnew}
mv ${VMBASE}.tmp ${VMBASE}
}

Without such prior mdconfig activity the
"cp -p" and following "xz -T 0" do not get the
large Meme:Active figure in top, "xz -T 0" getting
more like 781M Mem:Active with a xz:SIZE of 791M and
xz:RES < 800M (varying). Zero xz:SWAP. xz also gets
all the cores going, so well over 300% in top always
(4 cores) instead of < 100%. In this context both
the cp and the xz finish just fine.

In other words: no low memory problem without
first having the vnode backed mdconfig use.

>From the prior top report for the failure,
partially repeated here:

. . .
Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free
Swap: 6144M Total, 34M Used, 6110M Free, 348K Out

  PID USERNAMETHR PRI NICE   SIZERES   SWAP STATE   C   TIME CPU 
COMMAND
48988 root  4  310   651M 27048K 0K RUN 0   0:03  87.60% xz 
-T 0 /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-
. . .

The combination 1618M Mem:Active but 34M Swap:Used
and 651M xz:SIZE but 27M xz:RES and 0K xz:SWAP just
seems very odd, like it should not happen. The 17M
Mem:Inact is odd for the context as well. (Mem:Wired,
Mem:Buf, and Mem:Free look normal.)

An alternate hypothesis would be the memory "leak"
is from mkimg not having it memory-use cleaned up.
This happens after vm_copy_base but before the cp/xz
sequence and is what produces vm.raw.

For reference of what worked just fine after the
post-panic reboot, using the already existing
vm.raw (sparse) file as a starting place:

# cp -p vm.raw  
/usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarch64.raw
# xz -T 0 
/usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarch64.raw

# ls -lTt *raw*
-rw-r--r--  1 root  wheel  34360566272 Apr 27 18:40:24 2017 vm.raw
-rw-r--r--  1 root  wheel  34359746560 Apr 27 18:37:29 2017 vm.raw.nested_bsd
-rw-r--r--  1 root  wheel  27917287424 Apr 27 18:34:45 2017 raw.img

# du -sm *raw*
1762raw.img
1583vm.raw
1583vm.raw.nested_bsd

(Before the .xz replaces the .raw:)

# ls -lT /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/
total 33820032
-rw-r--r--  1 root  wheel  34360566272 Apr 27 18:40:24 2017 
FreeBSD-12.0-CURRENT-arm64-aarch64.raw

# du -sm /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/*
32777   
/usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarch64.raw

(After xz:)

# ls -lT /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/
total 258208
-rw-r--r--  1 root  wheel  264275808 Apr 27 18:40:24 2017 
FreeBSD-12.0-CURRENT-arm64-aarch64.raw.xz

# du -sm /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/*
253 
/usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarch64.raw.xz

(Mem:Active returned to 10M when xz finished.)


Prior reports from capturing text:

On 2017-Apr-27, at 7:31 PM, Mark Millard  wrote:

> [Another example panic. Again no dump. But I have what
> a top -PCwaopid froze at this time.]
> 
> On 2017-Apr-27, at 4:22 PM, Mark Millard  wrote:
> 
>> Unfortunately for this FYI the attempt to produce a dump
>> failed and so all the information that I have is what I
>> first captured from the console output: a backtrace.
>> 
>> The context was head -r317015 on a Pine64+ 2GB. At the
>> time I was experimenting with trying to build a vm.raw
>> from my own build of FreeBSD. The (root) file system
>> is on a USB SSD off of a powered USB hub.
>> 
>> panic: ARM64TODO: reclaim_pv_chunk
>> cpuid = 1
>> time = 1493332968
>> KDB: stack backtrace:
>> db_trace_self() at db_trace_self_wrapper+0x28
>>pc = 0x00605cc0  lr = 0x000869cc
>>sp =

Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [another example]

2017-04-27 Thread Mark Millard 
[Another example panic. Again no dump. But I have what
a top -PCwaopid froze at this time.]

On 2017-Apr-27, at 4:22 PM, Mark Millard  wrote:

> Unfortunately for this FYI the attempt to produce a dump
> failed and so all the information that I have is what I
> first captured from the console output: a backtrace.
> 
> The context was head -r317015 on a Pine64+ 2GB. At the
> time I was experimenting with trying to build a vm.raw
> from my own build of FreeBSD. The (root) file system
> is on a USB SSD off of a powered USB hub.
> 
> panic: ARM64TODO: reclaim_pv_chunk
> cpuid = 1
> time = 1493332968
> KDB: stack backtrace:
> db_trace_self() at db_trace_self_wrapper+0x28
> pc = 0x00605cc0  lr = 0x000869cc
> sp = 0x83ba4f00  fp = 0x83ba5110
> 
> db_trace_self_wrapper() at vpanic+0x164
> pc = 0x000869cc  lr = 0x0031d464
> sp = 0x83ba5120  fp = 0x83ba5190
> 
> vpanic() at panic+0x4c
> pc = 0x0031d464  lr = 0x0031d2fc
> sp = 0x83ba51a0  fp = 0x83ba5220
> 
> panic() at reclaim_pv_chunk+0x10
> pc = 0x0031d2fc  lr = 0x0061a234
> sp = 0x83ba5230  fp = 0x83ba5230
> 
> reclaim_pv_chunk() at get_pv_entry+0x240
> pc = 0x0061a234  lr = 0x00616184
> sp = 0x83ba5240  fp = 0x83ba5260
> 
> get_pv_entry() at pmap_enter+0x694
> pc = 0x00616184  lr = 0x006156a0
> sp = 0x83ba5270  fp = 0x83ba5300
> 
> pmap_enter() at vm_fault_hold+0x28c
> pc = 0x006156a0  lr = 0x005b9740
> sp = 0x83ba5310  fp = 0x83ba5460
> 
> vm_fault_hold() at vm_fault+0x70
> pc = 0x005b9740  lr = 0x005b9464
> sp = 0x83ba5470  fp = 0x83ba54a0
> 
> vm_fault() at data_abort+0xe0
> pc = 0x005b9464  lr = 0x0061ad94
> sp = 0x83ba54b0  fp = 0x83ba5560
> 
> data_abort() at handle_el1h_sync+0x70
> pc = 0x0061ad94  lr = 0x00607870
> sp = 0x83ba5570  fp = 0x83ba5680
> 
> handle_el1h_sync() at kern_select+0x9fc
> pc = 0x00607870  lr = 0x0037db3c
> sp = 0x83ba5690  fp = 0x83ba58f0
> 
> kern_select() at sys_select+0x5c
> pc = 0x0037db3c  lr = 0x0037dc58
> sp = 0x83ba5900  fp = 0x83ba5930
> 
> sys_select() at do_el0_sync+0xa48
> pc = 0x0037dc58  lr = 0x0061b91c
> sp = 0x83ba5940  fp = 0x83ba5a70
> 
> do_el0_sync() at handle_el0_sync+0x6c
> pc = 0x0061b91c  lr = 0x006079e8
> sp = 0x83ba5a80  fp = 0x83ba5b90
> 
> handle_el0_sync() at 0x4948c
> pc = 0x006079e8  lr = 0x0004948c
> sp = 0x83ba5ba0  fp = 0xd960


This time I got to record from top:
(swap is on a swap partition)
(pid 49888's SIZE vs. RES and SWAP might be interesting)
(as might the Active figure)

last pid: 48988;  load averages:  0.64,  0.44,  0.38

up 0+04:21:01  19:19:50
32 processes:  2 running, 30 sleeping
CPU 0: 13.2% user,  0.0% nice, 23.2% system,  0.3% interrupt, 63.3% idle
CPU 1:  4.6% user,  0.0% nice, 23.9% system,  0.0% interrupt, 71.5% idle
CPU 2:  2.1% user,  0.0% nice, 23.2% system,  0.0% interrupt, 74.8% idle
CPU 3:  3.3% user,  0.0% nice, 23.8% system,  0.0% interrupt, 72.8% idle
Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free
Swap: 6144M Total, 34M Used, 6110M Free, 348K Out

  PID USERNAMETHR PRI NICE   SIZERES   SWAP STATE   C   TIME CPU 
COMMAND
48988 root  4  310   651M 27048K 0K RUN 0   0:03  87.60% xz 
-T 0 
/usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarch64.raw
11983 root  1  220  5068K 0K 0K wait3   0:00   0.00% 
make vm-image vm-install DESTDIR=/usr/obj/DESTDIRs/vmimage-aarch64 ()
11981 root  1  420  7320K 0K  1516K wait1   0:00   0.00% sh 
/root/sys_build_scripts.aarch64-host/make_noscript_aarch64_nodebug_clang_bootstrap-aarch64-host.sh
 vm-image vm-install 
11980 root  1  200  6656K  1548K 0K select  0   0:02   0.00% 
[script]
11977 root  1  300  7320K 0K  1516K wait3   0:00   0.00% 
/bin/sh 
/root/sys_build_scripts.aarch64-host/make_aarch64_nodebug_clang_bootstrap-aarch64-host.sh
 vm-image vm-install DEST
 2694 root  1  200  8804K  2072K 0K CPU22   0:07   0.17% 
top -PCwaopid
  827 root  1  200  7320K 0K   360K wait0   0:00   0.00% su 
()
  826 markmi1  220 10372K 0K  1532K wait3   0:00   0.00% su 
()
  820 markmi1  240  7320K 0K

FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015

2017-04-27 Thread Mark Millard 
Unfortunately for this FYI the attempt to produce a dump
failed and so all the information that I have is what I
first captured from the console output: a backtrace.

The context was head -r317015 on a Pine64+ 2GB. At the
time I was experimenting with trying to build a vm.raw
from my own build of FreeBSD. The (root) file system
is on a USB SSD off of a powered USB hub.

panic: ARM64TODO: reclaim_pv_chunk
cpuid = 1
time = 1493332968
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
 pc = 0x00605cc0  lr = 0x000869cc
 sp = 0x83ba4f00  fp = 0x83ba5110

db_trace_self_wrapper() at vpanic+0x164
 pc = 0x000869cc  lr = 0x0031d464
 sp = 0x83ba5120  fp = 0x83ba5190

vpanic() at panic+0x4c
 pc = 0x0031d464  lr = 0x0031d2fc
 sp = 0x83ba51a0  fp = 0x83ba5220

panic() at reclaim_pv_chunk+0x10
 pc = 0x0031d2fc  lr = 0x0061a234
 sp = 0x83ba5230  fp = 0x83ba5230

reclaim_pv_chunk() at get_pv_entry+0x240
 pc = 0x0061a234  lr = 0x00616184
 sp = 0x83ba5240  fp = 0x83ba5260

get_pv_entry() at pmap_enter+0x694
 pc = 0x00616184  lr = 0x006156a0
 sp = 0x83ba5270  fp = 0x83ba5300

pmap_enter() at vm_fault_hold+0x28c
 pc = 0x006156a0  lr = 0x005b9740
 sp = 0x83ba5310  fp = 0x83ba5460

vm_fault_hold() at vm_fault+0x70
 pc = 0x005b9740  lr = 0x005b9464
 sp = 0x83ba5470  fp = 0x83ba54a0

vm_fault() at data_abort+0xe0
 pc = 0x005b9464  lr = 0x0061ad94
 sp = 0x83ba54b0  fp = 0x83ba5560

data_abort() at handle_el1h_sync+0x70
 pc = 0x0061ad94  lr = 0x00607870
 sp = 0x83ba5570  fp = 0x83ba5680

handle_el1h_sync() at kern_select+0x9fc
 pc = 0x00607870  lr = 0x0037db3c
 sp = 0x83ba5690  fp = 0x83ba58f0

kern_select() at sys_select+0x5c
 pc = 0x0037db3c  lr = 0x0037dc58
 sp = 0x83ba5900  fp = 0x83ba5930

sys_select() at do_el0_sync+0xa48
 pc = 0x0037dc58  lr = 0x0061b91c
 sp = 0x83ba5940  fp = 0x83ba5a70

do_el0_sync() at handle_el0_sync+0x6c
 pc = 0x0061b91c  lr = 0x006079e8
 sp = 0x83ba5a80  fp = 0x83ba5b90

handle_el0_sync() at 0x4948c
 pc = 0x006079e8  lr = 0x0004948c
 sp = 0x83ba5ba0  fp = 0xd960


===
Mark Millard
markmi at dsl-only.net

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

Re: Panic String: solaris assert: (lsize != psize) implies ((flags & ZIO_FLAG_RAW) != 0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 631

2017-04-27 Thread Andriy Gapon 
On 27/04/2017 18:52, Michael Jung wrote:
> Hi:
> 
> Recently upgraded from r315905 to r317435 and during a poudriere run got this
> panic which I have not seen before.
> 
> https://charon.gopai.com/core.txt.1
> https://charon.gopai.com/info.1
> 
> Let me know what additional information I might supply.

Mike,

could you please edit function zio_free_sync() in
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c so that the zio_create()
call has "size, size" arguments instead of "size, BP_GET_PSIZE(bp)" and see if
that helps?
(Your pool is probably low on space too.)

> panic: solaris assert: (lsize != psize) implies ((flags & ZIO_FLAG_RAW) != 0),
> file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 631
> cpuid = 6
> time = 1493306220
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe086140e850
> vpanic() at vpanic+0x19c/frame 0xfe086140e8d0
> panic() at panic+0x43/frame 0xfe086140e930
> assfail() at assfail+0x1a/frame 0xfe086140e940
> zio_create() at zio_create+0x11f/frame 0xfe086140e9a0
> zio_free_sync() at zio_free_sync+0x197/frame 0xfe086140ea50
> zio_gang_tree_issue() at zio_gang_tree_issue+0x13f/frame 0xfe086140eaa0
> zio_gang_issue() at zio_gang_issue+0x152/frame 0xfe086140ead0
> zio_execute() at zio_execute+0x36c/frame 0xfe086140eb20
> taskqueue_run_locked() at taskqueue_run_locked+0x13d/frame 0xfe086140eb80
> taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfe086140ebb0
> fork_exit() at fork_exit+0x84/frame 0xfe086140ebf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe086140ebf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> 
> Reading symbols from /boot/kernel/vmm.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/vmm.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/vmm.ko
> Reading symbols from /boot/kernel/filemon.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/filemon.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/filemon.ko
> Reading symbols from /boot/kernel/zfs.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/zfs.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/zfs.ko
> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/opensolaris.ko
> Reading symbols from
> /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko...done.
> Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko
> Reading symbols from 
> /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko...done.
> Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko
> Reading symbols from 
> /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko...done.
> Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko
> Reading symbols from 
> /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko...done.
> Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko
> Reading symbols from /boot/kernel/linux.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/linux.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/linux.ko
> Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/linux_common.ko
> Reading symbols from /boot/kernel/linux64.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/linux64.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/linux64.ko
> Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/nullfs.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/nullfs.ko
> Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/linprocfs.ko
> Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/tmpfs.ko
> Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/fdescfs.ko
> #0  doadump (textdump=0) at pcpu.h:232
> 232 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0  doadump (textdump=0) at pcpu.h:232
> #1  0x803a1f7b in db_dump (dummy=,
> dummy2=, dummy3=,
> dummy4=) at /usr/src/sys/ddb/db_command.c:546
> #2  0x803a1d6f in db_command (cmd_table=)
> at /usr/src/sys/ddb/db_command.c:453
> #3  0x803a1aa4 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:506
> #4  0x803a4b6f in db_trap (type=,
> code=) at /usr/src/sys/ddb/db_main.c:248
> #5  0x80a9 in kdb_trap (type=3, code=-61456,
> tf=) at /usr/src/sys/kern/subr_kdb.c:654
> #6

Re: panics in network stack in 12-current

2017-04-27 Thread Tom Uffner 

Andrey V. Elsukov wrote:

On 27.04.2017 08:42, Tom Uffner wrote:

Tom Uffner wrote:

Andrey V. Elsukov wrote:

I think the most of these panics should be fixed in r315956.


thanks. I'll give it a try and report back as soon as I have a result.


r315956 panicked about 22 min after boot. failed to dump a core.


Why not update to the latest revision?

Probably this is flowtable related, don't think it is usable.
Anyway we need the trace to determine the cause. Also it seems you have
VIMAGE enabled. This also have some known panics.


attached is a text dump from this version


core.txt.6.bz2
Description: Binary data
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panics in network stack in 12-current

2017-04-27 Thread Tom Uffner 

Andrey V. Elsukov wrote:

On 27.04.2017 08:42, Tom Uffner wrote:

r315956 panicked about 22 min after boot. failed to dump a core.


Why not update to the latest revision?


I did several times a while ago, but didn't get a panic free system. I was
hoping to bisect the point the point where the problem actually occurred
and maybe send a patch instead of just begging for help. trouble was, I got
down to a small number of revisions and none of them had any changes that
looked even remotely related to my problem. I'll give today's HEAD a try.


Probably this is flowtable related, don't think it is usable.
Anyway we need the trace to determine the cause. Also it seems you have
VIMAGE enabled. This also have some known panics.


OK, I will also try disabling flowtable. Not sure about VIMAGE. I don't
have it specifically enabled, but I don't have it specifically disabled
either if it defaults to on. I don't know much about it.

I have also tried using the GENERIC kernel instead of my custom one, but
it was even less stable on my hardware and bricked the system instead of
panicking and producing a core dump.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Panic String: solaris assert: (lsize != psize) implies ((flags & ZIO_FLAG_RAW) != 0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 631

2017-04-27 Thread Michael Jung 

Hi:

Recently upgraded from r315905 to r317435 and during a poudriere run got 
this panic which I have not seen before.


https://charon.gopai.com/core.txt.1
https://charon.gopai.com/info.1

Let me know what additional information I might supply.

--mikej

panic: solaris assert: (lsize != psize) implies ((flags & ZIO_FLAG_RAW) 
!= 0), file: 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, line: 631

cpuid = 6
time = 1493306220
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe086140e850

vpanic() at vpanic+0x19c/frame 0xfe086140e8d0
panic() at panic+0x43/frame 0xfe086140e930
assfail() at assfail+0x1a/frame 0xfe086140e940
zio_create() at zio_create+0x11f/frame 0xfe086140e9a0
zio_free_sync() at zio_free_sync+0x197/frame 0xfe086140ea50
zio_gang_tree_issue() at zio_gang_tree_issue+0x13f/frame 
0xfe086140eaa0

zio_gang_issue() at zio_gang_issue+0x152/frame 0xfe086140ead0
zio_execute() at zio_execute+0x36c/frame 0xfe086140eb20
taskqueue_run_locked() at taskqueue_run_locked+0x13d/frame 
0xfe086140eb80
taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 
0xfe086140ebb0

fork_exit() at fork_exit+0x84/frame 0xfe086140ebf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe086140ebf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

Reading symbols from /boot/kernel/vmm.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/vmm.ko.debug...done.

done.
Loaded symbols for /boot/kernel/vmm.ko
Reading symbols from /boot/kernel/filemon.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/filemon.ko.debug...done.

done.
Loaded symbols for /boot/kernel/filemon.ko
Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.

done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.

done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from 
/usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko...done.
Loaded symbols for 
/usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko
Reading symbols from 
/usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko...done.

Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko
Reading symbols from 
/usr/local/lib/vmware-tools/modules/drivers/vmblock.ko...done.
Loaded symbols for 
/usr/local/lib/vmware-tools/modules/drivers/vmblock.ko
Reading symbols from 
/usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko...done.

Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux.ko.debug...done.

done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.

done.
Loaded symbols for /boot/kernel/linux_common.ko
Reading symbols from /boot/kernel/linux64.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux64.ko.debug...done.

done.
Loaded symbols for /boot/kernel/linux64.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/nullfs.ko.debug...done.

done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linprocfs.ko.debug...done.

done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/tmpfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/tmpfs.ko.debug...done.

done.
Loaded symbols for /boot/kernel/tmpfs.ko
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fdescfs.ko.debug...done.

done.
Loaded symbols for /boot/kernel/fdescfs.ko
#0  doadump (textdump=0) at pcpu.h:232
232 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=0) at pcpu.h:232
#1  0x803a1f7b in db_dump (dummy=,
dummy2=, dummy3=,
dummy4=) at /usr/src/sys/ddb/db_command.c:546
#2  0x803a1d6f in db_command (cmd_table=)
at /usr/src/sys/ddb/db_command.c:453
#3  0x803a1aa4 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:506
#4  0x803a4b6f in db_trap (type=,
code=) at /usr/src/sys/ddb/db_main.c:248
#5  0x80a9 in kdb_trap (type=3, code=-61456,
tf=) at /usr/src/sys/kern/subr_kdb.c:654
#6  0x80ed2de6 in trap (frame=0xfe086140e780)
at /usr/src/sys/amd64/amd64/trap.c:537
#7  0x80eb54e1 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:236
#8  0x80a92a6b in kdb_enter (why=0x8143c265 "panic",
msg=) at cpufunc.h:63
#9  0x80a513c9 in vpanic (fmt=,
ap=0xfe086140e910) at /usr/src/sys/kern/kern_shutdown.c:772
#10 0x80a51433 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:710
#11

Re: panics in network stack in 12-current

2017-04-27 Thread Andrey V. Elsukov 
On 27.04.2017 08:42, Tom Uffner wrote:
> Tom Uffner wrote:
>> Andrey V. Elsukov wrote:
>>> I think the most of these panics should be fixed in r315956.
>>
>> thanks. I'll give it a try and report back as soon as I have a result.
> 
> r315956 panicked about 22 min after boot. failed to dump a core.

Why not update to the latest revision?

Probably this is flowtable related, don't think it is usable.
Anyway we need the trace to determine the cause. Also it seems you have
VIMAGE enabled. This also have some known panics.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: Opteron 6100-series "Magny-Cours"

2017-04-27 Thread Daniel Kalchev 
If you still have not found it, I have two Supermicro blades with these, one to 
be upgraded with 6127 these days… 

Daniel

> On 27.03.2017 г., at 16:11, Andriy Gapon  wrote:
> 
> On 27/03/2017 15:06, Piotr Kubaj wrote:
>> Does it have to be specifically 61xx series? I have a server running 2 
>> 6262HE's.
>> 
> 
> Yes.  I have the info that I need for 62xx Opterons.
> Thanks.
> 
> -- 
> Andriy Gapon
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: increased power consumption lately?

2017-04-27 Thread Johannes Lundberg 
There's a rather lengthy theory about it here
https://bugs.freedesktop.org/show_bug.cgi?id=98501


On Wed, Apr 26, 2017 at 11:15 PM, Adrian Chadd  wrote:

> can you file a bugzilla bug with this information in it? What's
> triggering the interrupt?
>
>
> -a
>
>
> On 20 April 2017 at 02:05, Johannes Lundberg  wrote:
> > I found another solution. Modifying the DSDT file by removing
> >
> > Method (_L06, 0, NotSerialized)  // _Lxx: Level-Triggered GPE
> > {
> > If (LAnd (\_SB.PCI0.IGPU.GSSE, LNot (GSMI)))
> > {
> > \_SB.PCI0.IGPU.GSCI ()
> > }
> > Else
> > {
> > Store (0x00, \_SB.PCI0.IGPU.GEFC)
> > Store (0x01, SCIS) /* \SCIS */
> > Store (0x00, \_SB.PCI0.IGPU.GSSE)
> > Store (0x00, \_SB.PCI0.IGPU.SCIE)
> > }
> > }
> >
> > seem to solve the problem, as discussed here
> > https://bugs.freedesktop.org/show_bug.cgi?id=98501
> >
> > I will keep an eye on that bug report and see what happens.
> > I should also mention that I am running the Linux i915kms driver
> > https://github.com/FreeBSDDesktop/freebsd-base-graphics
> >
> > Since we're constantly merging updates from Linux maybe there will be a
> fix
> > for this soon.
> >
> >
> >
> > On Thu, Apr 20, 2017 at 10:35 AM, Johannes Lundberg 
> > wrote:
> >>
> >> Seem like a temporary solution on Linux is to disable the interrupt. Can
> >> this be done on FreeBSD somehow?
> >>
> >> On Thu, Apr 20, 2017 at 10:09 AM, Johannes Lundberg  >
> >> wrote:
> >>>
> >>> Thanks Ngie, that was a good one!  (I really need to learn dtrace...)
> >>>
> >>> Got this among other:
> >>>
> >>> AcpiNsLookup:entry PathInfo: \/ _SB_PCI0IGPUGSSE�GSMI\/
> >>> _SB_PCI0IGPUGSCI�K p
> >>>
> >>> Might be related to:
> >>> https://bugs.freedesktop.org/show_bug.cgi?id=98501
> >>>
> >>>
> >>>
> >>> On Wed, Apr 5, 2017 at 8:15 PM, Ngie Cooper (yaneurabeya)
> >>>  wrote:
> 
> 
>  > On Apr 5, 2017, at 10:39, Adrian Chadd  wrote:
>  >
>  > hm, you could use dtrace to find what's calling that function and
>  > print out the call stack?
> 
>  *does shrug* something like this (I realize it’s not printing
>  out arg0 — arg0 is a union that would need decoding)?
>  Thanks,
>  -Ngie
> 
>  $ cat AcpiNsLookup.d
>  fbt:kernel:AcpiNsLookup:entry
>  {
>  printf("PathInfo: %s\nType: %d\nFlags: %u",
>  stringof(arg1), arg2, arg3);
>  }
>  $ sudo dtrace -s AcpiNsLookup.d
> >>>
> >>>
> >>
> >
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"