Re: Inconsistent behavior with wpa / devd / network interfaces

2019-05-30 Thread Poul-Henning Kamp


This sounds like handbook material ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Danish FreeBSD Developer hates jews collectively

2019-05-09 Thread Poul-Henning Kamp

In message <49cfcff55fe21d5d01df916e9f953...@redchan.it>, ossobserver@redchan.i
t writes:

You forgot to include this link:

http://phk.freebsd.dk/sagas/israel/


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ACPI Error: No handler for Region [ECOR]

2018-11-27 Thread Poul-Henning Kamp

In message <10399.1543270...@critter.freebsd.dk>, "Poul-Henning Kamp" writes:

>>I'm seeing it on my ThinkPad x230 as well
>
>and on T480 running 13.0-CURRENT  r340932M as well:

And seems to be gone with this kernel:

13.0-CURRENT r341006M

Havn't tried the ones in between.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Hole-punching, TRIM, etc

2018-11-13 Thread Poul-Henning Kamp

In message 
, Warner Losh writes:

>On a raw device it would be translated into a BIO_DELETE command directly,
>correct?

We already have ioctl(DIOCGDELETE) for that.  newfs(8) uses it.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


armv7 BETA3 panics when usb-disk inserted

2018-11-04 Thread Poul-Henning Kamp
 = 0x
swi_exit() at swi_exit
 pc = 0xc05cbcd4  lr = 0xc05cbcd4 (swi_exit)
 sp = 0xc35dce48  fp = 0x


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ctm(1) deprecation in the FreeBSD base system?

2018-10-22 Thread Poul-Henning Kamp

In message 
, Warner Losh writes:

>> > I think Julian Stacy is still running CTM generation ?
>>
>> Ah, yes, that brought back enough brain cells,
>> confirmed that is who I saw with ctm usage.
>
>Do we need it in base? Or can we make it a port?

Absolutely make it a port!

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ctm(1) deprecation in the FreeBSD base system?

2018-10-22 Thread Poul-Henning Kamp

In message <201810221957.w9mjvdxx012...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Gri
mes" writes:

>I do not know that other than I do know that I have seen
>one data point in the last 14 days of a user who was infact
>using ctm though I can not associate a username/email address
>with that memory.
>
>A search of the last 30 days of @freebsd.org public mail
>may yield a hit.

I think Julian Stacy is still running CTM generation ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Not sure if this is an important bug...

2018-10-09 Thread Poul-Henning Kamp

In message <201810082255.w98mtn1p033...@pdx.rh.cn85.dnsmgr.net>, "Rodney W. Gri
mes" writes:
>> I tried running 12.0-BETA8 under bhyve on a Phenom-II+11.2 box and
>> it explodes because of an unemulated instruction:
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232081
>> 
>> I have no idea what importance this has in relation to releasing 12.0
>
>Can you try an earlier alpha for me?  Specifically A3, I think this
>may be some hand optimization of memmov stuff that included a new
>instruction that we did not use before.

ALPHA[3-6] works, ALPHA[78] fails as reported in the ticket

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Not sure if this is an important bug...

2018-10-08 Thread Poul-Henning Kamp
I tried running 12.0-BETA8 under bhyve on a Phenom-II+11.2 box and
it explodes because of an unemulated instruction:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232081

I have no idea what importance this has in relation to releasing 12.0

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Should 11.2-p4+bhyve be able to run 12.0-ALPHA8-amd64 ?

2018-10-01 Thread Poul-Henning Kamp
On a 11.2-p4 host, trying to run 12.0-ALPHA8-amd64 under bhyve.

Right after console emits:

FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 4 package(s) x 1 core(s)
arc4random: no preloaded entropy cache

Bhyve quits with:

Failed to emulate instruction [0x0f 0xae 0x3b 0x8b 0x04 0x25 0xf8 0x5d 
0xb8 0x81 0x48 0x01 0xc3 0x4c 0x39] at 0x8104abb0
Abort trap


According to a disassembler "0f ae 3b" is "clflush byte ptr [%rbx]"

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: devmatch sideeffec: No sound

2018-09-30 Thread Poul-Henning Kamp

In message <20180930114717.0cfb5e6cdc881f39dbf4b...@bidouilliste.com>, Emmanuel
 Vadot writes:
>On Sun, 30 Sep 2018 07:51:38 +

>> Yet to be discovered workaround:  Prioritize sound devices, when
>> there are multiple.
>
> hw.snd.default_unit=XXX
> hw.snd.default_auto=0
>
> in /etc/sysctl.conf should do the trick.

Will try.

>> This kind of thing may cause some support-work when 12 comes out...
>
> The only new "issue" is that now with devmatch every hardware got its
>driver loaded, so on this case this would cause "problems" but for
>other it solve the problem of finding which driver you need to load to
>use your usb/pci/blah driver.

Ohh, absolutely!

Devmatch is a great improvement over "kldload /boot/kernel/*.ko"

But until now I had not expected any sideeffects in the "stopped
working" category.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


devmatch sideeffec: No sound

2018-09-30 Thread Poul-Henning Kamp
HW: Thinkpad T480 with T3 Dock.

SW: -current, r338952

With devmatch enabled in /etc/rc.conf (the default0, snd_uaudio
gets loaded automatically and finds the audio stuff in the dock,
which is connected to a screen output(s) I do not use.

Firefox ends up with /dev/dsp2.0 which goes there, and as a result
I get no sound through the laptops speakers where I expect it.

Obvious workaround: Disable devmatch.

Yet to be discovered workaround:  Prioritize sound devices, when
there are multiple.

This kind of thing may cause some support-work when 12 comes out...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Hooking RPi PWM driver into tree

2018-01-15 Thread Poul-Henning Kamp
I wrote a device driver for PWM on the RPi's, but I have not yet
hooked it into the tree, because I'm unsure how we would want that.

I personally think by default it should be a module which is
only compiled for RPi kernels, but how does one do that ?

(Needless to say, it should also be possible to compile it into the
kernel for an RPi, but I know how to do that :-)

And do we want it to live in sys/modules/rpi_pwm or sys/modules/rpi/pwm ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Onewire on BeagleBoneBlack example ?

2017-12-20 Thread Poul-Henning Kamp

In message <1513812077.77378.10.ca...@freebsd.org>, Ian Lepore writes:

>For years, folks have been espousing the value of getting people hooked
>on freebsd via rpi and beaglebone, 

I'm personally not that convinced about the value, for a number of
complex and interlocking reasons and I was merely noting that I
could see why it isn't happening - value or not.

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Onewire on BeagleBoneBlack example ?

2017-12-20 Thread Poul-Henning Kamp

In message <97808.1513774...@critter.freebsd.dk>, Poul-Henning Kamp writes:

>Does anybody have a working example of getting onewire sensors
>working on beagleboneblack ?

Ok, with some hints from the usual IRC channel I managed to figure it out:

cd /boot/dfb
mv am335x-boneblack.dtb _am335x-boneblack.dtb
dtc -I dtb -O dts -o am335x-boneblack.dts _am335x-boneblack.dtb
patch am335x-boneblack.dts (see below)
dtc -I dts -O dtb -o am335x-boneblack.dtb am335x-boneblack.dts
echo "owc_load=YES" >> /boot/loader.conf
echo "ow_load=YES" >> /boot/loader.conf
echo "ow_temp_load=YES" >> /boot/loader.conf

The patching of am335x-boneblack.dts is black magic, but this patch
worked for me:

root@beaglebone:/boot/dtb # diff -u *dts
--- _am335x-boneblack.dts   2017-07-21 11:24:18.229468000 +
+++ am335x-boneblack.dts2017-07-21 19:19:35.166447000 +
@@ -2149,6 +2149,14 @@
status = "disabled";
};
 
+   // first number (0x36, 0x4b) refers to "phandle" of gpio#
+   // second number is bit on that *cpu* GPIO
+   // not sure if the third matter, but 1 works.
+   onewire0 { compatible = "w1-gpio"; gpios = <0x36 30 1>; }; // 
P9::11
+   onewire1 { compatible = "w1-gpio"; gpios = <0x36 31 1>; }; // 
P9::13
+   onewire2 { compatible = "w1-gpio"; gpios = <0x4b 16 1>; }; // 
P9::15
+   onewire3 { compatible = "w1-gpio"; gpios = <0x36 3 1>; };  // 
P9::21
+
__symbols__ {
l4_wkup = "/ocp/l4_wkup@44c0";
wkup_m3 = "/ocp/l4_wkup@44c0/wkup_m3@10";

Either device tree overlays just plain don't work, I can't figure out how to
write them (p=0.5).

I sure get why getting people hooked on FreeBSD with RPi's and
BeagleBones is not happening :-/

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Onewire on BeagleBoneBlack example ?

2017-12-20 Thread Poul-Henning Kamp
Does anybody have a working example of getting onewire sensors
working on beagleboneblack ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


r325250: panics on USB stick insert

2017-11-02 Thread Poul-Henning Kamp
I updated to r325250M amd64 last night, and now my laptop panics in
geom when I plug my mobile phone in.

I'll try to get a panic message when I'm in less of a hurry...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: cve-2017-13077 - WPA2 security vulni

2017-10-16 Thread Poul-Henning Kamp

In message <calm2memawo7q7gnylqzpovpvp3dqun5s4aa4j8cw2nk8g6u...@mail.gmail.com>
, blubee blubeeme writes:

>Does anyone on FreeBSD know if it's affected by this?
>https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13077

It is, same as Linux, we use the same wpa_supplicant software

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Removal of catman from base

2017-09-13 Thread Poul-Henning Kamp

In message 
<canczdfoxe8haae+pvtvousyttyg7rgxcummwrak0lp0tgu9...@mail.gmail.com>, Warner 
Losh writes:

>Back in school, our SunOS 3, SunOS 4 and VAX running BSD 4.{2,3} we had to
>run a special ditroff [...]

ditroff = Device Independent Troff

The original troff were hardwired to the C/A/T photo-typesetter which
by the time of SVR bare existed in the market anymore.

Ditroff took a configfile and emitted a documented output, which a
device-dependent postprocessor would convert into something the
actual hardware understood.

I think I wrote about a dozen ditroff config+preprocessor combos during
the late 1980ies.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Removal of catman from base

2017-09-12 Thread Poul-Henning Kamp

In message <alpine.bsf.2.21.1709121210140.54...@orthanc.ca>, Lyndon Nerenberg 
writes:
>> That was actually not why catman was brought into the world:  ATT/USL
>> thought text-processing was The Goods so they unbundled it base SVR
>> and invented catman to make up for the missing nroff.
>
>Not quite.  They (AT) sold the rights to sell typeset manuals to some 
>publishing house (I forget which), at which point they stopped shipping 
>the *roff source for the manpages on the source tapes.  Instead, you got 
>pre-formatted "cat" pages on the source tape.  I think this happened 
>starting with SVR3.

I'm pretty sure that SVR1 had catman and roff was an extra and somewhat
pricey software package.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Removal of catman from base

2017-09-12 Thread Poul-Henning Kamp

In message <20170912184200.gd99...@gmail.com>, Gordon Tetlow writes:

>With modern hardware, it doesn't seem to be necessary to have pre-formatted
>man pages as rendering them is short enough to not be noticeable.

That was actually not why catman was brought into the world:  ATT/USL
thought text-processing was The Goods so they unbundled it base SVR
and invented catman to make up for the missing nroff.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [bmake] bmake sigint handling causing tty corruption

2017-07-19 Thread Poul-Henning Kamp

In message <20170718205700.GA2131@hades.panopticon>, Dmitry Marakasov writes:


>In short, when FreeBSD ports options dialog is interrupted by Ctrl+C,
>there's chance of sporadic terminal corruption. They are not always
>reproducible and seem to be dependent on a machine, shell, terminal,
>tmux used, but are not tied to any specific configuration.

I've noticed another quirk which may be related:

Start vi(1) on some file.

Type
!some_command_producing_significant_output | less

Ctrl-C

This leaves the less(1) alive and competing vi(1) for the terminal
in a most unworkable and annoying fashion.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: regression suspend/resume on Lenovo T420

2017-05-14 Thread Poul-Henning Kamp

In message <20170514193006.GA1298@brick>, Edward Tomasz =?utf-8?Q?Napiera=C5=82
a?= writes:

>I've tried to verify that, and sadly it wasn't it for me.  The commit
>that does break resume for me is r316767.  The current -CURRENT with
>this one commit reverted ("svn merge -c -r316767 .") suspends and resumes
>correctly, at least in VT; I decided to take X out of the picture for
>now.

I can confirm that this also makes resume work on my T430s running:

FreeBSD 12.0-CURRENT #0 r318250M amd64

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r316958: booting a server takes >10 minutes!

2017-04-15 Thread Poul-Henning Kamp

In message <20170415160916.gy1...@albert.catwhisker.org>, David Wolfskill write
s:

>And I understand that the Cloudflare/f-root server issue isn't quite
>that recent: "The new f-root servers appeared around two weeks ago"

And isn't the zone cache expiry time around two weeks as well ?


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r316958: booting a server takes >10 minutes!

2017-04-15 Thread Poul-Henning Kamp


>Recent CURRENT running on a server makes the system booting in multiuser mode 
>booting
>incredibly slow! On a machine, before I interrupted the booting process 
>hanging in
>starting postgresql 9.6.2 server, it took > 10 minutes.

Maybe this ticket ?

https://lists.freebsd.org/pipermail/freebsd-ports/2017-April/108144.html


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: arm64 vs. jemalloc and swapping in and out, sh/su examples: being swapped out leads to later Failed assertion: "tsd_booted" after being swapped in

2017-02-27 Thread Poul-Henning Kamp

In message <41a51b66-4290-48e0-a3e3-aeb809b27...@dsl-only.net>, Mark Millard 
writes:

>The evidence is that process-memory is trashed and so likely continued
>operation of any previously swapped-out processes is unreliable.

I can confirm process corruption on RPi3 as of r313567.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: removing SVR4 binary compatibilty layer

2017-02-15 Thread Poul-Henning Kamp

In message <20170215081430.gc58...@freebsd.org>, Gleb Smirnoff writes:

>Well, we all "maintain" it, meaning that we keep it compilable. However,
>I'm sure that no one checks the functionality. There are no regression
>tests, and seems to be no users.

And probably nobody ever bothered to check the code comprehensively
for security risks...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: vt(4) odd scrolling behavior

2016-12-16 Thread Poul-Henning Kamp

In message <CACNAnaEuMtKmFYd+2Z+U-VEWt6sBQ6kjdxSY-pdZO_=lmd_...@mail.gmail.com>
, Kyle Evans writes:

>I've had this odd behavior [1] on one of my machines with vt(4)
>misbehaving in graphics mode following the beastie loader's screen.
>
>Any ideas what might cause something like this, 

I've seen it too.  I think beastie sets a scrolling region and
doesn't clear it.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


a dirty trick: i386 nanobsd ports on amd64

2016-11-20 Thread Poul-Henning Kamp
I ran into a interesting problem, and want to share the solution, in
case anybody else can use it.

I'm upgrading a system which used to be i386 to amd64, but part of
its job is to compile i386 nanobsd images.

That's a solved problem, but I also needed a couple of ports installed,
which for reasons of paperwork, must be compiled from source.

Cross-compiling ports is not something I wanted to get into, but
happily amd64 cpus can run in i386 mode these days:

phk_ports () (
set -e
cd ${NANO_WORLDDIR}
mkdir -p usr/ports
trap "umount ${NANO_WORLDDIR}/usr/ports ; umount ${NANO_WORLDDIR}/dev" 
1 2 15 EXIT
mount -t nullfs -o readonly /usr/ports ${NANO_WORLDDIR}/usr/ports
mount -t devfs devfs ${NANO_WORLDDIR}/dev
echo '
ldconfig -elf
for i in ports-mgmt/pkg sysutils/smartmontools net/trafshow
do
cd /usr/ports/${i}
make \
WRKDIRPREFIX=/tmp \
BATCH=YES \
OPTIONS_UNSET="DOCS NLS" \
all install clean
done
' > ${NANO_WORLDDIR}/tmp/_job.sh
chroot ${NANO_WORLDDIR} /bin/sh /tmp/_job.sh
umount ${NANO_WORLDDIR}/usr/ports
umount ${NANO_WORLDDIR}/dev
trap - 1 2 15 EXIT
)

customize_cmd phk_ports

The same basic trick can of course be be used for any i386 software
which must be compiled from source.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Mime issue on -current

2016-10-02 Thread Poul-Henning Kamp
I just updated to current from source, and found that evince did
claimed all .pdf files were "application/octet".

The solution, after some digging around is to run

/usr/local/bin/update-mime-database /usr/local/share/mime

Which is something I pressume some port used to do, but for some
reasons didn't do this time...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: make universe and /etc/src.conf

2016-08-22 Thread Poul-Henning Kamp

In message <ad2f7a3b-21c5-2e2a-2f1b-0625a70e0...@freebsd.org>, Eric van Gyzen w
rites:
>I just tried a "make universe", and all the kernels failed because they 
>couldn't
>find the config files.  I had forgotten that I have this in /etc/src.conf:
>
>   KERNCONF=NUMA
>   KERNCONFDIR=/etc
>
>Since "make universe" is primarily used for build-testing changes in src,
>shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
>following?  Or is "make universe" used for other purposes for which it really
>should read /etc/src*.conf?

I frankly don't remember why universe ignores make.conf but not src.conf,
but I do remeber it was a deliberate decision.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: LibreOffice and CUPS

2016-05-14 Thread Poul-Henning Kamp

In message <20160514211909.gc1...@dendrobates.araler.com>, Sergey Manucharian w
rites:

>I've built kernel and world, cups and libreoffice were isnstalled as
>packages:

I just spent two hours finding out that shell pipes on -current(-ish),
r297556, returns EAGAIN when full:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209509

If, as I suspect, this affects any pipe, it has the potential to
break all sorts of things, including possibly this.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: why 100 packages are evil

2016-04-23 Thread Poul-Henning Kamp

In message <alpine.osx.2.00.1604222009300.15...@minnie.bitsea.ca>, Lyndon Neren
berg writes:

>With freebsd-update, an announcement comes out that says 'update'!.  So we 
>do.  Move from 10.2-p11 to 10.2-p12.  There is a very clear track record 
>of why and how this happened.

Is freebsd-update going away as result of the new packaging ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Use MAX()/MIN() macros in world.

2016-04-20 Thread Poul-Henning Kamp

In message 

Re: [CFT] packaging the base system with pkg(8)

2016-04-19 Thread Poul-Henning Kamp

In message <1461096962.1232.32.ca...@freebsd.org>, Ian Lepore writes:

>Oh yeah, now I remember:  Because in freebsd, design is decided by a
>race to commit rather than by discussion.

No, that's not it.

It is because code talks much louder than words.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [CFT] packaging the base system with pkg(8)

2016-04-19 Thread Poul-Henning Kamp
As far as I know, nobody is taking the source code or the Makefiles
away, so if somebody doesn't like the system being distributed with
pkg, they can very well roll their own.

It's nice to see the level of enthusiasm the FreeBSD project can
muster, I just wish it wasn't always enthusiasm for stopping progress.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CURRENT slow and shaky network stability

2016-04-11 Thread Poul-Henning Kamp


I have been trying to capture a packet trace for the breaking SSH
and while not a statistically rigid conclusion, it doesnt seem
to happen when I run a tcpdump on wlan0.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CURRENT slow and shaky network stability

2016-03-26 Thread Poul-Henning Kamp

In message <201603262331.u2qnvxvm080...@gw.catspoiler.org>, Don Lewis writes:

>> I am not running zfs.

Ohh, and I should probably add:  I don't have a swap-space configured.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CURRENT slow and shaky network stability

2016-03-26 Thread Poul-Henning Kamp

In message <canj8om5rknauy0j-undf9a8stj1ld2yho4xfqgg1qodeagv...@mail.gmail.com>
, Ultima writes:

> A large zfs send [...]

I am not running zfs.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CURRENT slow and shaky network stability

2016-03-26 Thread Poul-Henning Kamp

In message <caj-vmons87pun0nedma0uc63soop0e2ytt8whzodk08_c+b...@mail.gmail.com>
, Adrian Chadd writes:

I can second that -current isn't too great right now, and I also see
the breaking SSH sessions.

I'm running:

FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016

I repartitioned my disk I don't have the previous version around any more
but it was 4-6 weeks old, and I'm quite sure it didn't have the breaking
ssh connections.

On another machine running:

FreeBSD 11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016

I'm seeing weirdness with a 2TB and a 3TB external USB disk, in
particular I/O aborts with this message:

usb_pc_common_mem_cb: Page offset was not preserved

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: USB disks attach after rootfs prompt

2016-03-20 Thread Poul-Henning Kamp

In message <9901a1b3-1629-4bc7-9f2c-d5b0f1f2b...@freebsd.org>, =?utf-8?Q?Edward
_Tomasz_Napiera=C5=82a?= writes:

>That's seriously weird.  Did you see the messages about root mount waiting
>for usbusX, with the patch applied?  What's the hardware?

The hardware is BHYVE.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: USB disks attach after rootfs prompt

2016-03-20 Thread Poul-Henning Kamp

In message <20160319215624.ga1...@brick.home>, Edward Tomasz =?utf-8?Q?Napiera=
C5=82a?= writes:

>> I am somewhat certain that this used to work...
>
>That might be my fault.

I built this kernel overnight:

FreeBSD 11.0-CURRENT #2 r297053: Sun Mar 20 02:47:38 UTC 2016

Now it doesn't find _any_ devices at the -a prompt.

Your suggested patch did not change that.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: USB disks attach after rootfs prompt

2016-03-19 Thread Poul-Henning Kamp

In message <1458397972.68920.69.ca...@freebsd.org>, Ian Lepore writes:
>On Sat, 2016-03-19 at 13:04 +0000, Poul-Henning Kamp wrote:
>> Running:
>> 
>>  FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016
>> 
>> I tried "boot -a" and found that USB disks only attach *after* you
>> enter some root filesystem.
>> 
>> That's not terribly useful.
>
>iirc, interrupts are disabled while you're at the mountroot prompt,
>which freezes usb enumeration.

I am somewhat certain that this used to work...


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


USB disks attach after rootfs prompt

2016-03-19 Thread Poul-Henning Kamp
Running:

FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016

I tried "boot -a" and found that USB disks only attach *after* you
enter some root filesystem.

That's not terribly useful.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Crashes in libthr?

2016-03-14 Thread Poul-Henning Kamp

In message <2016031428.ga1...@borg.lerctr.org>, Larry Rosenman writes:

>And sshd is busted. 

FYI: I seeing no such issues on two systems running:

11.0-CURRENT #4 r296808: Sun Mar 13 22:39:59 UTC 2016
and
11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016 

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


New LOR ?

2016-02-12 Thread Poul-Henning Kamp
I don't recall seeing this one before:

FreeBSD critter.freebsd.dk 11.0-CURRENT FreeBSD 11.0-CURRENT #31 r293468: Sat 
Jan  9 11:50:09 UTC 2016 
r...@critter.freebsd.dk:/freebsd/obj/freebsd/svn_src/head/sys/GENERIC  amd64

+taskqueue_drain with the following non-sleepable locks held:
+exclusive sleep mutex bpf global lock (bpf global lock) r = 0 (0x81c53
fe8) locked @ /freebsd/svn_src/head/sys/net/bpf.c:772
+stack backtrace:
+#0 0x80a79ee0 at witness_debugger+0x70
+#1 0x80a7b1f7 at witness_warn+0x3d7
+#2 0x80a6daeb at taskqueue_drain+0x3b
+#3 0x80b4bb0b at ieee80211_waitfor_parent+0x3b
+#4 0x80b32d57 at ieee80211_ioctl+0x2f7
+#5 0x80afe025 at if_setflag+0xd5
+#6 0x80afdefc at ifpromisc+0x2c
+#7 0x80af41e8 at bpf_detachd_locked+0x1e8
+#8 0x80af6cfe at bpf_dtor+0x8e
+#9 0x808f7312 at devfs_destroy_cdevpriv+0x82
+#10 0x808faa85 at devfs_close_f+0x65
+#11 0x809d0e6a at _fdrop+0x1a
+#12 0x809d3fb1 at closef+0x1e1
+#13 0x809d3afd at fdescfree_fds+0x9d
+#14 0x809d361c at fdescfree+0x46c
+#15 0x809e1676 at exit1+0x4e6
+#16 0x809e118d at sys_sys_exit+0xd
+#17 0x80e6b13b at amd64_syscall+0x2db



-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


dhclient/unbound_local/forward.conf

2015-12-05 Thread Poul-Henning Kamp
I had my (-current) laptop on a couple of crippled guest nets
this week.

DNS didn't work.

I found out that the "forward.conf" file, which should point
local_unbound at the DNS server from the DHCP lease, is put in
/etc/unbound/forward.conf where unbound will not find it.

Should it be in /etc/unbound/conf.d/forward.conf, or should
forward.conf be explicitly included from unbound.conf ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Build Options Survey run

2015-11-03 Thread Poul-Henning Kamp

In message <b0b7a53d-2b33-40ce-97eb-f53a43b30...@bsdimp.com>, Warner Losh 
writes:

>> phk had asked me to run a build options survey again.  It took about 
>two weeks to go through all of them.  The results are here:

Many thanks!

>> There are plans to run it more often again and improve it a bit.  No 
>promises on the actual timeline but it'll happen.

It's actually a good beginner task if anybody wants to do something
for the project which requires just a machine and some shell
programming.

My old script can be improved in a lot of ways, the most productive
would probably be to make it incremental rather than one big batch
job.  (Something like:  Test any options for which there are no
results, otherwise retest the option with the oldest result.)

>While not all combinations tested were valid combinations, many that 
>failed are. Some of them look to be relatively easy to fix, while others 
>are much harder.

If one _really_ wanted to burn CPU cycles, my testing years back revealed
many combinations where options are incompatible.  (NB: Today we have almost
four times as many options as then and we're into N! territory here...)

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Depreciate and remove gbde

2015-10-23 Thread Poul-Henning Kamp

In message <20151023192353.ga95...@cons.org>, Martin Cracauer writes:

>If you want a secure filesystem I think that at this particular time
>it would be entirely reasonable to use both gbde and geli stacked on
>top of each other[...]

Nobody is going to break through the GELI or GBDE crypto, they'll
find their way to the keys instead, or more likely, jail you until
you sing.

But neither GELI og GBDE alone or together give you a secure filesystem.

The very first requirement for a secure filesystem is that you can
trust the computer it is mounted on.

No commercially available smartphone, tablet, laptop, server or
desktop computer can be trusted by the owner at this point in time.

Want a secure filesystem ?

First step is to mount it on RaspBerry or Beaglebone without network
connectivity...

But more importantly:  There is no technical fix for lost privacy,
that is a political problem, and it must be solved by political
means.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Depreciate and remove gbde

2015-10-20 Thread Poul-Henning Kamp

In message <5625d422.4040...@fizk.net>, Yonas Yanfa writes:

>> Think human rights activists for instance.
>
>Couldn't they use a fake email address and Tor to communicate 
>anonymously? I'd be surprised if they aren't already.

If you think being a human rights activist is that simple, you
really have *no* idea...

For a lot of them, using Tor would instantly blow their cover.

We're not talking about people who wear Amnesty International
T-shirts or who call themselves "human rights activists" when the
pass through immigration.

We're talking about people who for all practical purposes have a
job as hard or harder than "real" spies.

They do not have the the support and resources of their own government,
they do not have a spare diplomatic passport and a new identity
waiting for them at the embassy, and they certainly cannot afford
those sunglasses.

Getting it wrong on crypto or comms-footprint will at the very least
cost them a year in some Elbonian mud-jail, worst case they die in
a "traffic accident" or "commit suicide" in a turkish air-port
toilet.


>but we should improve the Handbook so gdbe vs. geli 
>strengths and weaknesses are better explained.

By all means go for it!

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Depreciate and remove gbde

2015-10-20 Thread Poul-Henning Kamp

In message <201510200841.t9k8fngy005...@mech-as222.men.bris.ac.uk>, Anton 
Shterenlikht writes:

>Am I correct that the papers are from 2003 and 2004
>respectively. Has much changed in gbde since then?

Nope.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Depreciate and remove gbde

2015-10-20 Thread Poul-Henning Kamp

In message <201510200645.t9k6jaam004...@mech-as222.men.bris.ac.uk>, Anton 
Shterenlikht writes:
>>GBDE is for when the user is in danger.
>
>In danger of what?
>Please elaborate.

Read the paper:

http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf

Or use the TL;DR version in the slides:

http://phk.freebsd.dk/pubs/bsdcan-04.slides.gbde.pdf


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Depreciate and remove gbde

2015-10-19 Thread Poul-Henning Kamp

In message 
<caghfrmddehgun_xbw_kkof_eppcrn0e1zxxvx6ga2nfrkn1...@mail.gmail.com>, NGie 
Cooper writes:

>1. Why are there 2 competing technologies?

They are not competing, they support two very different threat models.

>3. Is there a gain/loss for removing gbde?

Yes, you alienate a lot of users who very often are not even in a
position to tell you they run FreeBSD.

Think human rights activists for instance.

>4. Why is it marked experimental [still]?

To make people think.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Depreciate and remove gbde

2015-10-19 Thread Poul-Henning Kamp

In message <20151019234855.4ed82...@gumby.homeunix.com>, RW writes:

>I certainly wouldn't like to see gbde removed but I think it is
>unfortunate that it's given slightly greater prominence in the handbook
>than geli. geli is the right choice for most people.

This I fully agree with.

GELI is fine if your threatmodel is a stolen laptop.

GBDE is for when the user is in danger.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Depreciate and remove gbde

2015-10-18 Thread Poul-Henning Kamp

In message <5623846b.6000...@freebsd.org>, Allan Jude writes:

>While I think it isn't a bad idea to put GELI first in the handbook, I
>don't see any reason to remove gdbe.

I don't see any reason to remove gbde, and would consider any such
suggestion somewhat suspect, given the set of users I know about.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Those at BSDCan 2015: please test: iwn(4) patch to buffer 5ghz frames before transmitting

2015-06-11 Thread Poul-Henning Kamp

In message 
CAPyFy2Cd5FgOKoTEvFNH3PHL-t0Q6roYV9nYgLK3jkBXJpe=l...@mail.gmail.com
, Ed Maste writes:

I'm running with the patch at BSDCan. Failed to associate several
times at 5Ghz before settling on channel 11 (2462 MHz 11g ht/20). A
log with:

wlandebug +assoc +state +rate
sysctl dev.iwn.0.debug=0x1

I have had no luck getting my T430s to associate at 5GHz either, so
much so that I started wondering if I even have 5G antennas in this
laptop or not...

wn0: Intel Centrino Advanced-N 6205 mem 0xd1c0-0xd1c01fff irq 17 at 
device 0.0 on pci3
iwn0: iwn_read_firmware: ucode rev=0x12a80601


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Increase BUFSIZ to 8192

2015-05-14 Thread Poul-Henning Kamp

In message 5554b8d6.1010...@mu.org, Alfred Perlstein writes:

Shouldn't most of these be using st.st_blksize ?

We had a long discussion about that back when GEOM was young and the
conclusionis that st_blksize doesn't tell you anything useful
and generally does the wrong thing, in particular on non-native
filesystems like msdosfs and cd9660.

But the world is more complex than even that.

For instance on a RAID-5 volume, you want to write stripe-width
chunks, properly aligned, no matter what the st_blksize might be
in your filesystem.  Unless your filesystem is guaranteed to lay
out sequentially, you would have to ask before each write.

Other filesystems may have opinions about read-sizes (ie: NFS).

The only sane way to do this properly would be to ask each
individual file with fcntl(2) for preferred read or write
sizes.

You could then have embedded system mount filesystems with
-o iosize=min
and servers instead use
-o iosize=fastest

But for most practical purposes, having a sane constant BUFSIZ is
just fine.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Increase BUFSIZ to 8192

2015-05-14 Thread Poul-Henning Kamp

In message 72720ea2-c251-40b9-9ec0-702c07d5e...@gmail.com, Garrett Cooper 
writes:

Until performance has been characterized on 32-bit vs 
64-bit architectures, blanket changing a value doesn't make sense.

First time I saw benchmarks which showed improved performance
from a larger BUFSIZe was around 1998...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Increase BUFSIZ to 8192

2015-05-14 Thread Poul-Henning Kamp

In message 1431615185.1221.57.ca...@freebsd.org, Ian Lepore writes:

I think we've got differing interpretations of what BUFSIZ is for.

IMO, the one correct use of BUFSIZ outside of libc is if you are going
to call setbuf() the buffer you pass must be BUFSIZ bytes long.

Over the years, it seems that many people have somehow gotten the
impression that the intent was BUFSIZ is the right/ideal/whatever size
to allocate general purpose IO buffers in any program 

I don't know when you started, but when I started, on sys-III and
v7 in the mid 1980ies, that was exactly what people told you:
Do disk-I/O in BUFSIZ units.

I did a quick sampling of src and that seems to be exactly how it is
being used in most of the cases I looked at, including libmd where
I put it there on exactly that reason back in 1994 (5?)

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Increase BUFSIZ to 8192

2015-05-14 Thread Poul-Henning Kamp

In message 20150514075316.gy37...@funkthat.com, John-Mark Gurney writes:
Poul-Henning Kamp wrote this message on Thu, May 14, 2015 at 07:42 +:
 
 In message 20150514072155.gt37...@funkthat.com, John-Mark Gurney writes:
 
 Since you apprently missed my original reply, I said that we shouldn't
 abuse BUFSIZ for this work, and that it should be changed in mdXhl.c...
 
 Say what ?
 
 BUFSIZ is used entirely appropriately in MDXFileChunk():  For reading
 a file into an algorithm.

In fact, posix-2008 references LINE_MAX because:

MDXFileChunk() does not read lines, it reads an entire file.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Increase BUFSIZ to 8192

2015-05-14 Thread Poul-Henning Kamp

In message 20150514072155.gt37...@funkthat.com, John-Mark Gurney writes:

Since you apprently missed my original reply, I said that we shouldn't
abuse BUFSIZ for this work, and that it should be changed in mdXhl.c...

Say what ?

BUFSIZ is used entirely appropriately in MDXFileChunk():  For reading
a file into an algorithm.

If in stead of open(2), fopen(3) had been used, the exact same thing
would happen, but using malloc space rather than stack space.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Increase BUFSIZ to 8192

2015-05-14 Thread Poul-Henning Kamp

In message 1431542835.1221.30.ca...@freebsd.org, Ian Lepore writes:
On Wed, 2015-05-13 at 11:13 -0700, John-Mark Gurney wrote:

As I've already pointed out, BUFSIZ appears in the
base code over 2000 times.  Where is the analysis of the impact an 8x
change is going to have on all those uses?

Not to pick on Ian in particular, but I'm going to call bike-shed
on this discussion now.

Please just make it 4K on 32bit archs and 16K on 64 bit archs, and
get on with your lives.

If experience in -current (that's why developers run current, right ?!)
documents that this was the wrong decision, we can revisit it.

Until then:  Shut up and code.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Increase BUFSIZ to 8192

2015-05-12 Thread Poul-Henning Kamp

In message 20150512032307.gp37...@funkthat.com, John-Mark Gurney writes:

Also, you'd probably see even better performance by increasing the
size to 64k, [...]

easy:
8K on 32bit
64k on 64bit

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


iwn crashes in current (r282269)

2015-05-02 Thread Poul-Henning Kamp
May  2 01:01:34 critter kernel: iwn0: device timeout
May  2 01:01:34 critter kernel: firmware: 'iwn6000g2afw' version 0: 677296 
bytes loaded at 0x81f880c0
May  2 01:01:34 critter kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601
May  2 01:01:40 critter kernel: iwn0: iwn_tx_data: m=0xf80236fe8500: seqno 
(9550) (78) != ring index (0) !
May  2 01:01:40 critter kernel: iwn0: iwn_intr: fatal firmware error
May  2 01:01:40 critter kernel: iwn0: iwn_panicked: controller panicked, 
iv_state = 5; resetting...
May  2 01:01:40 critter kernel: firmware: 'iwn6000g2afw' version 0: 677296 
bytes loaded at 0x81f880c0
May  2 01:01:40 critter kernel: iwn0: iwn_read_firmware: ucode rev=0x12a80601

And then the machine hung.

No further details, as the screen-blanker was on.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Early use of log() does not end up in kernel msg buffer

2015-04-12 Thread Poul-Henning Kamp

In message 16486425.yxjbenq...@ralph.baldwin.cx, John Baldwin writes:

To be clear, you didn't turn off printing to the console, you turned off
writing to the msglog.

I've scavenged my notes and can't find anything to explain why.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Early use of log() does not end up in kernel msg buffer

2015-04-07 Thread Poul-Henning Kamp

In message 552326a2.5000...@badgerio.us, Eric Badger writes:

 The reason was systems not running syslog having slow serial consoles.

Correct me if I've misunderstood, but that doesn't seem to matter here; 
the proposed change adds logging to the message buffer but leaves 
logging to the console (when no syslog is listening) unchanged.

Sorry, I must have misunderstood the question then.

I don't think I have any opinion on the log() function.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Early use of log() does not end up in kernel msg buffer

2015-04-06 Thread Poul-Henning Kamp

In message 2033248.eu3rhs8...@ralph.baldwin.cx, John Baldwin writes:

I think phk@ broke this back in 70239.  Before that the log() function did
this:

log()
{

   /* log to the msg buffer */
   kvprintf(fmt, msglogchar, ...);

   if (!log_open) {
   /* log to console */
   kvprintf(fmt, putchar, ...);
   }
}

I think your patch is fine unless phk@ (cc'd) has a reason for not wanting to
do this.

The reason was systems not running syslog having slow serial consoles.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Some unresolved but important X.org problems

2015-02-11 Thread Poul-Henning Kamp

In message 20150211132039.42665...@rsbsd.rsb, Beeblebrox writes:

PROBLEMS:
1. PDF viewers fail to display pdf/ps files correctly. Many files
get displayed as blank pages, and I can only get the pdf to display
after closing/re-opening the file several times, or by repeatedly
scrolling up/down past the seemingly blank page. Pages with an image
have more problems than pages with text-only.

evince crashes for me about 1 out of two but files with purely
images seems to fare slightly better than others.

people have pointed fingers in the general direction of gtk/cairo

2. With the exception of Opera (which is out-dated), all remaining
Browsers fail to display most web pages in a sane manner (Firefox,
Seamonkey, Epiphany, Midori). Chrome is the worst because even with
just a blank page it flickers, goes completely white, comes back
as a partial image and sometimes locks X for 1/2 second or so.

I'm running firefox 35 on current and that seems to be working OK.

My guess is that your problems are specific to your graphics
hardware, and therefore it could be valuable if you could try,
just as an experiment, to move your diskdrive to different hardware,
just to see if the problems comes along for the ride.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Weird ACPI/DRM messages on -current

2015-02-06 Thread Poul-Henning Kamp
Thinkpad T430s:

11.0-CURRENT #15 r278283: Thu Feb  5 22:45:26 UTC 2015

Anybody know what this means ?

Feb  6 17:05:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:06:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:06:18 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:06:27 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:06:38 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:07:15 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 0007, was 
1907
Feb  6 17:07:37 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 

Feb  6 17:07:50 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:07:58 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900
Feb  6 17:08:12 critter kernel: error: [drm:pid1090:gen6_sanitize_pm] *ERROR* 
Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1907, was 
1900


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


unbound crashes on bootup

2015-02-06 Thread Poul-Henning Kamp
I just updated my -current to r278283, and unbound (still) croaks
during bootup:

Feb  6 13:00:54 critter dhclient: New Broadcast Address (wlan0): 192.168.60.255
Feb  6 13:00:54 critter dhclient: New Routers (wlan0): 192.168.60.1
Feb  6 13:00:54 critter kernel: pid 515 (unbound), uid 59: exited on signal 11
Feb  6 13:00:58 critter ntpd_initres[769]: host name not found: pool.ntp.org

No core file...


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Bug-report of sorts...

2015-02-01 Thread Poul-Henning Kamp

In message alpine.bsf.2.11.150130250.91...@z.fncre.vasb, Marcin Cieslak w
rites:
On Fri, 30 Jan 2015, Poul-Henning Kamp wrote:

 But the point is I never get to the webpage, local_unbound just doesn't
 seem to be able to resolve anything through the DHCP appointed server,
 despite the fact that dig(1) does so just fine.

So I finally had a chance to dig into this.

Commenting out the root.key fil in unbound.conf did it, with it
unbound seems to insist on validating the rootkey and to do nothing
else until that happens.

The DNS server in the meantime ignores DNSKEY queries...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Bug-report of sorts...

2015-01-30 Thread Poul-Henning Kamp
I'm at a hotel in Bruxelles right now, and the cordially provided free
wireless is a lot less useful than it can be, because my FreeBSD box
can't seem to do DNS lookups on it.

It's one of those captive portal kind of things where you get a
DHCP reply with a DNS server which lies to you until you agree to
the TC on a web-page.

But the point is I never get to the webpage, local_unbound just doesn't
seem to be able to resolve anything through the DHCP appointed server,
despite the fact that dig(1) does so just fine.

I have no idea what goes wrong or why it goes wrong, local_unbound does
not seem to record anything in syslog about failures.

I'm here for a couple of days (as are, I belive, another couple of
FreeBSD people) in case anybody has any ideas to try...

Input welcome...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Current trouble

2015-01-20 Thread Poul-Henning Kamp
I just tried current as of yesterday and had to give up rather quickly.

unbound sig#11'ed on bootup, couldn't find a coredump.

Trying to read a PDF file with evince I got one:

$ evince
Fatal error 'mutex is on list' at line 424 in file 
/freebsd/svn_src/head/lib/libthr/thread/thr_mutex.c (errno = 2)
Abort (core dumped)

Backtrace looks like:

#0  0x00080457648a in thr_kill () from /lib/libc.so.7
#1  0x0008045763f8 in raise () from /lib/libc.so.7
#2  0x000804574959 in abort () from /lib/libc.so.7
#3  0x00080422660a in pthread_attr_getaffinity_np () from /lib/libthr.so.3
#4  0x000804221c00 in pthread_mutex_destroy () from /lib/libthr.so.3
#5  0x000810ee0aa9 in Array::decRef () from /usr/local/lib/libpoppler.so.46
#6  0x000810f524ef in Object::free () from /usr/local/lib/libpoppler.so.46
#7  0x000810f07408 in Gfx::go () from /usr/local/lib/libpoppler.so.46
#8  0x000810f06ecb in Gfx::display () from /usr/local/lib/libpoppler.so.46
#9  0x000810f57058 in Page::displaySlice ()
   from /usr/local/lib/libpoppler.so.46
#10 0x000810a3b3e2 in _poppler_page_render ()
   from /usr/local/lib/libpoppler-glib.so.8
#11 0x00081080df51 in register_evince_backend ()
   from /usr/local/lib/evince/4/backends/libpdfdocument.so
#12 0x00081080d2c5 in register_evince_backend ()
   from /usr/local/lib/evince/4/backends/libpdfdocument.so
#13 0x000800ae4cc1 in ev_job_print_set_cairo ()
   from /usr/local/lib/libevview3.so.3
#14 0x000800ae5bc0 in ev_job_scheduler_get_running_thread_job ()
   from /usr/local/lib/libevview3.so.3
#15 0x0008039360fa in g_thread_proxy ()
   from /usr/local/lib/libglib-2.0.so.0
#16 0x00080421b6e4 in pthread_create () from /lib/libthr.so.3
#17 0x in ?? ()

I'm not sure if these two observations are connected, but it was enough
to make -current unworkable for me...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-22 Thread Poul-Henning Kamp

In message 1419224743.1018.108.ca...@freebsd.org, Ian Lepore writes:

On Sun, 2014-12-14 at 10:32 +, Poul-Henning Kamp wrote:
 The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
 large part of our boot time on systems with slow-ish serial consoles.
 
I investigated this a bit today.  I instrumented the loader on arm to
count how many times twiddle() is called while loading a 5.5MB kernel.
When loading over NFS it was called 5580 times.  When loading from an
sdcard it was called 284 times.

It would be plenty if it twiddled once per second, in fact it would
probably be much better if it *only* twiddled once per second, because
the at least people could count the steps and gain some idea where
in the process the problem is.

So all in all it seems like different kinds of IO need different
throttling, something like the attached (which also still has some stats
output in it).  I can't decide if it's worth committing... it'll have a
lot of value to someone with slow serial and netbooting, is that common?

How about a compile time global divisor so people can reduce it
even further ?

But even without that: Please commit

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-22 Thread Poul-Henning Kamp

In message 1419292392.1018.132.ca...@freebsd.org, Ian Lepore writes:

Rather than compile-time I made it a run-time setting by adding a
twiddle_divisor variable to loader(8).   r276079 and r276087.

Works for me,

Thanks a lot!

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


simple task to speed up booting

2014-12-14 Thread Poul-Henning Kamp
The rotating swirlie ('-/|\') in the loader accounts for a surprisingly
large part of our boot time on systems with slow-ish serial consoles.

I think right now it takes a step for each 512 byte read, reducing that
to once every 64kB or even 1MB would be an improvement with the kind of
kernel sizes we have today.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: simple task to speed up booting

2014-12-14 Thread Poul-Henning Kamp

In message 1418568731.935.8.ca...@freebsd.org, Ian Lepore writes:

It's the 21st century, but we never got the George Jetson flying cars we
were promised, and apparently we're never going to break loose from the
standards set by accoustic-coupled modems.

9600 is not from accoustic-coupled modems, but from RS-232 runs on unshielded
telephone wire in office environments.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: RFC: Remove pty(4)

2014-11-27 Thread Poul-Henning Kamp

In message 20141127095229.go17...@kib.kiev.ua, Konstantin Belousov writes:

On Wed, Nov 26, 2014 at 04:41:27PM -0800, Davide Italiano wrote:
 On Mon, Aug 25, 2014 at 12:37 PM, John Baldwin j...@freebsd.org wrote:
  On Wednesday, August 20, 2014 11:00:14 AM Davide Italiano wrote:
  One of my personal goals for 11 is to get rid of cloning mechanism
  entirely, and pty(4) is one of the few in-kernel drivers still relying
  on such mechanism.
Why this is good thing to do ?

I must have missed this detail back in august.

I checked my archive of incoming email and I couldn't find any
reason or argument for removing dev_clone mechanism, and I would
very much object to its removal, unless a very compelling reason
exists ?

I'll admit that the name is slightly misleading, it is really
a dev_ondemand facility which can also be used for cloning,
and because all the initial uses were cloning it got that name.

(I have no soft feelings for the pty driver)

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [RFC] Moving troff only documentation to the doc repository

2014-11-23 Thread Poul-Henning Kamp

In message ad7bf4d8-895f-420f-b42a-8ad1fae4a...@freebsd.org, Remko Lodder wri
tes:

How about doc-history, or something where we can archive documentation
that has high historic value?

It's about time the FreeBSD project starts to think about history
preservation in general, but I'm not sure how one goes about doing
that in an Open Source Project.

Do we have any volunteers at Computer History Museum in our ranks ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Finding a rogue src/sys commit with bisection?

2014-11-15 Thread Poul-Henning Kamp

In message 5467adf7.1020...@mu.org, Alfred Perlstein writes:

Nope.  You showed some svn commands to not do it, you weren't explicit 
in asking for ways to do it in svn, go ahead, look:

I didn't realize that the git-zealots also wanted us to adopt the
petty and childish behaviour of the linux email-culture ?

Can everybody please just shut up and code now ?

Thankyou!

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Finding a rogue src/sys commit with bisection?

2014-11-15 Thread Poul-Henning Kamp

In message 5467af7a.2080...@mu.org, Alfred Perlstein writes:

I resent your implications.  Seriously I do.

There was no intent to be childish or anything as such.

Well, you were, and intentional or not, you're wasting
a hell of a lot of peoples time right now.

See also: www.bikeshed.org

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: GNU LICENSING

2014-09-13 Thread Poul-Henning Kamp


I was wondering how to apply to the gnu licensing [...]

Don't feed the Troll please.

PS: John Ruse -- Really ?


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gbde destroy doesn't match man page?

2014-08-26 Thread Poul-Henning Kamp

In message 2945485.zemf81r...@ralph.baldwin.cx, John Baldwin writes:
On Saturday, August 23, 2014 10:16:42 AM Poul-Henning Kamp wrote:
 
 In message 20140820215522.ga92...@bewilderbeast.blackhelicopters.org,
 Michae
 l W. Lucas writes:
 Playing with GBDE for my FreeBSD disk book, on:
 
 # uname -a
 FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23
 11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC  amd64
 
 According to the man page, I should be able to destroy all copies of
 the key with gbde destroy device -n -1. It's in the examples. When I
 
 try it I get:
 I think that is an oversight in the code.

Can you expand on this?  I.e. what should the code do if it is fixed?

Hmm, now that I think about it, -n doesn't make sense because any 
one of the four keys can open the volume as needed to blow away the
masterkey.

The manual page should just be fixed.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gbde destroy doesn't match man page?

2014-08-26 Thread Poul-Henning Kamp

In message 201408261723.53428@freebsd.org, John Baldwin writes:

 Hmm, now that I think about it, -n doesn't make sense because any 
 one of the four keys can open the volume as needed to blow away the
 masterkey.
 
 The manual page should just be fixed.

Should the '-n -1' just be removed?  I.e., is 'gbde destroy' sufficient to 
destroy all copies of the key?


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gbde destroy doesn't match man page?

2014-08-26 Thread Poul-Henning Kamp

In message 201408261723.53428@freebsd.org, John Baldwin writes:

 Hmm, now that I think about it, -n doesn't make sense because any 
 one of the four keys can open the volume as needed to blow away the
 masterkey.
 
 The manual page should just be fixed.

Should the '-n -1' just be removed?  I.e., is 'gbde destroy' sufficient to 
destroy all copies of the key?

(Sorry about previous empty reply)

Yes, the -n isn't needed because it doesn't operate on any specific key
but all of them. 

This differs from for instance setkey where you may use key number
1 to set a new key number 2.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: gbde destroy doesn't match man page?

2014-08-23 Thread Poul-Henning Kamp

In message 20140820215522.ga92...@bewilderbeast.blackhelicopters.org, Michae
l W. Lucas writes:

Playing with GBDE for my FreeBSD disk book, on:

# uname -a
FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 
11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC  amd64

According to the man page, I should be able to destroy all copies of
the key with gbde destroy device -n -1. It's in the examples. When I
try it I get:

I think that is an oversight in the code.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Change top's notion of idle processes / threads

2014-05-23 Thread Poul-Henning Kamp
In message 201405231605.26312@freebsd.org, John Baldwin writes:

In essence, top will consider any thread that has run on a CPU 
since the last update as non-idle.

Sounds a lot more usable than the current heuristic.

Wouldn't ki_rusage.ru_n[i]vcsw be more correct than ki_runtime ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: current -r262780 explodes on wlan up

2014-03-06 Thread Poul-Henning Kamp
In message 1611.1394047...@critter.freebsd.dk, Poul-Henning Kamp writes:

Just tried a current kernel -r 262780 on my laptop.

When wlan0 comes up (if_iwn) it explodes with something about witness
and rtentry.c, but it clears the screen before I can get a photo...

-r262832 works.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


current -r262780 explodes on wlan up

2014-03-05 Thread Poul-Henning Kamp

Just tried a current kernel -r 262780 on my laptop.

When wlan0 comes up (if_iwn) it explodes with something about witness
and rtentry.c, but it clears the screen before I can get a photo...

Looks trivial to reproduce.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Import of DragonFly Mail Agent

2014-02-24 Thread Poul-Henning Kamp
In message 530b13ca.6000...@rewt.org.uk, Joe Holden writes:
On 24/02/2014 04:26, Julio Merino wrote:
 On Sun, Feb 23, 2014 at 4:11 PM, Baptiste Daroussin b...@freebsd.orgwrote:

 As some of you may have noticed, I have imorted a couple of days ago dma
 (DragonFly Mail Agent) in base. I have been asked to explain my motivation
 so here they are.

 I'd argue, for example, that postfix can be also easily configured and can
 be made to not listen on port 25 for local mail delivery, while at the same
 time it is a fully-functional MTA that could replace sendmail altogether.

The trend towards having sensible lightweight things in the base is a 
good thing IMO.

Fully agree.

To the extent we can manage it, we should have minimal client-focused
tools for things like DNS, SMTP and NTP in the tree and make it
trivial for people to install the fully featured server version of
their choice from ports.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Import of DragonFly Mail Agent

2014-02-24 Thread Poul-Henning Kamp
In message 530b2500.5030...@rewt.org.uk, Joe Holden writes:

Can I also suggest that ntp.org shouldn't be in the base either? :P

I absolutely agree, but the replacement is less clear in that case.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Import of DragonFly Mail Agent

2014-02-24 Thread Poul-Henning Kamp
In message 530b2953.3030...@rewt.org.uk, Joe Holden writes:

 openntpd not able to authenticate the sources it is using and thus lack a big
 ntp feature as a client.

Last I looked its clock-discipline algorithm were non-existent, it just
slammed the clock around.

hm, I can't say I have noticed this as being a problem where I've used 
it, are there any scenarios where this is a showstopper?

Yes, for this date and time it is a showstopper.



-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: ntpd replacement (Was: Re: Import of DragonFly Mail Agent)

2014-02-24 Thread Poul-Henning Kamp
In message 530b2dee.3030...@rewt.org.uk, Joe Holden writes:

The other point I should make here is that if you care that much about 
time security you shouldn't be contacting ntp servers over 3rd party 
networks anyway, at least not without some IP-level 
encryption/authentication, or use a source that can't easily be used as 
an attack surface, such as GPS/MSF etc.

Please check how NTP is authenticated before giving bad advice,
it's all in the RFC.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: ntpd replacement (Was: Re: Import of DragonFly Mail Agent)

2014-02-24 Thread Poul-Henning Kamp
In message 530b666a.1000...@rewt.org.uk, Joe Holden writes:

 Please check how NTP is authenticated before giving bad advice,
 it's all in the RFC.

v3 or v4? It is an optional part of the spec in both cases and again 
isn't required for 99% of people using ntpd as a client, which was the 
entire point of this exercise in the first place.

Authentication of NTP is rapidly gaining focus these days, for obvious
reasons, so I think adopting software now which don't support it would
be needlessly shortsighted.

3 years ago I would have agree with you, but not now.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Import of DragonFly Mail Agent

2014-02-24 Thread Poul-Henning Kamp
In message d39456d8-88d1-4617-825c-44b30890f...@orthanc.ca, Lyndon Nerenberg 
writes:

Try this in a shop where all your machines are completely air-gapped
from the internet.

Bullshit.

You got FreeBSD in there in the first place, there clearly
is some kind of aperture through which software can migrate.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Import of DragonFly Mail Agent

2014-02-24 Thread Poul-Henning Kamp
In message acbddbe2-34c5-4f8d-8803-d42686c52...@orthanc.ca, Lyndon Nerenberg 
writes:

On Feb 24, 2014, at 7:56 AM, Poul-Henning Kamp p...@phk.freebsd.dk =
wrote:

 Bullshit.

Sounds like your week didn't get off to a good start.

No, I'm simply calling your argument bullshit, because it is.

 You got FreeBSD in there in the first place, there clearly
 is some kind of aperture through which software can migrate.

Yes, we walk in a DVD-ROM with a FreeBSD installation image on it.

So put your packages on there as well, if they're not already there
(did you even check ?)

Or do a cd /usr/ports  make fetch and write a (number of ?) DVD's with 
the resulting distfiles, and carry those behind the firewall, knowing
that you have 20k pieces of software including NetHack and and an
INTERCAL compiler, so you will never be bored, no matter how long
airgap remains open.

I've been doing exactly that since 1998 and I know it is both
trivially easy and wonderfully assuring to the customer when you
can tell them:  *All* the source code is here, and you are running
a system verifiably compiled from it.

Just recently one of those old but still running FreeBSD systems
were plucked out for a random audit.  They found the CD's in storage,
installed the FreeBSD 2.2.5 on a machine, also from storage,
recompiled everything from sources, built the embedded image,
installed the image and passed all the test-cases.

And yes, now we're talking about a much overdue upgrade.

QED:  Bullshit.

And no, we obviously should not move /bin/sh to ports, but
software maintained by compet^H^H^H^H^H^capable projects
outside of FreeBSD should not be imported into FreeBSD
absent compelling reasons, and already imported software
should be constantly scrutinized to see if there are better
solutions.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: r259072 is not a happy camper...

2013-12-18 Thread Poul-Henning Kamp
In message 201312181458.20649@freebsd.org, John Baldwin writes:

 Does it get a crashdump if you try?
 
 No :-(
 
 There may be a connection to unclean UFS filesystems (SU + TRIM, no J).

Is this reproducible?

Not really.

It seems to happen at random, usually shortly after boot and as I
mentioned, there is some indications of it being related to munged
filesystems.

Amongst these indications:

Booting single-user and running fsck (without -p) almost always
prevents it from happening until after next crash, and I think all
the backtraces I've see have been UFS or maybe even WITNESS+UFS
related.

If it is WITNESS related, the serial console is obviously a
prime suspect...

But all that said, I havn't seen it for a couple of days...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: r259072 is not a happy camper...

2013-12-14 Thread Poul-Henning Kamp
In message 201312131620.25107@freebsd.org, John Baldwin writes:

 Hmmm.  Maybe do 'show lapic' and 'show apic' in ddb and paste that here?
 
 sorry about the delay...
 
 db show lapic
 lapic ID = 2
 version  = 1.0
 max LVT  = 5
 SVR  = ff (enabled)
 TPR  = 00
 In-service Interrupts:

Hmm, this is empty.  It should not be empty. :(

Never the less, the panic is further down than I thought it was.  The system 
thinks it had a valid IRQ that required an ithread to be scheduled, but when
it went to schedule the ithread, there was no thread to schedule:

Does it get a crashdump if you try?

No :-(

There may be a connection to unclean UFS filesystems (SU + TRIM, no J).

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: r259072 is not a happy camper...

2013-12-13 Thread Poul-Henning Kamp
In message 201312091216.04052@freebsd.org, John Baldwin writes:
On Saturday, December 07, 2013 2:32:56 pm Poul-Henning Kamp wrote:
 
 kdb_backtrace() at kdb_backtrace+0x39/frampanic: bad stray interrupt
 cpuid = 2
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
 0xfe011120e9e0
 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011120ea90
 vpanic() at vpanic+0x126/frame 0xfe011120ead0
 kassert_panic() at kassert_panic+0x136/frame 0xfe011120eb40
 intr_event_handle() at intr_event_handle+0x11d/frame 0xfe011120eb90
 intr_execute_handlers() at intr_execute_handlers+0x48/frame 
 0xfe011120ebc0
 lapic_handle_intr() at lapic_handle_intr+0x73/frame 0xfe011120ebf0
 Xapic_isr1() at Xapic_isr1+0xa4/frame 0xfe011120ebf0
 --- interrupt, rip = 0x11f7b11, rsp = 0x7fff8b50, rbp = 0x7fff8b80 
 ---
 KDB: enter: panic
 [ thread pid 72149 tid 100102 ]
 Stopped at  kdb_enter+0x3e: movq$0,kdb_why
 db 

Hmmm.  Maybe do 'show lapic' and 'show apic' in ddb and paste that here?

sorry about the delay...

db show lapic
lapic ID = 2
version  = 1.0
max LVT  = 5
SVR  = ff (enabled)
TPR  = 00
In-service Interrupts:
TMR Interrupts:
IRR Interrupts:
irr1: 30
irr7: f9
db show apic
Interrupts bound to lapic 0
vec 0x31 - IRQ 0
vec 0x32 - IRQ 8
vec 0x33 - IRQ 256
vec 0x34 - IRQ 257
vec 0x35 - IRQ 258
vec 0x36 - IRQ 259
vec 0x3b - IRQ 264
vec 0x40 - IRQ 269
vec 0x42 - IRQ 16
vec 0x48 - IRQ 21
vec 0x4a - IRQ 7
vec 0xef - lapic timer
Interrupts bound to lapic 1
vec 0x30 - IRQ 1
vec 0x31 - IRQ 9
vec 0x32 - IRQ 17
vec 0x33 - IRQ 22
vec 0x34 - IRQ 260
vec 0x35 - IRQ 265
vec 0xef - lapic timer
Interrupts bound to lapic 2
vec 0x30 - IRQ 4
vec 0x31 - IRQ 14
vec 0x32 - IRQ 18
vec 0x33 - IRQ 261
vec 0x34 - IRQ 263
vec 0x35 - IRQ 266
vec 0xef - lapic timer
Interrupts bound to lapic 3
vec 0x30 - IRQ 6
vec 0x31 - IRQ 15
vec 0x32 - IRQ 19
vec 0x33 - IRQ 262
vec 0x34 - IRQ 267
vec 0x35 - IRQ 268
vec 0xef - lapic timer


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


r259072 is not a happy camper...

2013-12-07 Thread Poul-Henning Kamp

I updated my canary machine to -current today and it's not a happy
camper.  Trying to run a buildworld on it I get the follwing reproducible
panic:

FreeBSD/amd64 (ni.freebsd.dk) (cuau0)

login: lock order reversal:
 1st 0xf8011641a9a0 ufs (ufs) @ /freebsd/head/sys/kern/vfs_lookup.c:518
 2nd 0xfe00e7858790 bufwait (bufwait) @ /freebsd/head/sys/ufs/ffs/ffs_vnops
.c:262
 3rd 0xf800b40ad5f0 ufs (ufs) @ /freebsd/head/sys/kern/vfs_subr.c:2101
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0111361da0
kdb_backtrace() at kdb_backtrace+0x39/frampanic: bad stray interrupt
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011120e9e0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe011120ea90
vpanic() at vpanic+0x126/frame 0xfe011120ead0
kassert_panic() at kassert_panic+0x136/frame 0xfe011120eb40
intr_event_handle() at intr_event_handle+0x11d/frame 0xfe011120eb90
intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe011120ebc0
lapic_handle_intr() at lapic_handle_intr+0x73/frame 0xfe011120ebf0
Xapic_isr1() at Xapic_isr1+0xa4/frame 0xfe011120ebf0
--- interrupt, rip = 0x11f7b11, rsp = 0x7fff8b50, rbp = 0x7fff8b80 ---
KDB: enter: panic
[ thread pid 72149 tid 100102 ]
Stopped at  kdb_enter+0x3e: movq$0,kdb_why
db 

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


  1   2   3   4   5   6   7   8   9   10   >