Re: Import rcorder-visualize.sh from NetBSD?

Go ahead. On Mon, Dec 5, 2016 at 11:16 AM, Eric van Gyzen wrote: > Would anyone object to me importing this script from NetBSD? > > http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sbin/rcorder/rcorder-visualize.sh?rev=1.5=text/plain > > I ask in particular because of the

Re: r308432: Capsicumized `basename` make zsh prompt broken

Hello Iblis, Please try reinstalling libcapsicum after r309366, rebuilding basename, and then removing the stdout kludge from your shell script. Let me know if there's still a problem! Thanks, Conrad On Sun, Nov 27, 2016 at 11:08 PM, Conrad Meyer <c...@freebsd.org> wrote: > Hi Iblis, &

Re: r308432: Capsicumized `basename` make zsh prompt broken

Hi Conrad, >Thanks for your reply. > >I revert the basename.c and `< /dev/null` do the trick! >I'm also curious that will `caph_limit_stdio` break lots of program work > with some shell scripts? > > -- > Iblis Lin > > > On 11/28/2016 12:55, Conrad Meyer wrote

Re: r308432: Capsicumized `basename` make zsh prompt broken

Hi Iblis, I see no such problem running 'basename $HOME' in a normal shell environment: > $ basename $HOME > cmeyer I suppose in your use, perhaps stdin is already closed? I think this is a limitation of caph_limit_stdio() in general. Can you try instead: function set_prompt {

Re: svn commit: r309144 - in head: lib/libipsec sys/net sys/netipsec [-r309174 does not fix everything]

Hi Mark, I believe this was addressed by Scott Long in r309201. r309174 (an incomplete fix for the same problem) can probably be reverted. Best, Conrad On Sun, Nov 27, 2016 at 6:34 PM, Mark Millard wrote: > key_debug.c is not the only place with problems : The below is >

Re: /head/sys/kern/kern_timeout.c breaks build on current amd64

Fixed in r304245. Thanks! On Tue, Aug 16, 2016 at 3:52 PM, Manfred Antar wrote: > New commit to current breaks build amd64: > > /usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. > -I../../.. -I../../../contrib/libfdt -D_KERNEL

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

The OpenSSH defaults are intentionally sane. RSA 2048 is anticipated to be fine for the next 10 years. It would not be a bad choice. I'm not aware of any reason not to use EC keys, and presumably the openssh authors wouldn't ship them as an option if they knew of any reason to believe they were

Re: SafeStack in base

On Wed, Jul 27, 2016 at 5:05 PM, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > On Wed, Jul 27, 2016 at 05:02:07PM -0700, Conrad Meyer wrote: >> The problem appears to be an upstream limitation of >> -fsanitize=safe-stack: "Most programs, static libraries, or individua

Re: SafeStack in base

On Wed, Jul 27, 2016 at 3:55 PM, Shawn Webb wrote: > Hey All, > > I'm interested in getting SafeStack working in FreeBSD base. Below is a > link to a simplistic (maybe too simplistic?) patch to enable SafeStack. > The patch applies against HardenedBSD's

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

Maybe Tier 2 can deal with just bootonly.iso. Or your machines should be dropped from Tier 2 if they don't support USB and we aren't okay with dropping disc1 support for all of Tier 2. There's lots of aging hardware we don't support in modern FreeBSD, including alpha and ia64. USB is 20 years

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

DVD-R dates to 1997; cheap USB flash devices are now pervasive. Maybe it's time to move on from CD. Best, Conrad On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop wrote: > Hi, > > Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on > Windows 10. It complained

Re: clang 3.3/3.4 fails to build items that use stdlib.h because of __alloc_size attribute assigned to posix_memalign

Whoops, missed reply-all the first time. It seems pretty clear that alloc_size (return value is a memory allocation of size from parameter N) does not apply to posix_memalign, because posix_memalign's allocation is stored via a pointer argument rather than return value.

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

I expect it's because: 1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t == unsigned long)) 2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1) (an array of nmemb=bitstr_size() size=bytes, doesn't have to be 'unsigned long' sized or aligned). 3. Various bit_*

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

FYI, this implies the ulong-accessed bitstring change is ABI-breaking for ARM userspace and maybe shouldn't go to stable/10. Best, Conrad On Mon, Jun 13, 2016 at 11:04 AM, Conrad Meyer <c...@freebsd.org> wrote: > I expect it's because: > > 1. bitstr_size() is just bytes (d

Re: thread suspension when dumping core

On Mon, Jun 6, 2016 at 7:46 PM, Konstantin Belousov wrote: > On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote: >> On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote: >> > Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ?

Re: Interesting error during installworld

FreeBSD has tail(1). Does HardenedBSD remove it? Or is /usr/bin missing from your PATH? On Sun, May 22, 2016 at 1:21 PM, Shawn Webb wrote: > Hey All, > > I’m getting this error when doing `make installworld` on recent builds of > HEAD. It seems that the error is

Re: r299512 breaks dhclient on some networks

On Wed, May 18, 2016 at 5:19 PM, Don Lewis wrote: > > It looks to me like r299512 is changing the format of the client > identifier by inserting the struct hardware hlen field into it. Yes. The problem with r299512 is that it assumed the client_id was actually a valid

Re: r299512 breaks dhclient on some networks

Hey Ian, r299512 incorrectly encoded client identifiers because I misunderstood the intent of the sizeof()-scaled client_id. I reverted that change and replaced it with r300174, which I believe fixes the first overrun more correctly. (Coverity may still complain about CID 1305550, but I don't

Re: CFR: extend use of nitems() macro in the kernel.

On Sat, Apr 16, 2016 at 11:25 AM, Pedro Giffuni wrote: > Hello; > > Using coccinelle, and some hand re-formatting, I generated a patch to > make use of the nitems() macro in sys, which is too big for > phabricator [1]. > > I was careful to exclude anything from the contrib

Re: Heads up

Max, If you implement a new IO scheduler you can name it whatever you like. "NG" isn't any more meaningful than "Netflix." Best, Conrad On Fri, Apr 15, 2016 at 9:13 AM, Maxim Sobolev wrote: > Great, work Warner, thanks! Small note, though. The CAM_IOSCHED_NETFLIX > seems

Re: sdhci_pci.ko fails to load

Try 'kldload mmc' first. 'sdhci_pci' is missing a MODULE_DEPEND on mmc. Best, Conrad On Sun, Mar 20, 2016 at 2:14 PM, Guido Falsi wrote: > Hi, > > I've just noticed a regression. > > I have been using mmc.ko, mmcsd.ko and sdhci.ko to use the integrated > SSD card reader on

Re: boot loaders got fatter in the last few days

On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude wrote: > On 2016-03-18 12:33, Guido Falsi wrote: >> >> Hi, >> >> I have just update one of my machines and noticed the booloaders files >> got quite fat in the last few days, some by a big margin. >> >> on an updated

Re: Could somebody just commit this patch: The new command line option to set the daemon(8) process title ?

Committed in r296321, thanks! On Wed, Mar 2, 2016 at 11:02 AM, Yuri <y...@rawbw.com> wrote: > On 02/29/2016 15:05, Conrad Meyer wrote: >> >> I'd be happy to (+ manual page changes) if I don't hear any objection >> in the next few days. I would keep [pid] in the titl

Re: WLAN hardware not recognized

"[1] iwn0: mem 0xf7b0-0xf7b01fff irq 18 at device 0.0 on pci3" is fine; "module iwn already present!" is fine. What makes you say it isn't recognized or doesn't work? On Tue, Mar 1, 2016 at 1:01 PM, Carsten Kunze <carsten.ku...@arcor.de> wrote: > Conrad M

Re: WLAN hardware not recognized

kldload iwn6000fw, iwn6000g2afw, iwn6000g2bfw. On Tue, Mar 1, 2016 at 12:48 PM, Carsten Kunze wrote: > Larry Rosenman wrote: > >> Did you load the iwn firmware? > > How do I do this? > > I put "if_iwn_load="YES"" into /boot/loader.conf, now I get >

Re: Could somebody just commit this patch: The new command line option to set the daemon(8) process title ?

On Mon, Feb 29, 2016 at 3:00 PM, Yuri wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205016 > > This is a very simple and mundane (in my opinion) patch that makes it easier > to see which daemon is which when there are a lot of them. I'd be happy to (+ manual page

Re: buffer overflow warning in /bin/sh

I have /etc/src.conf: WITH_DEBUG_FILES=1 WITH_CTF=1 /etc/make.conf: CFLAGS=-fno-omit-frame-pointer WITH_CTF=1 WITH_DEBUG=yes Not sure which of those is relevant (or even correct), but I seem to get debuginfo in /usr/lib/debug/.debug. Best, Conrad On Thu, Feb 25, 2016 at 7:21 PM, Howard Su

Re: Intel BT USB

Knowing nothing about USB or Bluetooth — it may just need an entry with the right device id in the ubt_devs table of sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c. Best, Conrad On Thu, Feb 25, 2016 at 11:40 AM, Larry Rosenman wrote: > Anyone know what I need to support this: > >

Re: FreeBSD_HEAD_i386 - Build #1616 - Still Failing

r290519 should fix this particular error. I'm building another i386 toolchain to run the rest of the kernel build locally, but it will be a while before I can do so. Thanks, Conrad On Sat, Nov 7, 2015 at 2:29 PM, wrote: > FreeBSD_HEAD_i386 - Build #1616 - Still

Re: dumpdev in loader.conf vs rc.d/dumpon

On Wed, Sep 23, 2015 at 9:05 AM, Andriy Gapon <a...@freebsd.org> wrote: > On 23/09/2015 18:59, Conrad Meyer wrote: >> On Wed, Sep 23, 2015 at 7:37 AM, Andriy Gapon <a...@freebsd.org> wrote: > Because that's how I read the code in sys/geom/geom_dev.c. Especially >

Re: dumpdev in loader.conf vs rc.d/dumpon

On Wed, Sep 23, 2015 at 7:37 AM, Andriy Gapon wrote: > > I have recently discovered 'dumpdev' kernel environment variable that is > settable, for example, from loader.conf. To me it *seems* that this variable > has to be set to a device name / path without the leading '/dev'.

Re: Panic on boot during scan with pmspcv

On Mon, Aug 31, 2015 at 6:20 PM, John Baldwin wrote: > Probably pCardInfo is NULL. > > Looking at the pms driver source is making my stomach churn, but I don't > see anything obvious. The field is set during attach, so it shouldn't be > NULL when the intrhook runs. Do you have

Panic on boot during scan with pmspcv

For some reason, it only crops up on UEFI boot. Legacy boot just works. It looks like we're locking a mutex in a struct at NULL. (trap) __mtx_assert+0xdb agtiapi_cam_action+0x45 xpt_action_default+0xbe3(?) scsi_scan_bus+0x1cd xpt_scanner_thread+0x15c ... Fault is at 0x18.

Re: bhyve: fix bhyve warning CTASSERT

Better to just replace CTASSERT() with _Static_assert() while you're here. Best, Conrad On Thu, Aug 13, 2015 at 5:05 AM, Stefano Garzarella stefanogarzare...@gmail.com wrote: Hi all, when I compile bhyve, I have the following errors from clang: pci_emul.c:750:2: error: unused typedef

Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #260 - Failure

Fixed in the very next revision, r286077. On Thu, Jul 30, 2015 at 9:31 AM, jenkins-ad...@freebsd.org wrote: FreeBSD_HEAD_amd64_gcc4.9 - Build #260 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/260/ Full change log:

Re: [CURRENT]: r285995: BROKEN! buildkernel fails in kern_shutdown.c

On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Sources as of r285995 fail to build kernel with [...] --- kernel --- linking kernel kern_shutdown.o: In function `kern_reboot': /usr/src/sys/kern/kern_shutdown.c:(.text+0x2e6): undefined reference to

Re: [CURRENT]: r285995: BROKEN! buildkernel fails in kern_shutdown.c

On Tue, Jul 28, 2015 at 10:21 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Tue, 28 Jul 2015 21:58:26 -0700 Conrad Meyer cse@gmail.com wrote: On Tue, Jul 28, 2015 at 9:35 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Sources as of r285995 fail to build kernel

Re: Kernel Application Binary Interface (kABI) support in FreeBSD

On Fri, Jul 17, 2015 at 7:47 AM, Julian Elischer jul...@freebsd.org wrote: On 7/17/15 9:02 PM, Venkat Duvvuru wrote: Hi, Is there kABI (Kabi-whitelist) equivalent feature in FreeBSD? well, yes and no. Julian, I believe Venkat is asking about a specific Linux package, kabi-whitelists. It

Re: unp gc vs socket close/shutdown race

Hi all, (Sorry In-Reply-To is wrong; gmail isn't the most flexible MUA and I was not subscribed to FreeBSD-Current until today.) I have a slightly cleaned up version of this patch in phabricator at https://reviews.freebsd.org/D3044 . My mentor thinks it looks ok, but we would appreciate any

<    1   2