FreeBSD 13.2-stable crash in /usr/src/sys/amd64/include/pcpu_aux.h:55

[Michael Jung]

After upgrading from

FreeBSD firewall.mikej.com 13.1-STABLE FreeBSD 13.1-STABLE #21 
stable/13-n253337-16603f60156e:Wed Dec 28 08:22:48 EST 2022 
mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64


TO

FreeBSD firewall.mikej.com 13.2-STABLE FreeBSD 13.2-STABLE #3 
stable/13-n254483-e0c3f2a1e296: Tue Feb 14 19:25:51 EST 2023 
mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64


I had a kernel crash which can be found here.

http://mail.mikej.com/core.txt.0

It has not happened again, but I'm putting it though it's normal paces.

The only thing that was occurring which is not a normal thing for me to
is I was moving TB's worth of data between directly attached two zpools.

Regards,

Michael Jung

witness_lock_list_get: witness exhausted

[Michael Jung]

First shame on me as I obviously missed the reply to my former report and did 
not
report back on a proposed patch.

https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068136.html

I am still running current – the guest has 160GB Ram and 64 vCPU’s assigned 
under ESXi
which mainly runs poudriere for amd64+arm builds and I again noticed
"witness_lock_list_get: witness exhausted" on the console (which I don't pay 
much attention to).

UNAME: FreeBSD poudriere.gopai.com 14.0-CURRENT FreeBSD 14.0-CURRENT #0 
main-n259872-f948cb717f50: Wed Dec 28 13:13:43 EST 2022 
mi...@poudriere.gopai.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

It seems that LOCK_NCHILDREN and LOCK_CHILDCOUNT never got incremented due to 
my lack of reporting in
/usr/src/sys/kern/subr_witness.c

If it's just a matter of incrementing LOCK_CHIDCOUNT 4096 and LOCK_NCHILDREN 20 
without adding the
sysctl knobs I do that also - I am not kernel savvy.

I will make sure and test an updated patch should one be made available or 
advise whether to increment these values
or ignore the warnings.

Regards,

Michael Jung





CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

RE: Chasing OOM Issues - good sysctl metrics to use?

[Michael Jung]

Hi:

I guess I'm kind of high jacking this thread but I think what I'm
going to ask is close enough to the topic at hand to ask instead
of starting a new thread and referencing this one.

I use sysutils/monit to what running processes and then restart them
I as I want.

I use  protect(1) to make sure that monit would not dies.

In /etc/rc.local "protect -i monit"

protect seems in the end simply call

 PROC_SPROTECT with the INHERIT flag and as documented in procctl(2)

So I followed a bit of code I guess that cools if I got it right but I know
about .0001% about system internals.

Can anyone speak to how protect(1) works and is it in itself is prone to what 
has been discussed?

For my use case is protect "good enough" or do I really need to tuning like has 
been talked about?

If protect is the right answer and someone could explain how it does
Its thing at a slighter higher technical barrier I would love to hear
more about why I'm either doing it wrong, that that what I'm doing it ok, or
why I should really be doing something completely different and the why I
should be doing it differently.

I suspect there are many that would like to know this but would never ask,
at least not on list.

Always the seeker of new knowledge.

Thanks in advance.

--mikej





CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245



From: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Mark Millard
Sent: Saturday, April 23, 2022 3:32 PM
To: Pete Wright 
Cc: freebsd-current 
Subject: Re: Chasing OOM Issues - good sysctl metrics to use?

On 2022-Apr-23, at 10:26, Pete Wright 
mailto:p...@nomadlogic.org>> wrote:

> On 4/22/22 18:46, Mark Millard wrote:
>> On 2022-Apr-22, at 16:42, Pete Wright 
>> mailto:p...@nomadlogic.org>> wrote:
>>
>>> On 4/21/22 21:18, Mark Millard wrote:
 Messages in the console out would be appropriate
 to report. Messages might also be available via
 the following at appropriate times:
>>> that is what is frustrating. i will get notification that the processes are 
>>> killed:
>>> Apr 22 09:55:15 topanga kernel: pid 76242 (chrome), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:19 topanga kernel: pid 76288 (chrome), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:20 topanga kernel: pid 76259 (firefox), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:22 topanga kernel: pid 76252 (firefox), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:23 topanga kernel: pid 76267 (firefox), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:24 topanga kernel: pid 76234 (chrome), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>>> Apr 22 09:55:26 topanga kernel: pid 76275 (firefox), jid 0, uid 1001, was 
>>> killed: failed to reclaim memory
>> Those messages are not reporting being out of swap
>> as such. They are reporting sustained low free RAM
>> despite a number of less drastic attempts to gain
>> back free RAM (to above some threshold).
>>
>> FreeBSD does not swap out the kernel stacks for
>> processes that stay in a runnable state: it just
>> continues to page. Thus just one large process
>> that has a huge working set of active pages can
>> lead to OOM kills in a context were no other set
>> of processes would be enough to gain the free
>> RAM required. Such contexts are not really a
>> swap issue.
>
> Thank you for this clarification/explanation - that totally makes sense!
>
>>
>> Based on there being only 1 "killed:" reason,
>> I have a suggestion that should allow delaying
>> such kills for a long time. That in turn may
>> help with investigating without actually
>> suffering the kills during the activity: more
>> time with low free RAM to observe.
>
> Great idea thank-you! and thanks for the example settings and descriptions as 
> well.
>> But those are large but finite activities. If
>> you want to leave something running for days,
>> weeks, months, or whatever that produces the
>> sustained low free RAM conditions, the problem
>> will eventually happen. Ultimately one may have
>> to exit and restart such processes once and a
>> while, exiting enough of them to give a little
>> time with sufficient free RAM.
> perfect - since this is a workstation my run-time for these processes is 
> probably a week as i update my system and pkgs over the weekend, then dog 
> food current 

RE: New panic in main-n253273-a52d8d4a6c6:

[Michael Jung]

Rob:

I did not remove Hans earlier patch, but your “latest” patch applied and 
compiled with no errors.

I can now watch and control a TTY (v0) or a SSH session (pts/1) without 
crashing.

Anything else you would like me to try?

--mikej


From: Rob Wing [mailto:rob.fx...@gmail.com]
Sent: Monday, February 21, 2022 9:30 PM
To: Michael Jung 
Cc: Hans Petter Selasky ; freebsd-current 

Subject: Re: New panic in main-n253273-a52d8d4a6c6:

The previous attached patch should work for testing purposes, but it's 
incorrect if an error occurs.

The fhold() should be below FILEDESC_SUNLOCK(), this patch addresses that.

On Mon, Feb 21, 2022 at 5:18 PM Rob Wing 
mailto:rob.fx...@gmail.com>> wrote:
try the attached patch

On Mon, Feb 21, 2022 at 5:14 PM Michael Jung 
mailto:mi...@paymentallianceintl.com>> wrote:




CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245


From: Michael Jung
Sent: Monday, February 21, 2022 9:06 PM
To: 'Hans Petter Selasky' mailto:h...@selasky.org>>; 
freebsd-current 
mailto:freebsd-current@freebsd.org>>
Subject: RE: New panic in main-n253273-a52d8d4a6c6:

From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung 
mailto:mi...@paymentallianceintl.com>>; 
freebsd-current 
mailto:freebsd-current@freebsd.org>>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occurred 
> then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch" for 
> comparison.
>
> http://mail.mikej.com/core.txt.1<http://mail.mikej.com/core.txt.1>
>
> http://mail.mikej.com/info.1<http://mail.mikej.com/info.1>
>
> http://mail.mikej.com/vmcore.1<http://mail.mikej.com/vmcore.1>
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count = 0x

f_data = 0xf800158b0400

In your KGDB, can you enter:

info 0x81b052d0

Does the attached patch make any difference?

--HPS


So sorry, yes step one, ssh to machine….

Even open a second console on the computer, no SSH and do “watch –I  -W v0” it 
panics.

Example of “watch –I –W v0” for comparison – kernel/kernel.full have not 
changed since .2

http://mail.mikej.com/core.txt.3<http://mail.mikej.com/core.txt.3>

http://mail.mikej.com/info.3<http://mail.mikej.com/info.3>

http://mail.mikej.com/vmcore.3<http://mail.mikej.com/vmcore.3>





Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

RE: New panic in main-n253273-a52d8d4a6c6:

[Michael Jung]

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245



From: Michael Jung
Sent: Monday, February 21, 2022 9:06 PM
To: 'Hans Petter Selasky' ; freebsd-current 

Subject: RE: New panic in main-n253273-a52d8d4a6c6:

From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung 
mailto:mi...@paymentallianceintl.com>>; 
freebsd-current 
mailto:freebsd-current@freebsd.org>>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occurred 
> then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch" for 
> comparison.
>
> http://mail.mikej.com/core.txt.1<http://mail.mikej.com/core.txt.1>
>
> http://mail.mikej.com/info.1<http://mail.mikej.com/info.1>
>
> http://mail.mikej.com/vmcore.1<http://mail.mikej.com/vmcore.1>
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count = 0x

f_data = 0xf800158b0400

In your KGDB, can you enter:

info 0x81b052d0

Does the attached patch make any difference?

--HPS


So sorry, yes step one, ssh to machine….

Even open a second console on the computer, no SSH and do “watch –I  -W v0” it 
panics.

Example of “watch –I –W v0” for comparison – kernel/kernel.full have not 
changed since .2

http://mail.mikej.com/core.txt.3

http://mail.mikej.com/info.3

http://mail.mikej.com/vmcore.3

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

RE: New panic in main-n253273-a52d8d4a6c6:

[Michael Jung]

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245



From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung ; freebsd-current 

Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occurred 
> then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch" for 
> comparison.
>
> http://mail.mikej.com/core.txt.1<http://mail.mikej.com/core.txt.1>
>
> http://mail.mikej.com/info.1<http://mail.mikej.com/info.1>
>
> http://mail.mikej.com/vmcore.1<http://mail.mikej.com/vmcore.1>
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count = 0x

f_data = 0xf800158b0400

In your KGDB, can you enter:

info 0x81b052d0

Does the attached patch make any difference?

--HPS



Patch made no difference, instant panic.

These are will the patch applied.

http://mail.mikej.com/vmcore.2

http://mail.mikej.com/core.txt.2

http://mail.mikej.com/info.2

http://mail.mikej.com/kernel.2

http://mail.mikej.com/kernel.full.2

--mikej

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

RE: New panic in main-n253273-a52d8d4a6c6:

[Michael Jung]

Hi:

I was trying to remember what I did that was odd when this crash occurred then 
it
hit me.  You can repeat this panic by doing:

# watch -I -W pts/0

Here is another panic that happened write after issuing "watch" for comparison.

http://mail.mikej.com/core.txt.1

http://mail.mikej.com/info.1

http://mail.mikej.com/vmcore.1

--mikej

-Original Message-----
From: Michael Jung
Sent: Monday, February 21, 2022 6:22 PM
To: 'Hans Petter Selasky' ; freebsd-current 

Subject: RE: New panic in main-n253273-a52d8d4a6c6:



-Original Message-
From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:53 AM
To: Michael Jung ; freebsd-current 

Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/21/22 14:07, Michael Jung wrote:
> (kgdb) fram 16
> #16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
> fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
> /usr/src/sys/kern/kern_descrip.c:1300
> 1300error = closef(fp, td);
>
> (kgdb) print /x *fdp
> $1 = {fd_files = 0xfe00df6d9000, fd_map = 0xf80001bb1800, fd_freefile 
> = 0x4, fd_refcnt = 0x1, fd_holdcnt = 0x1, fd_sx = {lock_object = {lo_name = 
> 0x8124f6a9, lo_flags = 0x233, lo_data = 0x0,
>lo_witness = 0xf8041eb94000}, sx_lock = 0x1}, fd_kqlist =
> {tqh_first = 0x0, tqh_last = 0x0}, fd_holdleaderscount = 0x0,
> fd_holdleaderswakeup = 0x0}
> (kgdb)

Can you also:

print /x *fp

in the same frame?

--HPS



Unread portion of the kernel message buffer:
panic: refcount 0xf801cc119284 wraparound cpuid = 7 time = 1645382575
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0119a83c80
vpanic() at vpanic+0x17f/frame 0xfe0119a83cd0
panic() at panic+0x43/frame 0xfe0119a83d30
fdclose() at fdclose/frame 0xfe0119a83dc0
closefp_impl() at closefp_impl+0x77/frame 0xfe0119a83e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0119a83f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0119a83f30
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x3309a531b62a, rsp = 
0x3309a2802bc8, rbp = 0x3309a2803000 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,


(kgdb) frame 16
#16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
/usr/src/sys/kern/kern_descrip.c:1300
1300error = closef(fp, td);


(kgdb) print /x *fp
$1 = {f_flag = 0x5, f_count = 0x, f_data = 0xf800158b0400, f_ops = 
0x81b052d0, f_vnode = 0xf800d9156000, f_cred = 0xf801d81be400, 
f_type = 0x1, f_vnread_flags = 0x0, {f_seqcount = {0x0,
  0x0}, f_pipegen = 0x0}, f_nextoff = {0x0, 0x0}, f_vnun = {fvn_cdevpriv = 
0x0, fvn_advice = 0x0}, f_offset = 0x0}
(kgdb)




CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

RE: New panic in main-n253273-a52d8d4a6c6:

[Michael Jung]

-Original Message-
From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:53 AM
To: Michael Jung ; freebsd-current 

Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/21/22 14:07, Michael Jung wrote:
> (kgdb) fram 16
> #16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
> fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
> /usr/src/sys/kern/kern_descrip.c:1300
> 1300error = closef(fp, td);
>
> (kgdb) print /x *fdp
> $1 = {fd_files = 0xfe00df6d9000, fd_map = 0xf80001bb1800, fd_freefile 
> = 0x4, fd_refcnt = 0x1, fd_holdcnt = 0x1, fd_sx = {lock_object = {lo_name = 
> 0x8124f6a9, lo_flags = 0x233, lo_data = 0x0,
>lo_witness = 0xf8041eb94000}, sx_lock = 0x1}, fd_kqlist = 
> {tqh_first = 0x0, tqh_last = 0x0}, fd_holdleaderscount = 0x0, 
> fd_holdleaderswakeup = 0x0}
> (kgdb)

Can you also:

print /x *fp

in the same frame?

--HPS



Unread portion of the kernel message buffer:
panic: refcount 0xf801cc119284 wraparound
cpuid = 7
time = 1645382575
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0119a83c80
vpanic() at vpanic+0x17f/frame 0xfe0119a83cd0
panic() at panic+0x43/frame 0xfe0119a83d30
fdclose() at fdclose/frame 0xfe0119a83dc0
closefp_impl() at closefp_impl+0x77/frame 0xfe0119a83e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0119a83f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0119a83f30
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x3309a531b62a, rsp = 
0x3309a2802bc8, rbp = 0x3309a2803000 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,


(kgdb) frame 16
#16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
/usr/src/sys/kern/kern_descrip.c:1300
1300error = closef(fp, td);


(kgdb) print /x *fp
$1 = {f_flag = 0x5, f_count = 0x, f_data = 0xf800158b0400, f_ops = 
0x81b052d0, f_vnode = 0xf800d9156000, f_cred = 0xf801d81be400, 
f_type = 0x1, f_vnread_flags = 0x0, {f_seqcount = {0x0,
  0x0}, f_pipegen = 0x0}, f_nextoff = {0x0, 0x0}, f_vnun = {fvn_cdevpriv = 
0x0, fvn_advice = 0x0}, f_offset = 0x0}
(kgdb)




CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

RE: New panic in main-n253273-a52d8d4a6c6:

[Michael Jung]

-Original Message-
From: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Hans Petter Selasky
Sent: Monday, February 21, 2022 2:48 AM
To: Michael Jung ; freebsd-current 

Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/20/22 21:53, Michael Jung wrote:
> Hi!
>
> The box was quite busy at the time.  The only odd thing I am aware of
> and which I do not think is related is I have not been able to expand
> one of my zpool's.  ZFS sees my added draid2:2d:10c:0s vdev but I
> can't seem to force zpool's expansion - my bet this is somehow related
> to the mirrored special device in the pool even though autoexpand is set to 
> 'on' for the pool.
>
> Not asking anyone to solve this, I plan on putting together a "how to
> reproduce" and post to freebsd-fs@ but wanted to note this oddity.
>
> --mikej
>
> This is a unmodified GENERIC kernel.
>
>
> Unread portion of the kernel message buffer:
> panic: refcount 0xf801cc119284 wraparound cpuid = 7 time =
> 1645382575
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe0119a83c80
> vpanic() at vpanic+0x17f/frame 0xfe0119a83cd0
> panic() at panic+0x43/frame 0xfe0119a83d30
> fdclose() at fdclose/frame 0xfe0119a83dc0
> closefp_impl() at closefp_impl+0x77/frame 0xfe0119a83e00
> amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0119a83f30
> fast_syscall_common() at fast_syscall_common+0xf8/frame
> 0xfe0119a83f30
> --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x3309a531b62a, rsp =
> 0x3309a2802bc8, rbp = 0x3309a2803000 ---
> KDB: enter: panic
>

This may be a refcount leak. Are you able to dump "fdp" at:

#16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4,
 fp=0xf801cc119280, td=0xfe00df8d0560, audit=true)
 at /usr/src/sys/kern/kern_descrip.c:1300

frame 16
print /x *fdp

--HPS


 [root@draid /var/crash]# kgdb kernel.full.0 vmcore.0
GNU gdb (GDB) 11.2 [GDB v11.2 for FreeBSD]
Copyright (C) 2022 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-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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.full.0...

Unread portion of the kernel message buffer:
panic: refcount 0xf801cc119284 wraparound
cpuid = 7
time = 1645382575
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0119a83c80
vpanic() at vpanic+0x17f/frame 0xfe0119a83cd0
panic() at panic+0x43/frame 0xfe0119a83d30
fdclose() at fdclose/frame 0xfe0119a83dc0
closefp_impl() at closefp_impl+0x77/frame 0xfe0119a83e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0119a83f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0119a83f30
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x3309a531b62a, rsp = 
0x3309a2802bc8, rbp = 0x3309a2803000 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,

(kgdb) fram 16
#16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
/usr/src/sys/kern/kern_descrip.c:1300
1300error = closef(fp, td);

(kgdb) print /x *fdp
$1 = {fd_files = 0xfe00df6d9000, fd_map = 0xf80001bb1800, fd_freefile = 
0x4, fd_refcnt = 0x1, fd_holdcnt = 0x1, fd_sx = {lock_object = {lo_name = 
0x8124f6a9, lo_flags = 0x233, lo_data = 0x0,
  lo_witness = 0xf8041eb94000}, sx_lock = 0x1}, fd_kqlist = {tqh_first 
= 0x0, tqh_last = 0x0}, fd_holdleaderscount = 0x0, fd_holdleaderswakeup = 0x0}
(kgdb)




CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
210

New panic in main-n253273-a52d8d4a6c6:

[Michael Jung]

Hi!

The box was quite busy at the time.  The only odd thing I am aware of and which 
I do
not think is related is I have not been able to expand one of my zpool's.  ZFS 
sees my
added draid2:2d:10c:0s vdev but I can't seem to force zpool's expansion - my 
bet this
is somehow related to the mirrored special device in the pool even though 
autoexpand
is set to 'on' for the pool.

Not asking anyone to solve this, I plan on putting together a "how to 
reproduce" and
post to freebsd-fs@ but wanted to note this oddity.

--mikej

This is a unmodified GENERIC kernel.


Unread portion of the kernel message buffer:
panic: refcount 0xf801cc119284 wraparound
cpuid = 7
time = 1645382575
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0119a83c80
vpanic() at vpanic+0x17f/frame 0xfe0119a83cd0
panic() at panic+0x43/frame 0xfe0119a83d30
fdclose() at fdclose/frame 0xfe0119a83dc0
closefp_impl() at closefp_impl+0x77/frame 0xfe0119a83e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0119a83f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0119a83f30
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x3309a531b62a, rsp = 
0x3309a2802bc8, rbp = 0x3309a2803000 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55   __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=textdump@entry=0)
at /usr/src/sys/kern/kern_shutdown.c:399
#2  0x804c86ba in db_dump (dummy=,
dummy2=, dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:575
#3  0x804c8572 in db_command (last_cmdp=,
cmd_table=, dopager=dopager@entry=1)
at /usr/src/sys/ddb/db_command.c:482
#4  0x804c81cd in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:535
#5  0x804cb806 in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:270
#6  0x80c566fb in kdb_trap (type=type@entry=3, code=code@entry=0,
tf=tf@entry=0xfe0119a83bb0) at /usr/src/sys/kern/subr_kdb.c:733
#7  0x810e75ca in trap (frame=0xfe0119a83bb0)
at /usr/src/sys/amd64/amd64/trap.c:609
#8  
#9  kdb_enter (why=0x812e5eaf "panic", msg=)
at /usr/src/sys/kern/subr_kdb.c:506
#10 0x80c08c50 in vpanic (
fmt=0x8122606d "refcount %p wraparound",
ap=ap@entry=0xfe0119a83d10) at /usr/src/sys/kern/kern_shutdown.c:908
#11 0x80c089e3 in panic (
fmt=0x81e8cf40  "\332#*\201\377\377\377\377")
at /usr/src/sys/kern/kern_shutdown.c:844
#12 0x80ba9180 in _refcount_update_saturated (count=0xf801cc119284)
at /usr/src/sys/sys/refcount.h:55
#13 refcount_releasen (count=0xf801cc119284, n=1)
at /usr/src/sys/sys/refcount.h:154
#14 refcount_release (count=0xf801cc119284)
at /usr/src/sys/sys/refcount.h:174
#15 closef (fp=, td=0xfe00df8d0560)
at /usr/src/sys/kern/kern_descrip.c:2776
#16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4,
fp=0xf801cc119280, td=0xfe00df8d0560, audit=true)
at /usr/src/sys/kern/kern_descrip.c:1300
#17 0x810e838e in syscallenter (td=)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189
#18 amd64_syscall (td=0xfe00df8d0560, traced=0)
at /usr/src/sys/amd64/amd64/trap.c:1191
#19 
#20 0x3309a531b62a in ?? ()
Backtrace stopped: Cannot access memory at address 0x3309a2802bc8
(kgdb)




http://mail.mikej.com/core.txt.0

http://mail.mikej.com/info.0

http://mail.mikej.com/kernel.full.0

http://mail.mikej.com/vmcore.0




CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious 

FW: pciconf -lbvV crashes kernel main-8d72c409c - 2022-02-07

[Michael Jung]

Hi:

Here are the kernel.full files some of you asked for.  Let me know what else
may be helpful to test.

Thanks!

Michael Jung

Notes below * (UPDATED)

* Started fresh

Installed FreeBSD-14.0-CURRENT-amd64-20220113-0910a41ef3b-252413-disc1.iso
with its accompany source tree. Built kernel/world, installed them, rebooted and

http://mail.mikej.com/core.txt.0
http://mail.mikej.com/info.0
http://mail.mikej.com/kernel.full.0
http://mail.mikej.com/vmcore.0

* I deleted all contents from /usr/obj built fresh /usr/src via git to 
b6724f7004c and

14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252997-b6724f7004c

http://mail.mikej.com/core.txt.1
http://mail.mikej.com/info.1
http://mail.mikej.com/kernel.full.1
http://mail.mikej.com/vmcore.1


* It's the '-V' switch that triggers the panic
* I did note that pciconf does not identify my CPU correctly (see below)
* The panic always occurs after ix0 output from pciconf -lbvV (see below)
ix1 has always followed next with -lbv - it has never been present 
with -lbvV
*  Switching the LSI 9208-16E and Intel dual port X520 PCI slots did not 
help
*   ixl1 definitely works using the exact same SPF+ adapter and cable
*   Removing the Intel X520 82599ES allow pciconf -lbvV to run
*   I have a single port version of this intel X520 which works

It seem to me, that when pciconf iterates to ix1@pci0:2:0:1 the problem always 
occurs.

I build like this:

nice make -WITH_META_MODE -DFAST_DEPEND -DWITHOUT_CLEAN -sj12 buildworld
nice make -WITH_META_MODE -DFAST_DEPEND -DWITHOUT_CLEAN -sj12 buildkernel

root@draid:/var/crash # cat /etc/make.conf
WITH_CCACHE_BUILD=yes
CCACHE_DIR=/root/.ccache
root@draid:/var/crash

There is no src.conf or sysctl.conf and I have only added '"filemon_load="YES"'
to /boot/loader.conf



* I did Note that pciconf does not identify my CPU correctly

It is actually an Intel Core i7-3770K - a sample programs in ports that gets it
right is sysutils/cpufetch.



* Here is "-vlb"


root@draid:/home/mikej # pciconf -vlb

pciconf -lvb
hostb0@pci0:0:0:0:  class=0x06 rev=0x09 hdr=0x00 vendor=0x8086 
device=0x0150 subvendor=0x1043 subdevice=0x844d
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:   class=0x060400 rev=0x09 hdr=0x01 vendor=0x8086 
device=0x0151 subvendor=0x1043 subdevice=0x844d
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:1:1:   class=0x060400 rev=0x09 hdr=0x01 vendor=0x8086 
device=0x0155 subvendor=0x1043 subdevice=0x844d
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
none0@pci0:0:22:0:  class=0x078000 rev=0x04 hdr=0x00 vendor=0x8086 
device=0x1c3a subvendor=0x1043 subdevice=0x844d
vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family MEI Controller'
class  = simple comms
bar   [10] = type Memory, range 64, base 0xf7f0b000, size 16, enabled
ehci0@pci0:0:26:0:  class=0x0c0320 rev=0x05 hdr=0x00 vendor=0x8086 
device=0x1c2d subvendor=0x1043 subdevice=0x844d
vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family USB Enhanced Host 
Controller'
class  = serial bus
subclass   = USB
bar   [10] = type Memory, range 32, base 0xf7f08000, size 1024, enabled
hdac1@pci0:0:27:0:  class=0x040300 rev=0x05 hdr=0x00 vendor=0x8086 
device=0x1c20 subvendor=0x1043 subdevice=0x8469
vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family High Definition Audio 
Controller'
class  = multimedia
subclass   = HDA
bar   [10] = type Memory, range 64, base 0xf7f0, size 16384, enabled
pcib3@pci0:0:28:0:  class=0x060400 rev=0xb5 hdr=0x01 vendor=0x8086 
device=0x1c10 subvendor=0x1043 subdevice=0x844d
vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family PCI Express Root Port 1'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:4:  class=0x060400 rev=0xb5 hdr=0x01 vendor=0x8086 
device=0x1c18 subvendor=0x1043 subdevice=0x844d
vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family PCI Express Root Port 5'
class  = bridge
subclass   = PCI-PCI
pcib5@pci0:0:28:5:  class=0x060400 rev=0xb5 hdr=0x01 vendor=0x8086 
device=0x1c1a subvendor=0x1043 subdevice=0x844d
vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family PCI Express Root Port 6'
class  = bridge
subclass   = PCI-PCI
pcib6@pci0:0:28:6:  class=0x060400 rev=0xb5 hdr=0x01 vendor=0x8086 
device=0x1c1c subvendor=0x1043 subdevice=0x844

pciconf -lbvV crashes kernel main-8d72c409c

[Michael Jung]

Dump header from device: /dev/ada0p2
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 900231168
  Blocksize: 512
  Compression: none
  Dumptime: 2022-02-04 15:48:08 -0500
  Hostname: draid.mikej.com
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 14.0-CURRENT #1 main-8d72c409c: Thu Feb 3 18:14:01 
EST 2022
mikej@draid:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
  Panic String: length mismatch
  Dump Parity: 1692982593
  Bounds: 2
  Dump Status: good

http://mail.mikej.com/info.2

http://mail.mikej.com/core.txt.2

http://mail.mikej.com/vmcore.2

This is a test system, nothing of value is store in these files.



CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

13.0-CURRENT #22 r369328 - possible deadlock detected

[Michael Jung]

Hi:

So I've had a crash - below is the relevant information.

FreeBSD firewall.mikej.com 13.0-CURRENT FreeBSD 13.0-CURRENT #22 r369328: Sun 
Feb 21 09:26:46 EST 2021 
mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
 amd64

http://firewall.mikej.com/core.txt.0

My FreeBSD server is virutalized under ESXi 6.7 with 3x passthough LSI-2008 
HBA's.  UFS on boot, and several ZFS pools via

the LSI controllers.  I have been running this setup since FreeBSD 9.x/ESXi 5.5 
without issue and I have never had

kernel panics until upgrading to FreeBSD 13.x.

I have no way to suggest to you on how to reproduce the panic as it has only 
occurred once.

I have since upgraded to FreeBSD 13.0-STABLE #23 stable/13-6f6c64800 so this is 
an informational email.  If the crash

occurs again I will post back to the list.



Thanks!



[cid:49af0ee7107c922eb53f7a0163f58961@mikej.com]



CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.
___
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: GELI attach issue from r326073 -> r334996

[Michael Jung]

On 2018-06-13 15:27, Ian Lepore wrote:

On Wed, 2018-06-13 at 14:29 -0400, Michael Jung wrote:

Hi!

I just tried updating current from r326073 -> r334996 and when
I try 'geli attach' I get the following error:

# geli attach -p -k mykey.key /dev/gpt/da14
geli: Missing keyno argument
#

If I boot the old kernel GELI attaches just fine.

I ran into this once before but can not find the thread.  I recall
it being a bug... with no resolution.

I mount zfs partitions over GELI - my painful solution was to
nuke each GPT partition in the zpool, resilver, repeat and
rinse until everything was non-encrypted and repeat the cycle
to re-encrypt.  NOT FUN.

Looking for suggestions to supply additional information to debug
and resolve.

dmesg attached from working kernel.

Thanks!


r333439 added a '-n keyno' parameter to geli attach, but it's supposed
to default to trying all keys if you don't use -n. Is it possible
you're running a newer kernel (or geom_eli module) than your userland
or vice versa?

-- Ian


___
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"


Ian:

Yes you are correct Maybe not the best method but I normally 
installkernel -
boot into single user mode - GELI attach, zfs mount -av, then 
installworld.


My boot volume is UFS, but many of the mount points are on zpools.

What would be the best way to test a new kernel without a full 
installworld

with new userland geli bits?

I currently don't have a way to backup my 35TB of data :-( and don't 
want to
lose anything. and I need a back out method should a full 
installworld fail.


Thanks for you quick reply.

--mikej
___
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"

GELI attach issue from r326073 -> r334996

[Michael Jung]

Hi!

I just tried updating current from r326073 -> r334996 and when
I try 'geli attach' I get the following error:

# geli attach -p -k mykey.key /dev/gpt/da14
geli: Missing keyno argument
#

If I boot the old kernel GELI attaches just fine.

I ran into this once before but can not find the thread.  I recall
it being a bug... with no resolution.

I mount zfs partitions over GELI - my painful solution was to
nuke each GPT partition in the zpool, resilver, repeat and
rinse until everything was non-encrypted and repeat the cycle
to re-encrypt.  NOT FUN.

Looking for suggestions to supply additional information to debug
and resolve.

dmesg attached from working kernel.

Thanks!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 12.0-CURRENT #2 r326073: Tue Nov 21 18:03:29 EST 2017
mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
5.0.0svn)
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): text 80x25
CPU: Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz (3400.02-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
  
Features=0xfa3fbff
  
Features2=0x9e982203
  AMD Features=0x28100800
  AMD Features2=0x1
  TSC: P-state invariant
Hypervisor: Origin = "VMwareVMware"
real memory  = 17179869184 (16384 MB)
avail memory = 16548577280 (15781 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 8 package(s) x 1 core(s)
random: unblocking device.
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0  irqs 0-23 on motherboard
SMP: AP CPU #5 Launched!
SMP: AP CPU #7 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #1 Launched!
SMP: AP CPU #6 Launched!
SMP: AP CPU #4 Launched!
SMP: AP CPU #2 Launched!
random: entropy device external interface
netmap: loaded module
[ath_hal] loaded
module_register_init: MOD_LOAD (vesa, 0x80f95c20, 0) error 19
kbd1 at kbdmux0
nexus0
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
cpu0:  numa-domain 0 on acpi0
cpu1:  numa-domain 0 on acpi0
cpu2:  numa-domain 0 on acpi0
cpu3:  numa-domain 0 on acpi0
cpu4:  numa-domain 0 on acpi0
cpu5:  numa-domain 0 on acpi0
cpu6:  numa-domain 0 on acpi0
cpu7:  numa-domain 0 on acpi0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
atrtc0:  port 0x70-0x71 irq 8 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: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1060-0x106f at device 7.1 on pci0
ata0:  at channel 0 on atapci0
ata1:  at channel 1 on atapci0
pci0:  at device 7.3 (no driver attached)
vgapci0:  port 0x1070-0x107f mem 
0xec00-0xefff,0xfe00-0xfe7f irq 16 at device 15.0 on pci0
vgapci0: Boot video device
mpt0:  port 0x1400-0x14ff mem 
0xfeba-0xfebb,0xfebc-0xfebd irq 17 at device 16.0 on pci0
mpt0: MPI Version=1.2.0.0
pcib2:  at device 17.0 on pci0
pci2:  on pcib2
em0:  port 0x2000-0x203f mem 
0xfd5c-0xfd5d,0xfdff-0xfdff irq 18 at device 0.0 on pci2
em0: attach_pre capping queues at 1
em0: using 1024 tx descriptors and 1024 rx descriptors
em0: allocated for 1 tx_queues
em0: allocated for 1 rx_queues
em0: Ethernet address: 00:0c:29:cc:f7:ac
Link state changed to up
em0: link state changed to UP
em0: netmap queues/slots: TX 1/1024, RX 1/1024
uhci0:  port 0x2040-0x205f irq 16 at device 2.0 
on pci2
usbus0 on uhci0
usbus0: 12Mbps Full Speed USB v1.0
ehci0:  mem 0xfd5ef000-0xfd5e irq 17 at 
device 3.0 on pci2
usbus1: EHCI version 1.0
usbus1 on ehci0
usbus1: 480Mbps High Speed USB v2.0
pcib3:  at device 21.0 on pci0
pcib3: [GIANT-LOCKED]
pci3:  on pcib3
mps0:  port 0x4000-0x40ff mem 
0xfd4fc000-0xfd4f,0xfd48-0xfd4b irq 18 at device 0.0 on pci3
mps0: Firmware: 19.00.00.00, Driver: 21.02.00.00-fbsd
mps0: IOCCapabilities: 
1285c
pcib4:  at device 21.1 on pci0
pcib4: [GIANT-LOCKED]
pcib5:  at device 21.2 on pci0
pcib5: [GIANT-LOCKED]
pcib6:  at device 21.3 on pci0
pcib6: [GIANT-LOCKED]
pcib7:  at device 21.4 on pci0
pcib7: [GIANT-LOCKED]
pcib8:  at device 21.5 on pci0
pcib8: [GIANT-LOCKED]
pcib9:  at device 21.6 on pci0
pcib9: [GIANT-LOCKED]
pcib10:  at device 21.7 on pci0

Re: witness_lock_list_get: witness exhausted

[Michael Jung]

On 2018-01-08 13:39, John Baldwin wrote:

On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote:

Hi!

I've recently up'd my processor count on our poudriere box and have
started noticing the error
"witness_lock_list_get: witness exhausted" on the console.  The kernel
*DOES NOT* crash but I
thought the report may be useful to someone.

$ uname -a
FreeBSD poudriere 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r325999: Sun 
Nov

19 18:41:20 EST 2017
mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

The machine is pretty busy running four poudriere build instances.

last pid: 76584;  load averages: 115.07, 115.96, 98.30

  up 6+07:32:59  14:44:03
763 processes: 117 running, 581 sleeping, 2 zombie, 63 lock
CPU: 59.0% user,  0.0% nice, 40.7% system,  0.1% interrupt,  0.1% idle
Mem: 12G Active, 2003M Inact, 44G Wired, 29G Free
ARC: 28G Total, 11G MFU, 16G MRU, 122M Anon, 359M Header, 1184M Other
  25G Compressed, 32G Uncompressed, 1.24:1 Ratio

Let me know what additional information I might supply.


This just means that WITNESS stopped working because it ran out of
pre-allocated objects.  In particular the objects used to track how
many locks are held by how many threads:

/*
 * XXX: This is somewhat bogus, as we assume here that at most 2048 
threads

 * will hold LOCK_NCHILDREN locks.  We handle failure ok, and we should
 * probably be safe for the most part, but it's still a SWAG.
 */
#define LOCK_NCHILDREN  5
#define LOCK_CHILDCOUNT 2048

Probably the '2048' (max number of concurrent threads) needs to scale 
with

MAXCPU.  2048 threads is probably a bit low on big x86 boxes.



Thank you for you explanation.  We are expanding our ESXi cluster and 
even
though with standard edition I can only assign 64 vCPU's to a guest and 
as much
RAM as I want, I do like to help with edge cases if I can make them 
occur pushing

boundaries as I can towards additianional improvements in FreeBSD.

--mikej
___
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"

witness_lock_list_get: witness exhausted

[Michael Jung]

Hi!

I've recently up'd my processor count on our poudriere box and have 
started noticing the error
"witness_lock_list_get: witness exhausted" on the console.  The kernel 
*DOES NOT* crash but I

thought the report may be useful to someone.

$ uname -a
FreeBSD poudriere 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r325999: Sun Nov 
19 18:41:20 EST 2017

mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

The machine is pretty busy running four poudriere build instances.

last pid: 76584;  load averages: 115.07, 115.96, 98.30   
 
 up 6+07:32:59  14:44:03

763 processes: 117 running, 581 sleeping, 2 zombie, 63 lock
CPU: 59.0% user,  0.0% nice, 40.7% system,  0.1% interrupt,  0.1% idle
Mem: 12G Active, 2003M Inact, 44G Wired, 29G Free
ARC: 28G Total, 11G MFU, 16G MRU, 122M Anon, 359M Header, 1184M Other
 25G Compressed, 32G Uncompressed, 1.24:1 Ratio

Let me know what additional information I might supply.


Thanks!
--mikej
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 12.0-CURRENT #1 r325999: Sun Nov 19 18:41:20 EST 2017
mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 
5.0.0svn)
WARNING: WITNESS option enabled, expect reduced performance.
VT(vga): text 80x25
CPU: Intel(R) Xeon(R) CPU E7- 4850  @ 2.00GHz (1995.00-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x206f2  Family=0x6  Model=0x2f  Stepping=2
  
Features=0x1fa3fbff
  
Features2=0x83b82203
  AMD Features=0x28100800
  AMD Features2=0x1
  Structured Extended Features=0x2
  TSC: P-state invariant
Hypervisor: Origin = "VMwareVMware"
real memory  = 96636764160 (92160 MB)
avail memory = 93873786880 (89525 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 60 CPUs
FreeBSD/SMP: 6 package(s) x 10 core(s)
random: unblocking device.
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0  irqs 0-23 on motherboard
SMP: AP CPU #46 Launched!
SMP: AP CPU #16 Launched!
SMP: AP CPU #7 Launched!
SMP: AP CPU #51 Launched!
SMP: AP CPU #20 Launched!
SMP: AP CPU #15 Launched!
SMP: AP CPU #1 Launched!
SMP: AP CPU #48 Launched!
SMP: AP CPU #23 Launched!
SMP: AP CPU #27 Launched!
SMP: AP CPU #12 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #55 Launched!
SMP: AP CPU #17 Launched!
SMP: AP CPU #52 Launched!
SMP: AP CPU #18 Launched!
SMP: AP CPU #39 Launched!
SMP: AP CPU #11 Launched!
SMP: AP CPU #41 Launched!
SMP: AP CPU #58 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #26 Launched!
SMP: AP CPU #37 Launched!
SMP: AP CPU #45 Launched!
SMP: AP CPU #40 Launched!
SMP: AP CPU #35 Launched!
SMP: AP CPU #53 Launched!
SMP: AP CPU #50 Launched!
SMP: AP CPU #44 Launched!
SMP: AP CPU #34 Launched!
SMP: AP CPU #30 Launched!
SMP: AP CPU #31 Launched!
SMP: AP CPU #47 Launched!
SMP: AP CPU #13 Launched!
SMP: AP CPU #28 Launched!
SMP: AP CPU #49 Launched!
SMP: AP CPU #54 Launched!
SMP: AP CPU #8 Launched!
SMP: AP CPU #57 Launched!
SMP: AP CPU #29 Launched!
SMP: AP CPU #4 Launched!
SMP: AP CPU #24 Launched!
SMP: AP CPU #33 Launched!
SMP: AP CPU #38 Launched!
SMP: AP CPU #59 Launched!
SMP: AP CPU #9 Launched!
SMP: AP CPU #42 Launched!
SMP: AP CPU #5 Launched!
SMP: AP CPU #6 Launched!
SMP: AP CPU #43 Launched!
SMP: AP CPU #14 Launched!
SMP: AP CPU #19 Launched!
SMP: AP CPU #10 Launched!
SMP: AP CPU #25 Launched!
SMP: AP CPU #56 Launched!
SMP: AP CPU #36 Launched!
SMP: AP CPU #22 Launched!
SMP: AP CPU #32 Launched!
SMP: AP CPU #21 Launched!
random: entropy device external interface
netmap: loaded module
[ath_hal] loaded
module_register_init: MOD_LOAD (vesa, 0x80f95c20, 0) error 19
kbd1 at kbdmux0
nexus0
vtvga0:  on motherboard
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
cpu0:  numa-domain 0 on acpi0
cpu1:  numa-domain 5 on acpi0
cpu2:  numa-domain 5 on acpi0
cpu3:  numa-domain 5 on acpi0
cpu4:  numa-domain 5 on acpi0
cpu5:  numa-domain 5 on acpi0
cpu6:  numa-domain 5 on acpi0
cpu7:  numa-domain 5 on acpi0
cpu8:  numa-domain 5 on acpi0
cpu9:  numa-domain 5 on acpi0
cpu10:  numa-domain 5 on acpi0
cpu11:  numa-domain 4 on acpi0
cpu12:  numa-domain 4 on acpi0
cpu13:  numa-domain 4 on acpi0
cpu14:  numa-domain 4 on acpi0
cpu15:  numa-domain 4 on acpi0
cpu16:  numa-domain 4 on acpi0
cpu17:  numa-domain 4 on acpi0
cpu18:  numa-domain 4 on acpi0
cpu19:  numa-domain 4 on acpi0

fatal error: 'wmmintrin.h' file not found

[Michael Jung]

I have started having problem building current more recent versions of 
current.


I am currently running

FreeBSD bsd11 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320869: Mon Jul 10 
13:57:55 UTC 2017 
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64


I have tried nuking /usr/src and doing a fresh svn checkout of the 
current running version

to see if I could rebuild even my current version r320869


[root@bsd11 /usr/src]# svnlite info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 320869
Node Kind: directory
Schedule: normal
Last Changed Author: bde
Last Changed Rev: 320869
Last Changed Date: 2017-07-10 05:00:35 -0400 (Mon, 10 Jul 2017)

/etc/make.conf and /etc/src.conf are empty.

I have

cd /obj
rm -rf

and made sure no remaining files or directories remain.

make buildwould -s


continues to fail as shown below.



cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -c -O3 -pipe -fno-strict-aliasing -Werror 
-D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common 
-g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mno-mmx 
-mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding 
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign 
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs 
-fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-error-address-of-packed-member -Wno-error-cast-qual -mno-aes 
-mno-avx -std=iso9899:1999 -Werror   -mmmx -msse -msse4 -maes -mpclmul 
/usr/src/sys/crypto/aesni/aesni_ghash.c
/usr/src/sys/crypto/aesni/aesni_ghash.c:75:10: fatal error: 
'wmmintrin.h' file not found

#include 
 ^
1 error generated.
*** Error code 1

Stop.
make[4]: stopped in /usr/src/sys/modules/aesni
*** Error code 1

Stop.
make[3]: stopped in /usr/src/sys/modules
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/sys/GENERIC
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src


Pointers?

Thank you.
___
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: r320358 panics immediately on boot / AMD64-GENERIC kernel

[Michael Jung]

On 2017-06-27 12:16, Eric van Gyzen wrote:

On 06/27/2017 11:09, Michael Jung wrote:

Screen image with backtrace

https://pasteboard.co/dZRVG5Uo.jpg


After upgrading from 318959 to 320358 I immediately get the attached 
panic.


This is AMD64 / GENERIC kernel.

/boot/loader.conf is empty.

The system boots off a UFS2 partition.

This is a virtual guest and I do currently have a serial cable.

Short of figuring out how to virtualize a serial console from a ESXi
guest is
there any more information I can provide?


Someone else hit this.  Removing the contents of /usr/obj and 
rebuilding

fixed it for him.  Apparently, some of the objects didn't get rebuilt,
as needed.

Eric



Thank to all that replied.  Indeed removing the contents of /usr/obj and 
rebuilding

the kernel resolved the issue.

Thanks!

--mikej
___
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"

r320358 panics immediately on boot / AMD64-GENERIC kernel

[Michael Jung]

After upgrading from 318959 to 320358 I immediately get the attached 
panic.


This is AMD64 / GENERIC kernel.

/boot/loader.conf is empty.

The system boots off a UFS2 partition.

This is a virtual guest and I do currently have a serial cable.

Short of figuring out how to virtualize a serial console from a ESXi 
guest is

there any more information I can provide?

Thanks.

Mike
___
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"

r320358 panics immediately on boot / AMD64-GENERIC kernel

[Michael Jung]

Screen image with backtrace

https://pasteboard.co/dZRVG5Uo.jpg


After upgrading from 318959 to 320358 I immediately get the attached 
panic.


This is AMD64 / GENERIC kernel.

/boot/loader.conf is empty.

The system boots off a UFS2 partition.

This is a virtual guest and I do currently have a serial cable.

Short of figuring out how to virtualize a serial console from a ESXi 
guest is

there any more information I can provide?

Thanks.

Mike
___
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

[Michael Jung]

On 2017-04-28 17:42, Andriy Gapon wrote:

On 28/04/2017 14:56, Michael Jung wrote:

I have mad the requested change..

[root@bsd11 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs]# 
diff zio.c

~mikej/zio.c.orig
965c965
< size, NULL, NULL, ZIO_TYPE_FREE, ZIO_PRIORITY_NOW,
---
BP_GET_PSIZE(bp), NULL, NULL, ZIO_TYPE_FREE, 
ZIO_PRIORITY_NOW,


Yes, that's the change that I had in mind.
I was a little bit confused by the order of the original and modified 
files,

though :-)


[root@bsd11 /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs]#

As to the pool size:

[root@bsd11 /usr/home/mikej]# zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAGCAP  DEDUP  HEALTH  
ALTROOT

tank   199G   143G  55.9G -85%71%  1.00x  ONLINE  -
[root@bsd11 /usr/home/mikej]#

I should have also mentioned that besides poudriere running a build, 
it was
removing old logs - There was some 43G of old logs files that were in 
the process

of being removed.


So, given that the panic was in the freeing path, you were probably low 
on the
pool space back when those log files were created.  I mean that the 
gang blocks

are typically created when a pool is very fragmented.

I will hammer the box with and report back first of the week whether 
the panic

re-occurs or not.


Please also try removing those old files again too.
Running zpool scrub afterwards could be a good idea too.

Thank you again!


Andriy:

I am happy to report that the system no longer panics.  As requested I 
removed
the remaining logs (34G worth) and punished the file system as hard as I 
could.


A scrub of the pool completed without error

Will the change be committed or do I need to open a PR?

Please let me know if I can supply additional information or if there 
are any

further tests you would like me to perform.

Thanks again for you prompt reply and apparent solution.

Regards,

Michael Jung
___
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

[Michael Jung]

On 2017-04-27 17:57, Andriy Gapon wrote:

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  0x80ed2de6 in trap (frame=0xfe086140e780)
at /usr/src/sys/amd64/amd64/trap.c:537
#7  0x80eb54e1 in

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

[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: head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774

[Michael Jung]

On 2016-06-02 18:17, Ngie Cooper wrote:

On Thu, Jun 2, 2016 at 3:05 PM, Michael Jung <mi...@mikej.com> wrote:

On 2016-06-01 12:37, Michael Jung wrote:


Since upgrading to head r301040 I have started to get the above panic
while running
poudriere while building packages for 10.3-STABLE r301107.

Unfortuately I can't tell you the previous version of head but it was 
from

some
months ago.


https://charon.gopai.com/core.txt.7

https://charon.gopai.com/info.7

I also have the full core file if needed.

Let me know what else I can provide.

Thank you.


Ideas? - there was another report of the same panic in vm_page.c

http://postimg.org/image/r78vxopkb/

I see from the web log 20+ people have looked at the core file

I can bump my build server but I was awaiting a response to the panic
before doing that.


It might have been fixed by r301212. CCing Kostik/Mark.
Thanks!
-Ngie
___
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"\


I pulling latest head based on comments r301229 - and will report back
in next 48 hours - The crashes where not predictable but would always 
seem to

occur within 12 hours of running poudriere builds.

Thanks!
___
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: head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774

[Michael Jung]

On 2016-06-01 12:37, Michael Jung wrote:

Since upgrading to head r301040 I have started to get the above panic
while running
poudriere while building packages for 10.3-STABLE r301107.

Unfortuately I can't tell you the previous version of head but it was 
from some

months ago.


https://charon.gopai.com/core.txt.7

https://charon.gopai.com/info.7

I also have the full core file if needed.

Let me know what else I can provide.

Thank you.
___
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"



Ideas? - there was another report of the same panic in vm_page.c

http://postimg.org/image/r78vxopkb/

I see from the web log 20+ people have looked at the core file

I can bump my build server but I was awaiting a response to the panic
before doing that.

Thanks all.

--mikej

___
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"

head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774

[Michael Jung]

Since upgrading to head r301040 I have started to get the above panic 
while running

poudriere while building packages for 10.3-STABLE r301107.

Unfortuately I can't tell you the previous version of head but it was 
from some

months ago.


https://charon.gopai.com/core.txt.7

https://charon.gopai.com/info.7

I also have the full core file if needed.

Let me know what else I can provide.

Thank you.
___
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: Call for testing: Using ELF Tool Chain elfcopy as objcopy

[Michael Jung]

On 2016-02-16 14:04, Ed Maste wrote:

Summary: If you're willing to help test the ELF Tool Chain tools and
you build -CURRENT from source, please set WITH_ELFCOPY_AS_OBJCOPY=yes
in /etc/src.conf, and report any build- or run-time issues you
experience with the base system, ports, or third-party software.

In SVN revision 295577 I updated ELF Tool Chain to upstream revision
3400, which corresponds roughly with the upcoming 0.7.1 release of
that project.  ELF Tool Chain's elfcopy is a functional replacement
for binutils objcopy for both the base system and ports tree after
this update and a few followup commits. (An exp-run is in progress in
PR 207091 to validate the followup fixes. One port failure is due to
an issue in that port and is tracked in PR 207170.)

There is a src.conf knob WITH_ELFCOPY_AS_OBJCOPY to install ELF Tool
Chain's elfcopy as /usr/bin/objcopy. I plan to make this the default
for 11.0, but first would like to ask for broader testing with the
setting enabled. I'm particularly interested in hearing from anyone
using the base system objcopy in unusual cases (e.g., converting ELF
files to ROM images).

Note that some lesser-used objcopy options (like --reverse-bytes or
--interleave-width) are not implemented in elfcopy, so I'm also
interested in hearing from anyone who makes use of options that are
not supported by elfcopy.
___
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 bsd11-elf-test 11.0-CURRENT FreeBSD 11.0-CURRENT #18 r295677M: 
Tue Feb 16 17:49:26 EST 2016 root@bsd11:/usr/obj/usr/src/sys/GENERIC 
 amd64


which was built with

WITH_ELFCOPY_AS_OBJCOPY=yes

in /etc/src.conf

has built 1400+ ports, via poudriere working without build errors,
applications like chrome, libre office, eclipse, xfce4 seem to run fine.

These tests are all in a VM under Esxi 6 using Xming as the X server.

Thanks for you work.

--mikej
Michael Jung

___
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"

r291494 PANIC mtx_lock() of spin mutex @ /usr/src/sys/kern/vfs_subr.c:512

[Michael Jung]

Since upgrading to r291494 from r290716 my system reliably panics when 
running poudriere.


Dump header from device: /dev/da2p1
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 4301131776
  Blocksize: 512
  Dumptime: Wed Dec  2 12:10:06 2015
  Hostname: bsd11
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 11.0-CURRENT #9 r291494: Mon Nov 30 13:21:08 
EST 2015

mikej@bsd11:/usr/obj/usr/src/sys/GENERIC
  Panic String: mtx_lock() of spin mutex  @ 
/usr/src/sys/kern/vfs_subr.c:512

  Dump Parity: 2232113789
  Bounds: 1
  Dump Status: good



https://charon.gopai.com/crash/info.1

https://charon.gppai.com/crash/core.txt.1

https://charon.gopai.com/crash/vmcore.1

I could not find a reference to this panic.

Regards,

--mikej

___
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"

two different solaris asserts in r288019

[Michael Jung]

This is my poudriere build box that has been running current for a very 
long time.  It was recently upgraded to r288019 and since then I have 
been getting these panics. One panic I could not find reported, maybe 
additional information here.


I followed the thread here 
http://lists.freebsd.org/pipermail/freebsd-fs/2015-August/021856.html 
but haven't found any movement.


Regards,

--mikej

Dump header from device: /dev/da2p1
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 3271299072
  Blocksize: 512
  Dumptime: Thu Sep 24 17:10:33 2015
  Hostname: bsd11
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 11.0-CURRENT #0 r288019: Sun Sep 20 17:16:46 
EDT 2015

mikej@bsd11:/usr/obj/usr/src/sys/GENERIC
  Panic String: solaris assert: avl_is_empty(>dn_dbufs), file: 
/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c, 
line: 495

  Dump Parity: 3609444522
  Bounds: 1
  Dump Status: good

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


Dump header from device: /dev/da2p1
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 3141214208
  Blocksize: 512
  Dumptime: Mon Sep 28 08:19:47 2015
  Hostname: bsd11
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 11.0-CURRENT #0 r288019: Sun Sep 20 17:16:46 
EDT 2015

mikej@bsd11:/usr/obj/usr/src/sys/GENERIC
  Panic String: solaris assert: (dn->dn_phys->dn_nlevels == 0 && 
db->db_level == 0) || dn->dn_phys->dn_nlevels > db->db_level || 
dn->dn_next_nlevels[txgoff] > db->db_level || 
dn->dn_next_nlevels[(tx->tx_txg-

  Dump Parity: 1563774101
  Bounds: 2
  Dump Status: good

https://charon.gopai.com/info.2
https://charon.gopai.com/core.txt.2
https://charon.gopai.com/vmcore.2

___
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"

pkg 1.4.0.alpha3 - pkg: pkg_repo_fetch_remote_mmap(cannot mmap fetched): Invalid argument / Assertion failed: (curvar != NULL), function pkg_solve_add_request_rule, file pkg_solve.c, line 537.

[Michael Jung]

Hello:

Errors shown toward end of email.

Note this is a cleanly installed jail but an previously built repository 
from an older
version of head.  I can nuke the head repository and rebuild from 
scratch but I wanted to

present these errors first.

--mikej


FreeBSD bsd11 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r273857: Thu Oct 30 
08:50:37 EDT 2014

mikej@bsd11:/usr/obj/usr/src/sys/GENERIC  amd64

JAILNAME  VERSION ARCH  METHOD TIMESTAMP   PATH
10stable  10.1-PRERELEASE r273580 amd64 svn2014-10-24 11:10:51 
/usr/local/poudriere/jails/10stable
head  11.0-CURRENT r273858amd64 svn2014-10-30 10:45:31 
/usr/local/poudriere/jails/head
9stable   9.2-STABLE  amd64 svn
/usr/local/poudriere/jails/9stable
9stable32 9.2-STABLE  i386  ftp
/usr/local/poudriere/jails/9stable32


root@bsd11:~ # pkg -vv
Version : 1.4.0.alpha3
PKG_DBDIR = /var/db/pkg;
PKG_CACHEDIR = /var/cache/pkg;
PORTSDIR = /usr/ports;
INDEXDIR = ;
INDEXFILE = INDEX-11;
HANDLE_RC_SCRIPTS = false;
ASSUME_ALWAYS_YES = false;
REPOS_DIR [
/etc/pkg/,
/usr/local/etc/pkg/repos/,
]
PLIST_KEYWORDS_DIR = ;
SYSLOG = true;
ABI = FreeBSD:11:amd64;
ALTABI = freebsd:11:x86:64;
DEVELOPER_MODE = false;
VULNXML_SITE = http://vuxml.freebsd.org/freebsd/vuln.xml.bz2;;
FETCH_RETRY = 3;
PKG_PLUGINS_DIR = /usr/local/lib/pkg/;
PKG_ENABLE_PLUGINS = true;
PLUGINS [
]
DEBUG_SCRIPTS = false;
PLUGINS_CONF_DIR = /usr/local/etc/pkg/;
PERMISSIVE = false;
REPO_AUTOUPDATE = true;
NAMESERVER = ;
EVENT_PIPE = ;
FETCH_TIMEOUT = 30;
UNSET_TIMESTAMP = false;
SSH_RESTRICT_DIR = ;
PKG_ENV {
}
PKG_SSH_ARGS = ;
DEBUG_LEVEL = 0;
ALIAS {
}
CUDF_SOLVER = ;
SAT_SOLVER = ;
RUN_SCRIPTS = true;
CASE_SENSITIVE_MATCH = false;
LOCK_WAIT = 1;
LOCK_RETRIES = 5;
SQLITE_PROFILE = false;
WORKERS_COUNT = 0;
READ_LOCK = false;
PLIST_ACCEPT_DIRECTORIES = false;
IP_VERSION = 0;
AUTOMERGE = true;


Repositories:
  myrepo: {
url : 
File:///usr/local/poudriere/data/packages/head-default,

enabled : yes
  }
  FreeBSD_ssp: {
url : pkg+http://pkg.FreeBSD.org/FreeBSD:11:amd64/ssp;,
enabled : yes,
mirror_type : SRV,
signature_type  : FINGERPRINTS,
fingerprints: /usr/share/keys/pkg
  }
root@bsd11:~ #


And here execution from the console:

root@bsd11:/usr/local/poudriere/data/packages # rm -r head-default/
root@bsd11:/usr/local/poudriere/data/packages # cd
root@bsd11:~ # poudriere bulk -j head archivers/arc
[00:00:00]  Creating the reference jail... done
[00:00:00]  Mounting system devices for head-default
[00:00:00]  Mounting ports/packages/distfiles
[00:00:00]  Converting package repository to new format
[00:00:00]  Stashing existing package repository
[00:00:00]  Mounting ccache from: /var/cache/ccache
[00:00:00]  Mounting packages from: 
/usr/local/poudriere/data/packages/head-default
[00:00:00]  Mounting /var/db/ports from: 
/usr/local/etc/poudriere.d/options
[00:00:00]  Appending to make.conf: 
/usr/local/etc/poudriere.d/head-make.conf
/etc/resolv.conf - 
/usr/local/poudriere/data/.m/head-default/ref/etc/resolv.conf

[00:00:00]  Starting jail head-default
[00:00:01]  Logs: 
/usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_11h12m11s

[00:00:01]  Loading MOVED
[00:00:01]  Calculating ports order and dependencies
[00:00:01]  pkg package missing, skipping sanity
[00:00:01]  Skipping incremental rebuild and repository sanity 
checks

[00:00:01]  Cleaning the build queue
[00:00:01]  Recording filesystem state for prepkg... done
[00:00:03]  Building 3 packages using 3 builders
[00:00:03]  Starting/Cloning builders
[00:00:03]  Hit CTRL+t at any time to see build progress and stats
[00:00:03]  [01][00:00:00] Starting build of ports-mgmt/pkg
[00:01:10]  [01][00:01:07] Finished build of ports-mgmt/pkg: 
Success

[00:01:11]  [01][00:00:00] Starting build of devel/ccache
[00:01:19]  [01][00:00:08] Finished build of devel/ccache: Success
[00:01:20]  [01][00:00:00] Starting build of archivers/arc
[00:01:25]  [01][00:00:05] Finished build of archivers/arc: 
Success

[00:01:26]  Stopping 3 builders
[00:01:27]  Creating pkgng repository
Creating repository in /tmp/packages: 100%
Packing files for repository: 100%
[00:01:29]  Committing packages to repository
[00:01:29]  Removing old packages
[00:01:29]  Built ports: ports-mgmt/pkg devel/ccache archivers/arc
[head-default] [2014-10-30_11h12m11s] [committing:] Queued: 3  Built: 3  
Failed: 0  Skipped: 0  Ignored: 0  Tobuild: 0   Time: 00:01:28
[00:01:29]  Logs: 
/usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_11h12m11s

[00:01:29]  Cleaning up
[00:01:29]  Umounting file systems
root@bsd11:~ #
root@bsd11:~ # pkg update
Updating myrepo repository catalogue...
Fetching meta.txz: 100%   260 B   0.3k/s00:01
Fetching 

Re: pkg 1.4.0.alpha3 - pkg: pkg_repo_fetch_remote_mmap(cannot mmap fetched): Invalid argument / Assertion failed: (curvar != NULL), function pkg_solve_add_request_rule, file pkg_solve.c, line 537.

[Michael Jung]

On 2014-10-30 13:10, Baptiste Daroussin wrote:

On Thu, Oct 30, 2014 at 12:53:29PM -0400, Michael Jung wrote:

Hello:

Errors shown toward end of email.

Note this is a cleanly installed jail but an previously built 
repository

from an older
version of head.  I can nuke the head repository and rebuild from
scratch but I wanted to
present these errors first.


Can you try alpha4 before nuking the head repository?

regards,
Bapt


Ok, I built archivers/zoo, pkg update and pkg install.  Looks ok know.

I'll let it build my pkg list for head/10/9 with a few new packages and
report back it I see any problems.

--mikej

root@bsd11:/usr/ports/ports-mgmt/pkg-devel # make reinstall
snip
root@bsd11:~ # pkg -v
1.4.0.alpha4
root@bsd11:~ #
root@bsd11:~ # poudriere bulk -j head  archivers/zoo
[00:00:00]  Creating the reference jail... done
[00:00:00]  Mounting system devices for head-default
[00:00:00]  Mounting ports/packages/distfiles
[00:00:00]  Stashing existing package repository
[00:00:00]  Mounting ccache from: /var/cache/ccache
[00:00:00]  Mounting packages from: 
/usr/local/poudriere/data/packages/head-default
[00:00:00]  Mounting /var/db/ports from: 
/usr/local/etc/poudriere.d/options
[00:00:00]  Appending to make.conf: 
/usr/local/etc/poudriere.d/head-make.conf
/etc/resolv.conf - 
/usr/local/poudriere/data/.m/head-default/ref/etc/resolv.conf

[00:00:00]  Starting jail head-default
[00:00:00]  Logs: 
/usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_14h33m25s

[00:00:00]  Loading MOVED
[00:00:01]  Calculating ports order and dependencies
[00:00:01]  Sanity checking the repository
[00:00:01]  Checking packages for incremental rebuild needed
[00:00:02]  Deleting stale symlinks
[00:00:02]  Deleting empty directories
[00:00:02]  Cleaning the build queue
[00:00:02]  Recording filesystem state for prepkg... done
[00:00:03]  Building 1 packages using 1 builders
[00:00:03]  Starting/Cloning builders
[00:00:03]  Hit CTRL+t at any time to see build progress and stats
[00:00:03]  [01][00:00:00] Starting build of archivers/zoo
[00:00:17]  [01][00:00:14] Finished build of archivers/zoo: 
Success

[00:00:18]  Stopping 1 builders
[00:00:18]  Creating pkgng repository
Creating repository in /tmp/packages: 100%
Packing files for repository: 100%
[00:00:19]  Committing packages to repository
[00:00:19]  Removing old packages
[00:00:19]  Built ports: archivers/zoo
[head-default] [2014-10-30_14h33m25s] [committing:] Queued: 1  Built: 1  
Failed: 0  Skipped: 0  Ignored: 0  Tobuild: 0   Time: 00:00:20
[00:00:20]  Logs: 
/usr/local/poudriere/data/logs/bulk/head-default/2014-10-30_14h33m25s

[00:00:20]  Cleaning up
[00:00:20]  Umounting file systems
root@bsd11:~ #
root@bsd11:~ # pkg update
Updating myrepo repository catalogue...
Fetching meta.txz: 100%   264 B   0.3k/s00:01
Fetching packagesite.txz: 100%2 KB   1.6k/s00:01
Processing entries: 100%
myrepo repository update completed. 4 packages processed
Updating FreeBSD_ssp repository catalogue...
FreeBSD_ssp repository is up-to-date.
root@bsd11:~ # pkg install zoo
Updating myrepo repository catalogue...
myrepo repository is up-to-date.
Updating FreeBSD_ssp repository catalogue...
FreeBSD_ssp repository is up-to-date.
All repositories are up-to-date.
Updating database digests format: 100%
The following 1 packages will be affected (of 0 checked):

New packages to be INSTALLED:
zoo: 2.10.1_3 [myrepo]

The process will require 112 KB more space.
56 KB to be downloaded.

Proceed with this action? [y/N]: y
Checking integrity... done (0 conflicting)
[1/1] Installing zoo-2.10.1_3...
[1/1] Extracting zoo-2.10.1_3: 100%
root@bsd11:~ #

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

Re: Resizing a zpool as a VMware ESXi guest ...

[Michael Jung]

On 2014-10-16 04:17, Garrett Cooper wrote:
On Oct 16, 2014, at 1:10, Edward Tomasz Napierała tr...@freebsd.org 
wrote:



camcontrol rescan does not force fetching the updated disk size.
AFAIK there is no way to do that.  However, this should happen
automatically, if the other side properly sends proper Unit 
Attention

after resizing.  No idea why this doesn't happen with VMWare.
Reboot obviously clears things up.

[..]


Is open-vm-tools installed?

I ask because if I don't have it installed and the kernel modules
loaded, VMware doesn't notify the guest OS of disks being
added/removed.

Also, what disk controller are you using?

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


I duplicated this behavior.  According to gpart The virtual disk does 
not grow

until the freebsd guest is rebooted.

FreeBSD freebsd10 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0: Tue Jun 24 
07:47:37 UTC 2014

r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC

pkg info -- amd64 open-vm-tools-nox11-1280544_8,1 Open VMware tools for 
FreeBSD VMware guests

ESXi reported -- Running, version:2147483647 (3rd-party/Independent)

ESXi-5.5-1331820(A00) Guest Hardware version 10

789  -  S 0:00.54 /usr/local/bin/vmtoolsd -c 
/usr/local/share/vmware-tools/


Id Refs AddressSize Name

1   12 0x8020 15f03b0  kernel
21 0x81a12000 5209 fdescfs.ko
31 0x81a18000 2198 vmmemctl.ko
41 0x81a1b000 23d8 vmxnet.ko
51 0x81a1e000 2bf0 vmblock.ko
61 0x81a21000 81b4 vmhgfs.ko

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

Re: Gallium debugging and crash dumps

[Michael Jung]

On , Jean-Sébastien Pédron wrote:

On 15.05.2014 15:59, Michael Jung wrote:

I've started playing with VT and gallium. I boot on ZFS but have a
UFS drive and swap partition. Anyone with idea's why I'm not getting
any crash info?


Were you able to get a kernel core dump? Or is your problem with X.Org 
gone?


I finally got around to forcing a crash with debug kdb.panic=1 and
I saw hardware I/O errors on my UFS drive while dumping :-(

I'll post back one I get the hardware straighten out.

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

Gallium debugging and crash dumps

[Michael Jung]

Hi:

If there is a better list to post this to please let me know.

I've started playing with VT and gallium. I boot on ZFS but have a UFS 
drive
and swap partition.  Anyone with idea's why I'm not getting any crash 
info?


I am guessing it is because the machine is not rebooting but locks up 
hard so

is there any extra debugging that can be turned on?

On the surface Gallium seems to be the root of the problem.

Here is my dump/swap config:

FreeBSD charon 10.0-STABLE FreeBSD 10.0-STABLE #0 r265914M: Wed May 14 
15:44:17 EDT 2014 mikej@charon:/usr/obj/usr/src/sys/VT  amd64


root@charon:/usr/home/mikej # swapinfo
Device  1K-blocks UsedAvail Capacity
/dev/ada2s1a 167772160 16777216 0%
root@charon:/usr/home/mikej #

root@charon:/usr/home/mikej # dumpon  -l
ada2s1a
root@charon:/usr/home/mikej #

root@charon:/usr/home/mikej # grep dump /etc/rc.conf
dumpdev=AUTO# Device to crashdump to (device name, AUTO, 
or NO).

dumpdir=/data/crash# Directory where crash dumps are to be stored
root@charon:/usr/home/mikej #

root@charon:/usr/home/mikej # ls -lad /data/crash/
drwxr-xr-x  2 root  wheel  512 Apr 20 13:15 /data/crash/
root@charon:/usr/home/mikej #

http://216.26.158.189/Xorg.0.log

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

Re: Gallium debugging and crash dumps

[Michael Jung]

On , Michael Jung wrote:

Hi:

If there is a better list to post this to please let me know.

I've started playing with VT and gallium. I boot on ZFS but have a UFS 
drive
and swap partition.  Anyone with idea's why I'm not getting any crash 
info?


I am guessing it is because the machine is not rebooting but locks up 
hard so

is there any extra debugging that can be turned on?

On the surface Gallium seems to be the root of the problem.

Here is my dump/swap config:

FreeBSD charon 10.0-STABLE FreeBSD 10.0-STABLE #0 r265914M: Wed May 14
15:44:17 EDT 2014 mikej@charon:/usr/obj/usr/src/sys/VT  amd64

root@charon:/usr/home/mikej # swapinfo
Device  1K-blocks UsedAvail Capacity
/dev/ada2s1a 167772160 16777216 0%
root@charon:/usr/home/mikej #

root@charon:/usr/home/mikej # dumpon  -l
ada2s1a
root@charon:/usr/home/mikej #

root@charon:/usr/home/mikej # grep dump /etc/rc.conf
dumpdev=AUTO# Device to crashdump to (device name, AUTO, 
or NO).

dumpdir=/data/crash# Directory where crash dumps are to be stored
root@charon:/usr/home/mikej #

root@charon:/usr/home/mikej # ls -lad /data/crash/
drwxr-xr-x  2 root  wheel  512 Apr 20 13:15 /data/crash/
root@charon:/usr/home/mikej #

http://216.26.158.189/Xorg.0.log

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



OK another crash today and the machine did reboot but still nothing in 
/data/crash



[mikej@charon ~]$ gpart list ada2
Geom name: ada2
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 3907029167
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: ada2s1
   Mediasize: 2000398901760 (1.8T)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r2w2e3
   rawtype: 165
   length: 2000398901760
   offset: 32256
   type: freebsd
   index: 1
   end: 3907029167
   start: 63
Consumers:
1. Name: ada2
   Mediasize: 2000398934016 (1.8T)
   Sectorsize: 512
   Mode: r2w2e5

[mikej@charon ~]$ ls /dev/ada2
ada2 ada2s1   ada2s1a  ada2s1b
[mikej@charon ~]$ ls /dev/ada2

I simply must just not understand something that is fundamental here.

If I get this right swap is a slice ada2s1b, not a partition which
should be fine for core dumps right?  On reboot dumps to swap are not
being wrote to /data/dump!

If UFS is dirty and auto-fsck runs - is this an issue?

I obviously don't get something. Please someone enlighten me ;-)

Regards,

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

Re: Gallium debugging and crash dumps

[Michael Jung]

On , Michael Jung wrote:

On , Michael Jung wrote:

Hi:

If there is a better list to post this to please let me know.

I've started playing with VT and gallium. I boot on ZFS but have a UFS 
drive
and swap partition.  Anyone with idea's why I'm not getting any crash 
info?


I am guessing it is because the machine is not rebooting but locks up 
hard so

is there any extra debugging that can be turned on?

On the surface Gallium seems to be the root of the problem.

Here is my dump/swap config:

FreeBSD charon 10.0-STABLE FreeBSD 10.0-STABLE #0 r265914M: Wed May 14
15:44:17 EDT 2014 mikej@charon:/usr/obj/usr/src/sys/VT  amd64

root@charon:/usr/home/mikej # swapinfo
Device  1K-blocks UsedAvail Capacity
/dev/ada2s1a 167772160 16777216 0%
root@charon:/usr/home/mikej #

root@charon:/usr/home/mikej # dumpon  -l
ada2s1a
root@charon:/usr/home/mikej #

root@charon:/usr/home/mikej # grep dump /etc/rc.conf
dumpdev=AUTO# Device to crashdump to (device name, AUTO, 
or NO).
dumpdir=/data/crash# Directory where crash dumps are to be 
stored

root@charon:/usr/home/mikej #

root@charon:/usr/home/mikej # ls -lad /data/crash/
drwxr-xr-x  2 root  wheel  512 Apr 20 13:15 /data/crash/
root@charon:/usr/home/mikej #

http://216.26.158.189/Xorg.0.log

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



OK another crash today and the machine did reboot but still nothing in
/data/crash


[mikej@charon ~]$ gpart list ada2
Geom name: ada2
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 3907029167
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: ada2s1
   Mediasize: 2000398901760 (1.8T)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r2w2e3
   rawtype: 165
   length: 2000398901760
   offset: 32256
   type: freebsd
   index: 1
   end: 3907029167
   start: 63
Consumers:
1. Name: ada2
   Mediasize: 2000398934016 (1.8T)
   Sectorsize: 512
   Mode: r2w2e5

[mikej@charon ~]$ ls /dev/ada2
ada2 ada2s1   ada2s1a  ada2s1b
[mikej@charon ~]$ ls /dev/ada2

I simply must just not understand something that is fundamental here.



EH.. Darn swap is a slice ada2s1a

Sorry for the inline - need more coffee!


If I get this right swap is a slice ada2s1b, not a partition which
should be fine for core dumps right?  On reboot dumps to swap are not
being wrote to /data/dump!

If UFS is dirty and auto-fsck runs - is this an issue?

I obviously don't get something. Please someone enlighten me ;-)

Regards,

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

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

Re: unknown mtx_assert at /usr/src/sys/x86/x86/io_apic.c:161

[Michael Jung]

On 1/14/11 8:55 PM, Michael Jung mi...@paymentallianceintl.com wrote:

 John:
 
 Thanks, I actually didn¹t see the MCA errors on the screen as the system has
 reloaded but noted them in the ddb.txt file last night.
 
 The Motherboard, CPU, Memory and PS were replaced today.  I¹ll post back if
 this has or not corrected the problem but I suspect you are on target in
 that the hardware was defective.  This machine was remote and I found the
 fan in the power supply not working, so I¹m suspecting that the CPU was or
 other logic was damaged.
 
 Thanks for your reply.
 
 --mikej
 
 
 On 1/14/11 4:13 PM, John Baldwin j...@freebsd.org wrote:
 
  On Thursday, January 13, 2011 11:26:46 am Michael Jung wrote:
   Links to crash info below.
   http://216.26.153.6/msgbuf.txt
 
  This might be a hardware problem.  The panic you got is a should never
  happen panic.  Note that in the code line sourced, the second argument to
  mtx_assert() is MA_OWNED.  The panic is saying that it is some invalid
 value
  (i.e. something other than MA_OWNED).  Given that is a constant, that's not
  very likely at all barring some hardware glitch.
 
  You do have a somewhat scary looking machine check logged before your
 panic:
 
  MCA: Bank 1, Status 0xd171
  MCA: Global Cap 0x0105, Status 0x
  MCA: Vendor AuthenticAMD, ID 0x20fc2, APIC ID 0
  MCA: CPU 0 COR OVER ICACHE L1 EVICT error
 
  It is a correctable error, but given the nature of the panic I'd suspect a
  hardware problem.
 
  mcelog doesn't provide many more details:
 
  HARDWARE ERROR. This is *NOT* a software problem!
  Please contact your hardware vendor
  CPU 0 1 instruction cache
 bit62 = error overflow (multiple errors)
memory/cache error 'evict mem transaction, instruction transaction, level
 1'
  STATUS d171 MCGSTATUS 0
  MCGCAP 105 APICID 0 SOCKETID 0
  CPUID Vendor AMD Family 15 Model 44
 
  --
  John Baldwin
 
 
 The box has run fine since hardware was replaced.  Thanks for you help.
 
 ---mikej


CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may contain 
information that is privileged, confidential, and exempt from 
disclosure under applicable law. If the reader of this message is 
not the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission 
in error, please notify us by telephone at (502) 212-4001 or 
notify us at PAI , Dept. 99, 11857 Commonwealth Drive, 
Louisville, KY  40299.  Thank you.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: unknown mtx_assert at /usr/src/sys/x86/x86/io_apic.c:161

[Michael Jung]

John:

Thanks, I actually didn¹t see the MCA errors on the screen as the system has
reloaded but noted them in the ddb.txt file last night.

The Motherboard, CPU, Memory and PS were replaced today.  I¹ll post back if
this has or not corrected the problem but I suspect you are on target in
that the hardware was defective.  This machine was remote and I found the
fan in the power supply not working, so I¹m suspecting that the CPU was or
other logic was damaged.

Thanks for your reply.

--mikej


On 1/14/11 4:13 PM, John Baldwin j...@freebsd.org wrote:

 On Thursday, January 13, 2011 11:26:46 am Michael Jung wrote:
  Links to crash info below.
  http://216.26.153.6/msgbuf.txt
 
 This might be a hardware problem.  The panic you got is a should never
 happen panic.  Note that in the code line sourced, the second argument to
 mtx_assert() is MA_OWNED.  The panic is saying that it is some invalid value
 (i.e. something other than MA_OWNED).  Given that is a constant, that's not
 very likely at all barring some hardware glitch.
 
 You do have a somewhat scary looking machine check logged before your panic:
 
 MCA: Bank 1, Status 0xd171
 MCA: Global Cap 0x0105, Status 0x
 MCA: Vendor AuthenticAMD, ID 0x20fc2, APIC ID 0
 MCA: CPU 0 COR OVER ICACHE L1 EVICT error
 
 It is a correctable error, but given the nature of the panic I'd suspect a
 hardware problem.
 
 mcelog doesn't provide many more details:
 
 HARDWARE ERROR. This is *NOT* a software problem!
 Please contact your hardware vendor
 CPU 0 1 instruction cache
bit62 = error overflow (multiple errors)
   memory/cache error 'evict mem transaction, instruction transaction, level 1'
 STATUS d171 MCGSTATUS 0
 MCGCAP 105 APICID 0 SOCKETID 0
 CPUID Vendor AMD Family 15 Model 44
 
 --
 John Baldwin
 


CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may contain 
information that is privileged, confidential, and exempt from 
disclosure under applicable law. If the reader of this message is 
not the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission 
in error, please notify us by telephone at (502) 212-4001 or 
notify us at PAI , Dept. 99, 11857 Commonwealth Drive, 
Louisville, KY  40299.  Thank you.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

unknown mtx_assert at /usr/src/sys/x86/x86/io_apic.c:161

[Michael Jung]

Links to crash info below.

 

http://216.26.153.6/bounds

 

http://216.26.153.6/config.txt

 

http://216.26.153.6/ddb.txt

 

http://216.26.153.6/info.1

 

http://216.26.153.6/msgbuf.txt

 

http://216.26.153.6/panic.txt

 

http://216.26.153.6/ version.txt http://216.26.153.6/%20version.txt 

 

 


CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may contain 
information that is privileged, confidential, and exempt from 
disclosure under applicable law. If the reader of this message is 
not the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission 
in error, please notify us by telephone at (502) 212-4001 or 
notify us at PAI , Dept. 99, 11857 Commonwealth Drive, 
Louisville, KY  40299.  Thank you.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org