Jenkins build is unstable: FreeBSD_HEAD #162

See ___ 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-update

Hello. Please consider a new clean command in the freebsd-update script. The modified manual and script are located at https://github.com/textbrowser/freebsd-update. Included are two diffs. Sorry for the long e-mail. --- /usr/src/usr.sbin/freebsd-update/freebsd-update.8    2015-08-12

Build failed in Jenkins: FreeBSD_HEAD #161

See -- Started by user rodrigc > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.com/freebsd/freebsd-ci.git

Re: FreeBSD_HEAD_amd64_gcc - Build #1147 - Still Failing

On Tue, Apr 05, 2016 at 09:22:11 -0700, Bryan Drewery wrote: > On 4/5/16 3:54 AM, jenkins-ad...@freebsd.org wrote: > > + sudo pkg install -y devel/amd64-xtoolchain-gcc > > Updating FreeBSD repository catalogue... > > FreeBSD repository is up-to-date. > > All repositories are up-to-date. > > Build

Re: FreeBSD_HEAD_amd64_gcc - Build #1147 - Still Failing

On 4/5/16 3:54 AM, jenkins-ad...@freebsd.org wrote: > + sudo pkg install -y devel/amd64-xtoolchain-gcc > Updating FreeBSD repository catalogue... > FreeBSD repository is up-to-date. > All repositories are up-to-date. > Build step 'Execute shell' marked build as failure pkg install -y is returning

Re: accessing a PCIe register from userspace through kmem or other ways ?

On Tue, Apr 5, 2016 at 2:10 AM, Konstantin Belousov wrote: > The mmap(2) interface to /dev/mem did not have the issue ever. The problem > was only with the read(2)/write(2) accesses. > I mis-remembered my situation. I was performing a read on /dev/mem rather than reading

FreeBSD_HEAD_amd64_gcc - Build #1148 - Fixed

FreeBSD_HEAD_amd64_gcc - Build #1148 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1148/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1148/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1148/console

Re: Packaging the FreeBSD base system with pkg(8)

On 2016-04-05 13:42, Benjamin Kaduk wrote: On Tue, 5 Apr 2016, Gary Jennejohn wrote: Will there be an option not to merge? I never update /etc when I do installworld because what I have works for me and I see no need to make any changes to a working system. And you expect your system to

Re: Packaging the FreeBSD base system with pkg(8)

On Tue, 5 Apr 2016, Gary Jennejohn wrote: > Will there be an option not to merge? I never update /etc when > I do installworld because what I have works for me and I see no > need to make any changes to a working system. And you expect your system to continue working after a new system user is

Re: accessing a PCIe register from userspace through kmem or other ways ?

On Tue, Apr 05, 2016 at 08:27:32PM +0300, Konstantin Belousov wrote: > On Tue, Apr 05, 2016 at 10:02:07AM -0700, John Baldwin wrote: > > For the ioctl I planned to either 1) call vm_mmap_object() or the like > > directly > > and return the virtual address to the user, or 2) return the mmap offset

Re: accessing a PCIe register from userspace through kmem or other ways ?

On Tue, Apr 05, 2016 at 10:02:07AM -0700, John Baldwin wrote: > For the ioctl I planned to either 1) call vm_mmap_object() or the like > directly > and return the virtual address to the user, or 2) return the mmap offset to > use > from the ioctl that the user would then supply to mmap() and

Re: accessing a PCIe register from userspace through kmem or other ways ?

On Tuesday, April 05, 2016 07:21:29 PM Konstantin Belousov wrote: > On Tue, Apr 05, 2016 at 08:55:54AM -0700, John Baldwin wrote: > > Mostly I do not have experience with MGTDEVICE, though I was planning to > > look at it as a way to implement this. Two things though: 1) there may > > not be a

Re: accessing a PCIe register from userspace through kmem or other ways ?

On Tue, Apr 05, 2016 at 08:55:54AM -0700, John Baldwin wrote: > Mostly I do not have experience with MGTDEVICE, though I was planning to > look at it as a way to implement this. Two things though: 1) there may > not be a cdev to associate with, and 2) I know of at least one device driver > that

Re: accessing a PCIe register from userspace through kmem or other ways ?

On Tuesday, April 05, 2016 09:14:31 AM Konstantin Belousov wrote: > On Mon, Apr 04, 2016 at 03:45:07PM -0700, John Baldwin wrote: > > However, another question is how to deal with systems that do bus address > > translation (like the arm64 ThunderX boxes) where the values in the PCI > > BAR are

Re: Packaging the FreeBSD base system with pkg(8)

On Tue, Apr 05, 2016 at 12:22:49PM +0200, Gary Jennejohn wrote: > On Tue, 5 Apr 2016 10:22:04 +0100 > David Chisnall wrote: > > > On 5 Apr 2016, at 10:07, Gergely Czuczy wrote: > > > > > > Also, quite often entries from the base system are

FreeBSD_HEAD_amd64_gcc - Build #1147 - Still Failing

FreeBSD_HEAD_amd64_gcc - Build #1147 - Still Failing: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1147/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1147/changes Full build log:

Re: Packaging the FreeBSD base system with pkg(8)

On Tue, 5 Apr 2016 10:22:04 +0100 David Chisnall wrote: > On 5 Apr 2016, at 10:07, Gergely Czuczy wrote: > > > > Also, quite often entries from the base system are changed > > manually, think of root's/toor's password. Are such cases > > going

Re: Packaging the FreeBSD base system with pkg(8)

On 5 Apr 2016, at 10:07, Gergely Czuczy wrote: > > Also, quite often entries from the base system are changed manually, think of > root's/toor's password. Are such cases going to be dealt with properly > between upgrades, including self-built-and-packaged base

Re: Packaging the FreeBSD base system with pkg(8)

On 2016-01-27 23:33, Glen Barber wrote: As many know, work has been in progress for quite some time to provide the ability to package and upgrade the FreeBSD base system using pkg(8). The majority of the initial implementation has provided much of the core functionality to make this possible,

Re: D3702: add support for Bluetooth Magic Mouse

On Mon, Apr 04, 2016 at 10:22:30PM -0600, Warren Block wrote: > Is anyone working on Bluetooth stuff? https://reviews.freebsd.org/D3702 > adds support for the Apple Magic Mouse, and has been tested and reported > working: >

Re: CURRENT slow and shaky network stability

In message <20160405092712.131ee...@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > On Mon, 04 Apr 2016 23:46:08 -0700 > Cy Schubert wrote: > > > In message <20160405082047.670d7...@freyja.zeit4.iv.bundesimmobilien.de>, > > "O. H > > artmann" writes: >

Re: CURRENT slow and shaky network stability

On Mon, 04 Apr 2016 23:46:08 -0700 Cy Schubert wrote: > In message <20160405082047.670d7...@freyja.zeit4.iv.bundesimmobilien.de>, > "O. H > artmann" writes: > > On Sat, 02 Apr 2016 16:14:57 -0700 > > Cy Schubert wrote: > > > > > In message

Re: CURRENT slow and shaky network stability

In message <20160405082047.670d7...@freyja.zeit4.iv.bundesimmobilien.de>, "O. H artmann" writes: > On Sat, 02 Apr 2016 16:14:57 -0700 > Cy Schubert wrote: > > > In message <20160402231955.41b05526.ohart...@zedat.fu-berlin.de>, "O. > > Hartmann" > > writes: > > >

Re: CURRENT slow and shaky network stability

On Sat, 02 Apr 2016 16:14:57 -0700 Cy Schubert wrote: > In message <20160402231955.41b05526.ohart...@zedat.fu-berlin.de>, "O. > Hartmann" > writes: > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding:

Re: accessing a PCIe register from userspace through kmem or other ways ?

On Mon, Apr 04, 2016 at 03:45:07PM -0700, John Baldwin wrote: > However, another question is how to deal with systems that do bus address > translation (like the arm64 ThunderX boxes) where the values in the PCI > BAR are not CPU physical addresses. To do this properly we may need some > sort of

Re: accessing a PCIe register from userspace through kmem or other ways ?

On Mon, Apr 04, 2016 at 09:02:49PM -0700, John Baldwin wrote: > kib@ fixed /dev/mem to handle addresses beyond the direct map limit to use > temporary mappings instead of failing with EFAULT in 277051 which was only > committed to HEAD last January, so well after 8.2. The mmap(2) interface to