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: > > > --Sig_/eJJPtbrEuK1nN2zIpc7BmVr > > > Content-Type: text/plain; charset=US-ASCII > > > Content-Transfer-Encoding: quoted-printable > > > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > > "O. Hartmann" schrieb: > > > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > > "O. Hartmann" schrieb: > > > >=20 > > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > > Cy Schubert schrieb: > > > > > =20 > > > > > > In message <56f6c6b0.6010...@protected-networks.net>, Michael Butle > r > > > > > > = > > > writes: =20 > > > > > > > -current is not great for interactive use at all. The strategy of > > > > > > > pre-emptively dropping idle processes to swap is hurting .. big > > > > > > > tim= > > > e. =20 > > > > > >=20 > > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to > > > > > > disk.= > > > LRU=20 > > > > > > doesn't do this. > > > > > >=20 > > > > > > >=20 > > > > > > > Compare inactive memory to swap in this example .. > > > > > > >=20 > > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% > > > > > > > i= > > > dle > > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > > > > >=20 > > > > > > To analyze this you need to capture vmstat output. You'll see the > > > > > > fre= > > > e pool=20 > > > > > > dip below a threshold and pages go out to disk in response. If you > > > > > > ha= > > > ve=20 > > > > > > daemons with small working sets, pages that are not part of the > > > > > > worki= > > > ng=20 > > > > > > sets for daemons or applications will eventually be paged out. This > > > > > > i= > > > s not=20 > > > > > > a bad thing. In your example above, the 281 MB of UFS buffers are > > > > > > mor= > > > e=20 > > > > > > active than the 917 MB paged out. If it's paged out and never used > > > > > > ag= > > > ain,=20 > > > > > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. > > > > > > Th= > > > e=20 > > > > > > inactive pages are part of your free pool that were active at one > > > > > > tim= > > > e but=20 > > > > > > now are not. They may be reclaimed and if they are, you've just > > > > > > saved= > > > more=20 > > > > > > I/O. > > > > > >=20 > > > > > > Top is a poor tool to analyze memory use. Vmstat is the better tool > > > > > > t= > > > o help=20 > > > > > > understand memory use. Inactive memory isn't a bad thing per se. > > > > > > Moni= > > > tor=20 > > > > > > page outs, scan rate and page reclaims. > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > > I give up! Tried to check via ssh/vmstat what is going on. Last lines > > > > > b= > > > efore broken > > > > > pipe: > > > > >=20 > > > > > [...] > > > > > procs memory pagedisks faults > cpu > > > > > r b w avm fre flt re pi pofr sr ad0 ad1 insyc > s > > > > > = > > > us sy id > > > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 > > > > > 540= > > > 0 95 5 0 > > > > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40869 > > > > > 345= > > > 9 93 7 0 > > > > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52192 > > > > > 436= > > > 6 91 9 0 > > > > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86209 > > > > > 436= > > > 8 88 12 0 > > > > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 779569 > > > > > 704= > > > 359 87 13 0 > > > > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 507337 > > > > > 484= > > > 861 93 7 0 > > > > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68131 > > > > > 4440= > > > 7 95 5 0 > > > > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99366 > > > > > 3806= > > > 0 89 11 0 > > > > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 99371 > > > > > 49= > > > 99 85 15 0 > > > > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29142 > > > > > 443= > > > 1 95 5 0 > > > > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken pip > e > > > > >=20 > > > > >=20 > > > > > This makes this crap system completely unusable. The server (FreeBSD > > > > > 11= > > > .0-CURRENT #20 > > > > > r297503: Sat Apr 2 09:02:41 CEST 2016 amd64) in question did > > > > > poudriere= > > > bulk job. I > > > > > can not even determine what terminal goes down first - another one, > > > > > muc= > > > h more time > > > > > idle than the one shwoing the "vmstat 5" output, is s
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: quoted-printable > > > > Am Sat, 2 Apr 2016 11:39:10 +0200 > > "O. Hartmann" schrieb: > > > > > Am Sat, 2 Apr 2016 10:55:03 +0200 > > > "O. Hartmann" schrieb: > > >=20 > > > > Am Sat, 02 Apr 2016 01:07:55 -0700 > > > > Cy Schubert schrieb: > > > > =20 > > > > > In message <56f6c6b0.6010...@protected-networks.net>, Michael Butler > > > > > = > > writes: =20 > > > > > > -current is not great for interactive use at all. The strategy of > > > > > > pre-emptively dropping idle processes to swap is hurting .. big > > > > > > tim= > > e. =20 > > > > >=20 > > > > > FreeBSD doesn't "preemptively" or arbitrarily push pages out to > > > > > disk.= > > LRU=20 > > > > > doesn't do this. > > > > >=20 > > > > > >=20 > > > > > > Compare inactive memory to swap in this example .. > > > > > >=20 > > > > > > 110 processes: 1 running, 108 sleeping, 1 zombie > > > > > > CPU: 1.2% user, 0.0% nice, 4.3% system, 0.0% interrupt, 94.5% > > > > > > i= > > dle > > > > > > Mem: 474M Active, 1609M Inact, 764M Wired, 281M Buf, 119M Free > > > > > > Swap: 4096M Total, 917M Used, 3178M Free, 22% Inuse =20 > > > > >=20 > > > > > To analyze this you need to capture vmstat output. You'll see the > > > > > fre= > > e pool=20 > > > > > dip below a threshold and pages go out to disk in response. If you > > > > > ha= > > ve=20 > > > > > daemons with small working sets, pages that are not part of the > > > > > worki= > > ng=20 > > > > > sets for daemons or applications will eventually be paged out. This > > > > > i= > > s not=20 > > > > > a bad thing. In your example above, the 281 MB of UFS buffers are > > > > > mor= > > e=20 > > > > > active than the 917 MB paged out. If it's paged out and never used > > > > > ag= > > ain,=20 > > > > > then it doesn't hurt. However the 281 MB of buffers saves you I/O. > > > > > Th= > > e=20 > > > > > inactive pages are part of your free pool that were active at one > > > > > tim= > > e but=20 > > > > > now are not. They may be reclaimed and if they are, you've just > > > > > saved= > > more=20 > > > > > I/O. > > > > >=20 > > > > > Top is a poor tool to analyze memory use. Vmstat is the better tool > > > > > t= > > o help=20 > > > > > understand memory use. Inactive memory isn't a bad thing per se. > > > > > Moni= > > tor=20 > > > > > page outs, scan rate and page reclaims. > > > > >=20 > > > > >=20 > > > >=20 > > > > I give up! Tried to check via ssh/vmstat what is going on. Last lines > > > > b= > > efore broken > > > > pipe: > > > >=20 > > > > [...] > > > > procs memory pagedisks faults cpu > > > > r b w avm fre flt re pi pofr sr ad0 ad1 insycs > > > > = > > us sy id > > > > 22 0 22 5.8G 1.0G 46319 0 0 0 55721 1297 0 4 219 23907 > > > > 540= > > 0 95 5 0 > > > > 22 0 22 5.4G 1.3G 51733 0 0 0 72436 1162 0 0 108 40869 > > > > 345= > > 9 93 7 0 > > > > 15 0 22 12G 1.2G 54400 0 27 0 52188 1160 0 42 148 52192 > > > > 436= > > 6 91 9 0 > > > > 14 0 22 12G 1.0G 44954 0 37 0 37550 1179 0 39 141 86209 > > > > 436= > > 8 88 12 0 > > > > 26 0 22 12G 1.1G 60258 0 81 0 69459 1119 0 27 123 779569 > > > > 704= > > 359 87 13 0 > > > > 29 3 22 13G 774M 50576 0 68 0 32204 1304 0 2 102 507337 > > > > 484= > > 861 93 7 0 > > > > 27 0 22 13G 937M 47477 0 48 0 59458 1264 3 2 112 68131 > > > > 4440= > > 7 95 5 0 > > > > 36 0 22 13G 829M 83164 0 2 0 82575 1225 1 0 126 99366 > > > > 3806= > > 0 89 11 0 > > > > 35 0 22 6.2G 1.1G 98803 0 13 0 121375 1217 2 8 112 99371 > > > > 49= > > 99 85 15 0 > > > > 34 0 22 13G 723M 54436 0 20 0 36952 1276 0 17 153 29142 > > > > 443= > > 1 95 5 0 > > > > Fssh_packet_write_wait: Connection to 192.168.0.1 port 22: Broken pipe > > > >=20 > > > >=20 > > > > This makes this crap system completely unusable. The server (FreeBSD > > > > 11= > > .0-CURRENT #20 > > > > r297503: Sat Apr 2 09:02:41 CEST 2016 amd64) in question did > > > > poudriere= > > bulk job. I > > > > can not even determine what terminal goes down first - another one, > > > > muc= > > h more time > > > > idle than the one shwoing the "vmstat 5" output, is still alive!=20 > > > >=20 > > > > i consider this a serious bug and it is no benefit what happened since > > > > = > > this "fancy" > > > > update. :-( =20 > > >=20 > > > By the way - it might be of interest and some hint. > > >=20 > > > One of my boxes is acting as server and gateway. It utilises NAT, IPFW, > > > w= > > hen it is under > > > high load, as it was to
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 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. Is there any documentation on the ThunderX PCI access mechanisms ? > > (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.).) Why cannot you use MGTDEVICE pager already ? Driver would need to maintain its private list of pages, and from this PoV, a convenience wrapper around MGTDEVICE which unifies operations on sg lists could be useful. Still, it could be that the wrapper appear to be single-purpose. ___ 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 ?
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 /dev/mem did not have the issue ever. The problem was only with the read(2)/write(2) accesses. >From what I understand, since the goal of the OP was to measure BAR access latencies, read(2) (or write) is unsuitable for him for obvious reasons. ___ 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"
D3702: add support for Bluetooth Magic Mouse
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 ?
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 ?
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 ?
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?
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
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 (&group[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(&node->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, &parent->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(&parent->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
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
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
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
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
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
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
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