D3702: add support for Bluetooth Magic Mouse

2016-04-04 Thread Warren Block 
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: 
https://lists.freebsd.org/pipermail/freebsd-bluetooth/2016-April/002053.html


Could someone please review and commit this?  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: accessing a PCIe register from userspace through kmem or other ways ?

2016-04-04 Thread John Baldwin 
On Monday, April 04, 2016 08:58:47 PM Ryan Stone wrote:
> On Mon, Apr 4, 2016 at 6:45 PM, John Baldwin  wrote:
> 
> > I suspect Ryan might be referring to BARs outside of the DMAP which we
> > only populate to Maxmem IIRC.  /dev/mem should work for those.
> >
> 
> Unfortunately I no longer have access to the systems so I can't really
> confirm.  I had a debug tool that attempted to read PCI device registers
> through /dev/mem, and on these systems (which were running a 8.2
> derivative) the reads from /dev/mem failed with some kind of error.
> 
> The one detail that I do remember is that the errors started happening
> after we enabled the use of 64-bit BARs in the BIOS and the addresses
> assigned to the BARs were quite large -- I believe well beyond the bounds
> of real memory.

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.

-- 
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: accessing a PCIe register from userspace through kmem or other ways ?

2016-04-04 Thread Ryan Stone 
On Mon, Apr 4, 2016 at 6:45 PM, John Baldwin  wrote:

> I suspect Ryan might be referring to BARs outside of the DMAP which we
> only populate to Maxmem IIRC.  /dev/mem should work for those.
>

Unfortunately I no longer have access to the systems so I can't really
confirm.  I had a debug tool that attempted to read PCI device registers
through /dev/mem, and on these systems (which were running a 8.2
derivative) the reads from /dev/mem failed with some kind of error.

The one detail that I do remember is that the errors started happening
after we enabled the use of 64-bit BARs in the BIOS and the addresses
assigned to the BARs were quite large -- I believe well beyond the bounds
of real memory.
___
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: accessing a PCIe register from userspace through kmem or other ways ?

2016-04-04 Thread John Baldwin 
On Friday, April 01, 2016 08:04:58 PM Konstantin Belousov wrote:
> On Fri, Apr 01, 2016 at 12:48:24PM -0400, Ryan Stone wrote:
> > That is actually a really good question.  I know that with some recent
> > BIOSes if I enabled allocating 64-bit addresses to BARs, the BAR would
> > actually be mapped outside of the range of /dev/mem.  From a quick glance
> > at libpciaccess, I don't think that it handles this case.  A specific
> > mechanism for allowing mmaping of BARs would be useful, I think.
> 
> I am not sure what do you mean by 'outside of the range of /dev/mem'.
> IMO /dev/mem (not kmem) handles every possible physical address both
> for mmap(2) and for read(2)/write(2).  For io interface there were
> some bugs, but they are believed to be fixed.  I mean amd64.

I suspect Ryan might be referring to BARs outside of the DMAP which we
only populate to Maxmem IIRC.  /dev/mem should work for those.

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 bus method akin to my bus_map_resource() WIP but one that instead
returns a suitable 'struct sglist' for a given 'struct resource *' that
can be used with OBJT_SG to build a VM object to use for the mapping.

(At some point I do think I would like a variant of OBJT_SG that used
managed pages so that mappings could be revoked when whatever is backing
the sglist is disabled (e.g. the device is ejected or the BAR is
relocated, etc.).)

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

EGL driver for vt?

2016-04-04 Thread Lundberg, Johannes 
Hi

Would anyone be interested in an Mesa/EGL driver for vt?

If we had this we could run wayland/egl-based compositors with llvmpipe on
platforms without GPU support similar to X+scfb driver. (if my
understanding of the graphics stack if correct..)

If similar to the (now deprecated) Linux framebuffer driver in Mesa I guess
it would not be that much work that has to be done. mesa/llvmpipe would do
all the heavy lifting, correct?

This would enable a whole lot of new exciting possibilities and solve the
problem with lack of GPU drivers..

What do you think?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
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"

[HEADSUP] new x86 smp topology detection code

2016-04-04 Thread Andriy Gapon 


I've just committed new code for detecting SMP (processor and cache) topology on
x86 systems.  Please be aware.

If you get any panics or crashes that look like they might be caused by this
change please send a copy of a report to me.

Another thing to watch is kern.sched.topology_spec.
Please check if the reported topology reasonably matches what you expect on your
system.
You can install hwloc package (devel/hwloc) and then run lstopo -p --no-io to
double-check the topology (--output-format ascii would produce a nice ASCII-art
diagram).

I hope that you see only improvements :-)

 Forwarded Message 
Subject: svn commit: r297558 - in head/sys: kern sys x86/x86
Date: Mon, 4 Apr 2016 16:09:29 + (UTC)
From: Andriy Gapon 
To: src-committ...@freebsd.org, svn-src-...@freebsd.org, 
svn-src-h...@freebsd.org

Author: avg
Date: Mon Apr  4 16:09:29 2016
New Revision: 297558
URL: https://svnweb.freebsd.org/changeset/base/297558

Log:
  new x86 smp topology detection code

  Previously, the code determined a topology of processing units
  (hardware threads, cores, packages) and then deduced a cache topology
  using certain assumptions.  The new code builds a topology that
  includes both processing units and caches using the information
  provided by the hardware.

  At the moment, the discovered full topology is used only to creeate
  a scheduling topology for SCHED_ULE.
  There is no KPI for other kernel uses.

  Summary:
  - based on APIC ID derivation rules for Intel and AMD CPUs
  - can handle non-uniform topologies
  - requires homogeneous APIC ID assignment (same bit widths for ID
components)
  - topology for dual-node AMD CPUs may not be optimal
  - topology for latest AMD CPU models may not be optimal as the code is
several years old
  - supports only thread/package/core/cache nodes

  Todo:
- AMD dual-node processors
- latest AMD processors
- NUMA nodes
- checking for homogeneity of the APIC ID assignment across packages
- more flexible cache placement within topology
- expose topology to userland, e.g., via sysctl nodes

  Long term todo:
- KPI for CPU sharing and affinity with respect to various resources
  (e.g., two logical processors may share the same FPU, etc)

  Reviewed by:  mav
  Tested by:mav
  MFC after:1 month
  Differential Revision:https://reviews.freebsd.org/D2728

Modified:
  head/sys/kern/subr_smp.c
  head/sys/sys/smp.h
  head/sys/x86/x86/mp_x86.c

Modified: head/sys/kern/subr_smp.c
==
--- head/sys/kern/subr_smp.cMon Apr  4 15:56:14 2016(r297557)
+++ head/sys/kern/subr_smp.cMon Apr  4 16:09:29 2016(r297558)
@@ -39,6 +39,7 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,10 @@ __FBSDID("$FreeBSD$");
 #include "opt_sched.h"

 #ifdef SMP
+MALLOC_DEFINE(M_TOPO, "toponodes", "SMP topology data");
+#endif
+
+#ifdef SMP
 volatile cpuset_t stopped_cpus;
 volatile cpuset_t started_cpus;
 volatile cpuset_t suspended_cpus;
@@ -556,7 +561,7 @@ smp_rendezvous(void (* setup_func)(void
smp_rendezvous_cpus(all_cpus, setup_func, action_func, teardown_func, 
arg);
 }

-static struct cpu_group group[MAXCPU];
+static struct cpu_group group[MAXCPU * MAX_CACHE_LEVELS + 1];

 struct cpu_group *
 smp_topo(void)
@@ -616,6 +621,17 @@ smp_topo(void)
 }

 struct cpu_group *
+smp_topo_alloc(u_int count)
+{
+   static u_int index;
+   u_int curr;
+
+   curr = index;
+   index += count;
+   return ([curr]);
+}
+
+struct cpu_group *
 smp_topo_none(void)
 {
struct cpu_group *top;
@@ -861,3 +877,233 @@ sysctl_kern_smp_active(SYSCTL_HANDLER_AR
return (error);
 }

+
+#ifdef SMP
+void
+topo_init_node(struct topo_node *node)
+{
+
+   bzero(node, sizeof(*node));
+   TAILQ_INIT(>children);
+}
+
+void
+topo_init_root(struct topo_node *root)
+{
+
+   topo_init_node(root);
+   root->type = TOPO_TYPE_SYSTEM;
+}
+
+struct topo_node *
+topo_add_node_by_hwid(struct topo_node *parent, int hwid,
+topo_node_type type, uintptr_t subtype)
+{
+   struct topo_node *node;
+
+   TAILQ_FOREACH_REVERSE(node, >children,
+   topo_children, siblings) {
+   if (node->hwid == hwid
+   && node->type == type && node->subtype == subtype) {
+   return (node);
+   }
+   }
+
+   node = malloc(sizeof(*node), M_TOPO, M_WAITOK);
+   topo_init_node(node);
+   node->parent = parent;
+   node->hwid = hwid;
+   node->type = type;
+   node->subtype = subtype;
+   TAILQ_INSERT_TAIL(>children, node, siblings);
+   parent->nchildren++;
+
+   return (node);
+}
+
+struct topo_node *
+topo_find_node_by_hwid(struct topo_node *parent, int hwid,
+topo_node_type type, uintptr_t subtype)
+{
+
+   struct topo_node *node;
+
+

Last call for 2016Q1 quarterly status report submissions

2016-04-04 Thread Benjamin Kaduk 
Dear FreeBSD Community,

There are just a few days left until the April 7 deadline for submitting
entries for the next FreeBSD Quarterly Status Report.  Please submit
entries for work done in January, February, or March.

Status report submissions do not have 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 what you're working
on.  Submission of reports is not restricted to committers.  Anyone doing
anything interesting and FreeBSD-related can -- and should -- write one!

The preferred and easiest submission method is to use the XML generator
[1] with the results emailed to the status report team at monthly at
FreeBSD.org .  There is also an XML template [2] which can be filled out
manually and attached if preferred.  For the expected content and style,
please study our guidelines on how to write a good status report [3].
You can also review previous issues [4][5] for ideas on the style and
format.

We are looking forward to all of your 2016Q1 reports!

Thanks,

Ben (on behalf of monthly@)

[1] http://www.freebsd.org/cgi/monthly.cgi
[2] http://www.freebsd.org/news/status/report-sample.xml
[3] http://www.freebsd.org/news/status/howto.html
[4] http://www.freebsd.org/news/status/report-2015-07-2015-09.html
[5] http://www.freebsd.org/news/status/report-2015-10-2015-12.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: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

2016-04-04 Thread Baptiste Daroussin 
On Mon, Apr 04, 2016 at 08:38:03PM +0800, Li-Wen Hsu wrote:
> On Mon, Apr 04, 2016 at 14:32:35 +0200, Baptiste Daroussin wrote:
> > On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote:
> > > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote:
> > > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> > > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > > > > > I've checked this a little more, I found the return code of
> > > > > > > "installing a installed package" has been changed.
> > > > > > > 
> > > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > > > > > consider the build script execution failure.
> > > > > > > 
> > > > > > > 
> > > > > > It shoudl not return 70 if it returns 70 then there is a bug I can 
> > > > > > fix, I need
> > > > > > to know more about what is failing to be able to fix
> > > > > 
> > > > > What else information do you need?  My experiment is as following:
> > > > > 
> > > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> > > > > installed package.  I choose rsync here, then echo $?, it returns 0.
> > > > > 
> > > > > And I switch to latest branch, also use `pkg install -y rsync`, but 
> > > > > this
> > > > > time $? is 70.
> > > > > 
> > > > > Jenkins "Execute shell" build step checks return value of each command
> > > > > in the shell script, if it is non-zero, it aborts the build and
> > > > > considers if failure.
> > > > 
> > > > Return 70 means an error occured. if I look at the log I can see that
> > > > powerpc64-gcc is not installed for sure, hence the error 70
> > > > 
> > > > What is strange it that no "error message is shown"
> > > 
> > > Very strange, no further error message is shown, even -d provided.
> > > 
> > > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc
> > > DBG(1)[44393]> pkg initialized
> > > Updating FreeBSD repository catalogue...
> > > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD
> > > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
> > > DBG(1)[44393]> Fetch: fetching from: 
> > > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts 
> > > "i"
> > > DBG(1)[44393]> Fetch: fetching from: 
> > > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz 
> > > with opts "i"
> > > FreeBSD repository is up-to-date.
> > > All repositories are up-to-date.
> > > DBG(1)[44393]> want to get an advisory lock on a database
> > > DBG(1)[44393]> release an advisory lock on a database
> > > root@jenkins10a:~ # echo $?
> > > 70
> > > 
> > > Is there anything I can help on debugging this?
> > > 
> > pkg info amd64-xtoolchain-gcc please
> 
> root@jenkins10a:~ # pkg -d info amd64-xtoolchain-gcc
> DBG(1)[44644]> pkg initialized
> amd64-xtoolchain-gcc-0.1
> Name   : amd64-xtoolchain-gcc
> Version: 0.1
> Installed on   : Tue Mar  3 07:32:25 2015 UTC
> Origin : devel/amd64-xtoolchain-gcc
> Architecture   : freebsd:10:x86:64
> Prefix : /usr/local
> Categories : devel
> Licenses   :
> Maintainer : b...@freebsd.org
> WWW: UNKNOWN
> Comment: Pre seeded toolchain to cross build FreeBSD base
> Annotations:
> repo_type  : binary
> repository : FreeBSD
> Flat size  : 225B
> Description:
> Pre seeded cross toolchain definition to cross build FreeBSD base
> 

Ok I see the issue, I will fix it thanks.

Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

2016-04-04 Thread Li-Wen Hsu 
On Mon, Apr 04, 2016 at 14:32:35 +0200, Baptiste Daroussin wrote:
> On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote:
> > On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote:
> > > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> > > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > > > > I've checked this a little more, I found the return code of
> > > > > > "installing a installed package" has been changed.
> > > > > > 
> > > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > > > > consider the build script execution failure.
> > > > > > 
> > > > > > 
> > > > > It shoudl not return 70 if it returns 70 then there is a bug I can 
> > > > > fix, I need
> > > > > to know more about what is failing to be able to fix
> > > > 
> > > > What else information do you need?  My experiment is as following:
> > > > 
> > > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> > > > installed package.  I choose rsync here, then echo $?, it returns 0.
> > > > 
> > > > And I switch to latest branch, also use `pkg install -y rsync`, but this
> > > > time $? is 70.
> > > > 
> > > > Jenkins "Execute shell" build step checks return value of each command
> > > > in the shell script, if it is non-zero, it aborts the build and
> > > > considers if failure.
> > > 
> > > Return 70 means an error occured. if I look at the log I can see that
> > > powerpc64-gcc is not installed for sure, hence the error 70
> > > 
> > > What is strange it that no "error message is shown"
> > 
> > Very strange, no further error message is shown, even -d provided.
> > 
> > root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc
> > DBG(1)[44393]> pkg initialized
> > Updating FreeBSD repository catalogue...
> > DBG(1)[44393]> PkgRepo: verifying update for FreeBSD
> > DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
> > DBG(1)[44393]> Fetch: fetching from: 
> > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts "i"
> > DBG(1)[44393]> Fetch: fetching from: 
> > http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz with 
> > opts "i"
> > FreeBSD repository is up-to-date.
> > All repositories are up-to-date.
> > DBG(1)[44393]> want to get an advisory lock on a database
> > DBG(1)[44393]> release an advisory lock on a database
> > root@jenkins10a:~ # echo $?
> > 70
> > 
> > Is there anything I can help on debugging this?
> > 
> pkg info amd64-xtoolchain-gcc please

root@jenkins10a:~ # pkg -d info amd64-xtoolchain-gcc
DBG(1)[44644]> pkg initialized
amd64-xtoolchain-gcc-0.1
Name   : amd64-xtoolchain-gcc
Version: 0.1
Installed on   : Tue Mar  3 07:32:25 2015 UTC
Origin : devel/amd64-xtoolchain-gcc
Architecture   : freebsd:10:x86:64
Prefix : /usr/local
Categories : devel
Licenses   :
Maintainer : b...@freebsd.org
WWW: UNKNOWN
Comment: Pre seeded toolchain to cross build FreeBSD base
Annotations:
repo_type  : binary
repository : FreeBSD
Flat size  : 225B
Description:
Pre seeded cross toolchain definition to cross build FreeBSD base



-- 
Li-Wen Hsu 
https://lwhsu.org


pgpdHfuwNBFfu.pgp
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

2016-04-04 Thread Baptiste Daroussin 
On Mon, Apr 04, 2016 at 08:25:39PM +0800, Li-Wen Hsu wrote:
> On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote:
> > On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> > > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > > > I've checked this a little more, I found the return code of
> > > > > "installing a installed package" has been changed.
> > > > > 
> > > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > > > consider the build script execution failure.
> > > > > 
> > > > > 
> > > > It shoudl not return 70 if it returns 70 then there is a bug I can fix, 
> > > > I need
> > > > to know more about what is failing to be able to fix
> > > 
> > > What else information do you need?  My experiment is as following:
> > > 
> > > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> > > installed package.  I choose rsync here, then echo $?, it returns 0.
> > > 
> > > And I switch to latest branch, also use `pkg install -y rsync`, but this
> > > time $? is 70.
> > > 
> > > Jenkins "Execute shell" build step checks return value of each command
> > > in the shell script, if it is non-zero, it aborts the build and
> > > considers if failure.
> > 
> > Return 70 means an error occured. if I look at the log I can see that
> > powerpc64-gcc is not installed for sure, hence the error 70
> > 
> > What is strange it that no "error message is shown"
> 
> Very strange, no further error message is shown, even -d provided.
> 
> root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc
> DBG(1)[44393]> pkg initialized
> Updating FreeBSD repository catalogue...
> DBG(1)[44393]> PkgRepo: verifying update for FreeBSD
> DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
> DBG(1)[44393]> Fetch: fetching from: 
> http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts "i"
> DBG(1)[44393]> Fetch: fetching from: 
> http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz with 
> opts "i"
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
> DBG(1)[44393]> want to get an advisory lock on a database
> DBG(1)[44393]> release an advisory lock on a database
> root@jenkins10a:~ # echo $?
> 70
> 
> Is there anything I can help on debugging this?
> 
pkg info amd64-xtoolchain-gcc please

Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

2016-04-04 Thread Li-Wen Hsu 
On Mon, Apr 04, 2016 at 12:53:16 +0200, Baptiste Daroussin wrote:
> On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> > On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > > I've checked this a little more, I found the return code of
> > > > "installing a installed package" has been changed.
> > > > 
> > > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > > consider the build script execution failure.
> > > > 
> > > > 
> > > It shoudl not return 70 if it returns 70 then there is a bug I can fix, I 
> > > need
> > > to know more about what is failing to be able to fix
> > 
> > What else information do you need?  My experiment is as following:
> > 
> > On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> > installed package.  I choose rsync here, then echo $?, it returns 0.
> > 
> > And I switch to latest branch, also use `pkg install -y rsync`, but this
> > time $? is 70.
> > 
> > Jenkins "Execute shell" build step checks return value of each command
> > in the shell script, if it is non-zero, it aborts the build and
> > considers if failure.
> 
> Return 70 means an error occured. if I look at the log I can see that
> powerpc64-gcc is not installed for sure, hence the error 70
> 
> What is strange it that no "error message is shown"

Very strange, no further error message is shown, even -d provided.

root@jenkins10a:~ # pkg -d install -y devel/amd64-xtoolchain-gcc
DBG(1)[44393]> pkg initialized
Updating FreeBSD repository catalogue...
DBG(1)[44393]> PkgRepo: verifying update for FreeBSD
DBG(1)[44393]> Pkgrepo, begin update of '/var/db/pkg/repo-FreeBSD.sqlite'
DBG(1)[44393]> Fetch: fetching from: 
http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/meta.txz with opts "i"
DBG(1)[44393]> Fetch: fetching from: 
http://pkgmir.pkg.freebsd.org/FreeBSD:10:amd64/latest/packagesite.txz with opts 
"i"
FreeBSD repository is up-to-date.
All repositories are up-to-date.
DBG(1)[44393]> want to get an advisory lock on a database
DBG(1)[44393]> release an advisory lock on a database
root@jenkins10a:~ # echo $?
70

Is there anything I can help on debugging this?

Li-Wen


-- 
Li-Wen Hsu 
https://lwhsu.org


pgpeYe5_Z1goK.pgp
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

2016-04-04 Thread Baptiste Daroussin 
On Mon, Apr 04, 2016 at 06:39:00PM +0800, Li-Wen Hsu wrote:
> On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> > On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > > I've checked this a little more, I found the return code of
> > > "installing a installed package" has been changed.
> > > 
> > > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > > consider the build script execution failure.
> > > 
> > > 
> > It shoudl not return 70 if it returns 70 then there is a bug I can fix, I 
> > need
> > to know more about what is failing to be able to fix
> 
> What else information do you need?  My experiment is as following:
> 
> On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
> installed package.  I choose rsync here, then echo $?, it returns 0.
> 
> And I switch to latest branch, also use `pkg install -y rsync`, but this
> time $? is 70.
> 
> Jenkins "Execute shell" build step checks return value of each command
> in the shell script, if it is non-zero, it aborts the build and
> considers if failure.

Return 70 means an error occured. if I look at the log I can see that
powerpc64-gcc is not installed for sure, hence the error 70

What is strange it that no "error message is shown"

Best regards,
Bapt


signature.asc
Description: PGP signature

Re: FreeBSD_HEAD_amd64_gcc - Build #1144 - Failure

2016-04-04 Thread Li-Wen Hsu 
On Mon, Apr 04, 2016 at 00:50:14 +0200, Baptiste Daroussin wrote:
> On Mon, Apr 04, 2016 at 04:41:47AM +0800, Li-Wen Hsu wrote:
> > I've checked this a little more, I found the return code of
> > "installing a installed package" has been changed.
> > 
> > For pkg 1.6.4_1, it returns 0, but 1.7.1 returns 70, thus jenkins
> > consider the build script execution failure.
> > 
> > 
> It shoudl not return 70 if it returns 70 then there is a bug I can fix, I need
> to know more about what is failing to be able to fix

What else information do you need?  My experiment is as following:

On a machine uses quarterly branch, where pkg is 1.6.4_1, install a
installed package.  I choose rsync here, then echo $?, it returns 0.

And I switch to latest branch, also use `pkg install -y rsync`, but this
time $? is 70.

Jenkins "Execute shell" build step checks return value of each command
in the shell script, if it is non-zero, it aborts the build and
considers if failure.


Regards,
Li-Wen

-- 
Li-Wen Hsu 
https://lwhsu.org


pgp4Q687kR8Pv.pgp
Description: PGP signature