Marcin Cieslak | 30 Jun 10:19 2015

Build for profiling? Got //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end'

I am trying to compile instrumented
for profiling. As far as I understand this does not work with clang,
so I am trying with gcc version 4.8.5 20150212 (prerelease) 
(FreeBSD Ports Collection).

This is a shared library in C++ that gets loaded by node (www/node).

I have a world built with profiling libraries, I have additionally
ran "make install INSTALL_PIC_ARCHIVE=yes" in lib/libc, lib/msun
and lib/libcxxrt directories (the latter probably not needed).

Here's config.log output:

configure:3344: checking whether the C++ compiler works
configure:3366: g++48 -pg -g   conftest.cpp  >&5
/usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end'
//lib/ error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
configure:3370: $? = 1
configure:3408: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libsass"
| #define PACKAGE_TARNAME "libsass"
| #define PACKAGE_VERSION "3.2.5-9-gbe07-dirty"
| #define PACKAGE_STRING "libsass 3.2.5-9-gbe07-dirty"
| #define PACKAGE_BUGREPORT "support <at>"
| #define PACKAGE_URL ""
| #define PACKAGE "libsass"
| #define VERSION "3.2.5-9-gbe07-dirty"
(Continue reading)

Julian Elischer | 29 Jun 10:33 2015

libc compile failure with new syscall.

Hi all,

At $JOB we have a few extra syscalls that we have added to our kernel.

After generating the new sysent files in /sys/kern, libc fails to 
compile with:

===> lib/libc (obj,depend,all,install)
building shared library
/usr/bin/ld: rlk_check_offline.So: relocation R_X86_64_32 against 
`SYS_rlk_check_offline' can not be used when making a shared object; 
recompile with -fPIC
rlk_check_offline.So: could not read symbols: Bad value
*** [] Error code 1

this suggests that the code that generates the libc syscall stubs is 
generating something the linker doesn't like.

the definition of the syscall is:

588     AUE_NULL        NOSTD   { int rlk_check_offline(char *localfs, 
char *path, \
                                     int *is_offline, int rlk_flags, \
                                     int *cache_status); }
which generates (in various files):
         { AS(rlk_check_offline_args), (sy_call_t *)lkmressys, 
AUE_NULL, NULL, 0, 0, 0, SY_THR_ABSENT }, /* 588 = rlk_check_offline */
(Continue reading)

Eric McCorkle | 28 Jun 16:19 2015

Re: EFI ZFS loader successful load and boot

On 06/28/2015 01:39 AM, Andrey Fesenko wrote:

> Unable to load the kernel, i'm make simple gpart structure
> efi part  <- write /boot/loader.efi as efi/boot/bootx64.efi
> ZFS root pool

Just saw this part.  You want to write /boot/boot1.efi to
efi/boot/bootx64.efi, not loader.

Eric McCorkle | 28 Jun 16:16 2015

Re: EFI ZFS loader successful load and boot

Looking at your screenshots, it looks like the ZFS pool is being
detected, but not initialized correctly.

Are you certain you have the latest version of the patch?  This looks
similar to errors I was getting earlier in development, before I figured
out the code for setting everything up correctly.

On 06/28/2015 01:39 AM, Andrey Fesenko wrote:
> On Tue, Jun 9, 2015 at 1:59 AM, Eric McCorkle <eric <at>> wrote:
>> OK, finally got time to turn the knobs.  This patch should make it
>> through a buildworld.
>> I will at some point add functionality to boot1 to actually check the
>> partition type GUIDs.
>> That aside, this is ready for testing, and I've been EFI-booting a ZFS
>> partition from GRUB using this patch for a while now.
>> On 05/26/2015 10:22 AM, Garrett Cooper wrote:
>>>> On May 26, 2015, at 05:34, Eric McCorkle <eric <at>> wrote:
>>>> Updates: with a new kernel, and the vt terminal, this works fine.
>>>> Unfortunately, the patch doesn't seem to work with a buildworld build (I was doing make from within the
directories). This is related to a hack I do of copying zfs.c into the efi loader directory so it can be built
with fPIC. The build system seems to get tripped up in mkdep as a result.
>>>> Could someone with more knowledge of the build system give me some pointers here? Otherwise, is all set
for testing.
(Continue reading)

Sean Bruno | 28 Jun 00:02 2015

sysctl(3) man page examples

Hash: SHA512

sysctl(3) specifies three easy to understand examples.

The first appears to depend on a FreeBSD libc() function or library that
is missing, "printkproc()".  Is this a deprecated/deleted function from
the past?

The second example works just fine.

The third accesss user.cs_path which seems to be empty across all
platforms.  I'm not sure if we should replace this example with
something more meaningful(that is to say that its proper for
user.cs_path to be empty) or if there is a bug causing user.cs_path to
be empty.

Version: GnuPG v2

(Continue reading)

Pratik Singhal | 20 Jun 09:19 2015

How to test for memory corruption ?

Hello, I have written code for adding support for DMA transfers for
Allwinner A10 SoC (Cubieboard 1) in MMC driver/

I have tried transferring files to/from mmc card and verified that files
are copied fine.
Although, many times the kernel panics suddenly, after I transfer files.
This does not happen If I use PIO to transfer data (PIO's code is tested
and already committed to ~HEAD). Panics don't occur in the statements
written for DMA transfer.

I am suspecting that the problem is that the DMA transfer apart from
writing where it is required, is overwriting other parts of the memory

Is there any way, I can verify that this is/this is not the case ?

Thank you,
Pratik Singhal
freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"

Brandon Valentine | 19 Jun 18:03 2015

debugging ATA command timeouts on 10.1-RELEASE

[ Starting with -hackers before a possible PR. If there's a better place
for this thread please advise. ]


I have an older Soekris net4801 with a NatSemi SC1100 ATA chipset. Runs
great under FreeBSD 8.3, but 10.1-RELEASE-p13 spews the following error, in
a loop, upon boot:

(aprobe0:ata0:0:1:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ata0:0:1:0): CAM status: Command timeout
(aprobe0:ata0:0:1:0): Retrying command

The atapci driver recognizes it as:

atapci0: <National Geode SC1100 ATA33 controller> port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at device 18.2 on pci0

And eventually, after a lot of command timeouts, I will get:

ada0: 16.700MB/s transfers (PIO4, PIO 512bytes)
ada0: 3825MB (7835184 512 byte sectors: 16H 63S/T 7773C)
ada0: Previously was known as ad0

However, the system continues issuing failed ATA_IDENTIFY commands after
this and never succeeds in booting. That ada device being detected there is
a 4GB CompactFlash card. In order to eliminate the possibility that the
hardware or card do not support UDMA, write caching, etc, I am booting this
10.1-RELEASE-p13 kernel with the following kernel hints in loader.conf:

(Continue reading)

Chris Fitch | 19 Jun 15:12 2015

Realtime process CPU starvation

Hello all,

I have a problem that appears to be scheduler/filesystem related and could
use some expert advice. I have a process running at realtime priority 0
under FreeBSD 10.0. The main thread needs to run every 10 ms, and when it
has completed its work, it yields the processor via a nanosleep() call. The
sleep time is computed to be the remainder of the 10 ms period that is not
needed. This mostly works, but there are occurrences where the thread
doesn't run again for an extended period of time. The thread is monitoring
how far behind the realtime target it is and reporting whenever it falls
more than 250 ms behind. I have seen it report anywhere from 270 ms to
almost 2 seconds behind. This was confirmed using an off-cpu dtrace script
with the following results when the thread reported that it fell 500 ms

Off cpu times (milliseconds):

           value  ------------- Distribution ------------- count
              -1 |                                         0
               0 |                                         18
               1 |                                         1
               2 |                                         5
               4 |                                         12
               8 | <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  <at>  42229
              16 |                                         7
              32 |                                         7
              64 |                                         0
             128 |                                         3
             256 |                                         1
(Continue reading)

Sai Prajeeth | 15 Jun 19:48 2015

PMCSTAT Event for counting L1-DCache Hit / Misses


I am not able to find the event that counts the L1 Data cache hits and
misses in pmccontrol -L. Can anyone tell me what the events are so that i
can get the counts using pmcstat ?\

freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"

Don whY | 13 Jun 12:34 2015

PXE boot an XIP image?


Apologies as to whether this belongs here... or on -embedded.  :<

I'd like to PXE boot a kernel then fetch (any choice of protocol)
a *single* image to load into RAM thereafter not requiring any
access to external media to operate.  I.e., as if the image
had resided in the device all along.

A crude approach *might* be something like crunchgen'ing init
with all of the (static linked) binaries that are required
and letting the loaded kernel NFS read (load) that init(1).
Obviously, I'd trim the kernel and other binaries down to the
bare essentials to minimize RAM requirements (as there would be no
swap, etc.)

[I.e., creating a tiny filesystem that simply links every executable
back to this *one* image]

In practice, this won't (?) really work as hoped.  Any pointers on
a proven technique to achieve these results?

freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"

Stefan Andritoiu | 12 Jun 09:50 2015

Are the sched_choose() or tdq_choose() functions called after returning from an interrupt?


When returning from an interrupt, does it switch directly the thread
that was interrupted? Or is the scheduler called to choose a thread to
run (most probable the thread that was interrupted)?

More specifically, are the sched_choose() or tdq_choose() functions
called after returning from an IPI?

Does an interrupt have it's own thread, or does it run in the context
of the interrupted thread as in Linux?

Thank you,
freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"