Re: Status of libarchive/bsdtar maintainership

[Eugene Grosbein]

On 01.02.2019 11:10, Warner Losh wrote:

> On Thu, Jan 31, 2019, 8:22 PM Eugene Grosbein   wrote:
> 
> Hi!
> 
> I wonder what is status of our contrib/libarchive and bsdtar/bsdcpio etc. 
> in modern versions of FreeBSD
> in a sense of serious bug fixing. Long story short: I faced a bug in the 
> libarchive bundled with 11.2
> that makes it impossible to create reliable backups of live file system 
> or its subtree
> using cron+bsdtar utility that delegate actial work to the libarchive 
> that just aborts
> if a file disappears (is removed) in process (GNU tar continues with just 
> warning).
> 
> This is serious issue for me as I used 'tar' command to make backups for 
> distinct subtrees
> since FreeBSD 6.x and when my GPS+ntpd subsystem went insane and shifted 
> system clock to 3 years
> in the future, I lost data in several thousands of RRD databases and 
> looked for backups to restore them
> and found only small portion of databases in the tar instead of full 
> backup.
> 
> I've create the PR 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006 and later attached a 
> patch
> solving the problem in same way as GNU tar deals with it.
> 
> Martin Matuska (mm) asked me to create an issue at GitHub for libarchive.
> I have no GitHub account nor I need one, and he was so kind and created 
> it himself:
> https://github.com/libarchive/libarchive/issues/1082
> 
> Almost 3 months have passed and no response from upstream.
> Should we go ahead and fix it despite of it is part of contrib?
> 
> 
> If you fix it, protocol is to submit it upstream first.

That was done 3 months ago.

> It causes fewer problems in the long run. While it is tempting to just fix it 
> in FreeBSD and move on,
> almost every time we've done that in the past someone else has had to come in 
> and fix the mess.
> 
> Do you have a fix? Can you put it up for review somewhere?

It is attached to mentioned PR: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006#c6

> We are no where near a release, so there is no reason to rush this in.

I waited for almost 3 months already. It seems, there would be no response at 
all.


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

Re: Status of libarchive/bsdtar maintainership

[Kurt Jaeger]

Hi!

> > Almost 3 months have passed and no response from upstream.
> > Should we go ahead and fix it despite of it is part of contrib?

> Do you have a fix? Can you put it up for review somewhere?

It's in the PR, see

https://bugs.freebsd.org/bugzilla/attachment.cgi?id=199000

> We are no where
> near a release, so there is no reason to rush this in.

It's reported *because* production systems already *have* issues...

-- 
p...@freebsd.org +49 171 3101372 One year to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Status of libarchive/bsdtar maintainership

[Warner Losh]

On Thu, Jan 31, 2019, 8:22 PM Eugene Grosbein  Hi!
>
> I wonder what is status of our contrib/libarchive and bsdtar/bsdcpio etc.
> in modern versions of FreeBSD
> in a sense of serious bug fixing. Long story short: I faced a bug in the
> libarchive bundled with 11.2
> that makes it impossible to create reliable backups of live file system or
> its subtree
> using cron+bsdtar utility that delegate actial work to the libarchive that
> just aborts
> if a file disappears (is removed) in process (GNU tar continues with just
> warning).
>
> This is serious issue for me as I used 'tar' command to make backups for
> distinct subtrees
> since FreeBSD 6.x and when my GPS+ntpd subsystem went insane and shifted
> system clock to 3 years
> in the future, I lost data in several thousands of RRD databases and
> looked for backups to restore them
> and found only small portion of databases in the tar instead of full
> backup.
>
> I've create the PR
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006 and later
> attached a patch
> solving the problem in same way as GNU tar deals with it.
>
> Martin Matuska (mm) asked me to create an issue at GitHub for libarchive.
> I have no GitHub account nor I need one, and he was so kind and created it
> himself:
> https://github.com/libarchive/libarchive/issues/1082
>
> Almost 3 months have passed and no response from upstream.
> Should we go ahead and fix it despite of it is part of contrib?
>

If you fix it, protocol is to submit it upstream first. It causes fewer
problems in the long run. While it is tempting to just fix it in FreeBSD
and move on, almost every time we've done that in the past someone else has
had to come in and fix the mess.

Do you have a fix? Can you put it up for review somewhere? We are no where
near a release, so there is no reason to rush this in.

Warner

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

Status of libarchive/bsdtar maintainership

[Eugene Grosbein]

Hi!

I wonder what is status of our contrib/libarchive and bsdtar/bsdcpio etc. in 
modern versions of FreeBSD
in a sense of serious bug fixing. Long story short: I faced a bug in the 
libarchive bundled with 11.2
that makes it impossible to create reliable backups of live file system or its 
subtree
using cron+bsdtar utility that delegate actial work to the libarchive that just 
aborts
if a file disappears (is removed) in process (GNU tar continues with just 
warning).

This is serious issue for me as I used 'tar' command to make backups for 
distinct subtrees
since FreeBSD 6.x and when my GPS+ntpd subsystem went insane and shifted system 
clock to 3 years
in the future, I lost data in several thousands of RRD databases and looked for 
backups to restore them
and found only small portion of databases in the tar instead of full backup.

I've create the PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233006 and 
later attached a patch
solving the problem in same way as GNU tar deals with it.

Martin Matuska (mm) asked me to create an issue at GitHub for libarchive.
I have no GitHub account nor I need one, and he was so kind and created it 
himself:
https://github.com/libarchive/libarchive/issues/1082

Almost 3 months have passed and no response from upstream.
Should we go ahead and fix it despite of it is part of contrib?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reminder: FCP-101: pending removal of some 10/100 Ethernet drivers

[Brooks Davis]

We are currently planning to remove the following less-popular 10/100
Ethernet drivers in the March/April timeframe:

ae, bm, cs, de, dme, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe

All of these drivers generate warnings in FreeBSD 12 and to the best of
my knowledge, none have cleared the bar specified in the FCP[0]:

https://github.com/freebsd/fcp/blob/master/fcp-0101.md

The easiest way for you to provide data to help our decision making is
to upload dmesgs to https://dmesgd.nycbug.org/.  If you have a
installations of FreeBSD 12 that are dependent on one of these NICs and
you can not report them this way, please feel free to contact me
directly.

-- Brooks

[0] I've received a couple reports of ae(4) devices, but still not 5 of
them.


signature.asc
Description: PGP signature

Re: igb now em driver in FreeBSD 12.0

[Clayton Milos]

I can confirm this. Had to change kernel conf to have em instead of igb and the 
device is detected as igb. 

 Matthew Macy wrote 

>They show up as igb. The only POLA violation is that for users of modules
>there is now no if_igb.ko so configuring an igb interface doesn't
>automatically load the (em) module.
>
>On Thu, Jan 31, 2019 at 07:04 Robert Blayzor  wrote:
>
>> Reading the release notes, the igb driver has been merged into the Intel
>> em driver so that should be added to custom kernels. No problem.
>>
>> Question is, when the system reboots, are the NIC devices going to come
>> up with "emX" now or will they remain "igbX" ?
>>
>> Kind of important to know on remote upgrading a server...
>>
>>
>> --
>> inoc.net!rblayzor
>> XMPP: rblayzor.AT.inoc.net
>> PGP:  https://inoc.net/~rblayzor/
>>
>> ___
>> freebsd-stable@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>>
>___
>freebsd-stable@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: X11 on Ryzen 2400G?

[Phil Norman]

On Wed, 30 Jan 2019 at 22:24, Pete Wright  wrote:

>
>
> On 1/30/19 12:10 PM, Phil Norman wrote:
>
[snip]

>
>> - after you have configured the amdgpu.ko to load on boot verify it is
>> able to load the kernel module and your console display looks good.  if
>> you have issues loading the kernel module let us know, there are some
>> things you can try to setup to get a useful backtrace that will help us
>> debug this.
>>
>
> This is where I get to. I've removed amdgpu from /etc/rc.conf, so I don't
> have to boot single-user mode; when I run kldload amdgpu, the following
> happens:
>
> 1: the 'kldload amdgpu' process doesn't return immediately, yet the
> terminal is responsive; I can hit return, and have the cursor move. The
> mouse pointer also moves.
> 2: something around 5s later, the screen turns off, the keyboard goes
> unresponsive (caps lock light doesn't toggle), and the machine no longer
> responds to pings.
>
>
> interesting, it looks like the kernel module and firmware modules do
> load.  one thing you may want to test is setting the
> "debug.debugger_on_panic=0" sysctl knob before loading the amdgpu.ko.
> hopefully this will allow you to get into a debugger before the system
> locks up.
>

I just tried 'sysctl debug.debugger_on_panic=0' from the command line - it
printed out that it was being switched from 1 -> 0. Then tried kldload
amdgpu, and unfortunately it behaved exactly the same as previously
reported. So no debugger for me.

Should I be reporting this in freebsd-x11? Or some other forum? I remember
there being a somewhat heated discussion about the drm kernel module not
always being 100% stable, back in the Summer I believe.

I suppose one further question: is anyone else successfully using the
in-built graphics from a Ryzen G chip with X11? And if so, any advice on
versions of things, or flags to set?

Thanks again for the advice.
Phil
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: igb now em driver in FreeBSD 12.0

[Matthew Macy]

They show up as igb. The only POLA violation is that for users of modules
there is now no if_igb.ko so configuring an igb interface doesn't
automatically load the (em) module.

On Thu, Jan 31, 2019 at 07:04 Robert Blayzor  wrote:

> Reading the release notes, the igb driver has been merged into the Intel
> em driver so that should be added to custom kernels. No problem.
>
> Question is, when the system reboots, are the NIC devices going to come
> up with "emX" now or will they remain "igbX" ?
>
> Kind of important to know on remote upgrading a server...
>
>
> --
> inoc.net!rblayzor
> XMPP: rblayzor.AT.inoc.net
> PGP:  https://inoc.net/~rblayzor/
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

igb now em driver in FreeBSD 12.0

[Robert Blayzor]

Reading the release notes, the igb driver has been merged into the Intel
em driver so that should be added to custom kernels. No problem.

Question is, when the system reboots, are the NIC devices going to come
up with "emX" now or will they remain "igbX" ?

Kind of important to know on remote upgrading a server...


-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://inoc.net/~rblayzor/

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

FreeBSD CI Weekly Report 2019-01-27

[Li-Wen Hsu]

(bcc -current and -stable for more audience)

FreeBSD CI Weekly Report 2019-01-27
===

Here is a summary of the FreeBSD Continuous Integration results for the period
from 2019-01-21 to 2019-01-27.

During this period, we have:

* 2429 builds (91.2% pass, 7.3% failed, 1.5% exception) were executed on
  aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64,
  powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11
  branches.
* 481 test runs (7.7% pass, 60% unstable, 15.6% exception) were executed on
  amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches.
* 10 doc buils (100% pass)

If any of the issues found by CI are in your area of interest or expertise
please investigate the PRs listed below.

Web version of this report is available at https://hackmd.io/s/SkFyq6bmN and
archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is
welcome.

## Failing Jobs

* https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/
GCC reports `error: floating constant exceeds range of 'long double'
[-Werror=overflow]`

## Failing Tests

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test/
* All are lib.libc.sys.sendfile_test.* and see
  https://bugs.freebsd.org/235200 for deails

* https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/
* common.misc.t_dtrace_contrib.tst_dynopt_d
* common.syscall.t_dtrace_contrib.tst_args_d
* common.ip.t_dtrace_contrib.tst_ipv4localsctp_ksh
* common.ip.t_dtrace_contrib.tst_localsctpstate_ksh

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/
* There are 63 failing cases, see
  
https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/
  for more details

* https://ci.freebsd.org/job/FreeBSD-head-i386-test/
* sys.netmap.ctrl-api-test.main
* sys.opencrypto.runtests.main
* lib.libc.regex.exhaust_test.regcomp_too_big
* lib.libregex.exhaust_test.regcomp_too_big
* sys.kern.coredump_phnum_test.coredump_phnum
  WIP: https://reviews.freebsd.org/D18495
* Other 20 are lib.libc.sys.sendfile_test.* and see
  https://bugs.freebsd.org/235200 for deails

* https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/
* sys.netmap.ctrl-api-test.main
* sys.opencrypto.runtests.main
* sbin.bectl.bectl_test.bectl_mount
* lib.libc.regex.exhaust_test.regcomp_too_big
* lib.libregex.exhaust_test.regcomp_too_big
* sys.kern.coredump_phnum_test.coredump_phnum
  WIP: https://reviews.freebsd.org/D18495

* https://ci.freebsd.org/job/FreeBSD-stable-11-amd64-test/
* usr.bin.procstat.procstat_test.kernel_stacks

* https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/
* sys.netmap.ctrl-api-test.main
* sys.opencrypto.runtests.main
* usr.bin.procstat.procstat_test.environment
* usr.bin.procstat.procstat_test.kernel_stacks
* local.kyua.* (31 cases)
* local.lutok.* (3 cases)

## Disabled Tests

* lib.libc.sys.mmap_test.mmap_truncate_signal
https://bugs.freebsd.org/211924

* sys.fs.tmpfs.mount_test.large
https://bugs.freebsd.org/212862

* sys.fs.tmpfs.link_test.kqueue
https://bugs.freebsd.org/213662

* sys.kqueue.libkqueue.kqueue_test.main
https://bugs.freebsd.org/233586

* usr.bin.procstat.procstat_test.command_line_arguments
https://bugs.freebsd.org/233587

* usr.bin.procstat.procstat_test.environment
https://bugs.freebsd.org/233588

* lib.msun.{cbrt_test.cbrtl_powl,trig_test.reduction}
https://bugs.freebsd.org/234040

## Open Issues

### New

* [235200: lib.libc.sys.sendfile_test.* fail](https://bugs.freebsd.org/235200)
* Patch available: https://reviews.freebsd.org/D19026

### Inprogress

* https://bugs.freebsd.org/235097
* Patch committed: https://svnweb.freebsd.org/changeset/base/343418

### Cause build fails

* [29: genassym.o build race](https://bugs.freebsd.org/29)
* [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h:
error: machine/endian.h: No such file or
directory](https://bugs.freebsd.org/233735)
* [233769: Possible build race: ld: error: unable to find library
-lgcc_s](https://bugs.freebsd.org/233769)

### Others
[Tickets related to testing@](https://preview.tinyurl.com/y9maauwg)

## Closed Issues

Works fine in the new CI infrastructure:
* https://bugs.freebsd.org/197600
* https://bugs.freebsd.org/200312
* https://bugs.freebsd.org/219759
* https://bugs.freebsd.org/219874

## Other news

* We still have 44 skipped tests in head-amd64, some of them because of test
  environment.  See
  
https://ci.freebsd.org/job/FreeBSD-head-amd64-test/lastCompletedBuild/testReport/
  for details.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"