Re: Panic: Page Fault in Kernel: Yesterday's CURRENT

2021-12-16 Thread Larry Rosenman 

On 12/16/2021 9:03 pm, Larry Rosenman wrote:

On 12/10/2021 10:43 am, Larry Rosenman wrote:
14-2021_12_07-1217 -  -  1.87G 2021-12-07 
12:17
14-2021_12_09-1957 NR /  121G  2021-12-09 
19:57


If that's any help

On 12/10/2021 10:36 am, Alexander Motin wrote:

Hi Larry,

This looks like some use-after-free or otherwise corrupted callout
structure.  Unfortunately the backtrace does not tell what was the
callout.  When was the previous update to look what could change?

On 10.12.2021 11:24, Larry Rosenman wrote:

FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL  
amd64


VMCORE *IS* available.




Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x804e0db4
stack pointer   = 0x0:0xfe0434de4e10
frame pointer   = 0x0:0xfe0434de4e70
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 = 82990 (c++)
trap number = 12
panic: page fault
cpuid = 0
time = 163998
KDB: stack backtrace:
#0 0x8050fc95 at kdb_backtrace+0x65
#1 0x804c468f at vpanic+0x17f
#2 0x804c4503 at panic+0x43
#3 0x807a2195 at trap_fatal+0x385
#4 0x807a21ef at trap_pfault+0x4f
#5 0x80779c78 at calltrap+0x8
#6 0x8045ddb8 at handleevents+0x188
#7 0x8045ea3e at timercb+0x24e
#8 0x807ca9eb at lapic_handle_timer+0x9b
#9 0x8077b9b1 at Xtimerint+0xb1
Uptime: 2h28m57s
Dumping 12829 out of 131023
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

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

#1  doadump (textdump=)
    at /usr/src/sys/kern/kern_shutdown.c:399
#2  0x804c428c in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:487
#3  0x804c46fe in vpanic (fmt=0x807e1276 "%s",
    ap=) at /usr/src/sys/kern/kern_shutdown.c:920
#4  0x804c4503 in panic (fmt=)
    at /usr/src/sys/kern/kern_shutdown.c:844
#5  0x807a2195 in trap_fatal (frame=0xfe0434de4d50, 
eva=0)

    at /usr/src/sys/amd64/amd64/trap.c:946
#6  0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
    usermode=false, signo=, ucode=)
    at /usr/src/sys/amd64/amd64/trap.c:765
#7  
#8  0x804e0db4 in callout_process 
(now=now@entry=38385536922300)

    at /usr/src/sys/kern/kern_timeout.c:488
#9  0x8045ddb8 in handleevents 
(now=now@entry=38385536922300,

    fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
#10 0x8045ea3e in timercb (et=0x80d475e0 ,
    arg=) at /usr/src/sys/kern/kern_clocksource.c:357
#11 0x807ca9eb in lapic_handle_timer 
(frame=0xfe0434de4f40)

    at /usr/src/sys/x86/x86/local_apic.c:1364
#12 
#13 0x00080df42bb6 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7def2c90
(kgdb)




'

I got a new crash on a today's current:
❯ more core.txt.1
borg.lerctr.org dumped core - see /var/crash/vmcore.1

Thu Dec 16 17:01:37 CST 2021

FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #22
main-n251748-c610426c4de: Thu Dec 16 09:22:52 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
amd64

panic: page fault

GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruct

Re: Panic: Page Fault in Kernel: Yesterday's CURRENT

2021-12-16 Thread Larry Rosenman 

On 12/10/2021 10:43 am, Larry Rosenman wrote:

14-2021_12_07-1217 -  -  1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR /  121G  2021-12-09 19:57

If that's any help

On 12/10/2021 10:36 am, Alexander Motin wrote:

Hi Larry,

This looks like some use-after-free or otherwise corrupted callout
structure.  Unfortunately the backtrace does not tell what was the
callout.  When was the previous update to look what could change?

On 10.12.2021 11:24, Larry Rosenman wrote:

FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL  
amd64


VMCORE *IS* available.




Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x804e0db4
stack pointer   = 0x0:0xfe0434de4e10
frame pointer   = 0x0:0xfe0434de4e70
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 = 82990 (c++)
trap number = 12
panic: page fault
cpuid = 0
time = 163998
KDB: stack backtrace:
#0 0x8050fc95 at kdb_backtrace+0x65
#1 0x804c468f at vpanic+0x17f
#2 0x804c4503 at panic+0x43
#3 0x807a2195 at trap_fatal+0x385
#4 0x807a21ef at trap_pfault+0x4f
#5 0x80779c78 at calltrap+0x8
#6 0x8045ddb8 at handleevents+0x188
#7 0x8045ea3e at timercb+0x24e
#8 0x807ca9eb at lapic_handle_timer+0x9b
#9 0x8077b9b1 at Xtimerint+0xb1
Uptime: 2h28m57s
Dumping 12829 out of 131023
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=)
    at /usr/src/sys/kern/kern_shutdown.c:399
#2  0x804c428c in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:487
#3  0x804c46fe in vpanic (fmt=0x807e1276 "%s",
    ap=) at /usr/src/sys/kern/kern_shutdown.c:920
#4  0x804c4503 in panic (fmt=)
    at /usr/src/sys/kern/kern_shutdown.c:844
#5  0x807a2195 in trap_fatal (frame=0xfe0434de4d50, 
eva=0)

    at /usr/src/sys/amd64/amd64/trap.c:946
#6  0x807a21ef in trap_pfault (frame=0xfe0434de4d50,
    usermode=false, signo=, ucode=)
    at /usr/src/sys/amd64/amd64/trap.c:765
#7  
#8  0x804e0db4 in callout_process 
(now=now@entry=38385536922300)

    at /usr/src/sys/kern/kern_timeout.c:488
#9  0x8045ddb8 in handleevents (now=now@entry=38385536922300,
    fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:213
#10 0x8045ea3e in timercb (et=0x80d475e0 ,
    arg=) at /usr/src/sys/kern/kern_clocksource.c:357
#11 0x807ca9eb in lapic_handle_timer 
(frame=0xfe0434de4f40)

    at /usr/src/sys/x86/x86/local_apic.c:1364
#12 
#13 0x00080df42bb6 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7def2c90
(kgdb)




'

I got a new crash on a today's current:
❯ more core.txt.1
borg.lerctr.org dumped core - see /var/crash/vmcore.1

Thu Dec 16 17:01:37 CST 2021

FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #22 
main-n251748-c610426c4de: Thu Dec 16 09:22:52 CST 2021 
r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL  amd64


panic: page fault

GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 20
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x804e0a34
st

Vastly improved speeds with iwn(4)

2021-12-16 Thread Graham Perrin 
In recent months, what (if anything) changed to improve things for users 
of iwn(4)?


Intel Centrino Advanced-N 6205 [Taylor Peak] here. At home, previously I 
typically got less than 9 (download), now I get more than 70 Mbps.


(I see last month's 
 
and 
 
for iwlwifi/mvm, If I understand correctly 
 this 
new driver is not applicable to iwn(4) cards.)

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

2021-12-16 Thread Gleb Smirnoff 
On Thu, Dec 16, 2021 at 07:53:10AM -0800, Gleb Smirnoff wrote:
T> P.S. If you really wish to deprecate something, I can suggest you to
T> sacrifice sbni(4) :)

P.P.S.
The driver actually provides a historical example: a driver removed,
later appeared not only used by somebody but even having a
responding vendor:

commit ceee59fa5ac606fe28b18086dd07f526ef717f55
Author: John Baldwin 
Date:   Wed Sep 10 18:42:19 2008 +

Disable the inline assembly crc32 routine and use the C version instead.
The assembly version is reported to be broken on 5.x+.

PR: kern/100425
Submitted by:   Rashid N. Achilov  shelton www.granch.ru
MFC after:  1 week

commit 26e46883290bfef867a15fb276b4eb7ee598dce6
Author: John Baldwin 
Date:   Wed Sep 10 18:36:58 2008 +

Resurrect the sbni(4) driver.  Someone finally tested the MPSAFE patches and
the driver worked ok with them.

Tested by:  friends of yar

commit e9a31041c016f6e2042440c9f18627b7708fc334
Author: John Baldwin 
Date:   Fri Jul 4 21:06:57 2008 +

Remove the sbni(4) driver.  No one responded to calls to test it on
current@ and stable@.

-- 
Gleb Smirnoff

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

2021-12-16 Thread Gleb Smirnoff 
On Thu, Dec 16, 2021 at 09:30:41AM -0700, Warner Losh wrote:
W> > E> And we're doing that just because the drivers compiles ?
W> > G> We are doing that because the hardware is still produced ...
W> > E> ... a lot of obsolete hardware that we've removed are still produced ...
W> > G> I'd be interested to see at least one example ...
W> > E> This was an hypothetical situation.
W> >
W> > I don't know what to reply here. :(
W> 
W> The standards that Brooks, Ed and I have been using in retiring drivers has
W> been
W> "Still relevant to FreeBSD". Although whether or not something was still in
W> production
W> is an input into that, it's not the only factor in decisions made.
W> 
W> While that standard is a bit vague, I'm struggling understanding the case
W> for these
W> drivers still being relevant to FreeBSD in the absence of documented actual
W> use,
W> let alone a use case that we can do a cost-benefit analysis on.

Yes, so what I'm trying to say here is that right now cost of having the
drivers in the tree is virtually zero. Emmanuel says that benefit is zero.

I can't refute Emmanuel's statement, I can only speculate that benefit
could be non-zero, as apparently devices are still produced and E1 lines
still exist.

So I'm fine with removal if anybody demonstrates me a non-zero cost of
leaving the drivers in.

-- 
Gleb Smirnoff

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

2021-12-16 Thread Warner Losh 
On Thu, Dec 16, 2021 at 8:54 AM Gleb Smirnoff  wrote:

>   Emmanuel,
>
> look at this communication:
>
> E> And we're doing that just because the drivers compiles ?
> G> We are doing that because the hardware is still produced ...
> E> ... a lot of obsolete hardware that we've removed are still produced ...
> G> I'd be interested to see at least one example ...
> E> This was an hypothetical situation.
>
> I don't know what to reply here. :(
>

The standards that Brooks, Ed and I have been using in retiring drivers has
been
"Still relevant to FreeBSD". Although whether or not something was still in
production
is an input into that, it's not the only factor in decisions made.

While that standard is a bit vague, I'm struggling understanding the case
for these
drivers still being relevant to FreeBSD in the absence of documented actual
use,
let alone a use case that we can do a cost-benefit analysis on.

Warner

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

2021-12-16 Thread Gleb Smirnoff 
  Emmanuel,

look at this communication:

E> And we're doing that just because the drivers compiles ?
G> We are doing that because the hardware is still produced ...
E> ... a lot of obsolete hardware that we've removed are still produced ...
G> I'd be interested to see at least one example ...
E> This was an hypothetical situation.

I don't know what to reply here. :(

Now let's get constructive.

E> > I'm not. Your position is simply: "the utility existence bugs me cause
E> > it is useless for me", and "I don't care if it exist on i386, cause I
E> > don't use i386". Kind of selfish position.
E> 
E>  What's selfish about removing some binary that 100% of our amd64 users
E> never needed since the creation of FreeBSD/amd64 ?

I agree that would be cool not to have stuff in the default install that
is very unlikely to be used. On the other hand it would be cool that a
device that is still in production doesn't require ancient FreeBSD to
work. The latter requires to keep them in the build. The former requires
not to have them installed. So what we need here is analog of LINT for
the world build. A build that would cover all possible tools that aren't
included into install. For example cxgbetool(8). Navdeep humbly put it
in tools/tools initially. Later I asked him to move it to usr.sbin to
make sure its build isn't broken. So it is installed, albeit 99% installations
don't have Chelsio card. I think we can find more examples.

So, proposed policy for such kind of devices is to have them in sys/conf/files
and sys/conf/options and in LINT and do not have them in sys/modules/Makefile.
Similarly for tools, to have them in the tree, enabled under 'lintworld' but
not enabled under 'world'. Have WITH_SCONFIG and WITH_OTHERTOOL, but don't
have it enabled by default.

E> > I agree with that. We need such policy. It is being promised, and while
E> > it is not there yet, there is this document:
E> > 
E> > https://wiki.freebsd.org/DeprecationPlan
E> > 
E> > As you see, a developer who wants to remove something needs to propose
E> > that, communicate that and plan. And as you can see there, Cronyx devices
E> > were proposed properly by Ed. The ISA ones were deleted quickly. For the
E> > PCI ones I communicated Cronyx and checked their status. Later the
E> > drivers were made as minimal as possible, removing sppp(4). This is a
E> > proper process.  Not do a drive by commit and refuse to revert it.
E> 
E>  Where did I refuse to revert ?

May I ask you to revert it then, please? If you have time we can discuss
and work on the above described policy of built but not included into
default install devices/tools.

P.S. If you really wish to deprecate something, I can suggest you to
sacrifice sbni(4) :)

-- 
Gleb Smirnoff

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

2021-12-16 Thread Emmanuel Vadot 
On Thu, 16 Dec 2021 07:01:30 -0800
Gleb Smirnoff  wrote:

>   Emmanuel,
> 
> On Thu, Dec 16, 2021 at 10:17:33AM +0100, Emmanuel Vadot wrote:
> E> > E>  I'm not sure I understand the logic here.
> E> > E>  We're keeping drivers for museum grade hardware that no developer 
> have
> E> > E> access to and likely no one uses nowadays just for an hypothetical
> E> > E> situation where someone will try to use those cards on FreeBSD 14 i386
> E> > E> in 2021 ?
> E> > E>  And we're doing that just because the drivers compiles ?
> E> > 
> E> > We are doing that because the hardware is still produced and can be
> E> > purchased at http://cronyx.ru/price/#taupci And this is not a dead
> E> > website, I gave a call to tech support last year. Who uses it? No
> E> > idea. For some obscure reason they are still produced along with
> E> > conventional PCI industrial mainboards (you can google that).
> E> 
> E>  I'm sure that if one looks deep enough, a lot of obsolete hardware
> E> that we've removed are still produced by some industrial computer maker.
> E>  And I don't think that this is a valid reason to keep everything that
> E> is old.
> 
> I'd be interested to see at least one example of removed driver for
> a hardware that is still produced. Can you demonstrate one please?

 This was an hypothetical situation.

> E> > I agree that actual intersection of FreeBSD users and Cronyx
> E> > users could be zero today. But potentially it can be non-zero.
> E> > I would appreciate if somebody chooses FreeBSD for their very
> E> > strange industrial communications equipment.
> E> >
> E> > Some corrections on above statements.
> E> > 
> E> > 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a
> E> >reason that some functions are marked with __attribute__ fastcall.
> E> >I'm 99% sure that attribute can be removed and ce(4) will build
> E> >on amd64. sconfig(8) is build on amd64.
> E> 
> E>  No we don't, see :
> E> https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772
> 
> Well, that was my miss, when I moved it from options.i386 to options.x86.
> Forgot about modules. The Makefile also has a comment at line 764.
> 
> With "we build" I meant that we can add it to kernel config and build.
> 
> E> > Does sconfig create any problems for you? I'm fine with removing
> E> > the drivers and the tool if they do really create a burden for us.
> E> > That was case with their sppp(4) half, and I removed it in 6aae3517ed25.
> E> > If there is no maintainance burden, why remove them? Just to save
> E> > disk space?
> E> 
> E>  They don't really create a burden.
> E>  The reason that made me look at this is that I've noticed that my
> E> FreeBSD-runtime package had this sconfig binary that I've never heard
> E> of before. After digging I saw that it was for those old cards.
> E>  I honestly don't care if we keep the drivers as of today we only
> E> compile them for i386. I don't think that we should enable them for
> E> amd64, we've lived ~20 years on amd64 without them, nobody complained
> E> that they weren't present so clearly nobody cares about having them. We
> E> shouldn't enable drivers on some arch just "because we can".
> E>  With a46856c3f9ec in main right now I'm perfectly happy as I don't
> E> have some useless tool, if it could stay that way that would be great.
> 
> I'm not. Your position is simply: "the utility existence bugs me cause
> it is useless for me", and "I don't care if it exist on i386, cause I
> don't use i386". Kind of selfish position.

 What's selfish about removing some binary that 100% of our amd64 users
never needed since the creation of FreeBSD/amd64 ?

> For myself FreeBSD also contains quite a lot of tools I never use and
> probably never would.
> 
> E>  But it will be nice to have some kind of official statement on what
> E> FreeBSD should deliver in term of drivers, I think we're way too
> E> conservative on keeping old stuff that nobody uses just because "it
> E> compiles".
> 
> I agree with that. We need such policy. It is being promised, and while
> it is not there yet, there is this document:
> 
> https://wiki.freebsd.org/DeprecationPlan
> 
> As you see, a developer who wants to remove something needs to propose
> that, communicate that and plan. And as you can see there, Cronyx devices
> were proposed properly by Ed. The ISA ones were deleted quickly. For the
> PCI ones I communicated Cronyx and checked their status. Later the
> drivers were made as minimal as possible, removing sppp(4). This is a
> proper process.  Not do a drive by commit and refuse to revert it.

 Where did I refuse to revert ?

-- 
Emmanuel Vadot

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

2021-12-16 Thread Gleb Smirnoff 
  Emmanuel,

On Thu, Dec 16, 2021 at 10:17:33AM +0100, Emmanuel Vadot wrote:
E> > E>  I'm not sure I understand the logic here.
E> > E>  We're keeping drivers for museum grade hardware that no developer have
E> > E> access to and likely no one uses nowadays just for an hypothetical
E> > E> situation where someone will try to use those cards on FreeBSD 14 i386
E> > E> in 2021 ?
E> > E>  And we're doing that just because the drivers compiles ?
E> > 
E> > We are doing that because the hardware is still produced and can be
E> > purchased at http://cronyx.ru/price/#taupci And this is not a dead
E> > website, I gave a call to tech support last year. Who uses it? No
E> > idea. For some obscure reason they are still produced along with
E> > conventional PCI industrial mainboards (you can google that).
E> 
E>  I'm sure that if one looks deep enough, a lot of obsolete hardware
E> that we've removed are still produced by some industrial computer maker.
E>  And I don't think that this is a valid reason to keep everything that
E> is old.

I'd be interested to see at least one example of removed driver for
a hardware that is still produced. Can you demonstrate one please?

E> > I agree that actual intersection of FreeBSD users and Cronyx
E> > users could be zero today. But potentially it can be non-zero.
E> > I would appreciate if somebody chooses FreeBSD for their very
E> > strange industrial communications equipment.
E> >
E> > Some corrections on above statements.
E> > 
E> > 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a
E> >reason that some functions are marked with __attribute__ fastcall.
E> >I'm 99% sure that attribute can be removed and ce(4) will build
E> >on amd64. sconfig(8) is build on amd64.
E> 
E>  No we don't, see :
E> https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772

Well, that was my miss, when I moved it from options.i386 to options.x86.
Forgot about modules. The Makefile also has a comment at line 764.

With "we build" I meant that we can add it to kernel config and build.

E> > Does sconfig create any problems for you? I'm fine with removing
E> > the drivers and the tool if they do really create a burden for us.
E> > That was case with their sppp(4) half, and I removed it in 6aae3517ed25.
E> > If there is no maintainance burden, why remove them? Just to save
E> > disk space?
E> 
E>  They don't really create a burden.
E>  The reason that made me look at this is that I've noticed that my
E> FreeBSD-runtime package had this sconfig binary that I've never heard
E> of before. After digging I saw that it was for those old cards.
E>  I honestly don't care if we keep the drivers as of today we only
E> compile them for i386. I don't think that we should enable them for
E> amd64, we've lived ~20 years on amd64 without them, nobody complained
E> that they weren't present so clearly nobody cares about having them. We
E> shouldn't enable drivers on some arch just "because we can".
E>  With a46856c3f9ec in main right now I'm perfectly happy as I don't
E> have some useless tool, if it could stay that way that would be great.

I'm not. Your position is simply: "the utility existence bugs me cause
it is useless for me", and "I don't care if it exist on i386, cause I
don't use i386". Kind of selfish position.

For myself FreeBSD also contains quite a lot of tools I never use and
probably never would.

E>  But it will be nice to have some kind of official statement on what
E> FreeBSD should deliver in term of drivers, I think we're way too
E> conservative on keeping old stuff that nobody uses just because "it
E> compiles".

I agree with that. We need such policy. It is being promised, and while
it is not there yet, there is this document:

https://wiki.freebsd.org/DeprecationPlan

As you see, a developer who wants to remove something needs to propose
that, communicate that and plan. And as you can see there, Cronyx devices
were proposed properly by Ed. The ISA ones were deleted quickly. For the
PCI ones I communicated Cronyx and checked their status. Later the
drivers were made as minimal as possible, removing sppp(4). This is a
proper process.  Not do a drive by commit and refuse to revert it.

-- 
Gleb Smirnoff

Re: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23)

2021-12-16 Thread Dimitry Andric 
On 15 Dec 2021, at 18:44, FreeBSD User  wrote:
> 
> On Fri, 10 Dec 2021 19:41:07 +1030
> Daniel O'Connor via freebsd-current  wrote:
>>> On 25 Nov 2021, at 18:50, FreeBSD User  wrote:
...
> 
>>> Since then named is crashing with a mysterious segmentation fault (see PR 
>>> 259921,
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259921).
...
> In the meanwhile, bind-9.16.24_1 has been issued in ports - the same problem 
> occurs with
> that version, too, when compiled with llvm13.

I committed a fix in:

https://cgit.freebsd.org/src/commit/?id=5a925e4644665b9a7a5cdd664764fb0a4d1c5797

which I'll MFC after the usual 3 days. Please try this out. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

2021-12-16 Thread Emmanuel Vadot 
On Wed, 15 Dec 2021 10:11:16 -0800
Gleb Smirnoff  wrote:

> On Wed, Dec 15, 2021 at 05:52:02PM +0100, Emmanuel Vadot wrote:
> E> > >  I've noticed this /sbin/sconfig binary and after looking it's for
> E> > > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe).
> E> > >  The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't
> E> > > supported.
> E> > >  We currently only build the drivers for i386 (and they contain native
> E> > > compiled code).
> E> > >
> E> > >  Anyway, I'd like to remove this from the tree, I really doubt that
> E> > > anyone uses this cards nowadays (or even E1) but just in case I send
> E> > > this mail.
> E> > 
> E> > I posted a similar query to -stable in 2020, at
> E> > 
> https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html
> E> > and did not get any response.
> E> > 
> E> > I have D23928 for a deprecation notice for ce and cp. Gleb commented
> E> > there that he'd offer to maintain them (and as part of that, removed
> E> > sppp in 6aae3517ed25).
> E> > 
> E> 
> E>  I'm not sure I understand the logic here.
> E>  We're keeping drivers for museum grade hardware that no developer have
> E> access to and likely no one uses nowadays just for an hypothetical
> E> situation where someone will try to use those cards on FreeBSD 14 i386
> E> in 2021 ?
> E>  And we're doing that just because the drivers compiles ?
> 
> We are doing that because the hardware is still produced and can be
> purchased at http://cronyx.ru/price/#taupci And this is not a dead
> website, I gave a call to tech support last year. Who uses it? No
> idea. For some obscure reason they are still produced along with
> conventional PCI industrial mainboards (you can google that).

 I'm sure that if one looks deep enough, a lot of obsolete hardware
that we've removed are still produced by some industrial computer maker.
 And I don't think that this is a valid reason to keep everything that
is old.

> I agree that actual intersection of FreeBSD users and Cronyx
> users could be zero today. But potentially it can be non-zero.
> I would appreciate if somebody chooses FreeBSD for their very
> strange industrial communications equipment.
>
> Some corrections on above statements.
> 
> 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a
>reason that some functions are marked with __attribute__ fastcall.
>I'm 99% sure that attribute can be removed and ce(4) will build
>on amd64. sconfig(8) is build on amd64.

 No we don't, see :
https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772

> 2) Drivers don't contain native precompiled code. They contain
>obfuscated code.

 Ok, I actually didn't looked, just noticed that they where listed
under MK_SOURCELESS_HOST.

> Does sconfig create any problems for you? I'm fine with removing
> the drivers and the tool if they do really create a burden for us.
> That was case with their sppp(4) half, and I removed it in 6aae3517ed25.
> If there is no maintainance burden, why remove them? Just to save
> disk space?

 They don't really create a burden.
 The reason that made me look at this is that I've noticed that my
FreeBSD-runtime package had this sconfig binary that I've never heard
of before. After digging I saw that it was for those old cards.
 I honestly don't care if we keep the drivers as of today we only
compile them for i386. I don't think that we should enable them for
amd64, we've lived ~20 years on amd64 without them, nobody complained
that they weren't present so clearly nobody cares about having them. We
shouldn't enable drivers on some arch just "because we can".
 With a46856c3f9ec in main right now I'm perfectly happy as I don't
have some useless tool, if it could stay that way that would be great.

 But it will be nice to have some kind of official statement on what
FreeBSD should deliver in term of drivers, I think we're way too
conservative on keeping old stuff that nobody uses just because "it
compiles".

 Cheers,

-- 
Emmanuel Vadot

Re: On amd64 main-n251456-22c4ab6cb015-dirty (Dec.-7): /boot/kernel/ng_ubt.ko is getting "symbol sysctl___net_bluetooth undefined"

2021-12-16 Thread Hans Petter Selasky 

On 12/15/21 23:58, Mark Millard via freebsd-current wrote:

Back when I upgraded the ThreadRipper 1950X amd64 system to (line split for 
readability):

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25 
main-n251456-22c4ab6cb015-dirty:
Tue Dec  7 19:38:53 PST 2021
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
arm64 aarch64 1400043 1400043

I started getting notices like:

Dec  7 18:38:57 amd64_ZFS kernel: link_elf_obj: symbol sysctl___net_bluetooth 
undefined
Dec  7 18:38:57 amd64_ZFS kernel: linker_load_file: /boot/kernel/ng_ubt.ko - 
unsupported file type

(Not that I use the bluetooth on the system.)

Is this expected for a kernel of that vintage?

For reference:

# more /usr/main-src/sys/amd64/conf/GENERIC-NODBG
#
# GENERIC -- Custom configuration for the amd64/amd64
#

include "GENERIC"

ident   GENERIC-NODBG

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

options NUMA
options MAXMEMDOM=2

#optionsALT_BREAK_TO_DEBUGGER

options KDB # Enable kernel debugger support

# For minimum debugger support (stable branch) use:
options KDB_TRACE   # Print a stack trace for a panic
options DDB # Enable the kernel debugger

# Extra stuff:
#optionsVERBOSE_SYSINIT=0   # Enable verbose sysinit messages
#optionsBOOTVERBOSE=1
#optionsBOOTHOWTO=RB_VERBOSE
#optionsKTR
#optionsKTR_MASK=KTR_TRAP
##options   KTR_CPUMASK=0xF
#optionsKTR_VERBOSE
#optionsACPI_DEBUG

# Disable any extra checking for. . .
nooptions   DEADLKRES   # Would enable the deadlock resolver
nooptions   INVARIANTS  # Would enable calls of extra sanity 
checking
nooptions   INVARIANT_SUPPORT   # Would enable extra sanity checks of 
internal structures, required by INVARIANTS
nooptions   WITNESS # Would enable checks to detect 
deadlocks and cycles
nooptions   WITNESS_SKIPSPIN# Would enable running witness on 
spinlocks for speed
nooptions   DIAGNOSTIC
nooptions   MALLOC_DEBUG_MAXZONES

# Kernel Sanitizers
nooptions   COVERAGE# Would enable generic kernel coverage. 
Used by KCOV
nooptions   KCOV# Would enable Kernel Coverage Sanitizer
# Warning: KUBSAN can result in a kernel too large for loader to load
nooptions   KUBSAN  # Would enable Kernel Undefined 
Behavior Sanitizer

device  iwm
device  iwmfw


sysctl___net_bluetooth seems to be from one or more of:

# grep -r "net_bluetooth[^_]" /usr/main-src/sys/ | more
/usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_INT(_net_bluetooth,
 OID_AUTO, version,
/usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth,
 OID_AUTO, hci, CTLFLAG_RW | CTLFLAG_MPSAFE, 0,
/usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth,
 OID_AUTO, l2cap, CTLFLAG_RW | CTLFLAG_MPSAFE, 0,
/usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth,
 OID_AUTO, rfcomm, CTLFLAG_RW | CTLFLAG_MPSAFE, 0,
/usr/main-src/sys/netgraph/bluetooth/common/ng_bluetooth.c:SYSCTL_NODE(_net_bluetooth,
 OID_AUTO, sco, CTLFLAG_RW | CTLFLAG_MPSAFE, 0,
/usr/main-src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c:SYSCTL_INT(_net_bluetooth,
 OID_AUTO, usb_isoc_enable, CTLFLAG_RWTUN | CTLFLAG_MPSAFE,
/usr/main-src/sys/netgraph/bluetooth/include/ng_bluetooth.h:SYSCTL_DECL(_net_bluetooth);



This issue was fixed:

https://cgit.freebsd.org/src/commit/?id=8fa952937bbe44a0fdd17348adfbbfd44aef6004

--HPS