Re: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)

2020-09-16 Thread Poul-Henning Kamp

Warner Losh writes:

> I too can report this for my Lenovo Yoga running code as of September 13,
> but with manu's latest drm...  It used to work fine, but my last build on
> the system was from May. Most likely a new panic in that code path, but
> I've not chased down further...

My T480 runs:

FreeBSD 13.0-CURRENT #1 r364533M: Mon Aug 24 00:02:01 UTC 2020

and

drm-devel-kmod-5.3.g20200724

And I have not seen any suspend/resume problems.


-- 
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: Please check the current beta git conversions

2020-09-01 Thread Poul-Henning Kamp

Goran Mekić writes:

> While I can clone src nicely, it is very slow in Serbia/Europe. The best
> speed I got is 1.45MB/s but it's mostly around 700kB/s (still cloning). 

I was about to ask about that:

Any guidance on amount of diskspace and how long it takes to clone the repo ?


-- 
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: Does FreeBSD have an assigned Internet OID?

2020-08-29 Thread Poul-Henning Kamp

Rick Macklem writes:
> Poul-Henning Kamp wrote:

> Is https://reviews.freebsd.org/D26225
> sufficient to allow me to use 1.3.6.1.4.1.2238.1.1.1 for a user@domain
> name in this otherName component of subjAltName in the X.509 cert?
> (I didn't list the UserName as the first item of the subtree. Should I?)

You should add a comment about how suballocations (if allowed) happens
under that branch.

> Do I need to update the date/time for LAST-UPDATED and REVISION
> when I commit it, I'd guess?

Yes please.

-- 
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: Does FreeBSD have an assigned Internet OID?

2020-08-27 Thread Poul-Henning Kamp

Rick Macklem writes:
> For the NFS over TLS work, I have a need for an Internet OID.
> (I understand that IETF assigns ones for things like SNMP under
> 1.3.6.1.4.1...)

See:

/usr/share/snmp/mibs/FREEBSD-MIB.txt

-- 
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: KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp

Michael Gmelin writes:
> 
>
> > On 29. Jul 2020, at 21:29, Poul-Henning Kamp  wrote:
> > 
> > Michael Gmelin writes:
> > 
> >> I meant which xorg driver - modesetting or Intel?
> > 
> > It looks like "modesetting":
> > 
>
> You could try installing xf86-video-intel and see if that makes a difference
> (in terms of artifacts, can't imagine it has anything to do with the focus 
> issue?!).

That seems to have taken care of the scroll-bar flickering, will see how
it goes.

-- 
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: KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp

Michael Gmelin writes:

> I meant which xorg driver - modesetting or Intel?

It looks like "modesetting":

[   149.032] (II) Loading 
/usr/local/lib/xorg/modules/extensions/libglx.so
[   149.038] (II) Module glx: vendor="X.Org Foundation"
[   149.038]compiled for 1.20.8, module version = 1.0.0
[   149.038]ABI class: X.Org Server Extension, version 10.0
[   149.038] (==) Matched intel as autoconfigured driver 0
[   149.038] (==) Matched modesetting as autoconfigured driver 1
[   149.038] (==) Matched scfb as autoconfigured driver 2
[   149.038] (==) Matched vesa as autoconfigured driver 3
[   149.038] (==) Assigned the driver to the xf86ConfigLayout
[   149.038] (II) LoadModule: "intel"
[   149.038] (WW) Warning, couldn't open module intel
[   149.038] (EE) Failed to load module "intel" (module does not exist, 
0)
[   149.038] (II) LoadModule: "modesetting"
[   149.038] (II) Loading 
/usr/local/lib/xorg/modules/drivers/modesetting_drv.so
[   149.039] (II) Module modesetting: vendor="X.Org Foundation"
[   149.039]compiled for 1.20.8, module version = 1.20.8
[   149.039]Module class: X.Org Video Driver
[   149.039]    ABI class: X.Org Video Driver, version 24.1

-- 
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: KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp

Michael Gmelin writes:

> Which driver are you using?

drm-devel-kmod-5.3.g20200724

dmesg:

drmn0:  on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Unable to create a private tmpfs mount, hugepage support will be 
disabled(-19).
__pm_runtime_resume not implemented -- see your local kernel hacker
pm_runtime_mark_last_busy not implemented -- see your local kernel 
hacker
__pm_runtime_suspend not implemented -- see your local kernel hacker
Failed to add WC MTRR for [0x8000-0x9fff]: -22; performance may 
suffer
[drm] Got stolen memory base 0x7d80, size 0x200
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] Connector eDP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.eDP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-2
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-2
[drm]   - kern.vt.fb.default_mode
pm_runtime_get_if_in_use not implemented -- see your local kernel hacker
kmem_cache_shrink not implemented -- see your local kernel hacker
kmem_cache_shrink not implemented -- see your local kernel hacker
kmem_cache_shrink not implemented -- see your local kernel hacker
kmem_cache_shrink not implemented -- see your local kernel hacker
register_oom_notifier not implemented -- see your local kernel hacker
kmem_cache_shrink not implemented -- see your local kernel hacker
kmem_cache_shrink not implemented -- see your local kernel hacker
kmem_cache_shrink not implemented -- see your local kernel hacker
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] Initialized i915 1.6.0 20190619 for drmn0 on minor 0
register_acpi_notifier not implemented -- see your local kernel hacker
async_schedule is dodgy -- see your local kernel hacker
pm_runtime_set_autosuspend_delay not implemented -- see your local 
kernel hacker
__pm_runtime_use_autosuspend not implemented -- see your local kernel 
hacker
async_synchronize_cookie not implemented -- see your local kernel hacker
acpi_video0:  on vgapci0
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 
13.0.
VT: Replacing driver "vga" with new "fb".
[drm] Reducing the compressed framebuffer size. This may lead to less 
power savings than a non-reduced-size. Try to increase stolen memory size if 
available in BIOS.
start FB_INFO:
type=11 height=1080 width=1920 depth=32
cmsize=16 size=14745600
pbase=0x8004 vbase=0xf8008004
name=drmn0 flags=0x0 stride=10240 bpp=32
cmap[0]=0 cmap[1]=7f cmap[2]=7f00 cmap[3]=c4a000
end FB_INFO
drmn0: fb0: i915drmfb frame buffer device
drmn0: successfully loaded firmware image with name: 
i915/kbl_dmc_ver1_04.bin
[drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)


-- 
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: KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp

Ed Maste writes:
> On Wed, 29 Jul 2020 at 06:20, Poul-Henning Kamp  wrote:
> >
> > I just noticed that KiCad's scroll-bars flash a lot whenever the mouse
> > pointer is moved, that sounds like it could be the focus-event-flooding.
>
> For me KiCad's scroll bars are hidden, and flash briefly on and off
> while the pointer's moving. This is with a USB mouse (trackball)
> attached, and xfwm4.

I'm seing similar stuff, and sometimes I am also seeing some screen
artifacts which could implicate DRM :-(

-- 
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: KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp

Christoph Moench-Tegeder writes:

> KiCad maintainer writing.

Many thanks maintaining KiCad, it's one of the tools I cannot live without.

> > One of the few diagnostics I see related to this is:
> > 
> > 07:33:34: Debug: window wxScrolledWindow(0x81a3f8000, ) lost focus even
>  though it didn't have it
>
> But this message exists even here. It's from wxWidgets (wx31-gtk3,
> pulled in via wxPython) and the whole wx-thingy is slightly messy...
> Anyways, I'd think this message itself is harmless.

Ok, I will disregard 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: KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp

Poul-Henning Kamp writes:
> 
> Michael Gmelin writes:
>
> > I might try to reproduce the issue myself later this week (if I happen
> > to find some time and nobody else comes up with a solution). Which WM
> > are you using?
>
> I just noticed that KiCad's scroll-bars flash a lot whenever the mouse
> pointer is moved, that sounds like it could be the focus-event-flooding.

I just checked: my x11-server is also -current as of sunday, so that
D245854 patch is in place.

-- 
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: KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp

Michael Gmelin writes:

> I might try to reproduce the issue myself later this week (if I happen
> to find some time and nobody else comes up with a solution). Which WM
> are you using?

I just noticed that KiCad's scroll-bars flash a lot whenever the mouse
pointer is moved, that sounds like it could be the focus-event-flooding.

I'm using ctwm :-)

-- 
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: KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp

Michael Gmelin writes:

> This sounds a bit like it could be related to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245854

That sounds like something in the same zip code.

> Two easy things you could check:
> - try connecting a usb mouse (to rule out synaptics being the issue).

Dont have any at hand this week :-(

> - try using a different WM and see if the problem persists.

I dont see any reason to think this is WM related, it happens while
the cursor stays firmly inside kicad's windows.

-- 
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: KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp

Hans Petter Selasky writes:

> Try to install "xev" and see if the log is full of events.

I only see problems in kicad, everything else, including firefox
and xev works fine (as far as I can tell)

-- 
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"


KiCad is horrible on CURRENT

2020-07-29 Thread Poul-Henning Kamp
I updated to current three days ago:

13.0-CURRENT #0 r363533M: Sun Jul 26 08:39:48 UTC 2020 

When I start cad/kicad (which I have not done in some time), the
gui is horribly lagging and often downright confused about
the cursors whereabouts.

I've tried switching between "fall-back" and "accellerated"
in kicad, but there does not seem to be any qualitative
difference.

One of the few diagnostics I see related to this is:

07:33:34: Debug: window wxScrolledWindow(0x81a3f8000, ) lost focus even 
though it didn't have it

I have no idea if this is a kicad, Xorg or libinput related.

In my Xorg log I have a lot of (rate-limited):

 SynPS/2 Synaptics TouchPad: kernel bug: Touch jump detected and 
discarded.

-- 
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: Weird mouse behaviour

2020-04-27 Thread Poul-Henning Kamp

In message <65670198-e725-5b66-646c-5b147c943...@daemonic.se>, Niclas Zeising 
writes:

>With my touchpad, ctrl left click and ctrl right click opens two 
>different menus in xterm, main menu and vt font menu, respectively.

ctrl-middle should open "VT Options" 

-- 
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: Weird mouse behaviour

2020-04-27 Thread Poul-Henning Kamp

In message <7549a5dd-3edc-4efd-bc0b-4d67232b4...@grem.de>, Michael Gmelin 
writes:

>> In my case, with the default
>> 
>>sysctl kern.evdev.rcpt_mask=12
>> 
>> CTRL + middle button would not activate the menu in xterm.
>> 
>
>Are you using the trackpoint?

No, the touchpad.

>Did you set the trackpoint sysctl?
>(hw.psm.trackpoint_support=1)

That seems to default to one ?

-- 
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: Weird mouse behaviour

2020-04-27 Thread Poul-Henning Kamp

In message <6dfad31c-68f2-c38f-28ac-0696e73b4...@daemonic.se>, Niclas Zeising 
writes:
>On 2020-04-27 08:03, Malcolm Matalka wrote:
>> I saw that there was another thread on this and I wanted to throw my
>> experience in: my mouse was sluggish and tap-to-click did not work.  I
>> set the evdev mask back to 3 and it worked.
>> 
>> I am on a Dell XPS 13.
>
>Hi!
>Is this on CURRENT?  When using X?
>Can you verify that you have xf86-input-libinput installed?

In my case yes, this is CURRENt and I have xf86-input-libinput-0.29.0

In my case, with the default

sysctl kern.evdev.rcpt_mask=12

CTRL + middle button would not activate the menu in xterm.


-- 
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: Weird mouse behaviour

2020-04-27 Thread Poul-Henning Kamp

In message <86imhlv518@gmail.com>, Malcolm Matalka writes:
>I saw that there was another thread on this and I wanted to throw my
>experience in: my mouse was sluggish and tap-to-click did not work.  I
>set the evdev mask back to 3 and it worked.

Thanks!  That helped a lot with my sanity on my T480

-- 
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: buildkernel failure because ctfconvert not installed

2020-04-10 Thread Poul-Henning Kamp

In message <9f03fb79-a0ad-3c11-9a50-bc7731882...@fastmail.com>, Yuri Pankov 
writes:
>Trond Endrestøl wrote:
>> On Thu, 9 Apr 2020 10:56+0200, Gary Jennejohn wrote:
>> 
>>> OK, I figured it out.
>>>
>>> I used to have MK_CTF=no in src.conf, but I recently changed it to
>>> WITH_CTF=no.
>> 
>> It's either WITH_xxx=yes or WITHOUT_xxx=yes.
>
>Or even WITH_xxx= or WITHOUT_xxx=, src.conf(5) explicitly states that 
>value is NOT checked:
>
>The values of variables are ignored regardless of their setting; even if 
>  they would be set to "FALSE" or "NO".  The presence of an option 
>causes it to be honored by make(1).

That is not even close to POLA-compliance...

Obviously negative values ("false", "no") should either be reported as
errors or preferably be respected.

PS: [This is not the bikeshed you are looking for]
 

-- 
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: New Xorg - different key-codes

2020-03-11 Thread Poul-Henning Kamp

In message , Niclas Zeising w
rites:

>This has to do with switching to using evdev to handle input devices on 
>FreeBSD 12 and CURRENT.  There's been several reports, and suggested 
>solutions to this, as well as an UPDATING entry detailing the change.

I don't think I would have thought the rather counter-intuitive
behaviour I saw yesterday, even if you had told me in those very
words that the scan-codes had changed :-)

-- 
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 Xorg - different key-codes

2020-03-10 Thread Poul-Henning Kamp
I just updated my laptop from source, and somewhere along the
way the key-codes Xorg sees changed.

I have the right Alt key mapped to "Multi_key", which is now
keycode 108 instead of 113, which is now arrow left instead.

I hope this email saves somebody else from the frustrating
morning I had...

-- 
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: M_TEMP trouble in 13.0-CURRENT #0 r355131M

2020-01-13 Thread Poul-Henning Kamp


Just to conclude this:

Whatever is in 13.0-CURRENT #1 r356602M has solved the problem.

-- 
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"


M_TEMP trouble in 13.0-CURRENT #0 r355131M

2020-01-09 Thread Poul-Henning Kamp
I noticed yesterday that M_TEMP stats are screwed up, and rebooted my
laptop for reasons of safety.

However, it's back again now:

critter phk> vmstat -m | grep temp
temp 18446744073709546036 18014398509476380K   -   963239  
16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536

FreeBSD critter.freebsd.dk 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355131M: Wed 
Nov 27 16:44:48 UTC 2019 
r...@critter.freebsd.dk:/usr/obj/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG  
amd64

I mentioned this on IRC yesterday and noted I had a "disk full" on
a tmpfs mount, but that can now be disregarded as a false lead.

On this kernel I have had an instance where X got killed for
out-of-swap, at a time where that certainly should not have been
the case.

Am I the only one seeing 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: ZFS with 32-bit, non-x86 kernel

2019-10-04 Thread Poul-Henning Kamp

In message , Ian Le
pore writes:

>There have also been some bug reports as recently as 2017 indicating
>that people are still doing this on small armv7 systems.

I actually have a potential off-site backup server in my lab right now,
consisting of a BeagleBoneBlack and two USB disks, seems to work.

The basic scheme is a cronjob which:

zfs import inl
run various rsyncs
zfs snapshot -r inl@$YYMMDDHHMM
zfs export inl

The import/export is so the USB disks spin down.

Not sure if ZFS will croak the 512M RAM on other workloads, but for
this one it seems to work fine so far.

-- 
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: Booting anything after r352057 kills console

2019-09-23 Thread Poul-Henning Kamp

In message 

, Warner Losh writes:

>We are working on making drm ports less problematic on upgrade...

Yes, I know.

But when you track current, it seems that it takes a port-reinstall
to get on that wagon...

-- 
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: Booting anything after r352057 kills console

2019-09-23 Thread Poul-Henning Kamp

In message <11db909b-57ee-b452-6a17-90ec2765c...@acm.org>, Thomas Laus writes:

>Where do I go from here?  The computer is an Intel i5 Skylake with
>onboard graphics.

Based on personal experience:

1. Deinstall drm ports

2. Remove all remaining drm related files under /boot

3. Reinstall drm 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: wlan can't discover known networks after relocating

2019-09-17 Thread Poul-Henning Kamp

In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org>, Johannes Lundber
g writes:

>For a long time now I have had this problem with iwm and wlan0. Whenever
>I move between work and home it won't reconnect automatically and I have
>to do wlan0 scan manually for it to pick up the different network.

I suffer from the dreaded "reason=0" when I move inside my house:

> scan
OK
<3>CTRL-EVENT-SCAN-RESULTS 
<3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' 
freq=2452 MHz)
<3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9 reason=0
<3>CTRL-EVENT-SCAN-RESULTS 
<3>Trying to associate with 6c:3b:6b:ab:ce:d4 (SSID='Palombia' 
freq=2412 MHz)
<3>Associated with 6c:3b:6b:ab:ce:d4

a2:e9 is the loudest AP here in my office, but my I have been in the
other end of the house iwn consistently fails to associate with it and
and keeps picking the weaker AP in the far end.

Eventually (hours!) it disconnects from the weaker ap, also with
"reason=0" and gets it right:

<3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4 [GTK=CCMP]
<3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4 reason=0
<3>CTRL-EVENT-SCAN-RESULTS 
<3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' 
freq=2452 MHz)
<3>Associated with 6c:3b:6b:3d:a2:e9
<3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9 [PTK=CCMP 
GTK=CCMP]
<3>CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:3d:a2:e9 completed 
[id=3 id_str=]
<3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9 [GTK=CCMP]

And yes, working roaming would be nice too...

-- 
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"


Weird goings on with make::empty()

2019-09-04 Thread Poul-Henning Kamp
On:

Repository Root: svn+ssh://repo.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 351809

I built a kernel, but drm-current-kmod did not get compiled
from the new world order in /usr/local/sys/modules

Debugging I ended up doing this to src/sys/conf/kern.post.mk:

Index: sys/conf/kern.post.mk
===
--- sys/conf/kern.post.mk   (revision 351809)
+++ sys/conf/kern.post.mk   (working copy)
@@ -77,12 +77,14 @@
${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
 .endif
 .for module in ${LOCAL_MODULES}
-.if !empty(module)
+   true "XXX A $(module) 2 ${LOCALBASE} 3 ${LOCAL_MODULES} 4 
${MODULES_WITH_WORLD}"
+#.if !empty(module)
+   true "XXX B $(module) 2 ${LOCALBASE} 3 ${LOCAL_MODULES} 4 
${MODULES_WITH_WORLD}"
@${ECHODIR} "===> ${module} 
(${target:S/^reinstall$/install/:S/^clobber$/cleandir/})"
@cd ${LOCAL_MODULES_DIR}/${module}; ${MKMODULESENV} ${MAKE} \
DIRPRFX="${module}/" \
${target:S/^reinstall$/install/:S/^clobber$/cleandir/}
-.endif
+#.endif
 .endfor
 .endif
 .endfor

This gives me the expected output from buildkernel:

true "XXX A drm-current-kmod 2 /usr/local 3 drm-current-kmod 4 "
true "XXX B drm-current-kmod 2 /usr/local 3 drm-current-kmod 4 "

If I leave in the ".if !empty(module)" line in, I only get:

true "XXX A drm-current-kmod 2 /usr/local 3 drm-current-kmod 4 "

suggestions 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
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: hdac0: Unexpected unsolicited response from address 0: 00000000

2019-08-21 Thread Poul-Henning Kamp

In message <20190821132305.1c11bb9c@hermann>, "Hartmann, O." writes:

>on a Lenovo E540 I get this weird error since I used 12-STABLE/CURRENT

>[...]
>hdac0: Unexpected unsolicited response from address 0: 
>hdac0: Unexpected unsolicited response from address 0: 
>hdac0: Unexpected unsolicited response from address 0: 
>[...]

I used to get a lot of similar-ish noise on my T480, but it seems
to have disappeared with my latest update to -CURRENT.

-- 
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"


Huawei mobile/wifi gadgets: HOWTO

2019-08-16 Thread Poul-Henning Kamp
This seems to be sort of a FAQ, and I had a chance to spend a couple of
quality minutes with one of these devices.

The fundamental problem is that they come up as a CD device, with Windows
software to do whatever it takes.

Sending them a magic USB command enables other interfaces, including
serial/modem, USB ethernet etc.

The remaining issue is: How to get FreeBSD do send the magic string?

A file in /etc/devd along these lines will do it:

notify 1000 {
match "system"  "GEOM";
match "type""CREATE";
match "cdev""iso9660/MOBILEWIFI";
action "/usr/local/sbin/usb_modeswitch -v 0x12d1 -p 0x15ca -J";
};

It works by reacting to the CD device appearing, which seems to be a
sure-fire indication that the device is in wrong mode.

You may have to adjust the precise "cdev" name (ls /dev/iso9660) and
vendor/product numbers (usbconfig dump_device_desc), and obviously
you have to install the usb_modeswitch port.

The -J argument seems to be what all newer Huawei devices want.

Add ifconfig_ue0=DHCP in /etc/rc.conf, and you should be set.

-- 
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: kernel module code coverage

2019-08-08 Thread Poul-Henning Kamp

In message , Slava Shwartsman 
writes:

>Apparently, Bullseye are dropping support for FreeBSD.
>
>We are looking for an alternative for kernel module run time analysis.
>Mostly interested in code coverage (for now).
>
>Any suggestions that work for you?

Back in early days, I fixed it so that all the BB-counter blocks
in the kernel were linked into a list which could be read out through
/dev/(k)mem, and I belive I added a program to do that, named
something like "kernbb".

Today I would probably have made a subtree under sysctl where the counters
could be pulled out per source-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
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CURRENT: supeblock hash failure - CURRENT wrecking disks

2019-08-07 Thread Poul-Henning Kamp

In message <39fb31e6-a8ec-484c-b297-39c19a787...@gmail.com>, Enji Cooper writes
:

There is an "interesting" failure-mechanism when you move a disk
between 13/current and older systems which do not support ufs-hashes.

It will be prudent to make 11 and 12 clear the "use hashes" flags
in the superblocks of all filesystems they mount R/W, to limit
the amount havoc this will cause when people start playing with 13.

-- 
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: i2c bit banging timeout for SCL

2019-07-01 Thread Poul-Henning Kamp

In message 
, Warner 
Losh writes:

>The only issue, really, is that this timeout is a busy loop and there may
>be I/O bus contention introduced on these systems.

Does it have to be a busy loop for the entire duration ?

Spin for the median, timeout+poll for the rest of the 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: i2c bit banging timeout for SCL

2019-07-01 Thread Poul-Henning Kamp

In message , Andriy Gapon 
writes:

>iicbb driver has a hardcoded timeout that defines how long the driver waits for
> SCL line to go high after the driver releases it to float.  Sometimes slaves
>hold the line low until they are ready to continue with the communication.
>As a side note, the timeout means that the driver just goes on as if the line
>became high.  Maybe it should produce an error instead.
>
>Anyway, I would like to increase the current timeout of 100 x 10us to 1000 x
>10us.  The rationale is that there are many slave devices, like sensors, that
>take about 10 ms to return a result.  So, I think that it makes sense to play
>nice with such devices by default.
>
>Probably I'll add a sysctl for that parameter while I'll be there.

sysctl or ioctl ?

-- 
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: 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


  1   2   3   4   5   6   7   8   9   10   >