Re: [HEADSUP] making /bin/sh the default shell for root

[Mateusz Piotrowski]

On 23/09/2021 10:55, Hans Ottevanger wrote:
As you mention elsewhere in this thread, usage in scripts is not affected by these changes. And 
for interactive use it could be a POLA violation, but the astonishment would be a positive one.


Unfortunately, the switch from csh to sh is going to affect scripts. Take a look at this (examples 
below assume that toor uses /bin/sh):


# su root -c 'echo $1' abc def
abc
# su toor -c 'echo $1' abc def
def

Another example:

# ssh -p  root@xxx -- '$@' echo 1 2 3
Illegal variable name.
# ssh -p  toor@xxx -- '$@' echo 1 2 3
1 2 3

I've been bitten by this a couple of times when working with some production scripts. I'm afraid 
changing the default shell to csh may cause a bit of hard-to-debug problems there in the wild.


Otherwise, I'd be happy with having sh(1) as the default shell for root. From my perspective, sh(1) 
was far more forgiving to my colleagues when they started with FreeBSD.


Best,

Mateusz Piotrowski

Re: dma-resv.c: make does not know, how to compile

[Mateusz Piotrowski]

On 11/18/20 11:32 AM, M - Krasznai András wrote:

Hi

in the last two days I was not able to compile FreeBSD-CURRENT, make stopped 
with error:

does not know, how to compile dma-resv.c

I did not find the above file in a freshly synchromized source tree (dma-resv.h 
file does exist).


You are probably using drm-kmod and missing the following patch:

https://docs.freebsd.org/cgi/getmsg.cgi?fetch=2979410+0+/usr/local/www/mailindex/archive/2020/svn-ports-head/20201115.svn-ports-head

Basically, you probably want to update the graphics/drm-current-kmod port and install it so that all 
the required driver sources are present at /usr/local/sys/modules/drm-current-kmod.


Cheers,

Mateusz

___
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: Shutdown errors and timeout

[Mateusz Piotrowski]

On 11/16/20 7:16 PM, Johan Hendriks wrote:


On 14/11/2020 13:03, Mateusz Piotrowski wrote:

On 11/14/20 1:19 AM, Tomoaki AOKI wrote:

On Fri, 13 Nov 2020 20:04:59 +0900 (JST)
Yasuhiro KIMURA  wrote:


From: Johan Hendriks 


Hello all, i have two FreeBSD 13 machines, one is a bare metal and one
is virtualbox machine which i both update about once a week.

The vritual machine seems to fail stopping something and gives a
timeout after 90 sec.

The console ends with

Writing entropy file: .
Writing early boot entropy file: .

90 second watchdog timeout expired. Shutdown terminated.
Fri Nov13 11:20:40 CEST 2020
Nov 13 11:20:40 test-head init[1]: /etc/rc.shutdown terminated
abnormally, going to single user mode
...

On the bare metal machine i see the following.
Writing entropy file: .
Writing early boot entropy file: .
cannot unmount '/var/run': umount failed
cannot unmount '/var/log': umount failed
cannot unmount '/var': umount failed
cannot unmount '/usr/home': umount failed
cannot unmount '/usr': umount failed
cannot unmount '/': umount failed


(snip)

The pools have not been upgraded after the latest openzfs import,
maybe that is related?

FreeBSD test-freebsd-head 13.0-CURRENT FreeBSD 13.0-CURRENT #2
r367585:

First thing i noticed is about a week ago.

I'm facing same problem with 13.0-CURRENT amd64 r367487 and
virtualbox. In my case I use autofs to mount remote file system of
12.2-RELEASE amd64 server with NFSv4. When there is still filesystem
mounted by autofs, then watchdog timeout happens while shutdown. The
watchdog timeout can be worked around by executing `automount -fu`
before shutting down. But 'cannot unmount ...' error messages are
still displayed.

I added 'rc_debug="YES"' to /etc/rc.conf and checked which rc script
causes this message. Then it is displayed when following `zfs_stop`
function of /etc/rc.d/zfs is executed.

--
zfs_stop_main()
{
zfs unshare -a
zfs unmount -a
}
--

At this point syslog process still running and it opens some files
under /var/log. So it make sence that `zfs unmount -a` results in the
message.

Probably order of executing each rc script in shutdown time should be
changed so `/etc/rc.d/zfs faststop` is executed after all processes
other than `init' are exited.

This happens on stable/12, too.
As a workaround, reverting r367291 on head (r367546 on stable/12)
would stop the issue until this is really fixed.

If you have shared dataset or jail(s) mounting dataset, the workaround
would be discouraged. Read commit message for detail.


I've committed r367291 and r367546.

I am not sure if I can think of a proper fix for the described issues, so I guess the best idea 
would be to revert those changes for now until we figure out how to do it properly.



I can tell that reverting the mentioned commit i do not have the symptoms when 
i reboot my servers.
Thank you all for your time, and no sorry needed ;-)


I'll revert the commit then. I'm just waiting for an approval from a src 
committer.

Best,

Mateusz

___
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: Shutdown errors and timeout

[Mateusz Piotrowski]

Hi,

On 11/14/20 1:19 AM, Tomoaki AOKI wrote:

On Fri, 13 Nov 2020 20:04:59 +0900 (JST)
Yasuhiro KIMURA  wrote:


From: Johan Hendriks 


Hello all, i have two FreeBSD 13 machines, one is a bare metal and one
is virtualbox machine which i both update about once a week.

The vritual machine seems to fail stopping something and gives a
timeout after 90 sec.

The console ends with

Writing entropy file: .
Writing early boot entropy file: .

90 second watchdog timeout expired. Shutdown terminated.
Fri Nov13 11:20:40 CEST 2020
Nov 13 11:20:40 test-head init[1]: /etc/rc.shutdown terminated
abnormally, going to single user mode
...

On the bare metal machine i see the following.
Writing entropy file: .
Writing early boot entropy file: .
cannot unmount '/var/run': umount failed
cannot unmount '/var/log': umount failed
cannot unmount '/var': umount failed
cannot unmount '/usr/home': umount failed
cannot unmount '/usr': umount failed
cannot unmount '/': umount failed


(snip)

The pools have not been upgraded after the latest openzfs import,
maybe that is related?

FreeBSD test-freebsd-head 13.0-CURRENT FreeBSD 13.0-CURRENT #2
r367585:

First thing i noticed is about a week ago.

I'm facing same problem with 13.0-CURRENT amd64 r367487 and
virtualbox. In my case I use autofs to mount remote file system of
12.2-RELEASE amd64 server with NFSv4. When there is still filesystem
mounted by autofs, then watchdog timeout happens while shutdown. The
watchdog timeout can be worked around by executing `automount -fu`
before shutting down. But 'cannot unmount ...' error messages are
still displayed.

I added 'rc_debug="YES"' to /etc/rc.conf and checked which rc script
causes this message. Then it is displayed when following `zfs_stop`
function of /etc/rc.d/zfs is executed.

--
zfs_stop_main()
{
zfs unshare -a
zfs unmount -a
}
--

At this point syslog process still running and it opens some files
under /var/log. So it make sence that `zfs unmount -a` results in the
message.

Probably order of executing each rc script in shutdown time should be
changed so `/etc/rc.d/zfs faststop` is executed after all processes
other than `init' are exited.

This happens on stable/12, too.
As a workaround, reverting r367291 on head (r367546 on stable/12)
would stop the issue until this is really fixed.

If you have shared dataset or jail(s) mounting dataset, the workaround
would be discouraged. Read commit message for detail.


I've committed r367291 and r367546.

I am not sure if I can think of a proper fix for the described issues, so I guess the best idea 
would be to revert those changes for now until we figure out how to do it properly.


Sorry for the regression.

Best,

Mateusz

___
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: Move from termcap(5) to terminfo(5)

[Mateusz Piotrowski]

Hi,

On 5/7/20 2:41 PM, Baptiste Daroussin wrote:

Hello everyone,

I can't find any proper rationale in our history (maybe I missed it) which
explains why our ncurses is stuck on using termcap(5) instead of terminfo(5)
Except an argument in the Makefile that builds ncurses:
"Used instead of the hideous read_termcap.c abomination."

Which I do not find really useful.

I would like to make the move from termcap to terminfo which would give us the
bonus to be able to track terminfo sources from upstream aka ncurses and to
add and use tic(1).
That's great! I've been bitten by termcap not being well understood by 
the open source community many times. I am supporting the move to 
terminfo wholeheartedly.

If you have some knowledge you want to share: "be careful about this or that" I
would be more than happy to collect it, to make sure the transition is as smooth
as possible.


What comes to my mind is that we should probably pay special attention 
to terminal ports, like x11/sterm. We might need to tell those ports to 
install their terminfo files. I don't remember the details though.


Cheers,

Mateusz


___
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 in fusefs(5) on 13.0-CURRENT r359773

[Mateusz Piotrowski]

Hi everyone!

I'm experiencing panics every day. Apparently, they are caused by a bug 
in our FUSE implementation.


The panic occurs when I'm editing files in a folder mounted via SSHFS 
from a bhyve VM running Ubuntu 18.04.


I'm sending some parts of the core.txt file. Let me know if I can 
provide any additional information.


Cheers,

Mateusz

---

t480 dumped core - see /var/crash/vmcore.3

Mon Apr 27 11:30:19 CEST 2020

FreeBSD t480 13.0-CURRENT FreeBSD 13.0-CURRENT #4 r359773: Sat Apr 11 
05:32:31 CEST 2020 root@t480:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64


panic: Assertion bp->b_flags & B_VMIO failed at 
/usr/src/sys/fs/fuse/fuse_node.c:433


GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD]
Copyright (C) 2020 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-freebsd13.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:
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577
WARNING !drm_modeset_is_locked(>mode_config.connection_mutex) 
failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:622
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821
WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821

<4>WARN_ON(!mutex_is_locked(>struct_mutex))

<4>WARN_ON(!mutex_is_locked(>lock))

<4>WARN_ON(!mutex_is_locked(>lock))WARN_ON(!mutex_is_locked(>lock))WARN_ON(!mutex_is_locked(>lock))
panic: Assertion bp->b_flags & B_VMIO failed at 
/usr/src/sys/fs/fuse/fuse_node.c:433

cpuid = 5
time = 1587979693
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe00cc0ef330

vpanic() at vpanic+0x182/frame 0xfe00cc0ef380
panic() at panic+0x43/frame 0xfe00cc0ef3e0
fuse_vnode_setsize() at fuse_vnode_setsize+0x135/frame 0xfe00cc0ef430
fuse_internal_cache_attrs() at fuse_internal_cache_attrs+0xc4/frame 
0xfe00cc0ef490

fuse_vnop_lookup() at fuse_vnop_lookup+0x6bf/frame 0xfe00cc0ef620
lookup() at lookup+0x5e1/frame 0xfe00cc0ef6c0
namei() at namei+0x524/frame 0xfe00cc0ef7b0
kern_statat() at kern_statat+0x7f/frame 0xfe00cc0ef8d0
sys_fstatat() at sys_fstatat+0x2f/frame 0xfe00cc0ef9d0
amd64_syscall() at amd64_syscall+0x140/frame 0xfe00cc0efaf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00cc0efaf0
--- syscall (552, FreeBSD ELF64, sys_fstatat), rip = 0x8006c2aaa, rsp = 
0x7fffda78, rbp = 0x7fffdb20 ---

KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55        __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
#2  0x8049a43a in db_dump (dummy=,
    dummy2=, dummy3=, dummy4=)
    at /usr/src/sys/ddb/db_command.c:575
#3  0x8049a1fc in db_command (last_cmdp=,
    cmd_table=, dopager=1) at 

Re: HOWTO donate CPU to the fight against the Corona-virus

[Mateusz Piotrowski]

On 3/20/20 1:51 PM, Jonathan Anderson wrote:

Hi all,

Running this on a 12.1-STABLE system, I see a whole lot of this in
/var/log/messages:
fahclient[53019]: ^[[91m12:15:25:ERROR:WU00:FS00:Exception: Could not get
an assignment^[[0m

Is this because there temporarily isn't enough work to go around, or
because more FreeBSD support is required on the work distribution end as
well?


Either there is no work or you have to change the user name in the 
config file. I am not sure however if the username change is really a 
solution.


Cheers,

Mateusz

___
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: HOWTO donate CPU to the fight against the Corona-virus

[Mateusz Piotrowski]

Hi!

On 3/19/20 11:04 PM, Mateusz Piotrowski wrote:

On 3/19/20 8:57 AM, Alexander Leidinger via freebsd-stable wrote:
if someone wants to donate some FreeBSD based CPU resources to the 
fight against the Corona-virus, here is a quick HOWTO in terms of 
installing the Folding@Home client on FreeBSD:


https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ 



I tested this on a recent -current.

If you are interested in how this helps in the fight against the 
virus, please refer to the https://foldingathome.org/ website. In 
short and over-simplified: they search for vaccines.


I've got an almost finished port of this software. I'll post a patch 
soonish.


The patch is now on Phabricator open to reviews & ready to be tested:

https://reviews.freebsd.org/D24127

Cheers,

Mateusz

___
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: HOWTO donate CPU to the fight against the Corona-virus

[Mateusz Piotrowski]

Hi,

On 3/19/20 8:57 AM, Alexander Leidinger via freebsd-stable wrote:

Hi,

if someone wants to donate some FreeBSD based CPU resources to the 
fight against the Corona-virus, here is a quick HOWTO in terms of 
installing the Folding@Home client on FreeBSD:


https://www.leidinger.net/blog/2020/03/19/fighting-the-coronavirus-with-freebsd-foldinghome/ 



I tested this on a recent -current.

If you are interested in how this helps in the fight against the 
virus, please refer to the https://foldingathome.org/ website. In 
short and over-simplified: they search for vaccines.


Bye,
Alexander.

I've got an almost finished port of this software. I'll post a patch 
soonish.


Thanks so much for your blog post!

Cheers!

Mateusz

___
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: Wired memory consumes almost all my memory recently

[Mateusz Piotrowski]

On 3/3/20 11:41 AM, Kirill Ponomarev wrote:

On 03/03, Mateusz Piotrowski wrote:

I'm experiencing some problems with memory on r358410.

Please try r358505, it should be fixed.


Thanks!

I'm running r358571 now. I'll post again if the problem persists.

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

Wired memory consumes almost all my memory recently

[Mateusz Piotrowski]

Hi current@,

I'm experiencing some problems with memory on r358410.

I'm building a lot of ports in poudriere for testing purposes, which is 
very a resource-intensive operation. After a couple of hours of such a 
workload, the machine starts to become much less responsive (e.g., it 
takes a couple seconds to start a new tmux pane). When I run top I would 
always see that almost all my memory is wired (15G), swap reports a 
couple of hundreds megabytes being used, and the free memory is less 
than 100M.


If I kill all my desktop processes like Firefox and Thunderbird (it 
takes a couple of minutes to complete this task!) then the machine 
becomes responsive again, still having maybe a couple hundreds of 
megabytes of free memory for me.


I thought that maybe this is an ARC problem (I'm using ZFS) but it 
didn't help to restrict ARC to 8G by setting sysctl 
vfs.zfs.arc_max=8517738496.


I think that I've never experienced similar problems before.

Cheers,

Mateusz Piotrowski


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

acpiconf does not return proper information about the second battery

[Mateusz Piotrowski]

Hello current,

I've upgraded to r358233 recently (from a 13.0-CURRENT snapshot from 
late January).


Since the upgrade, I cannot get full information about my second battery 
with acpiconf (I'm using Lenovo Thinkpad T480).


The number of batteries is detected properly. It is just the details of 
the second one that are not available. Here are the outputs of acpiconf 
invocations:


$ acpiconf -i 0
Design capacity:    24000 mWh
Last full capacity:    18600 mWh
Technology:        secondary (rechargeable)
Battery Swappable Capability:    Non-swappable
Design voltage:        11460 mV
Capacity (warn):    930 mWh
Capacity (low):        200 mWh
Cycle Count:        174
Mesurement Accuracy:    95 %
Max Average Interval:    1000 ms
Min Average Interval:    500 ms
Low/warn granularity:    -1 mWh
Warn/full granularity:    -1 mWh
Model number:        01AV421
Serial number:         4058
Type:            LiP
OEM info:        SMP
State:            high
Remaining capacity:    100%
Remaining time:        unknown
Present rate:        0 mW
Present voltage:    12503 mV



$ acpiconf -i 1
Design capacity:    0 mWh
Last full capacity:    0 mWh
Technology:        primary (non-rechargeable)
Design voltage:        0 mV
Capacity (warn):    0 mWh
Capacity (low):        0 mWh
Cycle Count:        0
Mesurement Accuracy:    0 %
Max Sampling Time:    0 ms
Min Sampling Time:    0 ms
Max Average Interval:    0 ms
Min Average Interval:    0 ms
Low/warn granularity:    0 mWh
Warn/full granularity:    0 mWh
Model number:
Serial number:
Type:
OEM info:
State:            not present
Present voltage:    11513 mV



The "Present voltage" of the second battery changes to "unknown" when 
the battery is removed.


___
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: r347638 breaks mergemaster

[Mateusz Piotrowski]

On Thu, 16 May 2019 at 13:34, David Wolfskill  wrote:

> ...
> But rr347638 moved master.passwd from src/etc to lib/libc/gen, so
> mergemaster ... isn't happy:
>
> | *** Creating the temporary root environment in /var/tmp/temproot
> |  *** /var/tmp/temproot ready for use
> |  *** Creating and populating directory structure in /var/tmp/temproot
> |
> | cp: /usr/src/etc/master.passwd: No such file or directory
> |
> |   *** FATAL ERROR: Cannot copy files to the temproot environment
>
> I don't know if etcupdate is similarly affected.
>

It is. I got the same error message from etcupdate.
___
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"

Call for 2019Q1 quarterly status reports (deadline on April 30)

[Mateusz Piotrowski]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is April 30,
2019, for work done since the last round of Quarterly Reports: January,
2019 – March, 2019.


Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
provide a great way to inform FreeBSD users and developers about
work that is underway and completed.  Submission of reports is not
restricted to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and email
it to quarte...@freebsd.org.  The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly
/master/report-sample.md

The old XML generator and templates are no longer used.

We look forward to seeing your 2019Q1 reports!

Cheers,
Mateusz (on behalf of quarterly@)
___
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"

Call for 2018Q4 quarterly status reports (deadline: 2019-01-31)

[Mateusz Piotrowski]

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is January 31,
2019, for work done since the last round of Quarterly Reports [1].

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
provide a great way to inform FreeBSD users and developers about
work that is underway and completed.  Submission of reports is not
restricted to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and email
it to quarte...@freebsd.org.  The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md

The old XML generator and templates are no longer used.

We look forward to seeing your 2018Q4 reports!

Cheers,
Mateusz (on behalf of quarterly@)

[1]: https://www.freebsd.org/news/status/report-2018-01-2018-09.html
___
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 Error: No handler for Region [ECOR]

[Mateusz Piotrowski]

On Tue, 20 Nov 2018 at 15:47, Charlie Li  wrote:

> Somewhere between r340491 and r340650, probably starting from r340595,
> my ThinkPad W550s started spewing these messages repeatedly in the
> system log since boot:
>
> ...
>
> As a result, I am now unable to query battery information at the very
> least. r340490 is my last built revision with this working.
>

There's a bug report for a similar issue after r330957:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
___
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: awk manual is outdated

[Mateusz Piotrowski]

On Tue, 24 Jul 2018 01:06:19 +0200
Samy Mahmoudi  wrote:

>The awk manual seems out of date.
>
>For example, the -V option is documented but is unknown at execution.
>Reciprocally, --version is not documented but is functional at execution.
>Under FreeBSD 12.0-CURRENT, the date at the end of the manual also seems
>older than expected, as the FreeBSD Manual Pages indicates a newer date for
>FreeBSD 11.2.
>
>I could edit awk.1 and copy/paste a patch to solve these but reviewing the
>whole manual may be better to eradicate other omissions. From the FreeBSD
>Manual Pages, I have found out that options (including -V) were introduced
>between 11.0 RELEASE and 11.1 RELEASE.
>
>By the way, choosing the "FreeBSD 12-current" manual on that web page
>
>actually gives the "FreeBSD 11.2" manual, seemingly.

I've created an issue on Bugzilla for this. Thanks for the heads up.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230730
___
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: [RFC] Deprecation and removal of the drm2 driver

[Mateusz Piotrowski]

On Tue, 29 May 2018 17:39:57 -0700 (PDT)
"Rodney W. Grimes"  wrote:

>> Let's also remember about our handbooks and those two wiki page:
>>  * https://wiki.freebsd.org/Graphics
>>  * https://wiki.freebsd.org/Graphics/FAQ
>This one has a bit rot on this claim:
>   "The i915kms kernel-side driver is already built into the
>generic FreeBSD kernel. No need to install anything. '
>
>That is slightly miss leading, it is not "built into the generic",
>it is avaliable as a module, at least on 11 and 12, not sure on
>10 as I dont have 10 running any place anymore.

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

Re: [RFC] Deprecation and removal of the drm2 driver

[Mateusz Piotrowski]

On Tue, 29 May 2018 21:28:49 +0200
Niclas Zeising  wrote:

>On 05/18/18 19:58, Niclas Zeising wrote:
>> [ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect
>> reply-to and send all replies to freebsd-x11@.  Thanks! ]
>>
>> [...]
>>
>> What does the community think?  Is there anyone still using the drm2
>> driver on 12-CURRENT?  If so, what is preventing you from switching to
>> the port?
>>
>
>
>Wow, this blew up quite a lot bigger than I anticipated.  I'll try to
>summarize the discussion a bit below and then suggest a way forward.
>
> [...]
>
>To move forward, we'll do the following:  Note that this is for current
>only.
>We take the drm and drm2 drivers and make a port for it, maintained by
>the graphics team (x11@).  After a transition period, then the drivers
>are removed from base.  At the same time, pkg-messages are added to
>relevant places to point people to the various available drm drivers.

Let's also remember about our handbooks and those two wiki page:
 * https://wiki.freebsd.org/Graphics
 * https://wiki.freebsd.org/Graphics/FAQ
___
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: Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD 12

[Mateusz Piotrowski]

On Wed, 23 May 2018 09:46:13 -0700
Pete Wright  wrote:

>On 05/23/2018 00:41, David Pan wrote:
>> how config the Intel Corporation Wireless 8265 / 8275 (rev 78) on
>> FreeBSD 12?I installed FreeBSD 12 on my thinkpad t470p ,and can not
>> drive the Intel Wireless Card.
>> please help me fix that,
>
>I have this working on my end under both 12-current and 11-stable.
>here's my configuration:
>
>output from "pciconf -lv"
>iwm0@pci0:3:0:0:    class=0x028000 card=0x10108086 chip=0x24fd8086
>rev=0x78 hdr=0x00
>     vendor = 'Intel Corporation'
>     device = 'Wireless 8265 / 8275'
>     class  = network
>
>
>to bring up the card i have added this entry to /etc/rc.conf:
>
>kld_list="if_iwm"
>
>then configuring the interface is the same as any other wifi as per the
>handbook, the device will be available as "iwm0".

Shouldn't you load some firmware as well? That's what the iwm(4) manual
and WiFi/FAQ wiki page[1] say.

[1]: 
https://wiki.freebsd.org/WiFi/FAQ#I.27ve_got_some_problems_with_the_iwm.284.29_driver
___
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: Nvidia issue with CURRENT

[Mateusz Piotrowski]

On Mon, 23 Apr 2018 08:19:25 -0700
Kevin Oberman <rkober...@gmail.com> wrote:

>On Mon, Apr 23, 2018 at 1:53 AM, Mateusz Piotrowski <0...@freebsd.org>
>wrote:
>
>> On Mon, 23 Apr 2018 09:00:33 +0200
>> "O. Hartmann" <ohartm...@walstatt.org> wrote:
>>  
>> >In /etc/src.conf , therefore you should add something similar to
>> >(like I added to mine):
>> >
>> >PORTS_MODULES=
>> >PORTS_MODULES+= x11/nvidia-driver
>> >PORTS_MODULES+=
>> >emulators/virtualbox-ose-kmod  
>>
>> Shouldn't it go into make.conf(5)? That's what the manual suggests.
>>  
>
>Ans the man page should be fixed. By putting it into make.conf, it
>pollutes the environment  of ever make(1) run on the system. (Yes,
>unlikely to ever cause a problem,)
>
>In src.conf it only impacts the builds of the system and ports. This
>is why src.conf was created a few years ago. In fact, it was
>originally supposed to only impact the build of the system, but the
>ports Mk files were modified to pull it in, to, much to my annoyance.
>I liked being able to modify compile options just for the system
>without them breaking ports builds.
>
>Simple rule... any definition used by make(1) only for system builds
>belongs in /etc/sec.conf.

Done, I've added this information to make.conf(5). Now it's waiting for
a review. 

https://reviews.freebsd.org/D15177

Thanks!

Mateusz
___
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: Nvidia issue with CURRENT

[Mateusz Piotrowski]

On Mon, 23 Apr 2018 09:00:33 +0200
"O. Hartmann"  wrote:

>In /etc/src.conf , therefore you should add something similar to (like
>I added to mine):
>
>PORTS_MODULES=
>PORTS_MODULES+= x11/nvidia-driver
>PORTS_MODULES+= emulators/virtualbox-ose-kmod

Shouldn't it go into make.conf(5)? That's what the manual suggests.

___
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: Is there possible run a MacOS X binary

[Mateusz Piotrowski]

On 8 Dec 2016, at 14:07, mokhi  wrote:

> I had started a writing a Mach-O image activator monthes ago, but
> time/daily-life distracted me from continuing it.
> Maybe some day I continue it :D
> Currently it's available on my github[1] if it helps.
> I had some success-like running of some super-simple less-than 'return
> A+B' programs with it :)

Have you considered adding it to the FreeBSD Google Summer of Code Ideas 
wiki[2]?

Maybe some brave student will like the idea and decide to spend some time on 
this project.

Cheers,

-mateusz

[2]: https://wiki.freebsd.org/SummerOfCodeIdeas
___
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"