Stefan Esser | 21 Aug 09:29 2014

[PATCH] Missing references to vt(4) "NEWCONS" in man-pages


the attached patch, also available from

contains changes to man pages that reference syscons(4), but so far do
not mention vt(4).  This should be fixed for 10.1, where vt(4) is in
the GENERIC kernel.

The following man-pages have been identified to contain references to

share/man/man4/terasic_mtl.4 (does this driver work with vt???)



(Continue reading)

Littlefield, Tyler | 21 Aug 01:20 2014

Making this Makefile work on FreeBSD

Hello all:
I'd really like to be able to say that this compiles with FreeBSD. when 
I use make, there are some issues; would anyone be able to look at this 
and provide some pointers for making this compile both on Linux and 


Take care,
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.

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

Wojciech Puchar | 21 Aug 01:08 2014

syslog receiving data by UDP from windows with nxlog

i configured nxlog on windows machine to send logs to FreeBSD.

checked with tcpdump windows actually send logs like this:

2014-08-21 00:50:17 winserver1 INFO 7036 Usluga nxlog weszla w stan uruchomienia.

this way:

00:50:27.995832 IP > [|syslog]

syslogd is run this way
/usr/sbin/syslogd -vn -b -a

and syslog.conf is like this

*.*				-/var/log/messages

nothing is logged.

to test things - i configured syslog from other FreeBSD computer to send 
logs to - works fine.

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

(Continue reading)

Elliot Robinson | 20 Aug 19:29 2014

root-on-ZFS - gptzfsboot fails to find pool

G'day all,
A fresh root-on-ZFS install using bsdinstall's ZFS option on FreeBSD 10
fails to boot on my Dell Studio XPS 1640. Output at boot is

gptzfsboot: error 1 lba 48
gptzfsboot: error 1 lba 1
gptzfsboot: No ZFS pools located, can't boot

Things I've tried:
  * ZFS with GPT - Fails with error above
  * ZFS with MBR - Fails with no output (doesn't find 2nd stage?)
  * UFS with GPT - Works
  * Different HDD/SDD - No change, fails with error above
  * USB thumb drive on VirtualBox with ZFS/GPT - Works

This system has not had FreeBSD on it before, though the guided
partitioning UFS/GPT install seems to work as expected.

I'm about at the point where I have to sprinkle printf's all through
zfsboot.c and trace what's going on, so any help is appreciated.

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

(Continue reading)

Dieter BSD | 19 Aug 21:21 2014

stopped processes using cpu?

8.2 on amd64
Top(1) with no arguments reports that some firefox processes are using cpu
dispite being stopped (via kill -stop pid) for at least several hours.
Adding -C doesn't change the numbers.  Ps(1) reports the same.
Interestingly, a firefox that isn't stopped is (correctly?) reported as
using 0 cpu.  The 100% idle should be correct, but who knows.

last pid: 51932;  load averages:  0.07, 0.99, 1.42 up 14+19:02:56  08:48:28
267 processes: 1 running, 138 sleeping, 128 stopped
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 1665M Active, 653M Inact, 240M Wired, 95M Cache, 372M Buf, 815M Free
Swap: 8965M Total, 560K Used, 8965M Free

44188 a           9  44    0   303M   187M STOP   113:19 13.43% firefox-bin
92986 b          11  44    0   164M 62848K STOP     0:18  5.03% firefox-bin
16507 c          11  44    0   189M 88976K STOP     0:13  0.24% firefox-bin
 2265 root        1  44    0   248M   193M select 625:38  0.00% Xorg
51271 d          10  44    0   233M   128M ucond   12:12  0.00% firefox-bin
freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"

Chris H | 19 Aug 19:26 2014

How to explicitly disable use of clang in ports Makefile?

 I'm on RELENG_8, and RELENG_9, so don't have access to recent versions
of clang. I'm maintaing several ports, and I'm currently dealing with
one that fails with the use of clang. While I plan to update one of my
"dev boxes" to 11, and start working with clang. Until then, where
clang is concerned, I'm guessing, at best. So can anyone tell me how to
ensure that clang is never considered for making my port?
my CXX = g++.
My port builds, and installs flawlessly on anything <=9. But because
anything >=10 uses clang, by default. I'm failing on those. I've
had a look at /usr/ports/MK/Uses/ But can't seem to unwind
the conditional(s) for my use needs.

Thank you for all your time, and consideration.


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

Stefan Esser | 19 Aug 10:27 2014

Opinions thought regarding: NEWCONS, rc.conf and rc.d/syscons

As you all probably know, 10.1 will ship with both SYSCONS and NEWCONS.

I'm working keymap files for NEWCONS (translated from those in SYSCONS),
and they'll need to be named differently than before.

The SYSCONF keymap names in rc.conf will not work for NEWCONS.  They
include an encoding scheme in their name, while NEWCONS universally
uses Unicode.

There are a few points that still need to be considered for 10.1:

a) Is rc.d/syscons still an appropriate name when using NEWCONS?
   (I'd leave it unchanged, but I thought I'd ask ...)

b) Do we need to identify NEWCONS vs. SYSCONS in the messages printed
   by that rc script? (I guess this might be a good idea.)

c) Do we expect to warn the user when he has a SYSCONS keymap name
   specified in the rc.conf "keymap" variable, while using NEWCONS?
   (This might be a good idea, at least when the default is to use
   NEWCONS and the user might not be aware of the change.)

d) Do we want to provide the user with an information regarding the
   name of the SYSCONS keymap configured, to ease the transition?
   (Could be done ...)

e) Do we want the rc script to translate the SYSCONS keymap name
   to its new form? (This might be good for people using foreign
   keyboards, if their password uses characters located at other
   positions than on the default keymap, that will be used if no
(Continue reading)

Lev Serebryakov | 18 Aug 18:36 2014

Build ARM ports on amd64 with qemu-arm-static and "native" cross-toolchain - how to?

Hello, Hackers.

  I'm trying to setup chroot environment to build ARMv6 ports on amd64 host.
 I'm using this instructions:

  It works with fully-emulated environment. But when I try to add native
 cross-toolchain (according to "Cross Building Using the Host Cross
 Compiler (and other toolchain friends):" section) it fails to build
 anything with cc complaining about absent "crt0.o".

  Are these instructions up-to-date? What do I do wrong?


// Black Lion AKA Lev Serebryakov <lev <at>>

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

Pokala, Ravi | 18 Aug 01:31 2014

Common storage of original MAC address

Hi folks,

At attach-time, the NIC drivers call ether_ifattach(), which stores the
MAC address in the sockaddr_dl. If the MAC is subsequently changed (like
by adding the interface to a lagg), if_setlladdr() changes the value in
the sockaddr_dl. At least, that's the way I'm reading things - is that

If so, then we do not keep a copy of the original MAC address. For a
couple of reasons (diagnostics, asset tracking and reporting), it would be
very nice if the original MAC were kept somewhere, even after the working
MAC was changed by if_setlladdr().

Up till now, Panasas has been saving the original MAC in the softc of
specific network drivers that we use, and making it accessible via a
sysctl. That's something we have to do on a per-driver basis, and
something we have to keep track of on our own. We'd like to put that
information in a structure all the NIC drivers already use, and get that
code upstream. Storing it would require a simple change to
ether_ifattach() to stash it in the new location in addition to in the
sockaddr_dl, and adding some standard way (a new ioctl or sysctl?) to
access it. Notably, it would not require changing all the individual

Are there any objections to this idea? Any suggestions as to where we
might stash the original MAC?


(Continue reading)

Stefan Esser | 17 Aug 22:08 2014

Re: Keymap definitions for VT / NEWCONS

Am 15.08.2014 um 09:14 schrieb Erik Cederstrand:
> Den 14/08/2014 kl. 23.40 skrev Stefan Esser <se <at>>:
>>> The worry I have with using locale names is that it implies there is a
>>> 1:1 mapping, which is sometimes true and sometimes not.
>> Do you know about cases where this is the case?
> Some years ago, I contributed a Danish Macbook keyboard layout which
> is considerably different from the standard Danish PC keyboard
> layout. I use it in Virtualbox VMs on my Danish Macbook.

Your keymap is now available as "dk.macbook.kbd" (the ".kbd" can be
ommitted in the keymap variable in "rc.conf").

Please test and report any regressions, if you have already switched
over to NEWCONS.

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

Alexander V. Chernikov | 17 Aug 00:25 2014

SIOCGI2C ioctl for NIC drivers

Hello list.

It seems that networking is evolving quite rapidly, so 10g nics are
quite common: we have Intel, Chelsio, Mellanox, Emulex, Solarflare and
Myricom drivers in our tree (maybe some others). 40G are also here:
(Chelsio, Mellanox, Intel). Things like 25G NICs are also getting more
interest. Most of them uses SFP+/QSPF+ (either for short range optics or
passive/active twinax cabling) and we can improve diagnostics here by
providing standard way to request i2c data (like vendor info and signal
levels) from transceivers.

Chelsio and Intel drivers already provide methods to retrieve those
info, but in a different way.

I'd like to add SIOCGI2C as standard ioctl for that, picking value like
61, if there are no objections.

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