[Bug 209788] clang fails with "frontend command failed due to signal" when building graphics/graphviz

2016-05-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209788

Bug ID: 209788
   Summary: clang fails with "frontend command failed due to
signal" when building graphics/graphviz
   Product: Base System
   Version: 10.3-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: ventur...@geeklan.co.uk

Created attachment 170720
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=170720&action=edit
script

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 209788] clang fails with "frontend command failed due to signal" when building graphics/graphviz

2016-05-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209788

--- Comment #1 from Sevan Janiyan  ---
Unable to attach source as "413 Request Entity Too Large"
So I've uploaded a copy here: https://www.geeklan.co.uk/files/lab-be86c4.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 209791] To tunefs utilities I added flag for generate new ufsid (unique filesystem id).

2016-05-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209791

Bug ID: 209791
   Summary: To tunefs utilities I added flag for generate new
ufsid (unique filesystem id).
   Product: Base System
   Version: 10.3-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: pavelivol...@gmail.com

Created attachment 170723
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=170723&action=edit
Added G flag.

In the superblock of the filesystem present unique id:

/usr/include/ufs/ffs/fs.h

/*
 * Super block for an FFS filesystem.
 */
struct fs {
...
int32_t  fs_id[2];  /* unique filesystem id */
...

It's may by used to mount filesystem (/dev/ufsid/...).

After duplicating the disc, it is necessary to change it, to restore the
uniqueness drives.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 202097] [EFI] boot/loader.efi: efinet regression

2016-05-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202097

Ganael LAPLANCHE  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

--- Comment #10 from Ganael LAPLANCHE  ---
This commit fixes boot on X9SRI-F, thanks John !

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 203349] [META] FreeBSD Foundation sponsored project dependencies for FreeBSD 11.0

2016-05-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203349
Bug 203349 depends on bug 202097, which changed state.

Bug 202097 Summary: [EFI] boot/loader.efi: efinet regression
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202097

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 209202] [PATCH] [powermac_thermal] In-Kernel PowerMac fan control does not effectively regulate some quad core models

2016-05-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209202

--- Comment #5 from Mark Millard  ---
(In reply to Mark Millard from comment #4)

Such timing. . .

Looks like the single pump cooling system started dying as of a couple of days
ago (May 25).

Interesting oddities compared to my other exeriences:

A) The problem is intermittent.

B) While it is working normally the CPU diodes for CPU's B0 and B1 are the
cooler 2 of 4 according to sysctl results but it is B0 and/or B1 that start
getting readings in the 90+ degC range when it fails.

C) I've had complete buildworld's with no sign of the problem. Other times it
shuts down fairly soon after starting that or other much smaller builds. (6 or
more 90degC+ readings in a row initiates shutdown.)

Its boot drive is at -r298990 (as of May 5) and it was off from May 6 through
May 21 so it is not a great test of if the -r298990 update had a software
change that might be contributing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 206128] vmstat -z is truncated when stdout is not terminal

2016-05-27 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206128

--- Comment #11 from Phil Shafer  ---
Was finally able to reproduce this and have a fix.  I was using the wrong value
when checking for available buffer space:

diff --git a/libxo/libxo.c b/libxo/libxo.c
index 9df67de..7a714b1 100644
--- a/libxo/libxo.c
+++ b/libxo/libxo.c
@@ -2816,7 +2816,7 @@ xo_format_string (xo_handle_t *xop, xo_buffer_t *xbp,
xo_xff_flags_t flags,
 * but if we did the work ourselves, then we need to do it.
 */
int delta = xfp->xf_width[XF_WIDTH_MIN] - cols;
-   if (!xo_buf_has_room(xbp, delta))
+   if (!xo_buf_has_room(xbp, xfp->xf_width[XF_WIDTH_MIN]))
goto bail;

/*

In addition, I'm adding a high-water mark that will trigger a flush:

@@ -6128,6 +6128,12 @@ xo_do_emit_fields (xo_handle_t *xop, xo_field_info_t
*fields,

 XOIF_CLEAR(xop, XOIF_REORDER);

+/*
+ * If we've got enough data, flush it.
+ */
+if (xo_buf_offset(&xop->xo_data) > XO_BUF_HIGH_WATER)
+   flush = 1;
+
 /* If we don't have an anchor, write the text out */
 if (flush && !XOIF_ISSET(xop, XOIF_ANCHOR)) {
if (xo_write(xop) < 0)

I'll roll a new version of libxo tomorrow.

Apologies for taking so long with this, but it was mostly just an issue of
reproducing it.  I wasn't seeing enough churn in my "vmstat -z" value to
trigger the issue, so I munged one of the regression tests to help.

Thanks,
 Phil

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"