Re: Optimization bug with floating-point?

2019-03-25 Thread Steve Kargl 
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
> All,
> 
> There seems to an optimization bug with clang on
> 
> % uname -a
> FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE  i386
> 
> IOW, if you do numerica work on i386, you may want to check your
> results.

This is now 

https://bugs.llvm.org/show_bug.cgi?id=41224

-- 
Steve
___
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 hotplug a PCI device (such as VF) on FreeBSD

2019-03-25 Thread John Baldwin 
On 3/25/19 7:05 AM, Ian Lepore wrote:
> On Mon, 2019-03-25 at 08:49 +, Hongxiong Xian (Wicresoft North
> America Ltd) wrote:
>> Hi,
>>
>> I'm looking for a way to refresh the pci device list.
>> In Linux, we can remove a particular pci device, and then after
>> preforming a "rescan" the device will appear again.
>> For example, disable/rescind PCI (such as VF) :
>> echo 1 >  /sys/bus/pci/devices/0001\:00\:02.0/remove
>> # Get the device back
>> echo 1 > /sys/bus/pci/rescan
>>
>> I'm looking for a similar way in FreeBSD. Does the FreeBSD support
>> the hotplug of a PCI device?  Thanks in advance!
>>
>>
> 
> I think 'devctl rescan' will do that, 'man devctl' for details.

For VFs you can create/remote them using iovctl on the PF device.

You can also use 'devctl rescan' to force a rescan of a PCI bus as
Ian noted.  For native PCI-express hotplug you should not need to
do manual rescans (though FreeBSD does not support PCI-e hotplug
via Thunderbolt).

-- 
John Baldwin
___
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 hotplug a PCI device (such as VF) on FreeBSD

2019-03-25 Thread Ian Lepore 
On Mon, 2019-03-25 at 08:49 +, Hongxiong Xian (Wicresoft North
America Ltd) wrote:
> Hi,
> 
> I'm looking for a way to refresh the pci device list.
> In Linux, we can remove a particular pci device, and then after
> preforming a "rescan" the device will appear again.
> For example, disable/rescind PCI (such as VF) :
> echo 1 >  /sys/bus/pci/devices/0001\:00\:02.0/remove
> # Get the device back
> echo 1 > /sys/bus/pci/rescan
> 
> I'm looking for a similar way in FreeBSD. Does the FreeBSD support
> the hotplug of a PCI device?  Thanks in advance!
> 
> 

I think 'devctl rescan' will do that, 'man devctl' for details.

-- Ian

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

Re: Long waits for Firefox and SeaMonkey to respond to links from other applications

2019-03-25 Thread Cy Schubert 
On March 25, 2019 6:41:18 AM PDT, Kjell Tore Ullavik  
wrote:
>
>
>On 24.03.2019 17.25, Graham Perrin wrote:
>> When I open a web address in (for example) Thunderbird, there's a
>wait 
>> of around fifteen seconds before the web browser, already open, 
>> handles the address.
>>
>> Affected browsers:
>>
>> - Firefox
>> - SeaMonkey
>> - Waterfox.
>>
>> Not affected:
>>
>> - New Moon (Pale Moon) – the waiting period is a split-second
>> - Chromium – split-second
>> - Falkon – less than two seconds.
>>
>> Any ideas?
>>
>>  shows the waiting period with
>
>> Konsole as the starting point, Firefox as the default web browser.
>>
>> I can't say exactly when the problem began, but it was long before 
>> Firefox 66.
>>
>> 
>>
>> $ date ; uname -v
>> Sun 24 Mar 2019 16:23:22 GMT
>> FreeBSD 13.0-CURRENT r345330 GENERIC-NODEBUG
>> $ pkg query '%o %v %R' firefox seamonkey waterfox
>> www/firefox 66.0_3,1 poudriere
>> www/seamonkey 2.49.4_24 FreeBSD
>> www/waterfox 56.2.7.2 poudriere
>> $
>
>I have seen this as well. But not right now so can't investigate.
>Could it be a dbus problem?
>
>I also have a vague and incomplete memory of fixing a similar
>problem a long time ago by filling out my /etc/hosts.
>Though that seems a bit weird.
>
>
>
>___
>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"

The way to attack this problem is to run tcpdump on the interface while running 
DTrace against firefox or under truss -d. Simply running tcpdump without the 
other might give you enough information to at least make an educated guess.

Also, ff & friends are especially sensitive to load. If you're doing buildworld 
-j while using ff, don't or give ff a higher priority. I've seen it use 
multiple threads within multiple processes.

Make sure you have lots of RAM. ff doesn't like to have any of it's working set 
paged out.


-- 
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert 
FreeBSD UNIX:  Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.
___
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: Long waits for Firefox and SeaMonkey to respond to links from other applications

2019-03-25 Thread Kjell Tore Ullavik 



On 24.03.2019 17.25, Graham Perrin wrote:
When I open a web address in (for example) Thunderbird, there's a wait 
of around fifteen seconds before the web browser, already open, 
handles the address.


Affected browsers:

- Firefox
- SeaMonkey
- Waterfox.

Not affected:

- New Moon (Pale Moon) – the waiting period is a split-second
- Chromium – split-second
- Falkon – less than two seconds.

Any ideas?

 shows the waiting period with 
Konsole as the starting point, Firefox as the default web browser.


I can't say exactly when the problem began, but it was long before 
Firefox 66.




$ date ; uname -v
Sun 24 Mar 2019 16:23:22 GMT
FreeBSD 13.0-CURRENT r345330 GENERIC-NODEBUG
$ pkg query '%o %v %R' firefox seamonkey waterfox
www/firefox 66.0_3,1 poudriere
www/seamonkey 2.49.4_24 FreeBSD
www/waterfox 56.2.7.2 poudriere
$


I have seen this as well. But not right now so can't investigate.
Could it be a dbus problem?

I also have a vague and incomplete memory of fixing a similar
problem a long time ago by filling out my /etc/hosts.
Though that seems a bit weird.



___
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 CI Weekly Report 2019-03-24

2019-03-25 Thread Li-Wen Hsu 
(bcc -current and -stable for more audience)

FreeBSD CI Weekly Report 2019-03-24
===

Here is a summary of the FreeBSD Continuous Integration results for
the period from 2019-03-18 to 2019-03-24.

During this period, we have:

* 2286 builds (98.3% passed, 1.7% failed) were executed on aarch64,
amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64,
powerpcspe, riscv64, sparc64 architectures for head, stable/12,
stable/11 branches.
* 498 test runs (37.3% passed, 60.7% unstable, 2% exception) were
executed on amd64, i386, riscv64 architectures for head, stable/12,
stable/11 branches.
* 15 doc buils (100% passed)

(The statistics from experimental jobs are omitted)

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

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

## Failing Tests

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test/
* lib.libarchive.functional_test.test_fuzz_zip
  (flakey) See https://bugs.freebsd.org/236300 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
* lib.libc.sys.sendfile_test.fd_positive_shm_v4
* lib.libc.sys.sendfile_test.hdtr_negative_bad_pointers_v4

* https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/
* sbin.bectl.bectl_test.bectl_mount
* 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

* 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.kernel_stacks
* local.kyua.* (31 cases)
* local.lutok.* (3 cases)
* lib.libc.sys.sendfile_test.fd_positive_shm_v4
* lib.libc.sys.sendfile_test.hdtr_negative_bad_pointers_v4

## Failing Tests (from experimental jobs)

* https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/
* 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 ~60 failing cases, including flakey ones, see
https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/
for more details

## 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

## Closed Issues

* [29: genassym.o build race](https://bugs.freebsd.org/29)

* sys.netmap.ctrl-api-test.main failed after
https://svnweb.freebsd.org/changeset/base/345269 , fixed in
https://svnweb.freebsd.org/changeset/base/345323 .

* https://bugs.freebsd.org/236475 triggered assertion failure on
initialing ZFS in tests, is fixed in
https://svnweb.freebsd.org/changeset/base/345418

* sys.netpfil.pf.icmp.cve_2019_5598 added with wrong failname in
https://svnweb.freebsd.org/changeset/base/345409 , fixed in
https://svnweb.freebsd.org/changeset/base/345430

## Open Issues

* Flakey test case: lib.libarchive.functional_test.test_fuzz_zip
https://bugs.freebsd.org/236300

### Cause build fails

* [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)

## Other News

* mizhka@ is fixing the subversion library used in Jenkins, which
solves the problem that Jenkins cannot checkout from a subversion
repository when running on FreeBSD after inode64 merge (FreeBSD
12.0-RELEASE). More details available:
  https://issues.tmatesoft.com/issue/SVNKIT-740
___
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"

How to hotplug a PCI device (such as VF) on FreeBSD

2019-03-25 Thread Hongxiong Xian (Wicresoft North America Ltd) 
Hi,

I'm looking for a way to refresh the pci device list.
In Linux, we can remove a particular pci device, and then after preforming a 
"rescan" the device will appear again.
For example, disable/rescind PCI (such as VF) :
echo 1 >  /sys/bus/pci/devices/0001\:00\:02.0/remove
# Get the device back
echo 1 > /sys/bus/pci/rescan

I'm looking for a similar way in FreeBSD. Does the FreeBSD support the hotplug 
of a PCI device?  Thanks in advance!


Thanks,
Hongxiong

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