R0B_ROD | 4 Mar 12:17 2015
Picon

ports/audio/alsa-lib Error code 74

Hello, 
First ld could not find python.
I removed a $.

Now the following: Dunno what to do.

PS: Thanks to all for such amazing software! FreeBSD rocks!
Willing to be a tester. I have this hobby of breaking things ;)

-Roberto Rodriguez Jr

/*
# diff Makefile.R0B Makefile.11.0-CURRENT 
18c18                                                                           
< CONFIGURE_ARGS=       --with-pkgconfdir="\${prefix}/libdata/pkgconfig"        
---                                                                             
> CONFIGURE_ARGS=       --with-pkgconfdir="\$${prefix}/libdata/pkgconfig"

# make install clean                      
===>  Installing for alsa-lib-1.0.29                                            
===>  Checking if alsa-lib already installed                                    
===>   Registering installation for alsa-lib-1.0.29                             

pkg-static: Unable to access file /usr/ports/audio/alsa-lib/work/stage/usr/local
/libdata/pkgconfig/alsa.pc: No such file or directory                           
*** Error code 74                                                               
Stop.                                                                           
make[1]: stopped in /usr/ports/audio/alsa-lib                                   
*** Error code 1                                                                
Stop.                                                                           
(Continue reading)

Tomoaki AOKI | 4 Mar 12:07 2015
Picon

sysutils/lsof does not build (maybe) after r279433

Hi.

Today I upgraded my -head (amd64) VM from r279417 to r279579, and
sysutils/lsof does not build any more.

Looking into build log (attached), it seems that r279433 broke build.
(Not actually bi-sected)

Fix:
 Not known. But maybe renaming asprintf() and vasprintf() in
 sys/sys/systm.h and its consumers to avoid conflicts would help from
 base side. Can sysutils/lsof side support this?

--

-- 
Tomoaki AOKI    junchoon <at> dec.sakura.ne.jp
Attachment (lsof_20150304.log): application/octet-stream, 8 KiB
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"
Jean-Sébastien Pédron | 3 Mar 23:33 2015
Picon

[Call for testers] DRM device-independent code update to Linux 3.8 (take #2)

Hi!

Here is a new patch to based on HEAD r279508:
    https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch

You can apply it to a Subversion checkout using the following command:
    svn patch drm-update-38.i.patch

There are few changes:
    o  The panic reported by J.R. Oldroyd is fixed, but not the CP init
       problem.
    o  A lock assert was added, suggested by Konstantin Belousov

I had several panics ("Stray timeout") with a taskqueue used by TTM, but
it didn't occur in the past 6 days. Maybe it was a problem outside of DRM.

I would like people to test again and report :) If something fails,
please post a full dmesg, taken after loading the relevant *kms module,
or the core.txt.$N file if it's a panic.

Hans Petter and Ed, I couldn't reproduce neither of your problems (HDMI
hotplug events storm and VT-switch misbehaviour). However, they both
involve callouts, like the "Stray timeout" panic I had with TTM. I
suspect there was a transient problem with callouts in HEAD at the same
time. Could you please test again with this patch and a very recent HEAD?

Thank you to everyone!

--

-- 
Jean-Sébastien Pédron
(Continue reading)

jenkins-admin | 3 Mar 06:01 2015
Picon

Jenkins build became unstable: FreeBSD_HEAD-tests2 #798

See <https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/798/>

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

Adrian Chadd | 2 Mar 21:42 2015
Picon

Doing zero-copy stuff in drivers, or "is vm_fault_quick_hold_pages() enough" ?

Hi,

gonzo <at>  committed a fix (r278615) to the videocore driver for the
raspberry pi. The fix involved doing an explicit wire of pages that
were about to be passed down to the hardware to send to the
videobuffer hardware.

It turns out that doing vm_fault_quick_hold_pages() wasn't enough -
the pages weren't being wired, and they may disappear before the
hardware gets to them.

I looked at vmapbuf() and how it uses vm_fault_quick_hold_pages(), but
I can't find anything that wires the pages down before it hands the
addresses to the hardware.

So, am I missing something about how/where that's done?

Thanks,

-adrian
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

O. Hartmann | 2 Mar 11:50 2015
Picon
Picon

r279514: buildworld failure: /usr/src/lib/libnv/tests/dnv_tests.cc:453:2: error: use of overloaded operator '<<' is ambiguous


Buildworld fails in CURRENT r279514 with the following error:

[...]

--- sbin.all__D ---
--- camcontrol.o ---
cc  -O2 -pipe -O3 -O3 -pipe -march=native  -std=gnu99 -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Qunused-arguments -c /usr/src/sbin/camcontrol/camcontrol.c --- gnu.all__D
--- /usr/src/gnu/usr.bin/rcs/lib/rcsrev.c:750:8: warning: add explicit braces
to avoid dangling else [-Wdangling-else] else { ^ --- lib.all__D
--- /usr/src/lib/libnv/tests/dnv_tests.cc:453:2: error: use of overloaded
operator '<<' is ambiguous (with operand types 'basic_ostream<char,
std::__1::char_traits<char> >' and 'nullptr_t') ATF_REQUIRE_EQ(actual_val,
NULL); --- kerberos5.all__D
--- /usr/src/kerberos5/usr.bin/ksu/../../../crypto/heimdal/appl/su/su.c:437:42:
warning: data argument not used by format string [-Wformat-extra-args] ---
lib.all__D ---
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/obj/usr/src/tmp/usr/include/atf-c++/macros.hpp:114:53:
note: expanded from macro 'ATF_REQUIRE_EQ' << " (" << (expected) << " != " <<
(actual) << ")"; \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~
Sulev-Madis Silber (ketas | 1 Mar 14:33 2015
Picon

Massive libxo-zation that breaks everything

Hello.

First, I would be happy to have JSON and XML output about filesystems,
users, routes... but I don't like how it makes code of df, w, netstat
hard to read/maintain and often broken.

I don't think it would be good to continue with this. Maybe the effort
should be put to creating new layer/library and then something on top of
it that actually outputs JSON and XML.

Or, if that's too difficult... maybe just regular df/w/netstat could be
copied to somewhere else and made code libxo-output-only. And original
df/w/netstat changes reverted and left alone.

Then, maybe later, df/w/netstat/... could be updated to this new
layer/library. Or maybe this should be just left as it is.

That would mean having two netstat's in system, which could be both good
(separation) and bad (maintaining).

Just some ideas... I don't know how to solve this issue fully. I'm also
not likely the one who would write code for all this. Hell, those aren't
even all my ideas here. I just worry that system drop-in xo-zation is
bad for overall health of base.

Oh and, it makes rescue larger and more complex, too? On that, there was
suggestion to maybe create separate "first aid kit" and "emergency room"
types of system rescue utils/methods.

Thanks.
(Continue reading)

Ryan Stone | 1 Mar 03:01 2015
Picon

HEADS UP: PCI SR-IOV infrastructure has been committed to head

I've just finished committing support for PCI Single Root I/O
Virtualization in the pci subsystem to head.  This should be a no-op
for everyone right now, but there were some minor refactorings in the
pci code that could have a lingering bug.  I did make sure to test
that it boots on a variety of systems (but only i386/amd64, as that's
all that I have access to).

What's been committed to head is only the pci subsystem side of
things, along with the userland tools to configure SR-IOV (along with,
I'm happy to say, a full set of man pages).  What's not in head yet
are any drivers making use of the infrastructure.  Full support for
ixl(4) is complete and I've sent the patch to jfv <at> ; I hope to see the
driver support committed soon.  I don't have any word on timelines for
getting support in other drivers.  Unfortunately adding SR-IOV support
to a driver is not trivial as the standard leaves a lot of the details
up to particular implementations (in the same way the the PCIe
standard does not define how to send a packet from a NIC; instead
defining how the PCIe device will expose its registers and whatnot,
and its up to the PCIe device and driver to understand how to poke at
the registers to send a packet).  I have heard anecdotally that a
number of driver maintainers have been very interested in this work so
I hope that to see more drivers supported SR-IOV in the near future.
I encourage all driver maintainers to read over the new manpages and
contact me if they have any questions about the new infrastructure.

Anybody interested in using SR-IOV should try to attend BSDCan 2015,
as I will be giving a talk on the subject.  I intend to focus more on
the system administration side of configuring and using SR-IOV rather
than the details of implementing an SR-IOV driver.

(Continue reading)

jenkins-admin | 28 Feb 23:49 2015
Picon

Build failed in Jenkins: FreeBSD_HEAD #2472

See <https://jenkins.freebsd.org/job/FreeBSD_HEAD/2472/changes>

Changes:

[loos] Add ofw_gpiobus_parse_gpios(), a new public function, to parse the gpios
property for devices that doesn't descend directly from gpiobus.

The parser supports multiple pins, different GPIO controllers and can use
arbitrary names for the property (to match the many linux variants:
cd-gpios, power-gpios, wp-gpios, etc.).

Pass the driver name on ofw_gpiobus_add_fdt_child().  Update gpioled to
match.

An usage example of ofw_gpiobus_parse_gpios() will follow soon.

[kib] Supposed fix for some SandyBridge mobile CPUs hang on AP startup when
x2APIC mode is detected and enabled.  Current theory is that switching
the APIC mode while an IPI is in flight might be the issue.

Postpone switching to x2APIC mode until we are guaranteed that all
starting IPIs are already send and aknowledged.  Use aps_ready signal
as an indication that the BSP is done with us.

Tested by:	adrian
Sponsored by:	The FreeBSD Foundation
MFC after:	2 months

[kan] Avoid closing unallocated socket in case socreate fails.

(Continue reading)

Ryan Stone | 28 Feb 22:25 2015
Picon

atkbd.c not compiling?

I updated my source tree this morning and now I'm seeing this compile
error in "make tinderbox";

/repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:382:26: error: use of undecla
red identifier 'key_map'; did you mean 'keymap'?
                keymap = malloc(sizeof(key_map), M_DEVBUF, M_NOWAIT);
                                       ^~~~~~~
                                       keymap
/repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:358:12: note: 'keymap' declar
ed here
        keymap_t *keymap;
/repos/users/rstone/freebsd/sys/dev/atkbdc/atkbd.c:383:26: error: use of undecla
red identifier 'accent_map'; did you mean 'accentmap_t'?
                accmap = malloc(sizeof(accent_map), M_DEVBUF, M_NOWAIT);
                                       ^
/repos/users/rstone/freebsd/sys/sys/kbio.h:210:26: note: 'accentmap_t' declared
here
typedef struct accentmap accentmap_t;

(By the way, this is the second time in two days that "make tinderbox"
has been broken for me.  It's extremely frustrating that I can't test
my pending commits because others haven't done me the same courtesy)
_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"

jenkins-admin | 27 Feb 22:07 2015
Picon

Jenkins build became unstable: FreeBSD_HEAD-tests2 #780

See <https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/780/>

_______________________________________________
freebsd-current <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at> freebsd.org"


Gmane