Re: CURRENT userland does not compile due to games/glorkz

[Jyri Hovila [Turvamies.fi]]

>> rebuild a new kernel, *reboot*, and next launch your make build.

> That is the wrong advice.  it is too precise and may still fail.

> The correct advice is: Upgrade to a snapshot.

> That is always the correct advice.

Theo, as an Asperger, I just love how you communicate yourself! =D

This time, however, the "wrong" advice was the right one -- for me, since I 
really don't want to do binary upgrades.

-j.
--
+358-404-177133 (24/7)
jyri.hov...@turvamies.fi

Re: latest iridium-browser on amd64-current => solved

[Stefan Wollny]

On 09.11.18 10:25, Stefan Wollny wrote:

[ ... ]

Thank you, robert@! Iridium is fine again.

Re: CURRENT userland does not compile due to games/glorkz

[Janne Johansson]

Den mån 12 nov. 2018 kl 09:00 skrev Jyri Hovila [Turvamies.fi]
:
> Theo: > Upgrade to from a snap.
> Thanks, but: NO! XD
> Seriously: As crazy as it may sound, I'm very stubborn about following the 
> CURRENT without taking shortcuts.

It's not a shortcut, it is how it's done. It is not cheating, or
dodging or anything, the docs are very clear on that for any
non-trivial situation where you want to go to -current, you start with
upgrading into as recent snapshot as possible, then build from there.
Period. It's fine if you want to waste your own time, but this is the
one single method of getting out of many holes, like yours.

-- 
May the most significant bit of your life be positive.

support new

[Stier, Sarah]

Hi there, 

Please find all information below: 

0
C Germany
P Berlin
T Berlin
Z 10119
O SMLan Software und Management Training
I Guenter Doerfler
A Kastanienallee 53
M mailto:i...@smlan.de 
U https://www.smlan.de/
B 0049 30 4492545
X 0049 30 43 73 57 59
N BSD and Linux training and consulting. Over 10 years of experience. 


Thank you and best wishes, 
Sarah 

support new

[Stier, Sarah]

Hi there,

Please find all information below:

0
C Germany
P Berlin
T Berlin
Z 10119
O SMLan Software und Management Training
I Guenter Doerfler
A Kastanienallee 53
M i...@smlan.de
U https://www.smlan.de/
B 0049 30 4492545
X 0049 30 43 73 57 59
N BSD and Linux training and consulting. Over 10 years of experience.


Thank you and best wishes,
Sarah
...
[logo_b2]

Software & Management Training
Sarah Stier, Seminarberatung
Tel: 030 - 449 25 45 | E-Mail: sarah.st...@smlan.de

Adresse: SMLAN | Kastanienallee 53 | 10119 Berlin
E-Mail: i...@smlan.de | Web: 
www.smlan.de
Powered by NetQuest GmbH | USt-IdNr.: DE813387728 | HRB 8735 Fürth

Re: CURRENT userland does not compile due to games/glorkz

[Jyri Hovila [Turvamies.fi]]

> It's not a shortcut,

This, as many things in this world, completely depend on the point of view.

One can not simply say "this is this" or "this is not this", without sufficient 
background information and overall understanding of the situation as a whole.

> it is how it's done.

Again: "how it is done" depends completely on the situation, the people and the 
technology involved, etc.
 
> It is not cheating, or
> dodging or anything,

Did I say something that made you think the opposite?

> the docs are very clear on that for any
> non-trivial situation where you want to go to -current,

Dear Janne, I warmly recommend you should broaden the way you look into 
situations like this.

You're clearly taking it all from a "tech first" perspective.

In real life, and especially when companies (and customers) are involved, it's 
not all just about tech, and how things are done are definitely not defined by 
any single software vendor, operating system etc. Many other factors come into 
play as well, and taking a "you just haven't read the rules" approach only 
makes you look a bit simple.

> you start with
> upgrading into as recent snapshot as possible, then build from there.

Having made my first OpenBSD mailing list post at around 2003 and having 
maintained hundreds of OpenBSD servers for years -- don't you think I might by 
now know, how the official recommended process goes?

There are specific reasons to why I'm not following the official process 100%.

You may agree or disagree on the reasons and the conclusions, but you can't 
make the world function as you would like to by simply repeating "it has been 
written". Many have tried that and I haven't seen a single success this far.

> Period.

=D

>  It's fine if you want to waste your own time, but this is the
> one single method of getting out of many holes, like yours.

It is also perfectly fine if you want to ignore how the real world functions, 
and/or give a super irritating / dislikable impression of yourself and your 
personality. To give you back just a little, it certainly seems you know your 
holes well enough.

-j.



--
+358-404-177133 (24/7)
jyri.hov...@turvamies.fi

support new

[Stier, Sarah]

0
C Germany
P Berlin
T Berlin
Z 10119
O SMLan Software und Management Training I Guenter Doerfler A Kastanienallee 53 
M mailto:i...@smlan.de U https://www.smlan.de/ B 0049 30 4492545 X 0049 30 43 
73 57 59 N BSD and Linux training and consulting. Over 10 years of experience. 

Re: support new

[Stefan Sperling]

On Mon, Nov 12, 2018 at 09:56:04AM +, Stier, Sarah wrote:
> Hi there, 
> 
> Please find all information below: 
> 
> 0
> C Germany
> P Berlin
> T Berlin
> Z 10119
> O SMLan Software und Management Training
> I Guenter Doerfler
> A Kastanienallee 53
> M mailto:i...@smlan.de 
> U https://www.smlan.de/
> B 0049 30 4492545
> X 0049 30 43 73 57 59
> N BSD and Linux training and consulting. Over 10 years of experience. 
> 
> 
> Thank you and best wishes, 
> Sarah 

Hi Sarah,

It is unclear to me how your offering relates to OpenBSD.
I cannot find any mention of OpenBSD on your website.

A search for "openbsd" with your website's own search box only
brings up 4 unrelated results:
  Seminar FreeBSD Administration
  Seminar Samba-Server
  Seminar Unix Netzwerkadministration
  Seminar Internetanbindung Workshop

It doesn't look like your site meets our criteria for entries
on https://www.openbsd.org/support.html, which explicitly states
that "we may at any time, and without notification, remove your
entry if it is found to be inaccurate, if your website is broken,
or if there is no mention of OpenBSD on it."
^^^

If you do indeed have OpenBSD-specific offerings, please add information
about them to your site first, and then re-submit your entry. Thanks.

support new

[Jyri Hovila [Turvamies.fi]]

0
C Finland
P Kymenlaakso
T Kouvola
Z 46900
O Turvamies tietoturvapalvelut (Turvamies IT Security Services)
I Jyri Hovila
A Opistonkuja 1
M i...@turvamies.fi
U https://turvamies.fi/
B +358-404-177133
X n/a
N Finnish specialists in OpenBSD based servers, firewalls and secure 
communications systems.

Re: support new

[Stefan Sperling]

On Mon, Nov 12, 2018 at 12:50:03PM +0200, Jyri Hovila [Turvamies.fi] wrote:
> 0
> C Finland
> P Kymenlaakso
> T Kouvola
> Z 46900
> O Turvamies tietoturvapalvelut (Turvamies IT Security Services)
> I Jyri Hovila
> A Opistonkuja 1
> M i...@turvamies.fi
> U https://turvamies.fi/
> B +358-404-177133
> X n/a
> N Finnish specialists in OpenBSD based servers, firewalls and secure 
> communications systems.
> 

Added, thanks.
I left out "X n/a" because it that is an optional field anyway.

support new

[info]

0
C Germany
P Berlin
T Berlin
Z 10119
O SMLan Software und Management Training
I Guenter Doerfler
A Kastanienallee 53
M mailto:i...@smlan.de
U https://www.smlan.de/seminarthemen/alle/freebsd-administration
B 0049 30 4492545
X 0049 30 43 73 57 59
N BSD and Linux training and consulting. Over 10 years of experience.

Re: recommended h/w for fanless audio-out?

[Colin Bortner]

Hi Adam

‐‐‐ Original Message ‐‐‐
On Sunday, November 11, 2018 7:24 PM, Adam Thompson  
wrote:

> Hello,
>
> I’d like to use OpenBSD to build a MIDI synthesizer using SoundFonts, as the 
> OpenBSD MIDI and audio subsystems are remarkably understandable and sane, 
> compared to everything else out there today.
>
> �
>
> However, I’m having difficulty finding a combination of hardware that is 
> known to be supported. (I tried this a few years ago, but was unhappy with 
> the results due to the quality of the audio-out ports on the laptop I used.)
>
> �
>
> I’ve heard a fair bit here about USB audio not working very well, or at all, 
> in -stable right now. I’m unsure if this only applies to XHCI ports or not?

As far as I know isochronous transfer mode required by USB audio class devices 
is not supported by the xhci driver. I believe a few people are poking at this, 
but that doesn't mean there will be support anytime soon. However - not all is 
lost...

>
> �
>
> Therefore, ideally, I’d like a fanless amd64 architecture system, that boots 
> from SATA (not eMMC) with either onboard stereo++ audio (up to and including 
> 7.1ch) or a PCI slot for a sound card.
>
> A laptop with really good audio-out would work, too, but I don’t know of any.
>
> If connecting USB audio to a RPi or BeagleBone Black works well, then I could 
> try that, too.
>
> �
>
> I intend to use USB MIDI interfaces, as they appear to be supported and 
> working fine (IIRC).
>
> �
>
> The problem is that, as I browse the list of embedded, fanless systems I can 
> get from DigiKey, Mouser, et al., all the boards with audio have HD Audio 
> Codecs that I cannot confirm work with OpenBSD, and I don’t know enough about 
> how azalia(4) [et a.] works with random unsupported DACs to drop $250-$500 on 
> something that may or may not work (i.e. the codec isn’t explicitly 
> supported).
>
> �
>
> Can anyone make any recommendations for specific hardware that’s fanless and 
> has working audio-out ports?
>
> �
>
> And/or if I’ve gone off completely in the wrong direction about USB audio, 
> please tell me so. (Working multi-channel USB audio would made this a lot 
> simpler/easier/cheaper.)

I am a basic audio user, but I have a fanless system and an external USB DAC. 
Here is my setup:

Computer: Intel NUC 5I5RYH 

Case: Akasa Newton S 
Audio: JDS Labs Objective2+ODAC Rev B 
 which I've 
heard some OpenBSD users are happy with.

>
> �
>
> Thanks in advance,
>
> -Adam
>
> �

Good luck. If you put together a system, let us know how it goes.

f86OpenWScons: cannot open /dev/ttyC4 (Permission denied)

[Krzysztof Strzeszewski]

Hi,

why I can't run Xorg?

My 10-radeon.conf:

--
#Section "OutputClass"

#   Identifier "Radeon"
#   MatchDriver "radeon"
#   Driver "radeon"
#EndSection

Section "Device"
Identifier "intel device"
Driver "intel"
EndSection

--

I changed 10-radeon.conf, because when I have radeon, my log is writeing 
"no driver"



__
Regards,
Krzysztof Strzeszewski



[ 186.207] X.Org X Server 1.19.6
Release Date: 2017-12-20
[ 186.207] X Protocol Version 11, Revision 0
[ 186.207] Build Operating System: OpenBSD 6.4 amd64 [ 186.207] Current 
Operating System: OpenBSD krzych 6.4 GENERIC.MP#436 amd64

[ 186.208] Build Date: 12 November 2018 12:20:38AM
[ 186.208] [ 186.208] Current version of pixman: 0.34.0
[ 186.208] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 186.208] Markers: (--) probed, (**) from config file, (==) default 
setting,

(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 186.209] (==) Log file: "/home/krzych/.local/share/xorg/Xorg.0.log", 
Time: Mon Nov 12 10:25:40 2018
[ 186.210] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"

[ 186.210] (==) No Layout section. Using the first Screen section.
[ 186.210] (==) No screen section available. Using defaults.
[ 186.210] (**) |-->Screen "Default Screen Section" (0)
[ 186.210] (**) | |-->Monitor ""
[ 186.210] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[ 186.210] (**) | |-->Device "intel device"
[ 186.210] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 186.210] (==) Automatically adding devices
[ 186.210] (==) Automatically enabling devices
[ 186.210] (==) Not automatically adding GPU devices
[ 186.211] (==) Max clients allowed: 256, resource mask: 0x1f
[ 186.211] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
[ 186.211] (==) ModulePath set to "/usr/X11R6/lib/modules"
[ 186.211] (II) The server relies on wscons to provide the list of input 
devices.
If no devices become available, reconfigure wscons or disable 
AutoAddDevices.

[ 186.211] (II) Loader magic: 0xf9721235000
[ 186.211] (II) Module ABI versions:
[ 186.211] X.Org ANSI C Emulation: 0.4
[ 186.211] X.Org Video Driver: 23.0
[ 186.211] X.Org XInput driver : 24.1
[ 186.211] X.Org Server Extension : 10.0
[ 186.211] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
(Permission denied)
Check that you have set 'machdep.allowaperture=1'
in /etc/sysctl.conf and reboot your machine
refer to xf86(4) for details
[ 186.211] linear framebuffer access unavailable
[ 186.211] (II) LoadModule: "glx"
[ 186.214] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
[ 186.219] (II) Module glx: vendor="X.Org Foundation"
[ 186.219] compiled for 1.19.6, module version = 1.0.0
[ 186.219] ABI class: X.Org Server Extension, version 10.0
[ 186.220] (II) LoadModule: "intel"
[ 186.221] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so
[ 186.321] (II) Module intel: vendor="X.Org Foundation"
[ 186.321] compiled for 1.19.6, module version = 2.99.916
[ 186.321] Module class: X.Org Video Driver
[ 186.321] ABI class: X.Org Video Driver, version 23.0
[ 186.322] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[ 186.322] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
[ 186.322] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
[ 186.322] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 
6200, P6300

[ 186.323] (EE) Fatal server error:
[ 186.323] (EE) xf86OpenWScons: cannot open /dev/ttyC4 (Permission 
denied)(EE) [ 186.323] (EE) Please consult the The X.Org Foundation 
support at http://wiki.x.org
for help. [ 186.323] (EE) Please also check the log file at 
"/home/krzych/.local/share/xorg/Xorg.0.log" for additional information.
[ 186.324] (EE) [ 186.333] (EE) Server terminated with error (1). 
Closing log file.

Re: undefined symbol tgetent

[Christian Weisgerber]

On 2018-11-12, Michael Steeves  wrote:

> I've updated my system to the latest snapshot, and then upgraded all the
> packages (and rebooted for good measure), but I still see these errors. I
> assume there's no simple fix for this, and I'd need to either file bugs (and
> wait until they're fixed), or else build the ports myself?

The problem is known and understood.  It's now a matter of either
(1) pushing for a general solution in base or (2) fixing all 30+
potentially affected ports individually.  We'll just have to wait
until somebody gets around to doing either.

Building the port yourself will just reproduce the problem.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: f86OpenWScons: cannot open /dev/ttyC4 (Permission denied)

[d . rauschenb]

Hi,

do you run -current and you have upgraded just before this issue
occurs, than read current.html and switch to xenodm. Xorg is not
installed setiud anymore. This means you cannot run startx anymore as
user.

-dra

On Mon, Nov 12, 2018 at 02:21:36PM +0100, Krzysztof Strzeszewski wrote:
> Hi,
> 
> why I can't run Xorg?
> 
> My 10-radeon.conf:
> 
> --
> #Section "OutputClass"
> 
> # Identifier "Radeon"
> # MatchDriver "radeon"
> # Driver "radeon"
> #EndSection
> 
> Section "Device"
>   Identifier "intel device"
>   Driver "intel"
> EndSection
> 
> --
> 
> I changed 10-radeon.conf, because when I have radeon, my log is writeing "no
> driver"
> 
> 
> __
> Regards,
> Krzysztof Strzeszewski
> 
> 
> 
> [ 186.207] X.Org X Server 1.19.6
> Release Date: 2017-12-20
> [ 186.207] X Protocol Version 11, Revision 0
> [ 186.207] Build Operating System: OpenBSD 6.4 amd64 [ 186.207] Current
> Operating System: OpenBSD krzych 6.4 GENERIC.MP#436 amd64
> [ 186.208] Build Date: 12 November 2018 12:20:38AM
> [ 186.208] [ 186.208] Current version of pixman: 0.34.0
> [ 186.208] Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> [ 186.208] Markers: (--) probed, (**) from config file, (==) default
> setting,
> (++) from command line, (!!) notice, (II) informational,
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [ 186.209] (==) Log file: "/home/krzych/.local/share/xorg/Xorg.0.log", Time:
> Mon Nov 12 10:25:40 2018
> [ 186.210] (==) Using system config directory
> "/usr/X11R6/share/X11/xorg.conf.d"
> [ 186.210] (==) No Layout section. Using the first Screen section.
> [ 186.210] (==) No screen section available. Using defaults.
> [ 186.210] (**) |-->Screen "Default Screen Section" (0)
> [ 186.210] (**) | |-->Monitor ""
> [ 186.210] (==) No device specified for screen "Default Screen Section".
> Using the first device section listed.
> [ 186.210] (**) | |-->Device "intel device"
> [ 186.210] (==) No monitor specified for screen "Default Screen Section".
> Using a default monitor configuration.
> [ 186.210] (==) Automatically adding devices
> [ 186.210] (==) Automatically enabling devices
> [ 186.210] (==) Not automatically adding GPU devices
> [ 186.211] (==) Max clients allowed: 256, resource mask: 0x1f
> [ 186.211] (==) FontPath set to:
> /usr/X11R6/lib/X11/fonts/misc/,
> /usr/X11R6/lib/X11/fonts/TTF/,
> /usr/X11R6/lib/X11/fonts/OTF/,
> /usr/X11R6/lib/X11/fonts/Type1/,
> /usr/X11R6/lib/X11/fonts/100dpi/,
> /usr/X11R6/lib/X11/fonts/75dpi/
> [ 186.211] (==) ModulePath set to "/usr/X11R6/lib/modules"
> [ 186.211] (II) The server relies on wscons to provide the list of input
> devices.
> If no devices become available, reconfigure wscons or disable
> AutoAddDevices.
> [ 186.211] (II) Loader magic: 0xf9721235000
> [ 186.211] (II) Module ABI versions:
> [ 186.211] X.Org ANSI C Emulation: 0.4
> [ 186.211] X.Org Video Driver: 23.0
> [ 186.211] X.Org XInput driver : 24.1
> [ 186.211] X.Org Server Extension : 10.0
> [ 186.211] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem
> (Permission denied)
> Check that you have set 'machdep.allowaperture=1'
> in /etc/sysctl.conf and reboot your machine
> refer to xf86(4) for details
> [ 186.211] linear framebuffer access unavailable
> [ 186.211] (II) LoadModule: "glx"
> [ 186.214] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
> [ 186.219] (II) Module glx: vendor="X.Org Foundation"
> [ 186.219] compiled for 1.19.6, module version = 1.0.0
> [ 186.219] ABI class: X.Org Server Extension, version 10.0
> [ 186.220] (II) LoadModule: "intel"
> [ 186.221] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so
> [ 186.321] (II) Module intel: vendor="X.Org Foundation"
> [ 186.321] compiled for 1.19.6, module version = 2.99.916
> [ 186.321] Module class: X.Org Video Driver
> [ 186.321] ABI class: X.Org Video Driver, version 23.0
> [ 186.322] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
> i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
> 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
> Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
> GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
> [ 186.322] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
> [ 186.322] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
> [ 186.322] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200,
> 6200, P6300
> [ 186.323] (EE) Fatal server error:
> [ 186.323] (EE) xf86OpenWScons: cannot open /dev/ttyC4 (Permission
> denied)(EE) [ 186.323] (EE) Please consult the The X.Org Foundation support
> at http://wiki.x.org
> for help. [ 186.323] (EE) Please also check the log file at
> "/home/krzych/.local/share/xorg/Xorg.0.log" for additional information.
> [ 186.324] (EE) [ 186.333] (EE) Server terminated with error (1). Closing
> log file.

Re: recommended h/w for fanless audio-out?

[Alexandre Ratchov]

On Sun, Nov 11, 2018 at 12:24:05PM -0600, Adam Thompson wrote:
> Hello,
> 
> I’d like to use OpenBSD to build a MIDI synthesizer using
> SoundFonts, as the OpenBSD MIDI and audio subsystems are remarkably
> understandable and sane, compared to everything else out there
> today.
>  �
> 
> However, I’m having difficulty finding a combination of hardware
> that is known to be supported.  (I tried this a few years ago, but
> was unhappy with the results due to the quality of the audio-out
> ports on the laptop I used.)
>  �
> 
> I’ve heard a fair bit here about USB audio not working very well, or
> at all, in -stable right now.  I’m unsure if this only applies to
> XHCI ports or not?

usb audio over xhci doesn't work yet.

> Therefore, ideally, I’d like a fanless amd64 architecture system,
> that boots from SATA (not eMMC) with either onboard stereo++ audio
> (up to and including 7.1ch) *or* a PCI slot for a sound card.
> A laptop with really good audio-out would work, too, but I don’t
> know of any.
> If connecting USB audio to a RPi or BeagleBone Black works well,
> then I could try that, too.
>  �
> I intend to use USB MIDI interfaces, as they appear to be supported
> and working fine (IIRC).

Yes, usb class-compliant MIDI interfaces are expected to work.

>
> The problem is that, as I browse the list of embedded, fanless
> systems I can get from DigiKey, Mouser, et al., all the boards with
> audio have HD Audio Codecs that I cannot confirm work with OpenBSD,
> and I don’t know enough about how azalia(4) [et a.] works with
> random unsupported DACs to drop $250-$500 on something that may or
> may not work (i.e. the codec isn’t explicitly supported).
> 

Most (all?) hd-audio codecs should work. The azalia(4) driver handles
the hd-audio chipset which interacts with the codec in a standardized
way. So the driver doesn't need to care about how codecs work.

This is not 100% true as certain vendor (ex Apple) add non-standard
features on top of this which break things and require quirks.

>
> Can anyone make any recommendations for specific hardware that’s
> fanless and has working audio-out ports?

I've exacly the same project. If you want to build a synth for
real-time performance (ie low-latency), I'd suggest using a PCI audio
interface. Currently I'm using a M-Audio Audiophile 192k and/or a ESI
Julia. I don't have a fanless amd64 board yet, mostly by lazyness and
lack of space on my desk.

For the MIDI the inputs, I'm using USB MIDI interfaces, but the ones
on the above audio interfaces work as well.

Re: recommended h/w for fanless audio-out?

[Alexandre Ratchov]

On Mon, Nov 12, 2018 at 12:30:30PM +, Colin Bortner wrote:
> 
> For the NUC, USB 3.0 can be disabled in the bios, forcing the ehci driver, 
> and allowing me to use the USB DAC without issues. From dmesg:
> 
> [...]
> ehci0 at pci0 dev 29 function 0 "Intel 9 Series USB" rev 0x03: apic 2 int 23
> usb0 at ehci0: USB revision 2.0
> [...]
> uhidev0 at uhub1 port 3 configuration 1 interface 0 "Yoyodyne Consulting 
> ODAC-revB" rev 1.10/0.01 addr 3
> uhidev0: iclass 3/0
> uhid0 at uhidev0: input=19, output=28, feature=0
> uaudio0 at uhub1 port 3 configuration 1 interface 1 "Yoyodyne Consulting 
> ODAC-revB" rev 1.10/0.01 addr 3
> uaudio0: audio rev 1.00, 2 mixer controls
> audio1 at uaudio0
> [...]
> 

out of curiosity, could you post the "uhub" lines as well, to show how
the "uaudio0" device is connected to the "usb0" device?

Thanks.

uvm_fault on HP T5740

[Kristjan Komloši]

Hello,
I've recently performed an install of i386 OpenBSD 6.4 on a HP T5740
thin client (Atom N280, 2GB DDR3, 2GB FLASH, more info on 
parkytowers.me.uk) and I keep running into uvm_fault errors at xenodm
startup when booting. At this point the whole computer freeyes, even
ddb prompt appearing after the error message doesn't work. Single user
boots fine, and doesn't produce any errors whatsoever. I have attached
the single mode dmesg, the disklabel output (I use the install
defaults), and pcidump output with this email.

When booting without any options at boot> prompt, the machine boots
normally until it starts xenodm, at which point the screen flashes
black, as expected at xenodm startup, but then goes back to console,
presenting the following error message:
uvm_fault(0x0d0d55bf0, 0xd2eaf000, 0, 2) -> e
kernel: page fault trap, code=0
Stopped at uvm_pmr_get1page+0x35d: movl %ecx, 0(%edi,%eax,1)
ddb{1}>

When booting bsd.sp kernel, results are very inconclusive. Most often
it results in the same crash as bsd.mp, but in very rare cases it also
crashes at kernel relink time. This didn't want to happen the many
times I have restarted the machine on purpose to trigger the relink, if
anyone can help me force the relink on the bsd.sp kernel, please let me
know. When it reaches the xenodm startup, it fails at the same assembly
line as the bsd.mp kernel.

I have also tested these machines with Alpine Linux, which runs very
stable (I use one of them as my home WiFi access point), so I don't
believe that the machine itself is faulty.

What would be the next step at solving this problem?

-- 
Thanks in advance
Kristjan Komloši
--
Dobite me lahko preko/you can contact me through:
Mail (šola/school): kristjan.koml...@sg.sckr.si
Mail (privat/private): kristjan.koml...@gmail.com
Tel: +386 31 679 339 (po 14. uri / after 14:00 CEST)
# /dev/rwd0c:
type: ESDI
disk: ESDI/IDE disk
label: 2GB ATA Flash Di
duid: 367182f625b2c5e3
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 64
sectors/cylinder: 4032
cylinders: 992
total sectors: 4000752 # total bytes: 1953.5M
boundstart: 64
boundend: 3999744
drivedata: 0 

16 partitions:
#size   offset  fstype [fsize bsize   cpg]
  a:  1889.3M   64  4.2BSD   2048 16384 12958 # /
  b:63.6M  3869440swap# none
  c:  1953.5M0  unused
OpenBSD 6.4 (GENERIC.MP) #943: Thu Oct 11 13:51:32 MDT 2018
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem  = 2076327936 (1980MB)
avail mem = 2023350272 (1929MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 11/12/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.6 @ 
0xfd070 (43 entries)
bios0: vendor American Megatrends Inc. version "786R8 v1.01" date 11/12/2009
bios0: Hewlett-Packard hp t5740
acpi0 at bios0: rev 0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC MCFG OEMB GSCI SSDT
acpi0: wakeup devices P0P2(S0) P0P1(S0) USB0(S0) USB1(S0) USB2(S0) USB5(S0) 
EUSB(S0) USB3(S0) USB4(S0) USB6(S0) USBE(S0) P0P4(S0) P0P5(S0) P0P6(S0) 
P0P7(S0) P0P8(S0) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz, 
06-1c-02
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,SENSOR,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N280 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz, 
06-1c-02
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,SENSOR,MELTDOWN
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 1 (P0P1)
acpiprt3 at acpi0: bus 2 (P0P4)
acpiprt4 at acpi0: bus -1 (P0P5)
acpiprt5 at acpi0: bus -1 (P0P6)
acpiprt6 at acpi0: bus -1 (P0P7)
acpiprt7 at acpi0: bus 3 (P0P8)
acpiprt8 at acpi0: bus 4 (P0P9)
acpicpu0 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
acpivideo0 at acpi0: GFX0
bios0: ROM list: 0xc/0xfc00! 0xd/0x2000
cpu0: Enhanced SpeedStep 1663 MHz: speeds: 1667, 1333, 1000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x09
drm0 at 

Re: recommended h/w for fanless audio-out?

[Colin Bortner]

‐‐‐ Original Message ‐‐‐
On Monday, November 12, 2018 5:14 PM, Alexandre Ratchov  wrote:

> On Mon, Nov 12, 2018 at 12:30:30PM +, Colin Bortner wrote:
>
> > For the NUC, USB 3.0 can be disabled in the bios, forcing the ehci driver, 
> > and allowing me to use the USB DAC without issues. From dmesg:
> > [...]
> > ehci0 at pci0 dev 29 function 0 "Intel 9 Series USB" rev 0x03: apic 2 int 23
> > usb0 at ehci0: USB revision 2.0
> > [...]
> > uhidev0 at uhub1 port 3 configuration 1 interface 0 "Yoyodyne Consulting 
> > ODAC-revB" rev 1.10/0.01 addr 3
> > uhidev0: iclass 3/0
> > uhid0 at uhidev0: input=19, output=28, feature=0
> > uaudio0 at uhub1 port 3 configuration 1 interface 1 "Yoyodyne Consulting 
> > ODAC-revB" rev 1.10/0.01 addr 3
> > uaudio0: audio rev 1.00, 2 mixer controls
> > audio1 at uaudio0
> > [...]
>
> out of curiosity, could you post the "uhub" lines as well, to show how
> the "uaudio0" device is connected to the "usb0" device?
>
> Thanks.

No problem - rate-matching hub:

uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
uhub1 at uhub0 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 
2.00/0.03 addr 2

Strange make behavior with :M

[Silamael]

Hi,

I've noticed a somehow strange behavior of make at least in 6.3 and 6.4 
with this simple Makefile:


--
FILEs=   Makefile Makefile.inc foo/Makefile.inc foo/src/force-build
DIR=  foo/src

# These both do not give me the expected result
FILES=${FILEs:M${DIR}/force-*}
FILES1=   ${FILEs:M${DIR}}

# Only this variant works
FILES2=   ${FILEs:Mfoo/src/force-*}

debug:
.for var in FILEs DIR FILES FILES1 FILES2
@echo ${var} = '${${var}}'
.endfor
--

$ make debug
FILEs = Makefile Makefile.inc foo/Makefile.inc foo/src/force-build
DIR = foo/src
FILES = /force-*}
FILES1 = }
FILES2 = foo/src/force-build

---

Only the variant without the variable in the :M pattern gives the 
expected result.

Is this expected behavior?
Am I making some mistake?

Thanks,
Matthias

Re: recommended h/w for fanless audio-out?

[Colin Bortner]

‐‐‐ Original Message ‐‐‐
On Monday, November 12, 2018 7:45 PM, gwes  wrote:

>
>
> On 11/12/18 07:30, Colin Bortner wrote:
>
> > > Hello,
> > > I’d like to use OpenBSD to build a MIDI synthesizer using SoundFonts, as 
> > > the OpenBSD MIDI and audio subsystems are remarkably understandable and 
> > > sane, compared to everything else out there today.
> > > I’ve heard a fair bit here about USB audio not working very well, or at 
> > > all, in -stable right now. I’m unsure if this only applies to XHCI ports 
> > > or not?
> > > As far as I know isochronous transfer mode required by USB audio class 
> > > devices is not supported by the xhci driver. I believe a few people are 
> > > poking at this, but that doesn't mean there will be support anytime soon. 
> > > However - not all is lost...
> >
> > For the NUC, USB 3.0 can be disabled in the bios, forcing the ehci driver, 
> > and allowing me to use the USB DAC without issues.
>
> Alas, the UCA-202 hangs...
>
> uaudio0 at uhub0 port 3 configuration 1 interface 0 "Burr-Brown from TI USB 
> Audio CODEC" rev 1.10/1.00 addr 7
> uaudio0: audio rev 1.00, 2 mixer controls
> audio1 at uaudio0
> uhidev3 at uhub0 port 3 configuration 1 interface 3 "Burr-Brown from TI USB 
> Audio CODEC" rev 1.10/1.00 addr 7
> uhidev3: iclass 3/0
> uhid0 at uhidev3: input=1, output=0, feature=0
>
> uaudio_chan_open: error creating pipe: err=INVAL endpt=0x02
> audio1: failed to start playback
>
> Disabling xhci allows it to run.

Good reminder to others that come across this thread that users
may also disable the xhci driver to try address to this issue -
the BIOS option was just convenient in my case.

>
> I'd love to fix isochronous mode in my Infinite Spare Time...
> once I learn the USB stack & hang my machine 100+ times,
> submit the code and get very embarrassed, try again...
> Very likely many of the developers who are much more familiar with
> the USB stack would like to fix it in their Infinite Spare Time.
>
> Geoff Steckel

Re: recommended h/w for fanless audio-out?

[gwes]

On 11/12/18 07:30, Colin Bortner wrote:

Hello,

I’d like to use OpenBSD to build a MIDI synthesizer using SoundFonts, as the 
OpenBSD MIDI and audio subsystems are remarkably understandable and sane, 
compared to everything else out there today.


I’ve heard a fair bit here about USB audio not working very well, or at all, in 
-stable right now. I’m unsure if this only applies to XHCI ports or not?

As far as I know isochronous transfer mode required by USB audio class devices 
is not supported by the xhci driver. I believe a few people are poking at this, 
but that doesn't mean there will be support anytime soon. However - not all is 
lost...


For the NUC, USB 3.0 can be disabled in the bios, forcing the ehci driver, and 
allowing me to use the USB DAC without issues.

Alas, the UCA-202 hangs...

uaudio0 at uhub0 port 3 configuration 1 interface 0 "Burr-Brown from TI USB Audio 
CODEC" rev 1.10/1.00 addr 7
uaudio0: audio rev 1.00, 2 mixer controls
audio1 at uaudio0
uhidev3 at uhub0 port 3 configuration 1 interface 3 "Burr-Brown from TI USB Audio 
CODEC" rev 1.10/1.00 addr 7
uhidev3: iclass 3/0
uhid0 at uhidev3: input=1, output=0, feature=0

uaudio_chan_open: error creating pipe: err=INVAL endpt=0x02
audio1: failed to start playback

Disabling xhci allows it to run.

I'd love to fix isochronous mode in my Infinite Spare Time...
once I learn the USB stack & hang my machine 100+ times,
submit the code and get very embarrassed, try again...
Very likely many of the developers who are much more familiar with
the USB stack would like to fix it in their Infinite Spare Time.

Geoff Steckel

Re: Change to init in -current?

[Theodore Wynnychenko]

-Original Message-
From: Theo de Raadt [mailto:dera...@openbsd.org] 
Sent: Saturday, November 10, 2018 7:57 PM
To: t...@uchicago.edu
Cc: misc@openbsd.org
Subject: Re: Change to init in -current?

Theodore Wynnychenko  wrote:

> So, to do this, I edited the appropriate terminal line in /etc/ttys to a
custom
> entry defined in /etc/gettytab; then added an entry to /etc/gettytab, using
> 'lo:' to point to a ksh script which (basically) looks at the input given to
> getty, and if it contains a specific username, runs "/usr/bin/login -f root" -
> if the user name entered is something different, the ksh script runs -> exec
> /usr/bin/login "$@" <- which allows any other user to login with a password.

Yes it is the unveil of /usr/bin/login specifically, rather than the
variable 'LO' which is 

gettytab.h:#define  LO  gettystrs[10].value

which is initialized by calling gettable() not just the first time,
but also later.  That picks up the change, but it is too late it is
after unveil() has locked the filesystem space down.

So we'll need to consider softening the unveil position, or removing
the obscure feature which no longer works.


-

I wanted to follow-up.  I guess I am just looking to understand/clarify.

In the reply above, it states that the problem lies in the "unveil of
/usr/bin/login specifically."

Does this mean that getty is only allowed to access "/usr/bin/login," and that
my custom script is not in an allowed location after unveil "locks down" getty?

This seems to make sense to me.  When I ran ktrace on the getty process that was
active for the local serial line, near the end of the trace (before the getty
session died and was re-spawned as a new/distinct process), I see:

...
 55962 gettyCALL  getpid()
 55962 gettyRET   getpid 55962/0xda9a
 55962 gettyCALL  sendsyslog(0x7f7bf2d0,64,0x2)
 55962 gettyGIO   fd -1 wrote 64 bytes
   "<35>getty[55962]: /local/autologin.sh: No such file or directory"
 55962 gettyRET   sendsyslog 0
 55962 gettyCALL  kbind(0x7f7c1338,24,0x6843e8d8b828be73)
 55962 gettyRET   kbind 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x3)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x1)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x3)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x1)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  kbind(0x7f7c1248,24,0x6843e8d8b828be73)
 55962 gettyRET   kbind 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x3)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  mprotect(0x15931882b000,0x1000,0x1)
 55962 gettyRET   mprotect 0
 55962 gettyCALL  munmap(0x15931882b000,0x1000)
 55962 gettyRET   munmap 0
 55962 gettyCALL  exit(1)



Obviously, my script is named autologin.sh and lives in /local; and it does
exist with appropriate file permissions.  It appears that getty does not have
access to it any longer.  I surmise this error is because getty's filesystem
access has been locked down by unveil.

Is that what was meant by "unveil of /usr/bin/login specifically," or is it
something else?

Also, I am assuming that the only way I could correct this for myself would be
to learn a lot more of C than I know now, edit the getty source, and compile it
locally.  In other words, there isn't something I can do from the command line
to get it to work again, is there?

Again, thanks.  I totally understand that this functionality in getty may or may
not be available going forward.

Ted

Re: CURRENT userland does not compile due to games/glorkz

[Philip Guenther]

On Mon, Nov 12, 2018 at 2:41 AM Jyri Hovila [Turvamies.fi] <
jyri.hov...@turvamies.fi> wrote:

> > It's not a shortcut,
>
> This, as many things in this world, completely depend on the point of view.
>
> One can not simply say "this is this" or "this is not this", without
> sufficient background information and overall understanding of the
> situation as a whole.
>

...which you didn't include.  As the line from diagnostic medicine goes
"hear hoofbeats?  expect horses, not zebras".  Failure to mention why your
case is unusual suggests that you're a "normal case" -current follower, not
someone who has an undisclosed reason for never using snaps.  If you're
uninterested in what you (now?) know to be the normal answer, you should
say that so everyone's time can be saved.

It also means that you need crank up your debugging and analysis, so you
can work through these things yourself.  What failed?  Why?  What does that
imply?  What can you change to resolve it?  To avoid it?  To undo it?  If
when you build -current, you also build a release, do you still have the
files from your last successful build so you can rollback to something you
accept?  Do you have a test machine you can use your own snap to run
through the source update multiple times to experiment with solutions?

"What problem are you trying to solve?"

...

> >  It's fine if you want to waste your own time, but this is the
> > one single method of getting out of many holes, like yours.
>
> It is also perfectly fine if you want to ignore how the real world
> functions, and/or give a super irritating / dislikable impression of
> yourself and your personality. To give you back just a little, it certainly
> seems you know your holes well enough.
>

That was an unpleasant turn.


Philip Guenther

Re: Change to init in -current?

[Ted Unangst]

Theodore Wynnychenko wrote:
> Does this mean that getty is only allowed to access "/usr/bin/login," and that
> my custom script is not in an allowed location after unveil "locks down" 
> getty?

yes.

> Obviously, my script is named autologin.sh and lives in /local; and it does
> exist with appropriate file permissions.  It appears that getty does not have
> access to it any longer.  I surmise this error is because getty's filesystem
> access has been locked down by unveil.
> 
> Is that what was meant by "unveil of /usr/bin/login specifically," or is it
> something else?

yes.

> Also, I am assuming that the only way I could correct this for myself would be
> to learn a lot more of C than I know now, edit the getty source, and compile 
> it
> locally.  In other words, there isn't something I can do from the command line
> to get it to work again, is there?

yes. the C involved is actually very rudimentary. just look for calls to
unveil in the source.

the downside is this isn't likely to be a change taken back. 

daily cron not starting

[Tony Boston]

Hi misc@,

the daily cron is not running anymore although I can execute '/bin/sh
/etc/daily' by hand just fine. I don't see anything in the logs and I
don't have any clue what else to check.
Do you guys have any idea?

-- 
Tony

GPG-FP: 49CC8250 CDCF2183 6209C1AE 625677C1 F7783D5F
Threema: DN8PJX4Z

Re: daily cron not starting

[Tom Smyth]

what does crontab -l say ?
On Tue, 13 Nov 2018 at 05:49, Tony Boston  wrote:
>
> Hi misc@,
>
> the daily cron is not running anymore although I can execute '/bin/sh
> /etc/daily' by hand just fine. I don't see anything in the logs and I
> don't have any clue what else to check.
> Do you guys have any idea?
>
> --
> Tony
>
> GPG-FP: 49CC8250 CDCF2183 6209C1AE 625677C1 F7783D5F
> Threema: DN8PJX4Z
>


-- 
Kindest regards,
Tom Smyth

Re: daily cron not starting

[Bruno Flueckiger]

On 13.11.18 06:35, Tony Boston wrote:
> Hi misc@,
> 
> the daily cron is not running anymore although I can execute '/bin/sh
> /etc/daily' by hand just fine. I don't see anything in the logs and I
> don't have any clue what else to check.
> Do you guys have any idea?
> 
> -- 
> Tony
> 
> GPG-FP: 49CC8250 CDCF2183 6209C1AE 625677C1 F7783D5F
> Threema: DN8PJX4Z
> 

Is the cron(8) daemon running?

Cheers,
Bruno

Re: daily cron not starting

[Otto Moerbeek]

On Tue, Nov 13, 2018 at 06:35:11AM +0100, Tony Boston wrote:

> Hi misc@,
> 
> the daily cron is not running anymore although I can execute '/bin/sh
> /etc/daily' by hand just fine. I don't see anything in the logs and I
> don't have any clue what else to check.
> Do you guys have any idea?

Check whats in /var/log/cron (or one of it's rotations)
Shoud contain something like:

Nov 13 01:30:01 clue cron[55565]: (root) CMD (/bin/sh /etc/daily)

-Otto