Re: filemon

[Peter Wemm]

On 7/30/2024 4:44 AM, Dag-Erling Smørgrav wrote:

"Poul-Henning Kamp"  writes:

Dag-Erling Smørgrav  writes:

There is very little difference between options and devices in kernel
configuration files, but for what it's worth, filemon is a device, not
an option.

Apart from the internals of config(8) and it's input data, is there
any actual difference left ?

 From the perspective of including files in the build, there is no
difference: `foo/foo.c optional foo` does not care whether "foo" is an
option or a device.  However, options generate macros, while devices
don't.  So adding `option FILEMON` to your kernel config will cause
filemon to be compiled into the kernel, but it will also generate an
unneeded opt_filemon.h with `#define FILEMON 1`.  Or it would, if it
weren't for this:

 % git annotate sys/conf/options |& grep -i filemon
 6c6f1f0185b84  (Peter Wemm 2013-07-03 20:22:12 +   
109)FILEMON opt_dontuse.h

which suggests Peter intended filemon to be an option rather than a
device.

DES


Yes it probably should have been a device from the start.  I do not 
recall why I picked one over the other.  It was originally not 
config(8)able at all.


-Peter

Re: NFSv4 crash of CURRENT

[Peter Blok]

Rick,

I can confirm Kostik’s fix works on 13-stable.

Peter

> On 15 Jan 2024, at 16:13, Peter Blok  wrote:
> 
> I can give it a shot on one of my clients.
> 
>> On 15 Jan 2024, at 16:04, Rick Macklem > <mailto:rick.mack...@gmail.com>> wrote:
>> 
>> On Mon, Jan 15, 2024 at 2:53 AM Peter Blok > <mailto:pb...@bsd4all.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> Forgot to mention I’m on 13-stable. The fix that is causing the crash with 
>>> automounted NFS is:
>>> 
>>> commit cc5cda1dbaa907ce52074f47264cc45b5a7d6c8b
>>> Author: Konstantin Belousov mailto:k...@freebsd.org>>
>>> Date:   Tue Jan 2 00:22:44 2024 +0200
>>> 
>>>nfsclient: limit situations when we do unlocked read-ahead by nfsiod
>>> 
>>>(cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e)
>>> 
>>> When I remove the fix, the problem is gone. Add it back and the crash 
>>> happens.
>> Kostik has already come up with a probable fix. If you want it right
>> away, here it is,
>> but he'll probably commit it soon anyhow:
>> diff --git a/sys/fs/nfsclient/nfs_clbio.c b/sys/fs/nfsclient/nfs_clbio.c
>> index c027d7d7c3fd..1cf45bb0c924 100644
>> --- a/sys/fs/nfsclient/nfs_clbio.c
>> +++ b/sys/fs/nfsclient/nfs_clbio.c
>> @@ -414,6 +414,18 @@ nfs_bioread_check_cons(struct vnode *vp, struct
>> thread *td, struct ucred *cred)
>>return (error);
>> }
>> 
>> +static bool
>> +ncl_bioread_dora(struct vnode *vp)
>> +{
>> +   vm_object_t obj;
>> +
>> +   obj = vp->v_object;
>> +   if (obj == NULL)
>> +   return (true);
>> +   return (!vm_object_mightbedirty(vp->v_object) &&
>> +   vp->v_object->un_pager.vnp.writemappings == 0);
>> +}
>> +
>> /*
>>  * Vnode op for read using bio
>>  */
>> @@ -486,9 +498,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
>> ioflag, struct ucred *cred)
>> * unlocked read by nfsiod could obliterate changes
>> * done by userspace.
>> */
>> -   if (nmp->nm_readahead > 0 &&
>> -   !vm_object_mightbedirty(vp->v_object) &&
>> -   vp->v_object->un_pager.vnp.writemappings == 0) {
>> +   if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp)) {
>>for (nra = 0; nra < nmp->nm_readahead && nra < seqcount &&
>>(off_t)(lbn + 1 + nra) * biosize < nsize; nra++) {
>>rabn = lbn + 1 + nra;
>> @@ -675,9 +685,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
>> ioflag, struct ucred *cred)
>> *  directory offset cookie of the next block.)
>> */
>>NFSLOCKNODE(np);
>> -   if (nmp->nm_readahead > 0 &&
>> -   !vm_object_mightbedirty(vp->v_object) &&
>> -   vp->v_object->un_pager.vnp.writemappings == 0 &&
>> +   if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp) &&
>>(bp->b_flags & B_INVAL) == 0 &&
>>(np->n_direofoffset == 0 ||
>>(lbn + 1) * NFS_DIRBLKSIZ < np->n_direofoffset) &&
>> 
>> rick
>> ps: It appears that autofs causes the directory to be read before it
>> is open'd for
>>  some reason. I've never looked at autofs.
>> 
>>> 
>>> Peter
>>> 
>>> On 15 Jan 2024, at 09:31, Peter Blok >> <mailto:pb...@bsd4all.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> I do have a crash on a NFS client with stable of today 
>>> (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. 
>>> Maybe it is the same problem.
>>> 
>>> I have ports automounted on /am/ports. When I do cd /am/ports/sys and type 
>>> tab to autocomplete it crashes with the below stack trace. If I plainly 
>>> mount ports on /usr/ports and do the same everything works. I am using NFSv3
>>> 
>>> Peter
>>> 
>>> 
>>> 
>>> 
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 2; apic id = 04
>>> fault virtual address = 0x89
>>> fault code = supervisor read data, page not present
>>> instruction pointer = 0x20:0x809645

Re: NFSv4 crash of CURRENT

[Peter Blok]

I can give it a shot on one of my clients.

> On 15 Jan 2024, at 16:04, Rick Macklem  wrote:
> 
> On Mon, Jan 15, 2024 at 2:53 AM Peter Blok  <mailto:pb...@bsd4all.org>> wrote:
>> 
>> Hi,
>> 
>> Forgot to mention I’m on 13-stable. The fix that is causing the crash with 
>> automounted NFS is:
>> 
>> commit cc5cda1dbaa907ce52074f47264cc45b5a7d6c8b
>> Author: Konstantin Belousov 
>> Date:   Tue Jan 2 00:22:44 2024 +0200
>> 
>>nfsclient: limit situations when we do unlocked read-ahead by nfsiod
>> 
>>(cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e)
>> 
>> When I remove the fix, the problem is gone. Add it back and the crash 
>> happens.
> Kostik has already come up with a probable fix. If you want it right
> away, here it is,
> but he'll probably commit it soon anyhow:
> diff --git a/sys/fs/nfsclient/nfs_clbio.c b/sys/fs/nfsclient/nfs_clbio.c
> index c027d7d7c3fd..1cf45bb0c924 100644
> --- a/sys/fs/nfsclient/nfs_clbio.c
> +++ b/sys/fs/nfsclient/nfs_clbio.c
> @@ -414,6 +414,18 @@ nfs_bioread_check_cons(struct vnode *vp, struct
> thread *td, struct ucred *cred)
>return (error);
> }
> 
> +static bool
> +ncl_bioread_dora(struct vnode *vp)
> +{
> +   vm_object_t obj;
> +
> +   obj = vp->v_object;
> +   if (obj == NULL)
> +   return (true);
> +   return (!vm_object_mightbedirty(vp->v_object) &&
> +   vp->v_object->un_pager.vnp.writemappings == 0);
> +}
> +
> /*
>  * Vnode op for read using bio
>  */
> @@ -486,9 +498,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
> ioflag, struct ucred *cred)
> * unlocked read by nfsiod could obliterate changes
> * done by userspace.
> */
> -   if (nmp->nm_readahead > 0 &&
> -   !vm_object_mightbedirty(vp->v_object) &&
> -   vp->v_object->un_pager.vnp.writemappings == 0) {
> +   if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp)) {
>for (nra = 0; nra < nmp->nm_readahead && nra < seqcount &&
>(off_t)(lbn + 1 + nra) * biosize < nsize; nra++) {
>rabn = lbn + 1 + nra;
> @@ -675,9 +685,7 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int
> ioflag, struct ucred *cred)
> *  directory offset cookie of the next block.)
> */
>NFSLOCKNODE(np);
> -   if (nmp->nm_readahead > 0 &&
> -   !vm_object_mightbedirty(vp->v_object) &&
> -   vp->v_object->un_pager.vnp.writemappings == 0 &&
> +       if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp) &&
>(bp->b_flags & B_INVAL) == 0 &&
>(np->n_direofoffset == 0 ||
>(lbn + 1) * NFS_DIRBLKSIZ < np->n_direofoffset) &&
> 
> rick
> ps: It appears that autofs causes the directory to be read before it
> is open'd for
>  some reason. I've never looked at autofs.
> 
>> 
>> Peter
>> 
>> On 15 Jan 2024, at 09:31, Peter Blok  wrote:
>> 
>> Hi,
>> 
>> I do have a crash on a NFS client with stable of today 
>> (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. Maybe 
>> it is the same problem.
>> 
>> I have ports automounted on /am/ports. When I do cd /am/ports/sys and type 
>> tab to autocomplete it crashes with the below stack trace. If I plainly 
>> mount ports on /usr/ports and do the same everything works. I am using NFSv3
>> 
>> Peter
>> 
>> 
>> 
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 2; apic id = 04
>> fault virtual address = 0x89
>> fault code = supervisor read data, page not present
>> instruction pointer = 0x20:0x809645d4
>> stack pointer= 0x28:0xfe00acadb830
>> frame pointer= 0x28:0xfe00acadb830
>> code segment = base 0x0, limit 0xf, type 0x1b
>> = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = interrupt enabled, resume, IOPL = 0
>> current process = 6869 (csh)
>> trap number = 12
>> panic: page fault
>> cpuid = 2
>> time = 1705306940
>> KDB: stack backtrace:
>> #0 0x806232f5 at kdb_backtrace+0x65
>> #1 0x805d7a02 at vpanic+0x152
>> #2 0x805d78a3 at panic+0x43
>> #3 0x809d58ad at trap_fatal+0x38d
>>

Re: NFSv4 crash of CURRENT

[Peter Blok]

Hi,

Forgot to mention I’m on 13-stable. The fix that is causing the crash with 
automounted NFS is:

commit cc5cda1dbaa907ce52074f47264cc45b5a7d6c8b
Author: Konstantin Belousov 
Date:   Tue Jan 2 00:22:44 2024 +0200

nfsclient: limit situations when we do unlocked read-ahead by nfsiod

(cherry picked from commit 70dc6b2ce314a0f32755005ad02802fca7ed186e)

When I remove the fix, the problem is gone. Add it back and the crash happens.

Peter

> On 15 Jan 2024, at 09:31, Peter Blok  wrote:
> 
> Hi,
> 
> I do have a crash on a NFS client with stable of today 
> (4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. Maybe 
> it is the same problem.
> 
> I have ports automounted on /am/ports. When I do cd /am/ports/sys and type 
> tab to autocomplete it crashes with the below stack trace. If I plainly mount 
> ports on /usr/ports and do the same everything works. I am using NFSv3
> 
> Peter
> 
> 
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 04
> fault virtual address = 0x89
> fault code= supervisor read data, page not present
> instruction pointer   = 0x20:0x809645d4
> stack pointer = 0x28:0xfe00acadb830
> frame pointer = 0x28:0xfe00acadb830
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 6869 (csh)
> trap number   = 12
> panic: page fault
> cpuid = 2
> time = 1705306940
> KDB: stack backtrace:
> #0 0x806232f5 at kdb_backtrace+0x65
> #1 0x805d7a02 at vpanic+0x152
> #2 0x805d78a3 at panic+0x43
> #3 0x809d58ad at trap_fatal+0x38d
> #4 0x809d58ff at trap_pfault+0x4f
> #5 0x809af048 at calltrap+0x8
> #6 0x804c7a7e at ncl_bioread+0xb7e
> #7 0x804b9d90 at nfs_readdir+0x1f0
> #8 0x8069c61a at vop_sigdefer+0x2a
> #9 0x809f8ae0 at VOP_READDIR_APV+0x20
> #10 0x81ce75de at autofs_readdir+0x2ce
> #11 0x809f8ae0 at VOP_READDIR_APV+0x20
> #12 0x806c3002 at kern_getdirentries+0x222
> #13 0x806c33a9 at sys_getdirentries+0x29
> #14 0x809d6180 at amd64_syscall+0x110
> #15 0x809af95b at fast_syscall_common+0xf8
> 
> 
> 
>> On 15 Jan 2024, at 06:46, FreeBSD User > <mailto:free...@walstatt-de.de>> wrote:
>> 
>> Am Sun, 14 Jan 2024 20:34:12 -0800
>> Cy Schubert mailto:cy.schub...@cschubert.com>> 
>> schrieb:
>> 
>>> In message 
>>> >> <mailto:CAM5tNy5aat8vUn2fsX9jV=D9yGZdnO20Q0Ea7qtszx+zSES2bw@mail.gmail.c>
>>> om>  
>>> , Rick Macklem writes:
>>>> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop >>> <mailto:ronald-li...@klop.ws>>=
>>>> wrote:  
>>>>> 
>>>>> 
>>>>> Van: FreeBSD User mailto:free...@walstatt-de.de>>
>>>>> Datum: 13 januari 2024 19:34
>>>>> Aan: FreeBSD CURRENT >>>> <mailto:freebsd-current@freebsd.org>>
>>>>> Onderwerp: NFSv4 crash of CURRENT
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> running CURRENT client (FreeBSD 15.0-CURRENT #4 
>>>>> main-n267556-69748e62e82a=  
>>>> : Sat Jan 13 18:08:32  
>>>>> CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned 
>>>>> cl=  
>>>> ient, other is FreeBSD  
>>>>> 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.
>>>>> 
>>>>> I can crash the client reproducable by accessing the one or other NFSv4 
>>>>> F=  
>>>> S (a simple ls -la).  
>>>>> The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla 
>>>>> a=  
>>>> ccess to the client  
>>>>> host, luckily the box recovers.  
>>>> Did you rebuild both the nfscommon and nfscl modules from the same sources?
>>>> I did a commit to main that changes the interface between these two
>>>> modules and did bump the
>>>> __FreeBSD_version to 1500010, which should cause both to be rebuilt.
>>>> (If you have "options NFSCL" in your kernel config, both should have
>>>> been rebuilt as a part of
>>>> the kernel build.)
>>>> 
>>> 
>>> Is anyone by chance seeing autofs in the backtrace too?
>>> 
>>> 
>> 
>> Hello Cy Shubert,
>> 
>> I forgot to mention that those crashes occur with autofs mounted 
>> filesystems. Good question,
>> by the way, I will check whether crashes also happen when mounting the 
>> tradidional way.
>> 
>> Kind regards,
>> 
>> oh
>> 
>> -- 
>> O. Hartmann
> 

Re: NFSv4 crash of CURRENT

[Peter Blok]

Hi,

I do have a crash on a NFS client with stable of today 
(4c4633fdffbe8e4b6d328c2bc9bb3edacc9ab50a). It is also autofs related. Maybe it 
is the same problem.

I have ports automounted on /am/ports. When I do cd /am/ports/sys and type tab 
to autocomplete it crashes with the below stack trace. If I plainly mount ports 
on /usr/ports and do the same everything works. I am using NFSv3

Peter




Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address   = 0x89
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x809645d4
stack pointer   = 0x28:0xfe00acadb830
frame pointer   = 0x28:0xfe00acadb830
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 6869 (csh)
trap number = 12
panic: page fault
cpuid = 2
time = 1705306940
KDB: stack backtrace:
#0 0x806232f5 at kdb_backtrace+0x65
#1 0x805d7a02 at vpanic+0x152
#2 0x805d78a3 at panic+0x43
#3 0x809d58ad at trap_fatal+0x38d
#4 0x809d58ff at trap_pfault+0x4f
#5 0x809af048 at calltrap+0x8
#6 0x804c7a7e at ncl_bioread+0xb7e
#7 0x804b9d90 at nfs_readdir+0x1f0
#8 0x8069c61a at vop_sigdefer+0x2a
#9 0x809f8ae0 at VOP_READDIR_APV+0x20
#10 0x81ce75de at autofs_readdir+0x2ce
#11 0x809f8ae0 at VOP_READDIR_APV+0x20
#12 0x806c3002 at kern_getdirentries+0x222
#13 0x806c33a9 at sys_getdirentries+0x29
#14 0x809d6180 at amd64_syscall+0x110
#15 0x809af95b at fast_syscall_common+0xf8



> On 15 Jan 2024, at 06:46, FreeBSD User  wrote:
> 
> Am Sun, 14 Jan 2024 20:34:12 -0800
> Cy Schubert mailto:cy.schub...@cschubert.com>> 
> schrieb:
> 
>> In message > om>  
>> , Rick Macklem writes:
>>> On Sat, Jan 13, 2024 at 12:39=E2=80=AFPM Ronald Klop =
>>> wrote:  
>>>> 
>>>> 
>>>> Van: FreeBSD User 
>>>> Datum: 13 januari 2024 19:34
>>>> Aan: FreeBSD CURRENT 
>>>> Onderwerp: NFSv4 crash of CURRENT
>>>> 
>>>> Hello,
>>>> 
>>>> running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a= 
>>>>  
>>> : Sat Jan 13 18:08:32  
>>>> CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned cl= 
>>>>  
>>> ient, other is FreeBSD  
>>>> 13.2-RELEASE-p8. Both offer NFSv4 filesystems, non-kerberized.
>>>> 
>>>> I can crash the client reproducable by accessing the one or other NFSv4 F= 
>>>>  
>>> S (a simple ls -la).  
>>>> The NFSv4 FS is backed by ZFS (if this matters). I do not have physicla a= 
>>>>  
>>> ccess to the client  
>>>> host, luckily the box recovers.  
>>> Did you rebuild both the nfscommon and nfscl modules from the same sources?
>>> I did a commit to main that changes the interface between these two
>>> modules and did bump the
>>> __FreeBSD_version to 1500010, which should cause both to be rebuilt.
>>> (If you have "options NFSCL" in your kernel config, both should have
>>> been rebuilt as a part of
>>> the kernel build.)
>>> 
>> 
>> Is anyone by chance seeing autofs in the backtrace too?
>> 
>> 
> 
> Hello Cy Shubert,
> 
> I forgot to mention that those crashes occur with autofs mounted filesystems. 
> Good question,
> by the way, I will check whether crashes also happen when mounting the 
> tradidional way.
> 
> Kind regards,
> 
> oh
> 
> -- 
> O. Hartmann

Re: Review of patch that uses "volatile sig_atomic_t"

[Peter Eriksson]

Interesting discussion regarding sig_atomic_t, volatile & stuff. It seems I 
opened a can of worms. Sorry :-)


Anyway here are the references I had read when suggesting this change:

C89:
- http://port70.net/~nsz/c/c99/n1256.html#7.14p2

CERT C Coding Standard:
- 
https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+shared+objects+in+signal+handlers


I’ve also been using "static int foo;” in my own code forever before and like 
you say it works but then I got curious and started searching to see if there 
was a more “correct” (and portable) way of doing this)


If I read you right then just dropping “volatile” and use “sig_atomic_t” should 
be better (and “portable” for some value of portable, not a problem in this 
case with mountd) but using atomic_int from stdatomic.h from C11 is even 
better? (volatile sig_atomic_t is from C89 I think). Something like this:

> #if __STDC_NO_ATOMICS__ != 1
> /* C11 */
> #include 
> static atomic_int got_sighup = ATOMIC_VAR_INIT(0);
> 
> #else
> /* C89 */
> static volatile sig_atomic_t got_sighup = 0;
> #endif

(for portability, not needed for mountd though). 

https://www.informit.com/articles/article.aspx?p=2204014


Ah well, time to relearn C again :-)

(K&R C was simpler :-)

- Peter

> On 2 Aug 2023, at 10:12, David Chisnall  wrote:
> 
> On 2 Aug 2023, at 00:33, Rick Macklem  wrote:
>> 
>> Just trying to understand what you are suggesting...
>> 1 - Declare the variable _Atomic(int) OR atomic_int (is there a preference) 
>> and
>>not volatile.
> 
> Either is fine (the latter is a typedef for the former).  I am not a huge fan 
> of the typedefs, some people like them, as far as I can tell it’s purely 
> personal preference.
> 
>> 2 - Is there a need for signal_atomic_fence(memory_order_acquire); before the
>>assignment of the variable in the signal handler. (This exists in
>> one place in
>>the source tree (bin/dd/misc,c), although for this example,
>> neither volatile nor
>>_Atomic() are used for the variable's declaration.
> 
> You don’t need a fence if you use an atomic variable.  The fence prevents the 
> compiler reordering things across it, using atomic operations also prevents 
> this.  You might be able to use a fence and not use an atomic but I’d have to 
> reread the spec very carefully to convince myself that this didn’t trigger 
> undefined behaviour.
> 
>> 3 - Is there any need for other atomic_XXX() calls where the variable is used
>>outside of the signal handler?
> 
> No.  By default, _Atomic variables use sequentially consistent semantics.  
> You need to use the `atomic_` functions only for explicit memory orderings, 
> which you might want to do for optimisation (very unlikely in this case).  
> Reading it outside the signal handler is the equivalent of doing 
> `atomic_load` with a sequentially consistent memory order.  This is a 
> stronger guarantee than you need, but it’s unlikely to cause performance 
> problems if you’re doing more than a few dozen instructions worth of work 
> between checks.
> 
>> In general, it is looking like FreeBSD needs to have a standard way of 
>> dealing
>> with this and there will be assorted places that need to be fixed?
> 
> If we used a language that let you build abstractions, that would be easy (I 
> have a C++ class that provides a static epoch counter that’s incremented in a 
> signal handler and a local copy for each instance, so you can check if the 
> signal handler has fired since it was last used.  It’s trivial to reuse in 
> C++ projects but C doesn’t give you tools for doing this.
> 
> David
> 
> 

Re: Possible PEBKAC bug for fwget(8)?

[Peter Jeremy]

On 2023-Jul-07 08:03:40 +0100, Graham Perrin  wrote:
>PCI pictured at
><https://en.wikipedia.org/wiki/Peripheral_Component_Interconnect>, somehow I
>don't imagine finding that type of slot inside the HP EliteBook where I ran
>the command ;-)

Whilst you probably don't have a full-size PCI or PCIe connector in
your laptop, it's very likely that it has a Mini PCIe connector for
the WiFi adapter.  Even without that, there are virtual PCI buses
inside your CPU chip - have a look at the output of "pciconf -lv".

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: panic: ASan: Invalid access, 1-byte read at ...

[Peter Holm]

On Wed, Jun 21, 2023 at 10:06:28AM -0400, Mark Johnston wrote:
> On Wed, Jun 21, 2023 at 11:53:44AM +0200, Peter Holm wrote:
> > Just got this panic:
> > 
> > 20230621 11:15:23 all (37/912): linux.sh
> > panic: ASan: Invalid access, 1-byte read at 0xfe020bd78e9f, 
> > RedZonePartial(2)
> > cpuid = 1
> > time = 1687338930
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 
> > 0xfe01f16abc10
> > kdb_backtrace() at kdb_backtrace+0xc7/frame 0xfe01f16abd70
> > vpanic() at vpanic+0x1d7/frame 0xfe01f16abe30
> > panic() at panic+0xb5/frame 0xfe01f16abf00
> > kasan_report() at kasan_report+0xdc/frame 0xfe01f16abfd0
> > pfs_lookup() at pfs_lookup+0x2c2/frame 0xfe01f16ac0f0
> > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x91/frame 0xfe01f16ac130
> > vfs_cache_lookup() at vfs_cache_lookup+0x1f7/frame 0xfe01f16ac210
> > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x91/frame 0xfe01f16ac250
> > vfs_lookup() at vfs_lookup+0xa0f/frame 0xfe01f16ac510
> > namei() at namei+0x679/frame 0xfe01f16ac690
> > vn_open_cred() at vn_open_cred+0xa94/frame 0xfe01f16aca10
> > kern_openat() at kern_openat+0x50d/frame 0xfe01f16acc70
> > linux_common_open() at linux_common_open+0x141/frame 0xfe01f16acd30
> > amd64_syscall() amd64_syscall+0x30f/frame 0xfast_syscall_common() at 
> > fast_syscall_common+0xf8/frame 0xfe01f16acf30
> > --- syscall (2, Linux ELF64, linux_open), rip = 0x8012ef7f0, rsp = 
> > 0x7fffa238, rbp = 0x7fffa290 ---
> > KDB: enter: panic
> > [ thread pid 31838 tid 100363 ]
> > Stopped at  kdb_enter+0x34: movq$0,0x1e3f7c1(%rip)
> > db>
> > 
> > Details @ https://people.freebsd.org/~pho/stress/log/log0450.txt
> 
> Hi Peter,
> 
> Thanks for the report.  I believe this would be fixed by
> https://reviews.freebsd.org/D40692 .

Hi Mark,

This works for me.

- Peter

panic: ASan: Invalid access, 1-byte read at ...

[Peter Holm]

Just got this panic:

20230621 11:15:23 all (37/912): linux.sh
panic: ASan: Invalid access, 1-byte read at 0xfe020bd78e9f, 
RedZonePartial(2)
cpuid = 1
time = 1687338930
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0xa5/frame 0xfe01f16abc10
kdb_backtrace() at kdb_backtrace+0xc7/frame 0xfe01f16abd70
vpanic() at vpanic+0x1d7/frame 0xfe01f16abe30
panic() at panic+0xb5/frame 0xfe01f16abf00
kasan_report() at kasan_report+0xdc/frame 0xfe01f16abfd0
pfs_lookup() at pfs_lookup+0x2c2/frame 0xfe01f16ac0f0
VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x91/frame 0xfe01f16ac130
vfs_cache_lookup() at vfs_cache_lookup+0x1f7/frame 0xfe01f16ac210
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x91/frame 0xfe01f16ac250
vfs_lookup() at vfs_lookup+0xa0f/frame 0xfe01f16ac510
namei() at namei+0x679/frame 0xfe01f16ac690
vn_open_cred() at vn_open_cred+0xa94/frame 0xfe01f16aca10
kern_openat() at kern_openat+0x50d/frame 0xfe01f16acc70
linux_common_open() at linux_common_open+0x141/frame 0xfe01f16acd30
amd64_syscall() amd64_syscall+0x30f/frame 0xfast_syscall_common() at 
fast_syscall_common+0xf8/frame 0xfe01f16acf30
--- syscall (2, Linux ELF64, linux_open), rip = 0x8012ef7f0, rsp = 
0x7fffa238, rbp = 0x7fffa290 ---
KDB: enter: panic
[ thread pid 31838 tid 100363 ]
Stopped at  kdb_enter+0x34: movq$0,0x1e3f7c1(%rip)
db>

Details @ https://people.freebsd.org/~pho/stress/log/log0450.txt

- Peter

ntpd fails on recent -current/arm64

[Peter Jeremy]

Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed,
some change in the kernel has made ntpd stop working on my arm64 test
box.  (My amd64 test box is a couple of days behind so I'm not sure if
it's arm-specific).

What I've identified so far:
* The problem is in the kernel, not userland.
* The impact seems to be limited to ntpd (in particular, ntpdate works).
* ntpd appears to be correctly exchanging NTP packets with peers.
* ntpd is not responding to "ntpq -p" queries
* ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime

I've looked through the commits and, beyond much of netinet being
roto-tilled, I can't see anything obvious.

Is anyone else seeing anything similar?  Can anyone suggest where
to look next?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: RFC: nfsd in a vnet jail

[Peter Eriksson]

Keep the global variables as defaults that apply to all nfsds and allow (at 
least some subset) to be overridden inside the net jails if some things need to 
be changed from the defaults?

- Peter


On Fri, Nov 25, 2022, 4:24 PM Rick Macklem mailto:rick.mack...@gmail.com>> wrote:
> Hi,
> 
> bz@ has encouraged me to fiddle with the nfsd
> so that it works in a vnet jail.
> I have now basically done so, specifically for
> NFSv4, since NFSv3 presents various issues.
> 
> What I have not yet done is put global variables
> in the vnet. This needs to be done so that the nfsd
> can be run in multiple jail instances and/or in and
> outside of a jail.
> The problem is that there are 100s of global variables.
> 
> I can see two approaches:
> 1 - Move them all into the vnet jail. This would imply
> that all the sysctls need to somehow be changed,
> which would seem to be a POLA violation.
> It also implies a lot of stuff in the vnet.
> 2 - Just move the global variables that will always
> differ from one nfsd to another (this would make
> the sysctls global and apply to all nfsds).
> This will keep the number of globals in the vnet
> smaller.
> 
> I am currently leaning towards #2, put what do others
> think?
> 
> rick
> ps: Personally, I don't know what use there is of
> running the nfsd inside a vnet jail, but bz@ has
> some use case.

Re: Beadm can't create snapshot

[Peter Jeremy]

On 2022-Aug-23 15:19:34 +0200, Ronald Klop  wrote:
>Van: Kyle Evans 
>> I was not aware that beadm touches loader.conf, but I find that
>> slightly horrifying. I won't personally make bectl do that, but I
>> guess I could at least document that it doesn't...
>
>Today I looked up something for boot environments myself and read this: 
>https://wiki.freebsd.org/BootEnvironments#Setting_Boot_Dataset
>
>"In order for boot environments to be effective, you must let the bootfs zpool 
>property control which dataset gets mounted as the root. Particularly, 
>/etc/fstab must be purged of any / mount, and /boot/loader.conf must not be 
>setting vfs.root.mountfrom directly. "
>
>So it is documented somewhere at least.

Looking at the wiki history, Kyle wrote that in January 2020.  I
wonder if he recalls where that requirement came from.

I've gone rummaging through the mailing list history and other wiki
pages.  It seems that vfs.root.mountfrom used to be required - e.g.
 https://lists.freebsd.org/pipermail/freebsd-fs/2011-September/012482.html
 https://lists.freebsd.org/pipermail/svn-src-head/2011-October/030641.html
and people wanted to change that - e.g.
 https://lists.freebsd.org/pipermail/freebsd-current/2009-October/012933.html
 https://lists.freebsd.org/pipermail/freebsd-fs/2010-March/008010.html
resulting in it becoming optional in May 2012:
 https://lists.freebsd.org/pipermail/svn-src-head/2012-May/036902.html

Based on the quoted wiki entry, it seems that sometime between May
2012 and January 2020, vfs.root.mountfrom went from "must be set" to
"must not be set" and I can't find anywhere where that is publicised.
This is a serious problem because we now have the situation where
some documentation still says to set vfs.root.mountfrom - e.g.
 https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror step 2.6
and people are still using it without being warned that it shouldn't
be used - e.g. the thread starting
 https://lists.freebsd.org/pipermail/freebsd-fs/2020-July/028351.html

I've had a look at the beadm source and it preserves/updates
vfs.root.mountfrom if it's present in loader.conf but doesn't add it
if it's not present.

IMO, if bectl isn't going to update loader.conf, it needs to warn and
fail if loader.conf contains a vfs.root.mountfrom that points to a
BE that's different to bootfs.  (And ideally, a similar check of
/etc/fstab, though beadm doesn't touch that).

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Beadm can't create snapshot

[Peter Jeremy]

On 2022-Aug-22 10:56:51 +0200, "Patrick M. Hausen"  wrote:
>> Am 22.08.2022 um 10:45 schrieb Peter Jeremy :
>> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrote:
>>> Isn't beadm retired in favour of bectl?
>> 
>> 2) "bectl activate" doesn't update /boot/loader.conf so the wrong
>>   root filesystem is mounted.
>
>You mean the vfs.root.mountfrom option? I thought that, too, was deprecated and
>replaced by the bootfs property of the zpool.

I've looking through mailing list archives and searched the 'net and
haven't found anything saying vfs.root.mountfrom is deprecated.
loader(8) mentions that it will fallback to using "currdev" if there's
no root entry in /etc/fstab and vfs.root.mountfrom isn't set.

At the very least, it's an undocumented incompatibility between beadm
and bectl: I can't take an existing system that's using beadm and just
switch to using bectl.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Beadm can't create snapshot

[Peter Jeremy]

On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen"  wrote:
>Isn't beadm retired in favour of bectl?

bectl still has a number of bugs:
1) The output from "bectl list" is in filesystem/bename order rather
   than creation date order.  This is an issue if you use (eg) git
   commit hashes as the name.
2) "bectl activate" doesn't update /boot/loader.conf so the wrong
   root filesystem is mounted.

That said "bectl create" appears to be a workable replacement for
"beadm create" and avoids the current "'snapshots_changed' is
readonly" bugs.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: recover deleted file

[Peter Jeremy]

On 2022-Apr-17 01:13:02 +0300, Sami Halabi  wrote:
>I understand its hard to undelete since no one designed UFS/ZFS to do so..
>that why I asked in later replies to see if someone would step in and
>implement such a "feature" and I suggested some directions/thoughts.

As you point out, neither UFS nor ZFS were designed to support an
"undelete" function: Once an inode has no references (open files
or directory entries), the inode and all associated data blocks are
returned to the free list and could be used by a subsequent allocation.

What semantics would you like UFS or ZFS to implement instead?  Is it
just that the inode and associated data blocks should stay in limbo
for some period?  If, what controls the period?  What if a file is
truncated to 0 or overwritten before being unlinked?  How much would
you be willing to pay for "undelete" functionality?

>As soren@ suggested in later reply it maybe would be easier to implement
>custom rm script that moves files to "Recycle bin" directory (and empty it
>after some period)

Alternatively, you could alias "rm" to "rm -i".

>but as a programmer I know that perfection is needed :)
>so It might start as a simple task and end in many what-if's
>(unfortunattly I did my last C programming in late 2003!).

This doesn't need to be C.  You could do this in your scripting
language of choice.  Or you could offer to pay someone to do this
for you.

>What amzes me is that this "feature" was asked too much in the last decade
>or two and no one ever implemented it, maybe it's not needed in daily
>usage, but in disasters it would be super userful, save admins many time
>and nerves..

I went rummaging back through my mail archives and it actually doesn't
seem to come up that often.  You seem to be about the 3rd person this
century on the lists I read.  I did find a discussion in zfs-discuss
from May/June 2006 about supporting undelete but it seems that no
agreement on the desired behaviour was achieved.

>For now I did some backup tools locally and used chflags to mark them
>undeletable so I wouldn't do that mistake again,

You could also consider snapshots - both UFS and ZFS support snapshots.

If the information is very critical (you mentioned legal consequences)
then you might like to consider real-time replication of the MySQL redo
logs to another systems - though that won't necessarily protect you
from someone accidently doing a "DELETE FROM xxx;" or "DROP TABLE xxx;"

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?

[Peter Jeremy]

On 2021-Dec-09 08:19:30 +0100, Emmanuel Vadot  wrote:
>
> Hi Mark,
>
>On Wed, 8 Dec 2021 20:36:20 -0800
>Mark Millard via freebsd-current  wrote:
>
>> [ Note: w...@freebsd.org is only a guess, based on:
>> https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html
>>  ]
>> 
>> Attempting to update to:
>> 
>> main-n251456-22c4ab6cb015-dirty: Tue Dec  7 19:38:53 PST 2021
>> 
>> resulted in boot failure (showing some boot -v output):
[hang just before root is mounted]
> Could you try reverting 
>8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400
>capability check" and let me know ?

I had exactly the same boot failure but was still working backwards
through the root mount code trying to isolate the issue.  Reverting
8661e085fb953855dbc7059f21a64a05ae61b22c solves the problem for me.
I'd noticed the mmc1 difference and mmcsd1 error:
 mmc1:  bus: 8bit, 200MHz (HS200 timing)
 mmc1:  memory: 30310400 blocks, erase sector 1024 blocks
mmc1: setting transfer rate to 150.000MHz (HS200 timing)

bud I didn't think it was the cause.

I had tracked down that the hang was somewhere between
https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n779 and
https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n1008
which led me to suspect that the problem might be in the geom
layer (eg g_waitidle()) but was still considering where to add
my next tranche of printf's when I saw Mark's mail.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Panic in pipe_write from syslogd in 12.2?

[Peter Eriksson]

I just noticed that a couple of my 12.2-RELEASE-p4 running servers have… 8263, 
14474 and 3831 defunct subprocesses from syslogd and also seems to have stopped 
writing to the log files… When I tried to kill syslogd on a fourth server (with 
some X000 defunct processes) the machine panic’ed and rebooted.

I seem to have a vague memory of this being a known bug/someone saw something 
similar or perhaps even solved in later patch releases? But my google-fu seems 
to be failing me today. Anyone else remember?

(The one that panic’ed is now running -p10 instead which they should have done 
a long time ago but…)


I reported it on the FreeBSD bugzilla:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259084 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259084>


Output from one that still is running:
# egrep syslogd /var/log/sys/15:10/procstat-kk-a.log
 9212 101640 syslogd -   mi_switch+0xd4 
sleepq_catch_signals+0x403 sleepq_wait_sig+0xf _sleep+0x1de pipe_write+0x583 
dofilewrite+0xb0 sys_write+0xc0 amd64_syscall+0x387 fast_syscall_common+0xf8

Output from the one that panic’ed:
Fatal trap 12: page fault while in kernel mode
cpuid = 20; apic id = 14
fault virtual address   = 0x410
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80b9f55c
stack pointer   = 0x28:0xfe14debc6710
frame pointer   = 0x28:0xfe14debc6790
code segment= base r 
<https://svnweb.freebsd.org/changeset/base/>x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 9277 (sshd)
trap number = 12
panic: page fault
cpuid = 20
time = 1633990484
KDB: stack backtrace:
#0 0x80c0ad75 at kdb_backtrace+0x65
#1 0x80bbf02b at vpanic+0x17b
#2 0x80bbeea3 at panic+0x43
#3 0x8108e911 at trap_fatal+0x391
#4 0x8108e96f at trap_pfault+0x4f
#5 0x8108dfb6 at trap+0x286
#6 0x81066c28 at calltrap+0x8
#7 0x80c6365f at unp_pcb_owned_lock2_slowpath+0x12f
#8 0x80c61e0f at uipc_send+0x139f
#9 0x80c55b7a at sosend_generic+0x4ca
#10 0x80c55f90 at sosend+0x50
#11 0x80c5cc55 at kern_sendit+0x225
#12 0x80c5cfcc at sendit+0x19c
#13 0x80c5ce1d at sys_sendto+0x4d
#14 0x8108f4c7 at amd64_syscall+0x387
#15 0x8106754e at fast_syscall_common+0xf8
Uptime: 212d21h35m47s

- Peter

Re: Install to ZFS root is using device names hence failing when device tree is changed.

[Peter Jeremy]

On 2021-Sep-06 17:45:31 +0200, Karel Gardas  wrote:
>just installed 14-current snapshot from 2.9. on uefi amd64 machine. 
>Installed from USB memstick which was detected as da0 into the ssd 
>hanging on usb3 in external enclosure which was detected as da1.
>
>ZFS root pool is then using /dev/da1p3 as swap and /dev/da1p1 as 
>/boot/efi and probably also something as root zpool.
>
>Anyway, expected thing happen. When I pulled out USB stick identified as 
>da0 on reboot, the drive on USB3 switch from da1 to da0 and result is 
>unbootable system with complains about various /dev/da1xx drives missing 
>for swap efi boot etc.

Can you give more details about exactly what the errors and when they
occur during the boot cycle.  In particular:
* Low-level boot (anything prior to the FreeBSD kernel) knows nothing
  about da0 or da1, so any problems there are associated with your
  BIOS config, not FreeBSD.
* The swap partition will, by default, appear as a hard-wired device
  name in /etc/fstab - that will definitely need updating.  This will
  prevent the "swapon" working but won't prevent the boot.
* ZFS doesn't care about device names - it looks for ZFS labels on all
  possible devices.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Files in /etc containing empty VCSId header

[Peter Jeremy via freebsd-current]

On 2021-Jun-08 17:13:45 -0600, Ian Lepore  wrote:
>On Tue, 2021-06-08 at 15:11 -0700, Rodney W. Grimes wrote:
>> There is a command for that which does or use to do a pretty
>> decent job of it called whereis(1).

Thanks.  That looks useful.

>revolution > whereis ntp.conf
>ntp.conf:
>revolution > whereis netif
>netif:
>revolution > whereis services
>services:
>
>So how does that help me locate the origin of these files in the source
>tree?

It works for me™:
server% whereis ntp.conf
ntp.conf: /usr/src/usr.sbin/ntp/ntpd/ntp.conf
server% whereis netif   
netif: /usr/src/libexec/rc/rc.d/netif
server% whereis services
services: /usr/src/contrib/unbound/services

Is your source tree somewhere other than /usr/src?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

pam_radius fails after the latest libradius security patch...

[Peter Eriksson]

After upgrading FreeBSD 12.2 in order to get the fix from 'FreeBSD Security 
Advisory FreeBSD-SA-21:12.libradius’ sudo with pam_radius has started to fail 
for us. It correctly seems to communicate with the RADIUS server (used to 
trigger MFA authentication, so I get an authentication popup in the Microsoft 
Authenticar App) after entering the unix password first, but then something 
fails:

% sudo su
Password:
sudo: PAM authentication error: Error in service module
sudo: a password is required


pam.d/sudo config file:

# auth
authrequisite   pam_unix.sono_warn try_first_pass
authrequisite   pam_radius.so   use_first_pass

# account
account include system

# session
session requiredpam_permit.so

# password
passwordinclude system


Dunno if the problem is in sudo, libpam, libradius or pam_radius but the only 
thing changed is libradius. And if I replace libradius.so.4 with the previous 
version things work again...

(Considering the spagetti code that sudo is I wouldn’t be surprised if the bug 
is there but still…)


Am I the only one seeing this?

- Peter

Re: RFC: changing the default NFSv4 minor version?

[Peter Eriksson]

I vote for this.

+1

- Peter


> On 14 May 2021, at 01:02, Rick Macklem  wrote:
> 
> Hi,
> 
> I believe that NFSv4.1 and NFSv4.2 are now mature in freebsd-current/main.
> I also believe that NFSv4.1/4.2 is a better protocol than NFSv4.0.
> (In particular, the sessions mechanism for "exactly once RPC semantics"
> is a significant improvement over the duplicate request cache for NFSv4.0,
> plus other improvements.)
> 
> Right now, the FreeBSD NFSv4 client will use NFSv4.0 unless the
> "minorversion" mount option is used to set the minor version to 1 or 2.
> 
> The Linux client uses the highest minor version supported by both
> client and server by default.
> I'd like to propose that the default behaviour of the FreeBSD client
> be changed to do the same, so that NFSv4.1/4.2 will be used when possible.
> --> The "minorversion" mount option could still be used to override the
>  above default.
> 
> I have hesitated doing this change because it could be considered a POLA
> violation, but I think the change from 4.0->4.1/4.2 will normally be a
> neutral to positive experience. (To be honest, I suspect most won't notice
> the change.)
> 
> How do others feel about this change?
> 
> rick
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

panic: general protection fault

[Peter Holm]

I just got this one:

0210415 17:01:45 all (458/755): callout_reset_on.sh
kernel trap 9 with interrupts disabled

Fatal trap 9: general protection fault while in kernel mode
cpuid = 10; apic id = 0a
instruction pointer = 0x20:0x80c7c286
stack pointer = 0x0:0xfe00e49b0730
frame pointer = 0x0:0xfe00e49b0770
code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process  = 12 (swi1: netisr 0)
trap number  = 9
panic: general protection fault
cpuid = 10
time = 1618498958
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e49b0440
vpanic() at vpanic+0x181/frame 0xfe00e49b0490
panic() at panic+0x43/frame 0xfe00e49b04f0
trap_fatal() at trap_fatal+0x387/frame 0xfe00e49b0550
trap() at trap+0xa4/frame 0xfe00e49b0660
calltrap() at calltrap+0x8/frame 0xfe00e49b0660
--- trap 0x9, rip = 0x80c7c286, rsp = 0xfe00e49b0730, rbp = 
0xfe00e49b0770 ---
turnstile_wait() at turnstile_wait+0x46/frame 0xfe00e49b0770
__rw_wlock_hard() at __rw_wlock_hard+0x464/frame 0xfe00e49b0820
_rw_wlock_cookie() at _rw_wlock_cookie+0xb7/frame 0xfe00e49b0860
in_pcblookup_hash() at in_pcblookup_hash+0x76/frame 0xfe00e49b0890
in_pcblookup_mbuf() at in_pcblookup_mbuf+0x24/frame 0xfe00e49b08b0
tcp_input() at tcp_input+0x6e8/frame 0xfe00e49b0a10
ip_input() at ip_input+0x194/frame 0xfe00e49b0aa0
swi_net() at swi_net+0x1a1/frame 0xfe00e49b0b20
ithread_loop() at ithread_loop+0x279/frame 0xfe00e49b0bb0
fork_exit() at fork_exit+0x80/frame 0xfe00e49b0bf0

https://people.freebsd.org/~pho/stress/log/log0092.txt

- Peter
___
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: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177

[Peter Holm]

On Thu, Mar 11, 2021 at 12:56:02PM -0500, Mark Johnston wrote:
> On Thu, Mar 11, 2021 at 06:32:13PM +0100, Peter Holm wrote:
> > I just got this panic:
> > 
> > panic: malloc(M_WAITOK) with sleeping prohibited
> > cpuid = 0
> > time = 1615472733
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> > 0xfe00e49748b0
> > vpanic() at vpanic+0x181/frame 0xfe00e4974900
> > panic() at panic+0x43/frame 0xfe00e4974960
> > malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4974980
> > malloc() at malloc+0x34/frame 0xfe00e49749e0
> > g_mirror_event_send() at g_mirror_event_send+0x30/frame 0xfe00e4974a30
> > softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfe00e4974b00
> > softclock() at softclock+0x66/frame 0xfe00e4974b20
> > ithread_loop() at ithread_loop+0x279/frame 0xfe00e4974bb0
> > fork_exit() at fork_exit+0x80/frame 0xfe00e4974bf0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4974bf0
> > 
> > https://people.freebsd.org/~pho/stress/log/log0078.txt
> 
> Hi Peter,
> 
> Could you try the patch here? https://reviews.freebsd.org/D29223

This fixed the problem for me. I ran the problem test for an hour and
then the rest of the g_mirror tests. No problems seen.

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

panic: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177

[Peter Holm]

I just got this panic:

panic: malloc(M_WAITOK) with sleeping prohibited
cpuid = 0
time = 1615472733
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e49748b0
vpanic() at vpanic+0x181/frame 0xfe00e4974900
panic() at panic+0x43/frame 0xfe00e4974960
malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4974980
malloc() at malloc+0x34/frame 0xfe00e49749e0
g_mirror_event_send() at g_mirror_event_send+0x30/frame 0xfe00e4974a30
softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfe00e4974b00
softclock() at softclock+0x66/frame 0xfe00e4974b20
ithread_loop() at ithread_loop+0x279/frame 0xfe00e4974bb0
fork_exit() at fork_exit+0x80/frame 0xfe00e4974bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4974bf0

https://people.freebsd.org/~pho/stress/log/log0078.txt

- Peter
___
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: malloc(M_WAITOK) with sleeping prohibited

[Peter Holm]

On Wed, Mar 10, 2021 at 01:33:34PM +0100, Hans Petter Selasky wrote:
> On 3/10/21 12:41 PM, Peter Holm wrote:
> > On Wed, Mar 10, 2021 at 10:52:53AM +0100, Hans Petter Selasky wrote:
> >> On 3/10/21 10:15 AM, Peter Holm wrote:
> >>> I just got this panic:
> >>>
> >>> igb0:  port 0xd020-0xd03f 
> >>> mem 0xfb32-0xfb33,0xfb344000-0xfb347fff irq 16 at device 0.0 on 
> >>> pci8
> >>> igb0: Using 1024 TX descriptors and 1024 RX descriptors
> >>> igb0: queue equality override not set, capping rx_queues at 6 and 
> >>> tx_queues at 6
> >>> igb0: Using 6 RX queues 6 TX queues
> >>> igb0: Using MSI-X interrupts with 7 vectors
> >>> igb0:
> >>> db>
> >>> db> show panic
> >>> panic: malloc(M_WAITOK) with sleeping prohibited
> >>> db> bt
> >>> Tracing pid 12 tid 100172 td 0xfe010dce2100
> >>> kdb_enter() at kdb_enter+0x37/frame 0xfe00e4f72980
> >>> vpanic() at vpanic+0x1b2/frame 0xfe00e4f729d0
> >>> panic() at panic+0x43/frame 0xfe00e4f72a30
> >>> malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4f72a50
> >>> malloc() at malloc+0x34/frame 0xfe00e4f72ab0
> >>> linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfe00e4f72b00
> >>> linux_irq_handler() at linux_irq_handler+0x3a/frame 0xfe00e4f72b20
> >>> ithread_loop() at ithread_loop+0x279/frame 0xfe00e4f72bb0
> >>> fork_exit() at fork_exit+0x80/frame 0xfe00e4f72bf0
> >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4f72bf0
> >>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> >>> db> x/s version
> >>> version:FreeBSD 14.0-CURRENT #0 main-n245371-ce53f92e6c81: Wed 
> >>> Mar 10 10:00:29 CET 2021\012
> >>> p...@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012
> >>> db>
> >>
> >> This should fix it:
> >> https://cgit.freebsd.org/src/commit/?id=d1cbe79089868226625c12ef49f51214d79aa427
> >>
> >> --HPS
> > 
> > Yes, thank you. Now I see this:
> > 
> > ugen0.3:  at usbus0
> > ukbd0 on uhub3
> > ukbd0:  on 
> > usbus0
> > kbd2 at ukbd0
> > panic: malloc(M_WAITOK) with sleeping prohibited
> > cpuid = 0
> > time = 1615375651
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> > 0xfe00e4974890
> > vpanic() at vpanic+0x181/frame 0xfe00e49748e0
> > panic() at panic+0x43/frame 0xfe00e4974940
> > malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4974960
> > malloc() at malloc+0x34/frame 0xfe00e49749c0
> > linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfe00e4974a10
> > linux_timer_callback_wrapper() at linux_timer_callback_wrapper+0x37/frame 
> > 0xfe00e4974a30
> > softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfe00e4974b00
> > softclock() at softclock+0x66/frame 0xfe00e4974b20
> > ithread_loop() at ithread_loop+0x279/frame 0xfe00e4974bb0
> > fork_exit() at fork_exit+0x80/frame 0xfe00e4974bf0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4974bf0
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > KDB: enter: panic
> > [ thread pid 12 tid 100088 ]
> 
> Try this:
> https://cgit.freebsd.org/src/commit/?id=dfb33cb0ef48084da84072244e8ca486dfcf3a96
> 

Works for me. Thank you!

- Peter

> There will be a more comprehensive fix coming:
> https://reviews.freebsd.org/D29183
> 
> --HPS
___
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: malloc(M_WAITOK) with sleeping prohibited

[Peter Holm]

On Wed, Mar 10, 2021 at 10:52:53AM +0100, Hans Petter Selasky wrote:
> On 3/10/21 10:15 AM, Peter Holm wrote:
> > I just got this panic:
> > 
> > igb0:  port 0xd020-0xd03f mem 
> > 0xfb32-0xfb33,0xfb344000-0xfb347fff irq 16 at device 0.0 on pci8
> > igb0: Using 1024 TX descriptors and 1024 RX descriptors
> > igb0: queue equality override not set, capping rx_queues at 6 and tx_queues 
> > at 6
> > igb0: Using 6 RX queues 6 TX queues
> > igb0: Using MSI-X interrupts with 7 vectors
> > igb0:
> > db>
> > db> show panic
> > panic: malloc(M_WAITOK) with sleeping prohibited
> > db> bt
> > Tracing pid 12 tid 100172 td 0xfe010dce2100
> > kdb_enter() at kdb_enter+0x37/frame 0xfe00e4f72980
> > vpanic() at vpanic+0x1b2/frame 0xfe00e4f729d0
> > panic() at panic+0x43/frame 0xfe00e4f72a30
> > malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4f72a50
> > malloc() at malloc+0x34/frame 0xfe00e4f72ab0
> > linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfe00e4f72b00
> > linux_irq_handler() at linux_irq_handler+0x3a/frame 0xfe00e4f72b20
> > ithread_loop() at ithread_loop+0x279/frame 0xfe00e4f72bb0
> > fork_exit() at fork_exit+0x80/frame 0xfe00e4f72bf0
> > fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4f72bf0
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > db> x/s version
> > version:FreeBSD 14.0-CURRENT #0 main-n245371-ce53f92e6c81: Wed Mar 
> > 10 10:00:29 CET 2021\012
> > p...@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012
> > db>
> 
> This should fix it:
> https://cgit.freebsd.org/src/commit/?id=d1cbe79089868226625c12ef49f51214d79aa427
> 
> --HPS

Yes, thank you. Now I see this:

ugen0.3:  at usbus0
ukbd0 on uhub3
ukbd0:  on 
usbus0
kbd2 at ukbd0
panic: malloc(M_WAITOK) with sleeping prohibited
cpuid = 0
time = 1615375651
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e4974890
vpanic() at vpanic+0x181/frame 0xfe00e49748e0
panic() at panic+0x43/frame 0xfe00e4974940
malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4974960
malloc() at malloc+0x34/frame 0xfe00e49749c0
linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfe00e4974a10
linux_timer_callback_wrapper() at linux_timer_callback_wrapper+0x37/frame 
0xfe00e4974a30
softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfe00e4974b00
softclock() at softclock+0x66/frame 0xfe00e4974b20
ithread_loop() at ithread_loop+0x279/frame 0xfe00e4974bb0
fork_exit() at fork_exit+0x80/frame 0xfe00e4974bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4974bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 12 tid 100088 ]
Stopped at  kdb_enter+0x37: movq$0,0x12891fe(%rip)
db> x/s version
version:FreeBSD 14.0-CURRENT #0 main-n245372-d1cbe7908986: Wed Mar 10 
12:25:03 CET 2021\012
p...@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012
db>

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

panic: malloc(M_WAITOK) with sleeping prohibited

[Peter Holm]

I just got this panic:

igb0:  port 0xd020-0xd03f mem 
0xfb32-0xfb33,0xfb344000-0xfb347fff irq 16 at device 0.0 on pci8
igb0: Using 1024 TX descriptors and 1024 RX descriptors
igb0: queue equality override not set, capping rx_queues at 6 and tx_queues at 6
igb0: Using 6 RX queues 6 TX queues
igb0: Using MSI-X interrupts with 7 vectors
igb0:
db>
db> show panic
panic: malloc(M_WAITOK) with sleeping prohibited
db> bt
Tracing pid 12 tid 100172 td 0xfe010dce2100
kdb_enter() at kdb_enter+0x37/frame 0xfe00e4f72980
vpanic() at vpanic+0x1b2/frame 0xfe00e4f729d0
panic() at panic+0x43/frame 0xfe00e4f72a30
malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4f72a50
malloc() at malloc+0x34/frame 0xfe00e4f72ab0
linux_alloc_current() at linux_alloc_current+0x3d/frame 0xfe00e4f72b00
linux_irq_handler() at linux_irq_handler+0x3a/frame 0xfe00e4f72b20
ithread_loop() at ithread_loop+0x279/frame 0xfe00e4f72bb0
fork_exit() at fork_exit+0x80/frame 0xfe00e4f72bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4f72bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db> x/s version
version:FreeBSD 14.0-CURRENT #0 main-n245371-ce53f92e6c81: Wed Mar 10 
10:00:29 CET 2021\012
p...@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012
db>

- Peter
___
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 broken in 13.0-BETA4 and later on armv8

[Peter Jeremy via freebsd-current]

On 2021-Mar-06 10:39:02 -0800, Oleksandr Tymoshenko  wrote:
>Peter Jeremy via freebsd-current (freebsd-current@freebsd.org) wrote:
>> [Adding arm@ and making it clearer that this is armv8-only]
>> 
>> On 2021-Mar-06 20:26:19 +1100, Peter Jeremy  
>> wrote:
>> >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable 
>> > wrote:
>> >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4
>> >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 -
>> >>RK3399, arm64) has changed so that a geli-encrypted partition (using
>> >>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on
>> >>13.0-BETA4.
>> >
>> >I've confirmed that the problem is f76393a6305b - reverting that
>> >commit fixes the problem in releng/13.0.
>> >
>> >I've further verified that the bug is still present in main (14.x)
>> >at 028616d0dd69.
>
>Could you test this patch and let me know if it fixes the issue?
>
>https://people.freebsd.org/~gonzo/patches/armv8crypto-xts-fix.diff

Yes, it does.  Thank you very much.

--- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: geli broken in 13.0-BETA4 and later on armv8

[Peter Jeremy via freebsd-current]

[Adding arm@ and making it clearer that this is armv8-only]

On 2021-Mar-06 20:26:19 +1100, Peter Jeremy  wrote:
>On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable 
> wrote:
>>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4
>>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 -
>>RK3399, arm64) has changed so that a geli-encrypted partition (using
>>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on
>>13.0-BETA4.
>
>I've confirmed that the problem is f76393a6305b - reverting that
>commit fixes the problem in releng/13.0.
>
>I've further verified that the bug is still present in main (14.x)
>at 028616d0dd69.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: geli broken in 13.0-BETA4 and later

[Peter Jeremy via freebsd-current]

On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable 
 wrote:
>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4
>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 -
>RK3399, arm64) has changed so that a geli-encrypted partition (using
>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on
>13.0-BETA4.

I've confirmed that the problem is f76393a6305b - reverting that
commit fixes the problem in releng/13.0.

I've further verified that the bug is still present in main (14.x)
at 028616d0dd69.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: r367672 broke the NFS server

[Peter Holm]

On Wed, Dec 30, 2020 at 07:27:08PM +0200, Konstantin Belousov wrote:
> On Wed, Dec 30, 2020 at 04:48:27PM +, Rick Macklem wrote:
> > Kostik wrote:
> > >On Wed, Dec 30, 2020 at 02:02:48AM +, Rick Macklem wrote:
> > >> Hi,
> > >>
> > >> Post r367671...
> > >> When multiple files are being created by an NFS client in the same
> > >> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
> > >> This results in a EIO return to the NFS client.
> > >> --> This causes "nfsv4 client/server protocol prob err=10026"
> > >>   on the client for NFSv4.0 mounts.
> > >>   --> This explains why this error has been reported by
> > >> several people lately, although it should "never happen".
> > >>
> > >> Unfortunately, for the NFS server, the Lookup call is done separately
> > >> and it will not be easy to redo it, given the current NFS code structure.
> > >>
> > >> Is there another way to deal with the problem r367672 was fixing that
> > >> avoids ufs_create() returning ERELOOKUP?
> > >
> > >Idea of the change is to restart the syscall at top level.  So for NFS
> > >server the right approach is to not send a response and also to not
> > >free the request mbuf chain, but to restart processing.
> > Yes. I took a look and I think restarting the operation by rolling the
> > working position in the mbuf lists back and redoing the operation
> > is feasible and easier than fixing the individual operations.
> > 
> > For NFSv4, you cannot redo the entire compound, since non-idempotent
> > operations like exclusive open may have already been completed.
> > However, rolling back to the beginning of the operation should be
> > doable.
> > --> It will serve as a good test, in that it may expose bugs in the
> >   RPC/operation code where failure (ERELOOKUP) doesn't clean
> >   things up correctly.
> >   --> In NFSv4, there is the open/lock state that cannot be updated
> > for this error case. (The seqid stuff in NFSv4.0 Open can be 
> > fun.
> > Its used to serialize the operations and the number must be
> > incremented for some errors, but not for others. The 10026
> > error occurs when you don't get this right.)
> Note that ERELOOKUP error can only show up from the VOPs that modify the 
> volume.
> Otherwise we simply do not call into SU.  In particular, I believe that opens
> in the sense of NFS are safe.
> 
> Regardless of it, there should be either a catch-all check for ERELOOKUP,
> or assert that ERELOOKUP did not leaked, as it is done for syscalls
> 
> > 
> > I'll start working on this to-day, but I have no idea how long it might
> > take?
> > 
> > >I am sorry I forgot about NFS server when designing this fix, the only
> > >mild excuse I can provide is that the change was quite complicated as is.
> > >I will start looking at the fix.
> > No problem. Sometimes I'd like to forget about NFS too;-).
> > 
> > For the rollback/redo the RPC/operation case, it's probably easier for me
> > to do it. As above, I'll start on it, but...
> > 
> > My main concern is how long it will take, given the FreeBSD13 release
> > starts soon.
> For sure I will help you if needed, and I believe that we could ask for
> testing from Peter.

Absolutely.
Not sure how I missed running NFS test the first time around.

- Peter

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

Re: panic: general protection fault from uipc_sockaddr+0x4c

[Peter Holm]

On Tue, Dec 08, 2020 at 10:30:41AM -0500, Mark Johnston wrote:
> On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote:
> > I just got this panic:
> > 
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 9; apic id = 09
> > instruction pointer = 0x20:0x80bc6e22
> > stack pointer = 0x28:0xfe0698887630
> > frame pointer = 0x28:0xfe06988876b0
> > code segment  = base 0x0, limit 0xf, type 0x1b
> >= DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > current process  = 45966 (fstat)
> > trap number  = 9
> > panic: general protection fault
> > cpuid = 9
> > time = 1607416693
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> > 0xfe0698887340
> > vpanic() at vpanic+0x181/frame 0xfe0698887390
> > panic() at panic+0x43/frame 0xfe06988873f0
> > trap_fatal() at trap_fatal+0x387/frame 0xfe0698887450
> > trap() at trap+0xa4/frame 0xfe0698887560
> > calltrap() at calltrap+0x8/frame 0xfe0698887560
> > --- trap 0x9, rip = 0x80bc6e22, rsp = 0xfe0698887630, rbp = 
> > 0xfe06988876b0 ---
> > __mtx_lock_sleep() at __mtx_lock_sleep+0xd2/frame 0xfe06988876b0
> > __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfe0698887700
> > uipc_sockaddr() at uipc_sockaddr+0x4c/frame 0xfe0698887730
> > soo_fill_kinfo() at soo_fill_kinfo+0x11e/frame 0xfe0698887770
> > kern_proc_filedesc_out() at kern_proc_filedesc_out+0xb57/frame 
> > 0xfe0698887810
> > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x7d/frame 
> > 0xfe0698887890
> > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame 
> > 0xfe06988878e0
> > sysctl_root() at sysctl_root+0x20d/frame 0xfe0698887960
> > userland_sysctl() at userland_sysctl+0x180/frame 0xfe0698887a10
> > sys___sysctl() at sys___sysctl+0x5f/frame 0xfe0698887ac0
> > amd64_syscall() at amd64_syscall+0x147/frame 0xfe0698887bf0
> > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0698887bf0
> > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8003948ea, rsp = 
> > 0x7fffc138, rbp = 0x7fffc170 ---
> > 
> > https://people.freebsd.org/~pho/stress/log/log0004.txt
> 
> So here the unpcb is freed, and indeed the file itself has been closed:
> 
> $3 = {f_flag = 0x3, f_count = 0x0, f_data = 0x0, f_ops = 0x81901f50 
> ,
>   f_vnode = 0x0, f_cred = 0xf80248beb600, f_type = 0x2, 
> 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}
> 
> However, it must have happened very recently because soo_fill_kinfo()
> dereferences fp->f_data and yet we did not panic due to a null
> dereference.
> 
> kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of
> this, which is supposed to prevent the table entry from being freed
> since that requires the exclusive lock.
> 
> Could you show fdp->fd_ofiles[3] and fdp->fd_map[0] from frame 26?

Sure:

(kgdb) p fdp->fd_files->fdt_ofiles[3]
$1 = {fde_file = 0xf807306fd0f0, fde_caps = {fc_rights = {cr_rights = {0x0, 
0x0}}, fc_ioctls = 0x0, fc_nioctls = 0x0, fc_fcntls = 0x0}, fde_flags = 0x0, 
fde_seqc = 0x2}
(kgdb) p fdp->fd_map[0]
$2 = 0x1f
(kgdb) 

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

panic: general protection fault from uipc_sockaddr+0x4c

[Peter Holm]

I just got this panic:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 9; apic id = 09
instruction pointer = 0x20:0x80bc6e22
stack pointer = 0x28:0xfe0698887630
frame pointer = 0x28:0xfe06988876b0
code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 45966 (fstat)
trap number  = 9
panic: general protection fault
cpuid = 9
time = 1607416693
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0698887340
vpanic() at vpanic+0x181/frame 0xfe0698887390
panic() at panic+0x43/frame 0xfe06988873f0
trap_fatal() at trap_fatal+0x387/frame 0xfe0698887450
trap() at trap+0xa4/frame 0xfe0698887560
calltrap() at calltrap+0x8/frame 0xfe0698887560
--- trap 0x9, rip = 0x80bc6e22, rsp = 0xfe0698887630, rbp = 
0xfe06988876b0 ---
__mtx_lock_sleep() at __mtx_lock_sleep+0xd2/frame 0xfe06988876b0
__mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfe0698887700
uipc_sockaddr() at uipc_sockaddr+0x4c/frame 0xfe0698887730
soo_fill_kinfo() at soo_fill_kinfo+0x11e/frame 0xfe0698887770
kern_proc_filedesc_out() at kern_proc_filedesc_out+0xb57/frame 
0xfe0698887810
sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x7d/frame 
0xfe0698887890
sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame 
0xfe06988878e0
sysctl_root() at sysctl_root+0x20d/frame 0xfe0698887960
userland_sysctl() at userland_sysctl+0x180/frame 0xfe0698887a10
sys___sysctl() at sys___sysctl+0x5f/frame 0xfe0698887ac0
amd64_syscall() at amd64_syscall+0x147/frame 0xfe0698887bf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0698887bf0
--- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8003948ea, rsp = 
0x7fffc138, rbp = 0x7fffc170 ---

https://people.freebsd.org/~pho/stress/log/log0004.txt

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

r367927 buildkernel stops on isp.o undeclared ATPDPSIZE

[Peter Libassi]

svnlite info /usr/src

Path: .
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 367927
Node Kind: directory
Schedule: normal
Last Changed Author: rew
Last Changed Rev: 367927
Last Changed Date: 2020-11-22 06:00:28 +0100 (Sun, 22 Nov 2020)

make -j4 buildkernel KERNCONF="GENERIC-NODEBUG”

--- isp.o ---
/usr/src/sys/dev/isp/isp.c:750:50: error: use of undeclared identifier 
'ATPDPSIZE'
icbp->icb_xchgcnt = MIN(isp->isp_maxcmds / 2, 
ATPDPSIZE);
  ^
/usr/src/sys/dev/isp/isp.c:750:50: error: use of undeclared identifier 
'ATPDPSIZE'
2 errors generated.
*** [isp.o] Error code 1

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
--- modules-all ---
ctfconvert -L VERSION -g ar5212_eeprom.o
*** [modules-all] Error code 2

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
--- isp_freebsd.o ---
ctfconvert -L VERSION -g isp_freebsd.o
--- if_ipw.o ---
ctfconvert -L VERSION -g if_ipw.o
2 errors

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG


/Peter
___
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: review of new mountd option disabling use of rpcbind

[Peter Eriksson]

Suggestion: 
Add a check for sysctl vfs.nfsd.server_min_nfsvers and if set to 4 or higher - 
automatically enable the “-R” option.

- Peter


> On 20 Oct 2020, at 02:56, Rick Macklem  wrote:
> 
> Hi,
> 
> I've put a patch up on phabricator that adds a new option to mountd
> which disables use of rpcbind. This can be done for NFSv4 only servers.
> It appears that rpcbind is now considered a security risk by some.
> 
> I listed freqlabs@ as a reviewer, but if anyone else would like to review
> it, please do so. (Someone has reviewed the man page update already.
> Thanks bcr@.)
> 
> It's D26746.
> 
> rick
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: vnet/jail crashdump

[Peter Libassi]

Looks like bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985> 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985>> and 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326> 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326>>

The workaround in Bug 238326 comment 7 worked for me.


/Peter

> 3 aug. 2020 kl. 19:36 skrev Ronald Klop :
> 
> Hi,
> 
> After stopping a jail I get a crashdump.
> core.txt: https://www.klop.ws/core_2eef39c581f90f2f0c4921e43f1998c1/core.txt.0
> 
> Jail.conf:
> --
> exec.stop = "/bin/sh /etc/rc.shutdown";
> exec.clean;
> 
> exec.prestart = "ifconfig bridge0 > /dev/null 2> /dev/null || ( ifconfig 
> bridge0 create && ifconfig bridge0 addm vtnet0 && ifconfig bridge0 up)";
> 
> exec.consolelog = "/var/log/jail_${name}_console.log";
> 
> mount.devfs;
> path = "/data/jails/$name";
> host.hostname = "$name";
> mount.fstab = "/data/jails/fstab.$name";
> vnet;
> allow.mlock;
> devfs_ruleset="110";
> 
> freebsd12 {
>   osrelease = 12.1-RELEASE-p4;
>   osreldate = 1201000;
>   vnet.interface = "epair0b";
>   # make sure the exec.prestart has a "+=" as we de it in the global 
> definition
>   # when checking for the bridge
>   exec.prestart += "ifconfig epair0 create up";
>   exec.prestart += "ifconfig bridge0 addm epair0a";
>   exec.prestart += "ifconfig epair0b link 02:xx:0c";
>   exec.start = "dhclient epair0b";
>   exec.start += "/bin/sh /etc/rc";
>   exec.poststop  = "ifconfig bridge0 deletem epair0a";
>   exec.poststop += "ifconfig epair0a destroy";
> 
> }
> freebsd13 {
>   vnet.interface = "epair1b";
>   # make sure the exec.prestart has a "+=" as we de it in the global 
> definition
>   # when checking for the bridge
>   exec.prestart += "ifconfig epair1 create up";
>   exec.prestart += "ifconfig bridge0 addm epair1a";
>   exec.prestart += "ifconfig epair1b link 02:xx:0d";
>   exec.start = "dhclient epair1b";
>   exec.start += "/bin/sh /etc/rc";
>   exec.poststop  = "ifconfig bridge0 deletem epair1a";
>   exec.poststop += "ifconfig epair1a destroy";
> }
> --
> 
> What can I do to help debug?
> 
> Regards,
> Ronald.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: CFT: if_bridge performance improvements

[peter . blok]

Just using pf is enough to provoke this panic. I had the same back trace. This 
patch from Kristof fixed it for me.

diff --git a/sys/net/if_bridge.c b/sys/net/if_bridge.c
index 373fa096d70..83c453090bb 100644
--- a/sys/net/if_bridge.c
+++ b/sys/net/if_bridge.c
@@ -2529,7 +2529,6 @@ bridge_input(struct ifnet *ifp, struct mbuf *m)
 OR_PFIL_HOOKED_INET6)) {   \
if (bridge_pfil(&m, NULL, ifp,  \
PFIL_IN) != 0 || m == NULL) {   \
-   BRIDGE_UNLOCK(sc);  \
return (NULL);  \
}   \
eh = mtod(m, struct ether_header *);\


> On 22 Apr 2020, at 18:15, Xin Li  wrote:
> 
> On 4/22/20 01:45, Kristof Provost wrote:
>> On 22 Apr 2020, at 10:20, Xin Li wrote:
>>> Hi,
>>> 
>>> On 4/14/20 02:51, Kristof Provost wrote:
 Hi,
 
 Thanks to support from The FreeBSD Foundation I’ve been able to work on
 improving the throughput of if_bridge.
 It changes the (data path) locking to use the NET_EPOCH infrastructure.
 Benchmarking shows substantial improvements (x5 in test setups).
 
 This work is ready for wider testing now.
 
 It’s under review here: https://reviews.freebsd.org/D24250
 
 Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true
 Patches for stable/12:
 https://people.freebsd.org/~kp/if_bridge/stable_12/
 
 I’m not currently aware of any panics or issues resulting from these
 patches.
>>> 
>>> I have observed the following panic with latest stable/12 after applying
>>> the stable_12 patchset, it appears like a race condition related NULL
>>> pointer deference, but I haven't took a deeper look yet.
>>> 
>>> The box have 7 igb(4) NICs, with several bridge and VLAN configured
>>> acting as a router.  Please let me know if you need additional
>>> information; I can try -CURRENT as well, but it would take some time as
>>> the box is relatively slow (it's a ZFS based system so I can create a
>>> separate boot environment for -CURRENT if needed, but that would take
>>> some time as I might have to upgrade the packages, should there be any
>>> ABI breakages).
>>> 
>> Thanks for the report. I don’t immediately see how this could happen.
>> 
>> Are you running an L2 firewall on that bridge by any chance? An earlier
>> version of the patch had issues with a stray unlock in that code path.
> 
> I don't think I have a L2 firewall (I assume means filtering based on
> MAC address like what can be done with e.g. ipfw?  The bridges were
> created on vlan interfaces though, do they count as L2 firewall?), the
> system is using pf with a few NAT rules:
> 
> $ sudo pfctl -s rules
> anchor "miniupnpd" all
> pass in quick inet6 proto tcp from  to any flags S/SA keep state
> block drop in quick inet6 proto tcp from !  to  flags S/SA
> block drop in quick proto tcp from any os "Linux" to any port = ssh
> pass out on igb6 inet proto tcp from (igb6) to any port = domain flags
> S/SA keep state queue dns
> pass out on igb6 inet proto udp from (igb6) to any port = domain keep
> state queue dns
> pass in on igb6 proto tcp from any to (igb6) port = http flags S/SA
> modulate state queue(web, ack)
> pass in on igb6 proto tcp from any to (igb6) port = https flags S/SA
> modulate state queue(web, ack)
> pass out on igb6 inet proto tcp from (igb6) to any flags S/SA modulate
> state queue bulk
> block drop in quick on igb6 proto tcp from  to any port = ssh
> label "ssh bruteforce"
> block drop in on igb6 from  to any
> 
> Cheers,

___
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: New Xorg - different key-codes

[Peter Jeremy]

On 2020-Mar-11 10:29:08 +0100, Niclas Zeising  wrote:
>This has to do with switching to using evdev to handle input devices on 
>FreeBSD 12 and CURRENT.  There's been several reports, and suggested 
>solutions to this, as well as an UPDATING entry detailing the change.

The UPDATING entry says that it's switched from devd to udev.  There's no
mention of evdev or that the keycodes have been roto-tilled.  It's basically
a vanilla "things have been changed, see the documentation" entry.  Given
that entry, it's hardly surprising that people are confused.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: System clock is slow

[Peter Jeremy]

On 2020-Mar-09 19:59:09 -0400, Theron  wrote:
>Since switching from 12.1-RELEASE to CURRENT I've noticed timing 
>problems with audio applications.  It turns out that the problem is not 
>with the audio drivers, but with the system clock driver, which now 
>reports passage of time 0.3% too slow.  Although I discovered this only 
>recently, it's been broken since r352684 made on Sept. 25.  Has anyone 
>else noticed?

Note that r352684 was MFC'd to both 11-stable (r353007) and 12-stable
(r353006) in early October and I don't recall seeing any adverse
reports before this.

Are you running NTP?  If so, is NTP maintaining lock and what is the
reported PLL frequency (ntpq -c kerni)?

What does "sysctl kern.timecounter" report and have you tried using
any of the alternative timecounters listed in kern.timecounter.choice?

Are you overclocking your CPU (or doing anything else non-standard)?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Which AMD CPUs are supported -- temperature

[Peter Jeremy]

On 2020-Feb-13 13:27:17 -0800, Chris  wrote:
>My BIOS appears to have the correct temp reading. Would it be of any use
>to anyone besides myself, if I were to decompile it, and get the source
>for the temp reading/monitoring from it?

I would definitely like to have this information.  If you are able to
share the two constants (both step size and reference temperature), that
would be great.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Which AMD CPUs are supported -- temperature

[Peter Jeremy]

On 2020-Feb-12 15:23:51 -0500, mike tancsa  wrote:
>Not sure about the older Athlon CPUs, but the 2 generations of Ryzen's I
>have seem correct as well as an APU
>
>CPU: AMD GX-412TC SOC    (998.17-MHz K8-class CPU)

OTOH, I'm not confident about temperatures on my APU.  The publicly
available data just says that the SoC reports "a temperature on its own
scale" relative to a Tctl_max which "is specified in the power and thermal
data sheet" (that I have been unable to locate).  Everyone seems to assume
that the step size is 0.125K but I haven't found that publicly documented
anywhere.  The AMD Product Brief states that the maximum temperature is
90°C but using that as Tctl_max gives me temperature readings that don't
look right.

>And on a fanless APU
>
># sysctl -a dev.cpu.0.temperature
>dev.cpu.0.temperature: 62.6C
>
># sysctl -a dev.amdtemp.0.core0.sensor0
>dev.amdtemp.0.core0.sensor0: 63.1C

At what ambient temperature?  I see a similar value from my (idle) APU3
but don't believe the (implied) ~35K junction-to-ambient difference.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: head -r356066 reaching kern.ipc.nmbclusters on Rock64 (CortexA53 with 4GiByte of RAM) while putting files on it via nfs: some evidence

[Peter Jeremy]

Sorry for the delay in responding.

On 2019-Dec-27 21:59:49 -0800, Mark Millard via freebsd-arm 
 wrote:
>The following sort of sequence leads to the Rock64 not
>responding on the console or over ethernet, after notifying
>of nmbclusters having been reached. (This limits what
>information I have of what things were like at the end.)

There's a bug in the dwc(4) driver such that it can leak mbuf clusters.
I've been running with the following patch but need to clean it up
samewhat before I can commit it:

Index: sys/dev/dwc/if_dwc.c
===
--- sys/dev/dwc/if_dwc.c(revision 356350)
+++ sys/dev/dwc/if_dwc.c(working copy)
@@ -755,7 +755,6 @@
 dwc_rxfinish_locked(struct dwc_softc *sc)
 {
struct ifnet *ifp;
-   struct mbuf *m0;
struct mbuf *m;
int error, idx, len;
uint32_t rdes0;
@@ -762,9 +761,8 @@
 
ifp = sc->ifp;
 
-   for (;;) {
+   for (; ; sc->rx_idx = next_rxidx(sc, sc->rx_idx)) {
idx = sc->rx_idx;
-
rdes0 = sc->rxdesc_ring[idx].tdes0;
if ((rdes0 & DDESC_RDES0_OWN) != 0)
break;
@@ -773,9 +771,9 @@
BUS_DMASYNC_POSTREAD);
bus_dmamap_unload(sc->rxbuf_tag, sc->rxbuf_map[idx].map);
 
+   m = sc->rxbuf_map[idx].mbuf;
len = (rdes0 >> DDESC_RDES0_FL_SHIFT) & DDESC_RDES0_FL_MASK;
if (len != 0) {
-   m = sc->rxbuf_map[idx].mbuf;
m->m_pkthdr.rcvif = ifp;
m->m_pkthdr.len = len;
m->m_len = len;
@@ -784,24 +782,33 @@
/* Remove trailing FCS */
m_adj(m, -ETHER_CRC_LEN);
 
+   /* Consume the mbuf and mark it as consumed */
+   sc->rxbuf_map[idx].mbuf = NULL;
DWC_UNLOCK(sc);
(*ifp->if_input)(ifp, m);
DWC_LOCK(sc);
+   m = NULL;
} else {
/* XXX Zero-length packet ? */
}
 
-   if ((m0 = dwc_alloc_mbufcl(sc)) != NULL) {
-   if ((error = dwc_setup_rxbuf(sc, idx, m0)) != 0) {
-   /*
-* XXX Now what?
-* We've got a hole in the rx ring.
-*/
+   if (m == NULL) {
+   if ((m = dwc_alloc_mbufcl(sc)) == NULL) {
+   if_inc_counter(sc->ifp, IFCOUNTER_IQDROPS, 1);
+   continue;
}
-   } else
+   }
+
+   if ((error = dwc_setup_rxbuf(sc, idx, m)) != 0) {
+   m_free(m);
+   device_printf(sc->dev,
+   "dwc_setup_rxbuf returned %d\n", error);
if_inc_counter(sc->ifp, IFCOUNTER_IQDROPS, 1);
-
-   sc->rx_idx = next_rxidx(sc, sc->rx_idx);
+   /*
+* XXX Now what?
+    * We've got a hole in the rx ring.
+*/
+   }
}
 }

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Best way to print something from the kernel at 1s intervals?

[Peter Eriksson]

I love dtrace, but I seriously doubt that it could be used it for this. This is 
the absolutely last code that executes at kernel shutdown/reboot. All other 
processes are terminated when this is happening...

Basically the code done in kern_reboot() (and stuff it calls) in 
/usr/src/sys/kern/kern_shutdown.c

This code in kern_reboot():
...
>  EVENTHANDLER_INVOKE(shutdown_pre_sync, howto);
>
>/*
> * Now sync filesystems
> */
>if (!cold && (howto & RB_NOSYNC) == 0 && once == 0) {
>once = 1;
>bufshutdown(show_busybufs);
>}
>
>print_uptime();
>
>cngrab();
>
>/*
> * Ok, now do things that assume all filesystem activity has
> * been completed.
> */
>EVENTHANDLER_INVOKE(shutdown_post_sync, howto);
>
>if ((howto & (RB_HALT|RB_DUMP)) == RB_DUMP && !cold && !dumping)
>doadump(TRUE);
>
>/* Now that we're going to really halt the system... */
>EVENTHANDLER_INVOKE(shutdown_final, howto);

What I’ve seen is that the three different EVENTHANDLER_INVOKE() all can cause 
a lot of calls that can take a long time. As can bufshutdown(), probably when 
it calls vfs_unmountall() to unmount all filesystems.

We’re talking like 5-20 minutes (or more). I’ve not really timed it.

I have a feeling it sometimes is due to transactions stored up in the ZFS 
filesystems that the system tries to “run” so it doesn’t have to do it at 
mount() time after the reboot. If I reset the machine while it is busy doing 
this then sometimes the “zfs mount -a” takes very long time at boot instead.

Hmm.. I should be able to use the getnanouptime() call to get a “clock” to look 
for (it’s used in print_uptime()). As long as the clock isn’t stopped at this 
time in the shutdown sequence atleast :-)

*Time to write some code and test this* :-)

- Peter


> On 29 Nov 2019, at 22:09, Enji Cooper  wrote:
> 
> 
>> On Nov 28, 2019, at 12:52, Peter Eriksson  wrote:
>> 
>> I’ve been looking into the “kernel looks to be hung at reboot” problem at 
>> bit. Adding a lot of printf() calls to the relevant parts it looks like it 
>> actually isn’t hung but busy unmounting filesystems (which we have thousands 
>> of), flushing disk caches, calling registered callbacks and stuff and 
>> sometimes it takes a bit longer than usual - probably due to ZFS having 
>> stuff queued up that needs to be written to disk before it finishes…
>> 
>> Anyway, I’d like to propose that we add some kind of counter/printf() calls 
>> in that code area so we can see that things are indeed progressing. However, 
>> I’d probably prefer not to print _every_ filesystem (or registered callbacks 
>> - a lot of those...) - that generates a lot of output (tried that :-) but 
>> something like:
>> 
>> Unmounting filesystems:
>> 1234 done
>> (With the "1234 done” updated something like once per second).
>> 
>> What’s the right/best way to do that from the kernel? In user space I’d just 
>> call time(&t) at some convenient points and only print something if “t” has 
>> changed. :-)
> 
> Can you use DTrace instead to get the information you need?
> Cheers,
> -Enji

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

Best way to print something from the kernel at 1s intervals?

[Peter Eriksson]

I’ve been looking into the “kernel looks to be hung at reboot” problem at bit. 
Adding a lot of printf() calls to the relevant parts it looks like it actually 
isn’t hung but busy unmounting filesystems (which we have thousands of), 
flushing disk caches, calling registered callbacks and stuff and sometimes it 
takes a bit longer than usual - probably due to ZFS having stuff queued up that 
needs to be written to disk before it finishes…

Anyway, I’d like to propose that we add some kind of counter/printf() calls in 
that code area so we can see that things are indeed progressing. However, I’d 
probably prefer not to print _every_ filesystem (or registered callbacks - a 
lot of those...) - that generates a lot of output (tried that :-) but something 
like:

Unmounting filesystems:
1234 done
(With the "1234 done” updated something like once per second).

What’s the right/best way to do that from the kernel? In user space I’d just 
call time(&t) at some convenient points and only print something if “t” has 
changed. :-)

- Peter

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

buildworld has mandatory dependency on optional executable.

[Peter Jeremy]

I've just discovered that "make buildworld" has a mandatory dependency
on kbdcontrol (see
https://svnweb.freebsd.org/base/head/Makefile.inc1?annotate=354138#l2207 )
but, if WITHOUT_LEGACY_CONSOLE is defined then kbdcontrol isn't built
(https://svnweb.freebsd.org/base/head/usr.sbin/Makefile?annotate=352949#l162 )
and the installed version will be deleted by "make delete-old":
https://svnweb.freebsd.org/base/head/tools/build/mk/OptionalObsoleteFiles.inc?annotate=353358#l4520

This seems undesirable...

The "make buildworld" failure doesn't make the cause obvious - it just
reports "*** Error code 1" in bootstrap-tools.  Having trace the failure,
I now see ".ERROR_TARGET='_bootstrap-tools-link-kbdcontrol'" but that was
only obvious in hindsight.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Reproducable deadlock in NFS client

[Peter Jeremy]

On 2019-Oct-03 23:28:07 +, Rick Macklem  wrote:
>1 - kib@ just put a patch up on phabricator that reorganizes the handling
>  of vnode_pager_setsize().
>  D21883
>  (If you could test this patch, that might be the best approach.)

That fixes my problem.  I've added a note to D21883

>ps: Btw, capturing "procstat -kk" and "ps axHl" would give you/us more info.
> (The "H" on "ps" shows the iod threads.)
>  If you can drop into the debugger when it is hung as above, you could
>  capture the stuff listed here:
>https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html

Thanks for the pointer and sorry for leaving that out.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Reproduceable deadlock in NFS Client

[Peter Jeremy]

My diskless Rock64 has taken to deadlocking reproduceably whilst
building libprivatesqlite3.a as part of buildworld when running
r352792.  At the time of the deadlock, the relevant running process
is:
ar -crD libprivatesqlite3.a sqlite3.o

And those files are:
-rw-r--r--1 root  wheel  3178496  4 Oct 01:10 libprivatesqlite3.a
-rw-r--r--1 root  wheel  7975272  4 Oct 01:10 sqlite3.o

The "ar" reports it's in bo_wwait and, after about 30 minutes, I get:
deadlres_td_sleep_q: possible deadlock detected for 0xfd00012c9560, blocked 
for 1800613 ticks

cpuid = 2
time = 1570117920
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
 pc = 0x0054b83c  lr = 0x000e2b08
 sp = 0x4030a790  fp = 0x4030a9a0

db_trace_self_wrapper() at vpanic+0x18c
 pc = 0x000e2b08  lr = 0x0027fb54
 sp = 0x4030a9b0  fp = 0x4030aa50

vpanic() at panic+0x44
 pc = 0x0027fb54  lr = 0x0027f904
 sp = 0x4030aa60  fp = 0x4030aae0

panic() at deadlkres+0x33c
 pc = 0x0027f904  lr = 0x0021c19c
 sp = 0x4030aaf0  fp = 0x4030ab50

deadlkres() at fork_exit+0x7c
 pc = 0x0021c19c  lr = 0x002404f4
 sp = 0x4030ab60  fp = 0x4030ab90

fork_exit() at fork_trampoline+0x10
 pc = 0x002404f4  lr = 0x0056743c
 sp = 0x4030aba0  fp = 0x0000


-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: panic: sleeping thread on r352386

[Peter Jeremy]

On 2019-Sep-17 15:24:30 +0300, Konstantin Belousov  wrote:
>Try this.
>
>diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
>index 63ea4736707..a23b4ba4efa 100644

Sorry for the delay but I'm not seeing problems with this version of
your patch (now r352457) either.  Thank you for your efforts.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: panic: sleeping thread on r352386

[Peter Jeremy]

On 2019-Sep-17 11:06:58 +0300, Konstantin Belousov  wrote:
>Try the following change, which more accurately tries to avoid
>vnode_pager_setsize().  The real cause requires much more extensive
>changes.
>
>diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
>index 63ea4736707..16dc7745c77 100644
>--- a/sys/fs/nfsclient/nfs_clport.c
>+++ b/sys/fs/nfsclient/nfs_clport.c
...

With that patch, I'm back to "Sleeping thread (...) owns a non-sleepable
lock" panics.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: "Sleeping with non-sleepable lock" in NFS on recent -current

[Peter Jeremy]

On 2019-Sep-16 11:19:02 +0300, Konstantin Belousov  wrote:
>diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
>index 471e029a8b5..63ea4736707 100644
...

Thanks, that patch seems much more stable.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: "Sleeping with non-sleepable lock" in NFS on recent -current

[Peter Jeremy]

On 2019-Sep-16 09:32:52 +0300, Konstantin Belousov  wrote:
>On Mon, Sep 16, 2019 at 04:12:05PM +1000, Peter Jeremy wrote:
>> I'm consistently seeing panics in the NFS code on recent -current on aarm64.
>> The panics are one of the following two:
>> Sleeping on "vmopar" with the following non-sleepable locks held:
>> exclusive sleep mutex NEWNFSnode lock (NEWNFSnode lock) r = 0 
>> (0xfd0078b346f0) locked @ /usr/src/sys/fs/nfsclient/nfs_clport.c:432
>> 
>> Sleeping thread (tid 100077, pid 35) owns a non-sleepable lock
>> 
>> Both panics have nearly identical backtraces (see below).  I'm running
>> diskless on a Rock64 with both filesystem and swap over NFS.  The panics
>> can be fairly reliably triggered by any of:
>> * "make -j4 buildworld"
>> * linking the kernel (as part of buildkernel)
>> * "make installworld"
>> 
>> Has anyone else seen this?
...

>Weird since this should have been fixed long time ago.  Anyway, please
>try the following, it should fix the rest of cases.
>
>diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c
...
>@@ -540,7 +541,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr 
>*nap, void *nvaper,
>   } else {
>   np->n_size = vap->va_size;
>   np->n_flag |= NSIZECHANGED;
>-  vnode_pager_setsize(vp, np->n_size);
>+  setnsize = 1;

Should this else block include a "nsize = np->n_size;"?  Without it,
nsize will remain set to 0, which looks wrong.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

"Sleeping with non-sleepable lock" in NFS on recent -current

[Peter Jeremy]

I'm consistently seeing panics in the NFS code on recent -current on aarm64.
The panics are one of the following two:
Sleeping on "vmopar" with the following non-sleepable locks held:
exclusive sleep mutex NEWNFSnode lock (NEWNFSnode lock) r = 0 
(0xfd0078b346f0) locked @ /usr/src/sys/fs/nfsclient/nfs_clport.c:432

Sleeping thread (tid 100077, pid 35) owns a non-sleepable lock

Both panics have nearly identical backtraces (see below).  I'm running
diskless on a Rock64 with both filesystem and swap over NFS.  The panics
can be fairly reliably triggered by any of:
* "make -j4 buildworld"
* linking the kernel (as part of buildkernel)
* "make installworld"

Has anyone else seen this?

The first panic (sleeping on vmopar) has a backtrace:
sched_switch() at mi_switch+0x19c
 pc = 0x002ab368  lr = 0x0028a9f4
 sp = 0x61192660  fp = 0x61192680

mi_switch() at sleepq_switch+0x100
 pc = 0x0028a9f4  lr = 0x002d56dc
 sp = 0x61192690  fp = 0x611926d0

sleepq_switch() at sleepq_wait+0x48
 pc = 0x002d56dc  lr = 0x002d5594
 sp = 0x611926e0  fp = 0x61192700

sleepq_wait() at _sleep+0x2c4  [***]
 pc = 0x002d5594  lr = 0x00289eec
 sp = 0x61192710  fp = 0x611927b0

_sleep() at vm_object_page_remove+0x178  [***]
 pc = 0x00289eec  lr = 0x0052211c
 sp = 0x611927c0  fp = 0x61192820

vm_object_page_remove() at vnode_pager_setsize+0xc0
 pc = 0x0052211c  lr = 0x00539a70
 sp = 0x61192830  fp = 0x61192870

vnode_pager_setsize() at nfscl_loadattrcache+0x2e8
 pc = 0x00539a70  lr = 0x001ed4b4
 sp = 0x61192880  fp = 0x611928e0

nfscl_loadattrcache() at ncl_writerpc+0x104
 pc = 0x001ed4b4  lr = 0x001e2158
 sp = 0x611928f0  fp = 0x61192a40

ncl_writerpc() at ncl_doio+0x36c
 pc = 0x001e2158  lr = 0x001f0370
 sp = 0x61192a50  fp = 0x61192ae0

ncl_doio() at nfssvc_iod+0x228
 pc = 0x001f0370  lr = 0x001f1d88
 sp = 0x61192af0  fp = 0x61192b50

nfssvc_iod() at fork_exit+0x7c
 pc = 0x001f1d88  lr = 0x0023ff5c
 sp = 0x61192b60  fp = 0x61192b90

fork_exit() at fork_trampoline+0x10
 pc = 0x0023ff5c  lr = 0x00562c34
 sp = 0x61192ba0  fp = 0x


For the second panic, the [***] change to:
sleepq_wait() at vm_page_sleep_if_busy+0x80
vm_page_sleep_if_busy() at vm_object_page_remove+0xfc


-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: "panic: Duplicate alloc" in dwmmc_attach on Rock64

[Peter Jeremy]

On 2019-Jun-21 20:59:39 +1000, Peter Jeremy  wrote:
>Since r349169, my Rock64 has consistently panic'd whilst attaching
>rockchip_dwmmc1.  A kernel built at r349135 works OK.  The relevant
>output looks like:
>rockchip_dwmmc0: (RockChip)> mem 0xff50-0xff503fff irq 40 on ofwbus0
>rockchip_dwmmc0: Hardware version ID is 270a
>mmc0:  on rockchip_dwmmc0
>rockchip_dwmmc1: (RockChip)> mem 0xff52-0xff523fff irq 42 on ofwbus0
>rockchip_dwmmc1: Hardware version ID is 270a
>panic: Duplicate alloc of 0xfd89cf50 from zone 0xfd817540(16) 
>slab 0xfd89cf90(0)

I did some more digging and narrowed this down to r349151 (which has nothing
that would be an obvious cause).  And the problem went away somewhere
between r349269 and r349288.  Since there's nothing obvious there either, I
presume this is something more subtle like a race condition that has been
provoked by the code changes.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

"panic: Duplicate alloc" in dwmmc_attach on Rock64

[Peter Jeremy]

Since r349169, my Rock64 has consistently panic'd whilst attaching
rockchip_dwmmc1.  A kernel built at r349135 works OK.  The relevant
output looks like:
rockchip_dwmmc0:  mem 0xff50-0xff503fff irq 40 on ofwbus0
rockchip_dwmmc0: Hardware version ID is 270a
mmc0:  on rockchip_dwmmc0
rockchip_dwmmc1:  mem 0xff52-0xff523fff irq 42 on ofwbus0
rockchip_dwmmc1: Hardware version ID is 270a
panic: Duplicate alloc of 0xfd89cf50 from zone 0xfd817540(16) 
slab 0xfd89cf90(0)

cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
 pc = 0x00535d54  lr = 0x000df10c
 sp = 0x000104d0  fp = 0x000106e0

db_trace_self_wrapper() at vpanic+0x18c
 pc = 0x000df10c  lr = 0x00278218
 sp = 0x000106f0  fp = 0x00010790

vpanic() at panic+0x44
 pc = 0x00278218  lr = 0x00277fc8
 sp = 0x000107a0  fp = 0x00010820

panic() at uma_dbg_alloc+0x144
 pc = 0x00277fc8  lr = 0x004fa4b0
 sp = 0x00010830  fp = 0x00010850

uma_dbg_alloc() at uma_zalloc_arg+0x9b0
 pc = 0x004fa4b0  lr = 0x004f9960
 sp = 0x00010860  fp = 0x000108e0

uma_zalloc_arg() at malloc+0x9c
 pc = 0x004f9960  lr = 0x00252a8c
 sp = 0x000108f0  fp = 0x00010920

malloc() at bounce_bus_dmamem_alloc+0x4c
 pc = 0x00252a8c  lr = 0x00533b64
 sp = 0x00010930  fp = 0x00010960

bounce_bus_dmamem_alloc() at dwmmc_attach+0x5fc
 pc = 0x00533b64  lr = 0x00556f14
 sp = 0x00010970  fp = 0x000109e0

dwmmc_attach() at device_attach+0x3f4
 pc = 0x00556f14  lr = 0x002abd8c
 sp = 0x000109f0  fp = 0x00010a40

device_attach() at bus_generic_new_pass+0x12c
 pc = 0x002abd8c  lr = 0x002adb40
 sp = 0x00010a50  fp = 0x00010a80
...

I've looked through all the intervening commits and don't see any
smoking gun.  Does anyone have any suggestions?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: error: yacc.h: No such file or directory

[Peter Jeremy]

On 2019-Jun-18 07:01:31 -0700, Enji Cooper  wrote:
>
>> On Jun 18, 2019, at 06:59, Enji Cooper  wrote:
>> PS This is one of the reasons why I wasn’t quick to discount Peter Jeremy’s 
>> reported build issue.
>
>Correction: I meant Julian Stacey.

I'm not sure how I feel about being confused with jhs.

Actually, I had also seen this problem in both mkesdb_static and
mkcsmapper_static but hadn't reported it because I was investigating
something else and wasn't certain that it wasn't self-inflicted.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: FreeBSD 12 kernel broken

[Peter Jeremy]

On 2019-Mar-22 19:08:18 +0300, Rozhuk Ivan  wrote:
>ld: error: undefined symbol: xz_dec_init
>>>> referenced by g_uzip_lzma.c:106 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:106)
>>>>   g_uzip_lzma.o:(g_uzip_lzma_ctor)
>
>ld: error: undefined symbol: xz_dec_run
>>>> referenced by g_uzip_lzma.c:81 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:81)
>>>>   g_uzip_lzma.o:(g_uzip_lzma_decompress)
>
>ld: error: undefined symbol: xz_dec_end
>>>> referenced by g_uzip_lzma.c:60 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:60)
>>>>   g_uzip_lzma.o:(g_uzip_lzma_free)
>--- kernel.full ---
>*** [kernel.full] Error code 1

Are you talking about FreeBSD 12 or FreeBSD 13?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Optimization bug with floating-point?

[Peter Jeremy]

On 2019-Mar-13 23:30:07 -0700, Steve Kargl  
wrote:
>AFAICT, all libm float routines need to be modified to conditional
>include ieeefp.h and call fpsetprec(FP_PD).  This will work around
>issues is FP and libm.  FreeBSD needs to issue an erratum about 
>the numerical issues with clang.

I vaguely recall looking into the x87 initialisation a long time ago
and STR that the startup code (either crtX or in the kernel) does
a fninit() to set the precision.  I don't recall exactly where.

IMO, calling fpsetprec() in every libm float function is overkill. It
should be enough to fpsetprec() before main() and add a note in the
man pages that libm is built to use the default FPU configuration and
changing the configuration (precision or rounding) may result in larger
errors.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: r340343 triggers kernel assertion if file is opened with O_BENEATH flag set through symlink

[Peter Holm]

On Wed, Nov 28, 2018 at 01:46:17AM +0200, Konstantin Belousov wrote:
> On Wed, Nov 28, 2018 at 12:54:21AM +0300, Vladimir Kondratyev wrote:
> > Following test case triggers assertion after r340343:
> > 
> > 
> > #include 
> > 
> > int
> > main(int argc, char **argv)
> > {
> >     openat(open("/etc", O_RDONLY), "termcap", O_RDONLY | O_BENEATH);
> > }
> > 
> > It results in:
> > 
> > panic: Assertion (ndp->ni_lcf & NI_LCF_LATCH) != 0 failed at
> > /usr/src/sys/kern/vfs_lookup.c:182
> > 
> 
> The following should fix it. Problem was that the topping directory was
> only latched when the initial path was absolute. Since your example
> switched from the relative argument to the absolute symlink, the BENEATH
> tracker rightfully complained that there were no recorded top.
> 
> I also added some asserts I used during the debugging.
> 
> diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
> index 78893c4f2bd..7a80775d91d 100644
> --- a/sys/kern/vfs_lookup.c

With this patch I got a:

$ ./beneath.sh
open("a/b") succeeded
stat("a/b
panic: Assertion (ndp->ni_lcf & NI_LCF_LATCH) != 0 failed at 
../../../kern/vfs_lookup.c:269
cpuid = 4
time = 1543397647
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00c71881a0
vpanic() at vpanic+0x1a3/frame 0xfe00c7188200
panic() at panic+0x43/frame 0xfe00c7188260
namei_handle_root() at namei_handle_root+0xf7/frame 0xfe00c71882b0
namei() at namei+0x617/frame 0xfe00c71884f0
vn_open_cred() at vn_open_cred+0x526/frame 0xfe00c7188640
vn_open() at vn_open+0x4c/frame 0xfe00c7188680
kern_openat() at kern_openat+0x2e9/frame 0xfe00c71888e0
sys_openat() at sys_openat+0x69/frame 0xfe00c7188910
syscallenter() at syscallenter+0x4e3/frame 0xfe00c71889f0
amd64_syscall() at amd64_syscall+0x4d/frame 0xfe00c7188ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00c7188ab0
--- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x8003a215a, rsp = 
0x7fffe4f8, rbp = 0x7fffe5e0 ---

https://people.freebsd.org/~pho/stress/log/kostik1127.txt

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

panic: mtx_lock() by idle thread ... mutex igb0 @ ../../../net/iflib.c:2084

[Peter Holm]

Feeding entropy: .
lo0: link state changed to UP
panic: mtx_lock() by idle thread 0xf800036ac000 on sleep mutex igb0 @ 
../../../net/iflib.c:2084
cpuid = 4
time = 1540286062
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe007876e610
vpanic() at vpanic+0x1a3/frame 0xfe007876e670
panic() at panic+0x43/frame 0xfe007876e6d0
__mtx_lock_flags() at __mtx_lock_flags+0x15a/frame 0xfe007876e720
iflib_admin_intr_deferred() at iflib_admin_intr_deferred+0x2a/frame 
0xfe007876e750
em_msix_link() at em_msix_link+0x84/frame 0xfe007876e780
iflib_fast_intr_ctx() at iflib_fast_intr_ctx+0x21/frame 0xfe007876e7a0
intr_event_handle() at intr_event_handle+0xbb/frame 0xfe007876e7f0
intr_execute_handlers() at intr_execute_handlers+0x58/frame 0xfe007876e820
lapic_handle_intr() at lapic_handle_intr+0x5f/frame 0xfe007876e840
Xapic_isr1() at Xapic_isr1+0xd9/frame 0xfe007876e840
--- interrupt, rip = 0x811e6be6, rsp = 0xfe007876e910, rbp = 
0xfe007876e910 ---
acpi_cpu_c1() at acpi_cpu_c1+0x6/frame 0xfe007876e910
acpi_cpu_idle() at acpi_cpu_idle+0x23d/frame 0xfe007876e960
cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfe007876e980
cpu_idle() at cpu_idle+0xa7/frame 0xfe007876e9a0
sched_idletd() at sched_idletd+0x517/frame 0xfe007876ea70
fork_exit() at fork_exit+0x84/frame 0xfe007876eab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe007876eab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 11 tid 17 ]
Stopped at  kdb_enter+0x3b: movq$0,kdb_why
db> x/s version
version:FreeBSD 13.0-CURRENT r339638 PHO-GENERIC\012
db> 
-- 
Peter
___
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: Page fault in midi/sequencer.c

[Peter Holm]

On Mon, Oct 22, 2018 at 11:00:41AM +0200, Hans Petter Selasky wrote:
> On 10/20/18 6:56 PM, Peter Holm wrote:
> > I can trigger this on 13.0-CURRENT r339445 with a non-root test program:
> > 
> 
> Hi,
> 
> The following commits should fix the issues you experience:
> 
> https://svnweb.freebsd.org/changeset/base/339581
> https://svnweb.freebsd.org/changeset/base/339582
> https://svnweb.freebsd.org/changeset/base/339583
> 
> --HPS

Thank you for fixing this!

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

Page fault in midi/sequencer.c

[Peter Holm]

I can trigger this on 13.0-CURRENT r339445 with a non-root test program:

Calling uiomove() with the following non-sleepable locks held:
exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ 
dev/sound/midi/sequencer.c:952
stack backtrace:
#0 0x80bfe263 at witness_debugger+0x73
#1 0x80bff1b8 at witness_warn+0x448
#2 0x80bf6a91 at uiomove_faultflag+0x71
#3 0x809439e6 at mseq_write+0x4c6
#4 0x80a4f725 at devfs_write_f+0x185
#5 0x80c02a87 at dofilewrite+0x97
#6 0x80c0287f at kern_pwritev+0x5f
#7 0x80c0277d at sys_pwrite+0x8d
#8 0x81070af7 at amd64_syscall+0x2a7
#9 0x8104a4ad at fast_syscall_common+0x101
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ 
dev/sound/midi/sequencer.c:952
stack backtrace:
#0 0x80bfe263 at witness_debugger+0x73
#1 0x80bff1b8 at witness_warn+0x448
#2 0x810700d3 at trap_pfault+0x53
#3 0x8106f70a at trap+0x2ba
#4 0x81049bc5 at calltrap+0x8
#5 0x80bf6b42 at uiomove_faultflag+0x122
#6 0x809439e6 at mseq_write+0x4c6
#7 0x80a4f725 at devfs_write_f+0x185
#8 0x80c02a87 at dofilewrite+0x97
#9 0x80c0287f at kern_pwritev+0x5f
#10 0x80c0277d at sys_pwrite+0x8d
#11 0x81070af7 at amd64_syscall+0x2a7
#12 0x8104a4ad at fast_syscall_common+0x101


Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 04
fault virtual address = 0x20ea6b
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x8106d32d
stack pointer = 0x28:0xfe00a844a660
frame pointer = 0x28:0xfe00a844a660
code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 2356 (xxx)
[ thread pid 2356 tid 100278 ]
Stopped at  copyin_nosmap_erms+0xdd:movl(%rsi),%edx
db>

-- 
Peter
___
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: Page fault in udp_usrreq.c:823

[Peter Holm]

On Thu, Jun 21, 2018 at 06:42:41PM -0700, Matthew Macy wrote:
> I made changes this morning / early afternoon.
> -M
> 

With r335501 I no longer see any of the issues I reported. Thank
you for the fix!

- Peter

> On Thu, Jun 21, 2018 at 6:41 PM, Cy Schubert  
> wrote:
> > Like as of now?
> >
> > The last panic occurred this morning after a build last night.
> >
> >
> > --
> > Cheers,
> > Cy Schubert 
> > FreeBSD UNIX: Web:  http://www.FreeBSD.org
> >
> > The need of the many outweighs the greed of the few.
> >
> >
> > In message  > il.com>
> > , Matthew Macy writes:
> >> Try updating. It should be fixed.
> >>
> >> On Thu, Jun 21, 2018 at 6:14 PM, Cy Schubert  
> >> wrot
> >> e:
> >> > In message <20180620090957.ga...@x2.osted.lan>, Peter Holm writes:
> >> >> 20180620 10:32:47 all (1/1): udp.sh
> >> >> Kernel page fault with the following non-sleepable locks held:
> >> >> shared rw udpinp (udpinp) r = 0 (0xf80bbc808d78) locked @ 
> >> >> netinet/in_p
> >> cb.
> >> >> c:2398
> >> >> stack backtrace:
> >> >> #0 0x80c00733 at witness_debugger+0x73
> >> >> #1 0x80c01b11 at witness_warn+0x461
> >> >> #2 0x81075763 at trap_pfault+0x53
> >> >> #3 0x81074d7a at trap+0x2ba
> >> >> #4 0x8105076c at calltrap+0x8
> >> >> #5 0x80dd21b0 at udp_ctlinput+0x50
> >> >> #6 0x80d3081d at icmp_input+0x96d
> >> >> #7 0x80d316d7 at ip_input+0x3f7
> >> >> #8 0x80cc0a92 at netisr_dispatch_src+0xa2
> >> >> #9 0x80ca3ebe at ether_demux+0x16e
> >> >> #10 0x80ca5377 at ether_nh_input+0x427
> >> >> #11 0x80cc0a92 at netisr_dispatch_src+0xa2
> >> >> #12 0x80ca437f at ether_input+0x8f
> >> >> #13 0x80cbc500 at iflib_rxeof+0xc90
> >> >> #14 0x80cb6b6f at _task_fn_rx+0x7f
> >> >> #15 0x80bdd209 at gtaskqueue_run_locked+0x139
> >> >> #16 0x80bdcf88 at gtaskqueue_thread_loop+0x88
> >> >> #17 0x80b54514 at fork_exit+0x84
> >> >>
> >> >>
> >> >> Fatal trap 12: page fault while in kernel mode
> >> >> cpuid = 10; apic id = 0a
> >> >> fault virtual address = 0x8
> >> >> fault code  = supervisor read data, page not present
> >> >> instruction pointer = 0x20:0x80dd2423
> >> >> stack pointer = 0x0:0xfe4a5500
> >> >> frame pointer = 0x0:0xfe4a55a0
> >> >> code segment  = base 0x0, limit 0xf, type 0x1b
> >> >>= DPL 0, pres 1, long 1, def32 0, gran 1
> >> >> processor eflags = interrupt enabled, resume, IOPL = 0
> >> >> current process  = 0 (if_io_tqg_10)
> >> >> [ thread pid 0 tid 100069 ]
> >> >> Stopped at  udp_common_ctlinput+0x263:  cmpq$0,0x8(%rax)
> >> >> db>
> >> >>
> >> >> Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt
> >> >>
> >> >> --
> >> >> Peter
> >> >> ___
> >> >> 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"
> >> >>
> >> >
> >> > This is surprisingly similar to my panic. Twice since June 19.
> >> >
> >> > slippy# kgdb /boot/kernel/kernel vmcore.3
> >> > GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
> >> > Copyright (C) 2018 Free Software Foundation, Inc.
> >> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.
> >> > html>
> >> > This is free software: you are free to change and redistribute it.
> >> > There is NO WARRANTY, to the extent permitted by law.  Type "show
> >> > copying"
> >> > and "show warranty" for details.
> >> > This GDB was configured as "x86_64-portbld-freebsd12.0".
> >> > Type "show configuration" for configuration details.
> >> > For bug reporting instructions, please see:
> >> > <http

Page fault in udp_usrreq.c:823

[Peter Holm]

20180620 10:32:47 all (1/1): udp.sh
Kernel page fault with the following non-sleepable locks held:
shared rw udpinp (udpinp) r = 0 (0xf80bbc808d78) locked @ 
netinet/in_pcb.c:2398
stack backtrace:
#0 0x80c00733 at witness_debugger+0x73
#1 0x80c01b11 at witness_warn+0x461
#2 0x81075763 at trap_pfault+0x53
#3 0x81074d7a at trap+0x2ba
#4 0x8105076c at calltrap+0x8
#5 0x80dd21b0 at udp_ctlinput+0x50
#6 0x80d3081d at icmp_input+0x96d
#7 0x80d316d7 at ip_input+0x3f7
#8 0x80cc0a92 at netisr_dispatch_src+0xa2
#9 0x80ca3ebe at ether_demux+0x16e
#10 0x80ca5377 at ether_nh_input+0x427
#11 0x80cc0a92 at netisr_dispatch_src+0xa2
#12 0x80ca437f at ether_input+0x8f
#13 0x80cbc500 at iflib_rxeof+0xc90
#14 0x80cb6b6f at _task_fn_rx+0x7f
#15 0x80bdd209 at gtaskqueue_run_locked+0x139
#16 0x80bdcf88 at gtaskqueue_thread_loop+0x88
#17 0x80b54514 at fork_exit+0x84


Fatal trap 12: page fault while in kernel mode
cpuid = 10; apic id = 0a
fault virtual address = 0x8
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80dd2423
stack pointer = 0x0:0xfe4a5500
frame pointer = 0x0:0xfe4a55a0
code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 0 (if_io_tqg_10)
[ thread pid 0 tid 100069 ]
Stopped at  udp_common_ctlinput+0x263:  cmpq$0,0x8(%rax)
db>

Details @ https://people.freebsd.org/~pho/stress/log/udp_usrreq.txt

-- 
Peter
___
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: how to browse svnweb source?

[Peter Jeremy]

On 2018-May-28 18:06:07 -0700, Jeffrey Bouquet  
wrote:
>> > Suddenly the site www.secnetix.de/olli/FreeBSD/svnews which showed 
>> > sequential
>> > source as for example xx1966 on april 3  xx2040 on april 4 this year, 
>> > is not loading
>> > in the browser.

That site is not associated with the FreeBSD Project so you would need to
discuss the absence of information on that site with whoever runs it.

>I tried that url every which way, sorting the headings, etc, and onscreen
>would be at best, a description of the new source but not specifically which
>files were changed and their complete path. Nothing like the url mentioned 
>above at
>.de in the latter's overview. 

Without knowing what that site displayed, it's very difficult to know where
(or if) svnweb provides the information.  Given a known revision, you can
check (eg) https://svnweb.freebsd.org/base?view=revision&revision=333926

If you want a sequential list of commits, you might be better off with (eg)
https://lists.freebsd.org/pipermail/svn-src-all/

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: IGNORE_OSVERSION=yes -- can't install pkg

[Peter Wemm]

On Saturday, May 5, 2018 9:47:36 AM PDT Ian Lepore wrote:
> On Sat, 2018-05-05 at 08:26 -0700, Chris H wrote:
> > On Fri, 04 May 2018 22:57:52 -0700  said
> > 
> > > I just setup a jail from a 12-CURRENT I built awhile ago. It has no
> > > ports
> > > tree. So I'm attempting
> > > to install svnlite. issuing pkg search svnlite returns
> > > The package management tool is not yet installed on your system.
> > > Do you want to fetch and install it now? [y/N]: y
> > > Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/
> > > latest,
> > > please wait...
> > > Verifying signature with trusted certificate
> > > pkg.freebsd.org.2013102301...
> > > done
> > > [12current.localhost] Installing pkg-1.10.5...
> > > Newer FreeBSD version for package pkg:
> > > To ignore this error set IGNORE_OSVERSION=yes
> > > - package: 1200062
> > > - running kernel: 1200054
> > > Allow missmatch now?[Y/n]:
> > > 
> > > Umm, what? Should I ignore this error? If so, why is there an error
> > > at all?
> > > I answered no. Guess I won't be able to use pkg(8) on this jail(8).
> > > 
> > > :-(
> > > 
> > > --Chris
> > 
> > OK the only reference[1] I can find regarding this, indicates that
> > answering "Y"
> > to Allow missmatch now? resulted in an ABI mismatch that caused
> > pkg(8) to be
> > unusable.
> > This is on an older version of 12, so I don't have anything that
> > might have
> > appeared in UPDATING. I really need this jail to resolve accumulating
> > pr(1)'s
> > on ports(7) I maintain.
> > 
> > Thank you.
> 
> The difference between 1200062 and 1200054 isn't going to affect
> anything except modules which are intimate with kernel internals, such
> as video drivers or virtualbox type stuff.
> 
> IMO, this new version checking done by pkg(8) is just bad Bad BAD. The
> only control you get is a knob that tells you to ignore any version
> mismatch. There appears to be no option to get the historical worked-
> really-well behavior of ignoring mismatches of the minor version for
> people who track -current.

There was an unfortunate Incident caused OSVERSION handling at a certain 
Verizon company that happens to run FreeBSD.

We hit an OSVERSION implementation bug on the freebsd.org cluster today.  
We've disabled it across the entire site as it is unusable for us in this 
form.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5


___
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: g_handleattr: md0 bio_length 24 len 31 -> EFAULT

[Peter Holm]

On Sun, Apr 08, 2018 at 02:36:08AM -0700, Michael Dexter wrote:
> On 3/24/18 2:35 AM, O. Hartmann wrote:
> > Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images, 
> > created via
> > the classical manual way, no makefs), my recent CURRENT system dumps the
> > console full of these error messages:
> > 
> > g_handleattr: md0 bio_length 24 len 31 -> EFAULT
> > 
> > I do not know what they are supposed to mean and I'd like to ask whether 
> > someone could
> > shed some light on this.
> 
> I am seeing this on the the latest snapshot when attempting to run 
> option_survey.sh which creates an md-attached disk image.
> 
> Anyone else seeing this?
> 
> Michael

Yes, I have:

[pho@freefall ~/public_html/stress/log]$ grep -a g_handleattr: `ls -rt`
numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
numa025.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
kostik1104.txt:g_handleattr: md10 bio_length 24 len 31 -> EFAULT
[pho@freefall ~/public_html/stress/log]$ 

-- 
Peter
___
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: UEFI Changes

[Peter Lei]

On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
> Hi.
> For problem 2, try reverting r331241 alone.
> This worked for my ThinkPad T420.


I also hit this after updating to latest and was about to post when I
saw this thread -

I build efirt into the kernel and it's now doing a panic on boot. It
appears to be due to this recent addition in dev/efidev/efirt.c by r331241:

> if (!efi_is_in_map(map, efihdr->memory_size / efihdr->descriptor_size,
> efihdr->descriptor_size, (vm_offset_t)efi_runtime->rt_gettime)) {

The faulting address is for "efi_runtime->rt_gettime" (and is still a
phys addr here).

--peter


> 
> On Thu, 22 Mar 2018 08:22:13 -0500
> Kyle Evans  wrote:
> 
>> On Thu, Mar 22, 2018 at 5:13 AM, Jakob Alvermark  wrote:
>>> Hi!
>>>
>>>
>>> Just updated to r331345.
>>>
>>> Two problems:
>>>
>>> 1. boot/efi.4th is added to /usr/src/ObsoleteFiles.inc but still included in
>>> loader.rc. Loader fails to load it and subsequently fails to load modules.
>>> Reinstalling efi.4th problem 2 appears.
>>>
>>>
>>> 2. Fixing problem 1 and adding efirt_load="YES" to /boot/loader.conf makes
>>> the kernel panic instantly. Photo of panic:
>>> https://photos.app.goo.gl/ph3yQukOAUdQpsvK2
>>>
>>>
>>> Jakob
>>>
>>>
>>
>> Hi,
>>
>> The efi.4th removal has been reverted in r331353. A couple of inquiries for 
>> you:
>>
>> 1.) Before loading efirt, can you show me what `sysctl
>> machdep.efi_map` looks like?
>>
>> 2.) After `kldload efirt` and getting a panic, can you show me what
>> `show registers` looks like?
>>
>> 3.) Have you used efirt successfully before?
>>
>> Thanks,
>>
>> Kyle Evans
>> ___
>> 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"
>>
> 
> 



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

[Peter Jeremy]

On 2018-Mar-11 10:43:58 -1000, Jeff Roberson  wrote:
>Also, if you could try going back to r328953 or r326346 and let me know if 
>the problem exists in either.  That would be very helpful.  If anyone is 
>willing to debug this with me contact me directly and I will send some 
>test patches or debugging info after you have done the above steps.

I ran into this on 11-stable and tracked it to r326619 (MFC of r325851).
I initially got around the problem by reverting that commit but either
it or something very similar is still present in 11-stable r331053.

I've seen it in my main server (32GB RAM) but haven't managed to reproduce
it in smaller VBox guests - one difficulty I faced was artificially filling
ARC.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

amd64: panic on -CURRENT @r330539 for certain UEFI hosts

[Peter Lei]

Some recent UEFI implementations have begun to leave the CPU with page
write protection enabled in CR0.

With r330539 which enables kernel page protections, interesting things
happen during boot (aka panic) when protection is already enabled,
including a write protection fault from an explicit .text fixup write
from xsave->xsaveopt by fpuinit().

I see this so far booting -CURRENT under virtual environments:

- QEMU with recent OVMF EDK2 builds: this is certainly due to UEFI
enabling paging and page protections.

- VMWare Fusion 10.1.x on Mac: no specific insight on what's going
inside the implementation, but CR0_WP is definitely left enabled before
the kernel is booted.

I have patched my kernel build to explicitly clear CR0_WP (e.g. in
initializecpu) prior to creating the page tables to get around this, but
someone might have a cleaner/better solution...

--peter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: INTRNG

[peter . blok]

While on the subject INTRNG - does anybody know the status of handling GPIO 
interrupts with queue/kevent?

There were some patches before INTRNG, but they require some work.

Peter

> On 23 Feb 2018, at 07:25, Jon Brawn  wrote:
> 
> Wotcha Gang!
> 
> In my travels through the arm64 GENERIC config file I came across the option 
> ‘INTRNG’, and wondered what it was:
> 
> INTeRrupt Next Generation?
> INTeger Random Number Generator?
> IN TRaiNinG?
> INTerrupt Random Number Generator?
> INdependent TRaiNinG?
> 
> So, please put me out of my misery, what does INTRNG stand for, and what are 
> its implications when selected vs not selected?
> 
> Cheers!
> 
> Jon.

___
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: ACPI panic on boot with new Lua loader and other minor issues

[Peter Lei]

On 2/19/18 5:48 PM, Kyle Evans wrote:
> 
> 
> On Feb 19, 2018 5:44 PM, "Peter Lei"  <mailto:peter@ieee.org>> wrote:
> 
> 
> 
> On 2/19/18 2:21 PM, Kyle Evans wrote:
> > Hello!
> >
> > On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor
> mailto:lis...@club.fr>> wrote:
> >> I have done a full build of r329555 to test the new Lua boot loader.
> >>
> >> Both the new and the old kernels panic after being loaded with:
> >>
> >> panic: running without device atpic requires a local APIC
> >>
> >> For reasons unknown, ACPI is off, as shown by David Wolfskill in
> a previous
> >> message:
> >>
> 
> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
> 
> <https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html>
> >>
> >> OK show hint.acpi.0.disabled
> >> 1
> >>
> >> Setting ACPI to On resolves the issue.
> >
> > As David noted, this should actually Just Work (TM) now. Can you break
> > into a loader prompt with just the forth loader and tell me what "show
> > hint.acpi.0.rsdp" looks like?
> 
> 
> This doesn't appear to "just work out-of-the-box" yet when EFI booting
> amd64, as I still get the 'no local APIC' panic (I just tried @r329609).
> 
> Under EFI and lua loader, the following is set when breaking to prompt:
>     hint.acpi.0.disabled=1
> Under forth loader, this is not present/set.
> 
> In neither case is hint.acpi.0.rsdp present/set as that appears to get
> set during the exec of the loaded kernel...
> 
> I've worked around the issue by adding hint.acpi.0.disabled="0" to
> loader.conf (or patching the amd64 efi loader code to explicitly clear
> that hint).
> 
> 
> [Apologies for broken quoting, currently mobile]
> 
> What happens if you patch this line out?
> https://svnweb.freebsd.org/base/head/stand/lua/core.lua?view=markup#l233


Ah, right - yep, commenting out that line works.


> I'll have to go back and figure out what I was thinking here again. It
> made sense when I wrote it, maybe explicitly disabling ACPI if it's not
> immediately detected was the wrong move. =)




smime.p7s
Description: S/MIME Cryptographic Signature

Re: ACPI panic on boot with new Lua loader and other minor issues

[Peter Lei]

On 2/19/18 2:21 PM, Kyle Evans wrote:
> Hello!
> 
> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  
> wrote:
>> I have done a full build of r329555 to test the new Lua boot loader.
>>
>> Both the new and the old kernels panic after being loaded with:
>>
>> panic: running without device atpic requires a local APIC
>>
>> For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
>> message:
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html
>>
>> OK show hint.acpi.0.disabled
>> 1
>>
>> Setting ACPI to On resolves the issue.
> 
> As David noted, this should actually Just Work (TM) now. Can you break
> into a loader prompt with just the forth loader and tell me what "show
> hint.acpi.0.rsdp" looks like?


This doesn't appear to "just work out-of-the-box" yet when EFI booting
amd64, as I still get the 'no local APIC' panic (I just tried @r329609).

Under EFI and lua loader, the following is set when breaking to prompt:
hint.acpi.0.disabled=1
Under forth loader, this is not present/set.

In neither case is hint.acpi.0.rsdp present/set as that appears to get
set during the exec of the loaded kernel...

I've worked around the issue by adding hint.acpi.0.disabled="0" to
loader.conf (or patching the amd64 efi loader code to explicitly clear
that hint).



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Build error: 'emmintrin.h' file not found

[Peter Jeremy]

On 2018-Jan-24 17:34:33 +0100, Florian Limberger  
wrote:
>since a few days I can't build 12-CURRENT anymore, due to the 'emmintrin.h'
>header missing.

I ran into a similar problem about a month ago.  First of all, does
your host system have emmintrin.h?  E.g. what is the output of "find
/usr/lib/clang -name emmintrin.h" ?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Unable to build 12-current/amd64

[Peter Jeremy]

On 2017-Dec-23 13:42:40 +0100, Dimitry Andric  wrote:
>On 23 Dec 2017, at 10:56, Peter Jeremy  wrote:
>> 
>> Since r326496, buildworld on my 12-current/amd64 system has consistently
>> died as follows.
>...
>> /usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1166:10: fatal 
>> error: 'emmintrin.h' file not found
>> #include 
>> ^
>> 1 error generated.
>> *** Error code 1
>> 
>> Stop.
>> make[4]: stopped in /usr/src/lib/clang/libclang
>> 
>> I'm building on a 12.0-CURRENT VirtualBox guest at r326430.  I've checked
>> that my /usr/src is clean and deleted /usr/obj to no effect.  I have dug
>> into SourceManager.cpp and the #include is protected by a #if __SSE2__,
>> which is relying on clang internal checks to define (and my CPU supports
>> SSE2).  Does anyone have any ideas to explain what is going on?
>
>First of all, does your host system have emmintrin.h?  E.g. what is the
>output of "find /usr/lib/clang -name emmintrin.h" ?

Aha.  Somehow my entire /usr/lib/clang/5.0.0 tree was missing.  I'm not sure
if that was an installworld glitch or something I accidently did.  In any
case, restoring it has fixed the problem.  Thanks for the pointer.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Unable to build 12-current/amd64

[Peter Jeremy]

Since r326496, buildworld on my 12-current/amd64 system has consistently
died as follows.  I have no problems building on i386 or building
12-current/amd64 on 11-stable.

...
>>> stage 3: cross tools
--
cd /usr/src; INSTALL="sh /usr/src/tools/install.sh"  
TOOLS_PREFIX=/usr/obj/usr/src/amd64.amd64/tmp  
PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
  WORLDTMP=/usr/obj/usr/src/amd64.amd64/tmp  MAKEFLAGS="-m 
/usr/src/tools/build/mk  -m /usr/src/share/mk" make  -f Makefile.inc1  DESTDIR= 
 OBJTOP='/usr/obj/usr/src/amd64.amd64/tmp/obj-tools'  OBJROOT='${OBJTOP}/'  
MAKEOBJDIRPREFIX=  BOOTSTRAPPING=1200054  BWPHASE=cross-tools  SSP_CFLAGS=  
MK_HTML=no NO_LINT=yes MK_MAN=no  -DNO_PIC MK_PROFILE=no -DNO_SHARED  
-DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no  MK_CLANG_EXTRAS=no MK_CLANG_FULL=no  
MK_LLDB=no MK_TESTS=no  MK_INCLUDES=yes  TARGET=amd64 TARGET_ARCH=amd64  
MK_GDB=no MK_LLD_IS_LD=no MK_TESTS=no cross-tools
...
===> lib/clang/libclang (all)
...
c++  -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/contrib/llvm/tools/clang/lib/Driver 
-I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections 
-fdata-sections -gline-tables-only -MD -MF.depend.Basic_SourceLocation.o 
-MTBasic/SourceLocation.o -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -std=c++11 
-fno-exceptions -fno-rtti -gline-tables-only -stdlib=libc++ 
-Wno-c++11-extensions  -c 
/usr/src/contrib/llvm/tools/clang/lib/Basic/SourceLocation.cpp -o 
Basic/SourceLocation.o
c++  -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang 
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm 
-I/usr/src/contrib/llvm/tools/clang/lib/Driver 
-I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\" 
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections 
-fdata-sections -gline-tables-only -MD -MF.depend.Basic_SourceManager.o 
-MTBasic/SourceManager.o -Qunused-arguments 
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -std=c++11 
-fno-exceptions -fno-rtti -gline-tables-only -stdlib=libc++ 
-Wno-c++11-extensions  -c 
/usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp -o 
Basic/SourceManager.o
/usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1166:10: fatal 
error: 'emmintrin.h' file not found
#include 
 ^
1 error generated.
*** Error code 1

Stop.
make[4]: stopped in /usr/src/lib/clang/libclang

I'm building on a 12.0-CURRENT VirtualBox guest at r326430.  I've checked
that my /usr/src is clean and deleted /usr/obj to no effect.  I have dug
into SourceManager.cpp and the #include is protected by a #if __SSE2__,
which is relying on clang internal checks to define (and my CPU supports
SSE2).  Does anyone have any ideas to explain what is going on?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: get_swap_pager(x) failed

[Peter Jeremy]

On 2017-Dec-13 11:23:46 +, Gary Palmer  wrote:
>An open question would be why ARC is not reducing if the system is
>under memory pressure.  It's meant to, but there have been various
>bugs in that implementation.

The OP doesn't say what version of -current he is running but I would
point the finger at r325851.  I have discovered that, in 11-stable,
r326619 (which is the MFC of r325851) stops ARC responding to memory
backpressure.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Install FreeBSD from source into VM image

[Peter Grehan]

  Error return from kevent monitor: Not permitted in capability mode

...

This sounds like an issue with the bhyve capsicum work.  I've cc'd Allan
and Peter who might be able to help track that down.  It might be useful
if you can run bhyve under ktrace, e.g.:

   sudo ktrace -i -t p sh /usr/share/examples/bhyve/vmrun.sh -d .raw vm-

And then post the output of 'sudo kdump'


 I think this is the error now returned when a file doesn't exist or 
can't be accessed - the code probably needs to be reworked to test for 
existence before entering capability mode to make the error more meaningful.


later,

Peter.

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

Caveat emptor: Beware of ZFS on HEAD

[Peter Wemm]

We mostly run HEAD in the freebsd.org cluster.  Sometime in the last few weeks 
an ugly zfs problem has surfaced. If a redundant volume is degraded, zfs 
panics on boot.  If a drive fails while running, or is manually put offline, 
zfs 
panics the same way.

I do not have a smoking gun, but I am suspicious of the June 28th commits 
(starting at r320156) and their follow-ups. eg: r320452.

https://bugs.freebsd.org/220691

I believe single disk systems will *not* be affected by this - the panic only 
happens when a raidz (and presumably mirror) degrades.  Your laptop etc should 
be fine.

I apologize for being vague - I do not know more. Folks running HEAD should 
take appropritate precautions (eg: keeping a known-good kernel.old and modules 
around).  This is always advisable when running HEAD anyway, particularly so 
now.  For us, a kernel.old from June 18th worked fine.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

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

Re: dump trying to access incorrect block numbers?

[Peter Jeremy]

On 2017-Jul-07 10:44:36 -0400, Michael Butler  
wrote:
>Recent builds doing a backup (dump) cause nonsensical errors in syslog:

I can't directly offer any ideas but some more background might help:
When did you first notice this (what SVN revision)?
Do you know what the last good SVN revision was?
Is this a new or old filesystem?
Is the filesystem mounted/active or not when you dump it?
What are the relevant parameters for the filesystem on ada0s3a?
Are you running softupdates, journalling etc?
Which dump(8) phase is reporting the errors?
What are the exact dump and fsck commands you ran?

>I now have two UFS-based systems showing the same symptoms - what's up 
>with this?

Was there anything you did on either filesystem that might have triggered it?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Time to increase MAXPHYS?

[peter . blok]

One area that breaks after changing MAXPHYS from 128K to 1MB is the iscsi 
target. I don’t have details, because that server is semi-production and I 
reverted it back ASAP
> On 5 Jun 2017, at 19:49, Edward Tomasz Napierała  wrote:
> 
> On 0604T0952, Hans Petter Selasky wrote:
>> On 06/04/17 09:39, Tomoaki AOKI wrote:
>>> Hi
>>> 
>>> One possibility would be to make it MD build-time OTIONS,
>>> defaulting 1M on regular systems and 128k on smaller systems.
>>> 
>>> Of course I guess making it a tunable (or sysctl) would be best,
>>> though.
>>> 
>> 
>> Hi,
>> 
>> A tunable sysctl would be fine, but beware that commonly used firmware 
>> out there produced in the millions might hang in a non-recoverable way 
>> if you exceed their "internal limits". Conditionally lowering this 
>> definition is fine, but increasing it needs to be carefully verified.
>> 
>> For example many USB devices are only tested with OS'es like Windows and 
>> MacOS and if these have any kind of limitation on the SCSI transfer 
>> sizes, it is very likely many devices out there do not support any 
>> larger transfer sizes either.
> 
> FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed
> that both issue 1MB requests.  I wouldn't be surprised if they avoided
> doing that for older devices, depending on eg the SCSI version reported
> by device.
> 
> ___
> freebsd-current@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> 
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
> "

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

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Peter Jeremy]

On 2017-May-24 20:21:54 +0300, Konstantin Belousov  wrote:
>No SIGSEGV etc, so I think that the effects seen are due to build system.
>rm -rf obj/* is the safest trick, I believe.

But the behaviour does indicate that meta mode is not doing the right thing
under all circumstances.  It's blatently breaking in this scenario but could
be causing more subtle (and unnoticed) breakage in other cases.  This makes
me feel that this is worth investigating further.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Peter Jeremy]

On 2017-May-24 18:01:42 -0700, "Simon J. Gerraty"  wrote:
>Peter Jeremy  wrote:
>> as follows.  My suspicion is that meta mode isn't seeing enough of the
>> differences between the bootstrap and main build steps and so causing make
>> to incorrectly skip steps.
>
>I see a number of places in src/Makefile* where BUILD_TOOLS_META=.NOMETA
>is added to env of things like CROSSENV, CD2MAKE, LIBCOMPATWMAKEENV
>
>Use of .NOMETA could be leading to problems - but I'm not familiar with
>where BUILD_TOOLS_META is used.

I've not looked at the guts of how meta mode works or is inhibited either.

In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was
using "make buildworld" - which failed.  The upgrade worked cleanly
when I manually deleted all the .meta files.  If I get a round tuit,
I'll try to revert to before the update and have a closer look at what
broke with the "normal" build, if no-one else beats me to it.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[Peter Jeremy]

On 2017-May-24 08:47:41 -0700, Ngie Cooper  wrote:
>There was another report on the list about a stale MAKEOBJDIRPREFIX 
> causing someone grief. I think it's safe to say that meta mode and -DNO_CLEAN 
> might not work across this transition--in particular meta mode tends to err 
> on the side of not to rebuilding things.

I ran into a very similar problem trying to update from r318744 to r318781.
In my case, even two "make clean" wasn't enough and "make buildworld" died
as follows.  My suspicion is that meta mode isn't seeing enough of the
differences between the bootstrap and main build steps and so causing make
to incorrectly skip steps.

--
>>> stage 2.3: build tools
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj  INSTALL="sh /usr/src/tools/install.sh"  
TOOLS_PREFIX=/usr/obj/usr/src/tmp  
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
  WORLDTMP=/usr/obj/usr/src/tmp  MAKEFLAGS="-m /usr/src/tools/build/mk  -m 
/usr/src/share/mk" /usr/obj/usr/src/make.amd64/bmake  -f Makefile.inc1  
TARGET=amd64 TARGET_ARCH=amd64  DESTDIR=  BOOTSTRAPPING=1200031  SSP_CFLAGS=  
-DNO_LINT  -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no  MK_CLANG_EXTRAS=no 
MK_CLANG_FULL=no  MK_LLDB=no MK_TESTS=no build-tools
...
===> usr.bin/mkesdb_static (obj,build-tools)
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_bcs.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_factory.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_db_hash.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/citrus_lookup_factory.o
Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.c
Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.o
/usr/src/usr.bin/mkesdb/lex.l:44:10: fatal error: 'yacc.h' file not found
#include "yacc.h"
 ^~~~
 1 error generated.
 *** Error code 1

Stop.
bmake[3]: stopped in /usr/src/usr.bin/mkesdb_static
.ERROR_TARGET='lex.o'
.ERROR_META_FILE='/usr/obj/usr/src/usr.bin/mkesdb_static/lex.o.meta'
.MAKE.LEVEL='3'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/usr.bin/mkesdb_static'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/usr.bin/mkesdb_static'
.TARGETS='build-tools'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20161212'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
/usr/src/usr.bin/mkesdb_static/Makefile /usr/src/usr.bin/mkesdb/Makefile.inc 
/usr/src/tools/build/mk/bsd.prog.mk /usr/src/share/mk/bsd.prog.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/usr.bin/mkesdb_static/../Makefile.inc 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk 
/usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk /usr/src/tools/build/mk/Makefile.boot'
.PATH='. /usr/src/usr.bin/mkesdb_static /usr/src/lib/libc/iconv 
/usr/src/usr.bin/mkesdb'
*** Error code 1

I've done a "find /usr/obj -name \*.meta -print0 | xargs -0 rm" and am still
waiting for that to complete, though it has passed the above failure point.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

panic with jail bug_id 213673 was: VNET branch destiny

[peter . blok]

The problem happens when stopping a jail. It doesn’t seem to be related to vnet 
at all.

When stopping a jail, pfr_cleanup calls uma_zdestroy(V_pfr_kentry_z). The dtor 
calls zone_release, which calls slab_free_item. The issue seems to be that the 
keg found in zone_release does not belong to the zone that is to be destroyed, 
but belongs to the zone that is created for the same purpose at the host. The 
zone belongs to the jail (verified). The added if (marked with XXX) fixes the 
problem.

I don’t understand how a keg ends up in a different zone.

zone_release(uma_zone_t zone, void **bucket, int cnt)
{
void *item;
uma_slab_t slab;
uma_keg_t keg;
uint8_t *mem;
int clearfull;
int i;

clearfull = 0;
keg = zone_first_keg(zone);
KEG_LOCK(keg);
for (i = 0; i < cnt; i++) {
item = bucket[i];
if (!(zone->uz_flags & UMA_ZONE_VTOSLAB)) {
mem = (uint8_t *)((uintptr_t)item & (~UMA_SLAB_MASK));
if (zone->uz_flags & UMA_ZONE_HASH) {
slab = hash_sfind(&keg->uk_hash, mem);
} else {
mem += keg->uk_pgoff;
slab = (uma_slab_t)mem;
}
} else {
slab = vtoslab((vm_offset_t)item);
if (slab->us_keg != keg) {
KEG_UNLOCK(keg);
keg = slab->us_keg;
KEG_LOCK(keg);
}
}
if (keg == slab->us_keg)// XXX 
seems to fix the problem
slab_free_item(keg, slab, item);

> On 11 Apr 2017, at 13:43, peter.b...@bsd4all.org wrote:
> 
> Hi Kristof,
> 
> I’m prety sure it is the same as 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673 
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673>. It is unrelated 
> to epair or ng_eiface (my case).
> 
> I’ll dig some more.
> 
> Peter
> 
> 
>> On 11 Apr 2017, at 08:47, Kristof Provost  wrote:
>> 
>> On 10 Apr 2017, at 12:10, peter.b...@bsd4all.org wrote:
>>> There have been issues with pf if I recall correctly. I currently have 
>>> issues with stable, pf and vnet. There is an issue with pf table entries 
>>> when an interface is moved to a different vnet.
>>> 
>>> Does anyone no if there is a specific fix for this that hasn’t been ported 
>>> to stable? I haven’t had the time to test this on current.
>>> 
>> I’m currently aware of at least some issues with pf and vnet, even in 
>> CURRENT.
>> Not that one though, so can you make sure there’s a bug report with as much 
>> detail as possible?
>> Please also cc me (k...@freebsd.org) on the report.
>> 
>> Thanks,
>> Kristof
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: VNET branch destiny

[peter . blok]

Hi Kristof,

I’m prety sure it is the same as 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213673>. It is unrelated to 
epair or ng_eiface (my case).

I’ll dig some more.

Peter


> On 11 Apr 2017, at 08:47, Kristof Provost  wrote:
> 
> On 10 Apr 2017, at 12:10, peter.b...@bsd4all.org wrote:
>> There have been issues with pf if I recall correctly. I currently have 
>> issues with stable, pf and vnet. There is an issue with pf table entries 
>> when an interface is moved to a different vnet.
>> 
>> Does anyone no if there is a specific fix for this that hasn’t been ported 
>> to stable? I haven’t had the time to test this on current.
>> 
> I’m currently aware of at least some issues with pf and vnet, even in CURRENT.
> Not that one though, so can you make sure there’s a bug report with as much 
> detail as possible?
> Please also cc me (k...@freebsd.org) on the report.
> 
> Thanks,
> Kristof

___
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: VNET branch destiny

[peter . blok]

No problem. Although pf is not used the vnet_destroy seems to be the issue. 
Some parts are not virtualized and the vnet_destroy->vnet_pf_uninit teardown 
happens on the host vnet so to speak.


> On 10 Apr 2017, at 22:11, Ernie Luzar  wrote:
> 
> peter.b...@bsd4all.org wrote:
>> Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, 
>> not in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It 
>> is my intention to use the netgrpah bridge with bhyve as well.
> 
> 
> I also tested using Devin Teske’s jng to create a netgraph bridge on
> RELEASE 10.0 and it worked. But when I tried the same configuration on
> RELEASE 11.0 it no longer worked.
> 
> Sorry for the noise. I missed this sentence. "I’m only using pf on the
> host, not in the jail.". Thats what happens when I answer email after a long 
> day at work.
> 
> 

___
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: VNET branch destiny

[peter . blok]

Well, in my case it panic’ed on 11-stable. I’m only using pf on the host, not 
in the jail. I’m using Devin Teske’s jng to create a netgraph bridge. It is my 
intention to use the netgrpah bridge with bhyve as well.

The panic (one-time) happened in pfioctl when I refreshed the rules. I suspect 
the problem is related to the following message when I stop the jail.

kernel: Freed UMA keg (pf table entries) was not empty (32 items).  Lost -57 
pages of memory.

Current does not display the UMA message. I’m still narrowing down what happens 
with the pf table entries. My suspicion is that the netgraph bridge which 
creates a ng_ether device which is handed over to the jail vnet, is causing 
this.


The panic happened on LIST_REMOVE in keg_fetch_slab

static uma_slab_t
keg_fetch_slab(uma_keg_t keg, uma_zone_t zone, int flags)
{
uma_slab_t slab;
int reserve;

mtx_assert(&keg->uk_lock, MA_OWNED);
slab = NULL;
reserve = 0;
if ((flags & M_USE_RESERVE) == 0)
reserve = keg->uk_reserve;

for (;;) {
/*
 * Find a slab with some space.  Prefer slabs that are partially
 * used over those that are totally full.  This helps to reduce
 * fragmentation.
 */
if (keg->uk_free > reserve) {
if (!LIST_EMPTY(&keg->uk_part_slab)) {
slab = LIST_FIRST(&keg->uk_part_slab);
} else {
slab = LIST_FIRST(&keg->uk_free_slab);
LIST_REMOVE(slab, us_link);
LIST_INSERT_HEAD(&keg->uk_part_slab, slab,
us_link);
}
MPASS(slab->us_keg == keg);
return (slab);
}

KDB: stack backtrace:
#0 0x805df0e7 at kdb_backtrace+0x67
#1 0x8059d176 at vpanic+0x186
#2 0x8059cfe3 at panic+0x43
#3 0x808ebaa2 at trap_fatal+0x322
#4 0x808ebaf9 at trap_pfault+0x49
#5 0x808eb336 at trap+0x286
#6 0x808d1441 at calltrap+0x8
#7 0x808a871e at zone_fetch_slab+0x6e
#8 0x808a87cd at zone_import+0x4d
#9 0x808a4fc9 at uma_zalloc_arg+0x529
#10 0x80803214 at pfr_ina_define+0x584
#11 0x807f0734 at pfioctl+0x3364
#12 0x80469288 at devfs_ioctl_f+0x128
#13 0x805fa925 at kern_ioctl+0x255
#14 0x805fa65f at sys_ioctl+0x16f
#15 0x808ec604 at amd64_syscall+0x6c4
#16 0x808d172b at Xfast_syscall+0xfb

The panic is so far not reproducible.


> On 10 Apr 2017, at 15:50, Ernie Luzar  wrote:
> 
> peter.b...@bsd4all.org wrote:
>> There have been issues with pf if I recall correctly. I currently have 
>> issues with stable, pf and vnet. There is an issue with pf table entries 
>> when an interface is moved to a different vnet.
>> Does anyone no if there is a specific fix for this that hasn’t been ported 
>> to stable? I haven’t had the time to test this on current.
>> Peter
> 
> PF was fixed in 11.0 to not panic when run on a host that has vimage compiled 
> into the kernel. On 11.0 you can configure pf to run in a vnet jail but it 
> really does not enforce any firewall rules because pf needs access to the 
> kernel which jail(8) is blocking by design. As far as I know this is a show 
> shopper that can not be fixed without a pf rewrite changing the way it works 
> internally.
> 
> This PR gives all the details
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: VNET branch destiny

[peter . blok]

There have been issues with pf if I recall correctly. I currently have issues 
with stable, pf and vnet. There is an issue with pf table entries when an 
interface is moved to a different vnet.

Does anyone no if there is a specific fix for this that hasn’t been ported to 
stable? I haven’t had the time to test this on current.

Peter
> On 10 Apr 2017, at 08:50, Pavel Timofeev  wrote:
> 
> 31 марта 2017 г. 17:40 пользователь "Bjoern A. Zeeb" <
> bzeeb-li...@lists.zabbadoz.net> написал:
> 
> On 31 Mar 2017, at 13:57, Pavel Timofeev wrote:
> 
> Hello, dear freebsd-current@!
>> 
>> There was FreeBSD Foundation report back in 2016Q2 where it told us
>> about VNET (VIMAGE) update project sponsored by foundation.
>> What is the current situation? Is it committed into base? If not
>> what's the plan?
>> 
> 
> Changes are in 12 and 11.   12 has seen more slight fixes due to other
> changes that other committers are tracking and I hope they merge to 11.
> 
> /bz
> 
> 
> Sorry, do you know if there is any plan to include VNET into GENERIC?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: effect of strip(1) on du(1)

[Peter Jeremy]

On 2017-Mar-02 22:19:10 -0800, "Rodney W. Grimes" 
 wrote:
>> du(1) is using fts_read(3), which is based on the stat(2) information.
>> The OpenGroup defines st_blocksize as "Number of blocks allocated for
>> this object."  In the case of ZFS, a write(2) may return before any
>> blocks are actually allocated.  And thanks to compression, gang
...
>My gut tells me that this is gona cause problems, is it ONLY
>the st_blocksize data that is incorrect then not such a big
>problem, or are we returning other meta data that is wrong?

Note that it's st_blocks, not st_blocksize.

I did an experiment, writing a (roughly) 113MB file (some data I had
lying around), close()ing it and then stat()ing it in a loop.  This is
FreeBSD 10.3 with ZFS and lz4 compression.  Over the 26ms following the
close(), st_blocks gradually rose from 24169 to 51231.  It then stayed
stable until 4.968s after the close, when st_blocks again started
increasing until it stabilized after a total of 5.031s at 87483.  Based
on this, st_blocks reflects the actual number of blocks physically
written to disk.  None of the other fields in the struct stat vary.

The 5s delay is presumably the TXG delay (since this system is basically
unloaded).  I'm not sure why it writes roughly ½ the data immediately
and the rest as part of the next TXG write.

>My expectactions of executing a stat(2) call on a file would
>be that the data returned is valid and stable.  I think almost
>any program would expect that.

I think a case could be made that st_blocks is a valid representation
of "the number of blocks allocated for this object" - with the number
increasing as the data is physically written to disk.  As for it being
stable, consider a (hypothetical) filesystem that can transparently
migrate data between different storage media, with different compression
algorithms etc (ZFS will be able to do this once the mythical block
rewrite code is written).

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: effect of strip(1) on du(1)

[Peter Jeremy]

On 2017-Mar-02 22:29:46 +0300, Subbsd  wrote:
>During some interval after strip call, du will show 512B for any file.
>If execute du(1) after strip(1) without delay, this behavior is reproduced 
>100%:

What filesystem are you using?  strip(1) rewrites the target file and du(1)
reports the number of blocks reported by stat(2).  It seems that you are
hitting a situation where the file metadata isn't immediately updated.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: removing SVR4 binary compatibilty layer

[Peter Jeremy]

On 2017-Feb-14 10:32:32 -0800, Gleb Smirnoff  wrote:
>  After some discussion on svn mailing list [1], there is intention
>to remove SVR4 binary compatibilty layer from FreeBSD head, meaning
>that FreeBSD 12.0-RELEASE, available in couple of years would
>be shipped without it. There is no intention of merge of the removal.
>The stable@ mailing list added for wider audience.

Can I suggest that we put some warnings into the SVr4 image activation
code and MFC that to at least 11 to try and smoke out anyone who might
actually be using it.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: [RFC/RFT] projects/ipsec

[peter . blok]

Andrey,

Is this going to MFC'ed to stable-11 in the future? I have tested with current 
and found no issues, but I would like to add it to a semi-production 
environment running stable-11

Peter


> On 6 Feb 2017, at 10:07, Andrey V. Elsukov  wrote:
> 
> On 11.12.2016 02:07, Andrey V. Elsukov wrote:
>> I am pleased to announce that projects/ipsec, that I started several
>> months ago is ready for testing and review.
>> The main goals were:
>>  * rework locking to make IPsec code more friendly for concurrent
>>processing;
>>  * make lookup in SADB/SPDB faster;
>>  * revise PFKEY implementation, remove stale code, make it closer
>>to RFC;
>>  * implement IPsec VTI (virtual tunneling interface);
>>  * make IPsec code loadable as kernel module.
> 
> JFYI, the project was merged into head/ in r313330.
> 
> -- 
> WBR, Andrey V. Elsukov
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

Re: crash in iflib_fast_intr

[peter . blok]

This is with an igb interface.

Peter
> On 18 Jan 2017, at 15:31, Sean Bruno  wrote:
> 
> 
> 
> On 01/18/17 03:37, peter.b...@bsd4all.org <mailto:peter.b...@bsd4all.org> 
> wrote:
>> Hi,
>> 
>> A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since 
>> GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is 
>> reproducible.
>> 
>> KDB: stack backtrace:
>> #0 0x805cec97 at kdb_backtrace+0x67
>> #1 0x80584816 at vpanic+0x186
>> #2 0x80584683 at panic+0x43
>> #3 0x8090f222 at trap_fatal+0x322
>> #4 0x8090f3ec at trap_pfault+0x1bc
>> #5 0x8090eaa0 at trap+0x280
>> #6 0x808f35e1 at calltrap+0x8
>> #7 0x806a202d at iflib_fast_intr+0x3d
>> #8 0x8054963b at intr_event_handle+0x9b
>> #9 0x80965f38 at intr_execute_handlers+0x48
>> #10 0x8096b1cf at lapic_handle_intr+0x3f
>> #11 0x808f3cc7 at Xapic_isr1+0xb7
>> #12 0x805b994a at sched_idletd+0x37a
>> #13 0x805460f5 at fork_exit+0x85
>> #14 0x808f3b1e at fork_trampoline+0xe
>> 
>> Peter
> 
> Thanks for the report.  We're looking at this.
> 
> This is with an igb(4) interface or em(4)?
> 
> sean

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

crash in iflib_fast_intr

[peter . blok]

Hi,

A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since 
GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is 
reproducible.

KDB: stack backtrace:
#0 0x805cec97 at kdb_backtrace+0x67
#1 0x80584816 at vpanic+0x186
#2 0x80584683 at panic+0x43
#3 0x8090f222 at trap_fatal+0x322
#4 0x8090f3ec at trap_pfault+0x1bc
#5 0x8090eaa0 at trap+0x280
#6 0x808f35e1 at calltrap+0x8
#7 0x806a202d at iflib_fast_intr+0x3d
#8 0x8054963b at intr_event_handle+0x9b
#9 0x80965f38 at intr_execute_handlers+0x48
#10 0x8096b1cf at lapic_handle_intr+0x3f
#11 0x808f3cc7 at Xapic_isr1+0xb7
#12 0x805b994a at sched_idletd+0x37a
#13 0x805460f5 at fork_exit+0x85
#14 0x808f3b1e at fork_trampoline+0xe

Peter
___
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: CURRENT: "service netif restart" looses default route

[Oliver Peter]

On Wed, Oct 05, 2016 at 06:47:48PM +0200, O. Hartmann wrote:
> 
> Today, I checked on two servers of ours running both a recent CURRENT (i.e. 
> FreeBSD
> 12.0-CURRENT #43 r306701: Wed Oct  5 06:40:40 CEST 2016) via "service netif 
> restart" the
> upcoming network and realised that the default route is lost then!
> 
> I'm able to config the route via "service routing restart" - or manually as I 
> did
> otherwise. But I recall that I did a simple "service netif restart" in 
> 11-CURRENT
> recently and that worked.
> 
> Has there been a change? What is now the official way to restart network?

Since the past couple of years on every new FreeBSD I put this in motd for my
linux colleagues and coworkers:

Network:
To apply changes you have made to the network:
# /etc/rc.d/netif restart && /etc/rc.d/routing restart

Perhaps we could introduce a wrapper to be used with:
# service network restart

oliver@local ~ % cat /etc/rc.d/network
#!/bin/sh

# PROVIDE: network
# REQUIRE: netif routing
# KEYWORD: nojailvnet

. /etc/rc.subr
. /etc/network.subr

name="network"
start_cmd="network_start"
stop_cmd="network_stop"

network_start()
{
/etc/rc.d/netif start
/etc/rc.d/routing start
}

network_stop()
{
/etc/rc.d/netif stop
/etc/rc.d/routing stop
}

load_rc_config $name
run_rc_command $*


-- 
Oliver PETER   oli...@gfuzz.de   0x456D688F
___
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: commits between r305191 - r305211 broke zfs list

[Peter Wemm]

On Saturday, September 03, 2016 10:31:04 PM Steven Hartland wrote:
> Out of sync kernel / world?
> 
> Do you have a crash dump?

This has caused a considerable amount of excitement on the freebsd.org 
cluster.  Having kernel+world out of sync causes zfs(8) to abort rather 
ungracefully.

> On 03/09/2016 21:50, Subbsd wrote:
> > Hi.
> > 
> > Can anybody test of output for:
> > 
> > zfs list
> > 
> > command on FreeBSD current after r305211 ? On my hosts his leads to
> > zfs segfault.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

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

Re: Somethign missing in my environment?

[Peter Jeremy]

On 2016-Aug-16 23:14:45 +0200, Willem Jan Withagen  wrote:
>And I'm running:
>make -j8 buildworld
>So getting a good target that give the error is hard.
>
>So I continued with make -DNOCLEAN -DNO_CLEAN buildworld.

There's nothing immediately obvious.  I suggest trying without the
"-DNOCLEAN -DNO_CLEAN" - they are shortcuts that aren't guaranteed to
work under all circumstances.  And if that still fails, skip the '-j8'
because it's possible there are still race conditions in buildworld
(though that is very unlikely).

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: Somethign missing in my environment?

[Peter Jeremy]

On 2016-Aug-16 20:31:57 +0200, Willem Jan Withagen  wrote:
>I'm trying to compile world, but I keep getting:
>
>/usr/obj/usr/srcs/head/src/tmp/usr/lib/libgcc_s.so: undefined reference
>to `__gxx_personality_v0'
>cc: error: linker command failed with exit code 1 (use -v to see invocation)
>*** [h_raw.full] Error code 1
>
>Even after refetching the complete tree.

We need more context:
- What SVN revision of (presumably) -current is this?
- What architecture are you compiling on/for?
- What do you have in /etc/make.conf and /etc/src.conf
- What is your current environment?
- What is the output leading up to that error (what is being built?

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: FreeBSD 11.0-RC1 Now Available

[Peter Wemm]

On Saturday, August 13, 2016 08:47:52 PM Glen Barber wrote:
> On Sat, Aug 13, 2016 at 07:35:45PM +0200, Jan Beich wrote:
> > Glen Barber  writes:
> > > The first RC build of the 11.0-RELEASE release cycle is now available.
> > > 
> > > Installation images are available for:
> > > 
> > > o 11.0-RC1 amd64 GENERIC
> > > o 11.0-RC1 i386 GENERIC
> > > o 11.0-RC1 powerpc GENERIC
> > > o 11.0-RC1 powerpc64 GENERIC64
> > > o 11.0-RC1 sparc64 GENERIC
> > > o 11.0-RC1 armv6 BANANAPI
> > > o 11.0-RC1 armv6 BEAGLEBONE
> > > o 11.0-RC1 armv6 CUBIEBOARD
> > > o 11.0-RC1 armv6 CUBIEBOARD2
> > > o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD
> > > o 11.0-RC1 armv6 GUMSTIX
> > > o 11.0-RC1 armv6 RPI-B
> > > o 11.0-RC1 armv6 RPI2
> > > o 11.0-RC1 armv6 PANDABOARD
> > > o 11.0-RC1 armv6 WANDBOARD
> > > o 11.0-RC1 aarch64 GENERIC
> > 
> > What about granular sets? sparc64 is N/A while amd64 is missing
> > lib32.txz, src.txz, ports.txz, tests.txz. Regressed since 11.0-BETA4.
> > I've waited a day to see if the issue would disappear after mirrors
> > catch up but no joy, even via Tor.
> > 
> > [...]
> 
> Thanks for letting us know.  This isn't an re@ issue, it's an admins@
> issue, and we thought this was fixed.  Give me a bit to investigate.
> 
> Glen

If this isn't fixed now, please yell.

It seems we found a bug in the syncthing-inotify tool.  chmod events were 
being missed.  In theory this is worked around now.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

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

Re: Mosh regression between 10.x and 11-stable

[Peter Jeremy]

On 2016-Aug-11 10:06:35 -0700, Ngie Cooper  wrote:
>
>> On Aug 11, 2016, at 09:30, John Hood  wrote:
>> 
>> I still can't reproduce this on 3 different 11.0-BETA4 servers and a
>> variety of clients and networks.  Can you try and identify a more
>> portable repro or at least figure out why it fails on your system?
>> 
>> Please try applying this patch, too.  It's a shot in the dark, though.
>
>Dumb question: what ssh key type(s) (dsa, rsa, etc) are you using Peter :)?

I'm using ECDSA for both the host and user keys.

-- 
Peter Jeremy


signature.asc
Description: PGP signature