hotplugd attach script

[Jan Lambertz]

Hi,
i am not sure that the hotplug scripts are executed by the system user of
the person that is sitting in front of the Computer. So, no rights to files
or no display can be a Problem. How can the Computer know how inserted that
device ?

Re: understanding ldapd log error messages

[Predrag Punosevac]

> Use the options "-dv" at first.  If you need to see th BER messages
> use "-dvv"  (see also "man ldapd").

Do you see anything in this snipped

b,dc=org by any, in namespace dc=autonlab,dc=org
Apr 23 23:19:09.481 [18682] found dn
uid=rrabbany,ou=users,dc=autonlab,dc=org
Apr 23 23:19:09.481 [18682] requesting 01 access to
uid=rrabbany,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:19:09.481 [18682] found dn
uid=zhez,ou=users,dc=autonlab,dc=org
Apr 23 23:19:09.481 [18682] requesting 01 access to
uid=zhez,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:19:09.482 [18682] found dn
uid=awertz,ou=users,dc=autonlab,dc=org
Apr 23 23:19:09.482 [18682] requesting 01 access to
uid=awertz,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:19:09.482 [18682] 259 scanned, 135 matched, 0 dups
Apr 23 23:19:09.482 [18682] sending response 5 with result 0
Apr 23 23:19:09.482 [18682] finished search on msgid 3
Apr 23 23:19:09.645 [18682] end-of-file on connection 16
Apr 23 23:19:09.645 [18682] closing connection 16
Apr 23 23:19:10.960 [18682] accepted connection from 10.8.0.6 on fd 16
Apr 23 23:19:10.961 [18682] consumed 31 bytes
Apr 23 23:19:10.961 [18682] got request type 23, id 1
Apr 23 23:19:10.961 [18682] got extended operation
1.3.6.1.4.1.1466.20037
Apr 23 23:19:10.961 [18682] sending response 24 with result 0
Apr 23 23:19:10.961 [18682] conn_tls_init: switching to TLS
Apr 23 23:19:10.978 [18682] error 0x24 on connection 16
Apr 23 23:19:10.978 [18682] closing connection 16




Apr 23 23:19:30.086 [18682] consumed 31 bytes
Apr 23 23:19:30.086 [18682] got request type 23, id 1
Apr 23 23:19:30.086 [18682] got extended operation
1.3.6.1.4.1.1466.20037
Apr 23 23:19:30.086 [18682] sending response 24 with result 0
Apr 23 23:19:30.086 [18682] conn_tls_init: switching to TLS
Apr 23 23:19:30.105 [18682] error 0x24 on connection 16
Apr 23 23:19:30.105 [18682] closing connection 16
Apr 23 23:19:41.811 [18682] accepted connection from 10.8.0.6 on fd 16
Apr 23 23:19:41.811 [18682] consumed 31 bytes
Apr 23 23:19:41.811 [18682] got request type 23, id 1
Apr 23 23:19:41.811 [18682] got extended operation
1.3.6.1.4.1.1466.20037
Apr 23 23:19:41.811 [18682] sending response 24 with result 0
Apr 23 23:19:41.811 [18682] conn_tls_init: switching to TLS
Apr 23 23:19:41.828 [18682] error 0x24 on connection 16
Apr 23 23:19:41.828 [18682] closing connection 16
Apr 23 23:19:51.312 [18682] accepted connection from 10.8.0.6 on fd 16
Apr 23 23:19:51.312 [18682] consumed 31 bytes
Apr 23 23:19:51.312 [18682] got request type 23, id 1
Apr 23 23:19:51.312 [18682] got extended operation
1.3.6.1.4.1.1466.20037
Apr 23 23:19:51.312 [18682] sending response 24 with result 0
Apr 23 23:19:51.312 [18682] conn_tls_init: switching to TLS
Apr 23 23:19:51.331 [18682] error 0x24 on connection 16
Apr 23 23:19:51.331 [18682] closing connection 16

Apr 23 23:20:26.243 [18682] requesting 01 access to
uid=yichongx,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:20:26.243 [18682] found dn
uid=sray,ou=users,dc=autonlab,dc=org
Apr 23 23:20:26.243 [18682] requesting 01 access to
uid=sray,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:20:26.244 [18682] found dn
uid=ekennedy,ou=users,dc=autonlab,dc=org
Apr 23 23:20:26.244 [18682] requesting 01 access to
uid=ekennedy,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:20:26.244 [18682] found dn
uid=aharley,ou=users,dc=autonlab,dc=org
Apr 23 23:20:26.244 [18682] requesting 01 access to
uid=aharley,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:20:26.244 [18682] found dn
uid=rrabbany,ou=users,dc=autonlab,dc=org
Apr 23 23:20:26.244 [18682] requesting 01 access to
uid=rrabbany,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:20:26.244 [18682] found dn
uid=zhez,ou=users,dc=autonlab,dc=org
Apr 23 23:20:26.244 [18682] requesting 01 access to
uid=zhez,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:20:26.245 [18682] found dn
uid=awertz,ou=users,dc=autonlab,dc=org
Apr 23 23:20:26.245 [18682] requesting 01 access to
uid=awertz,ou=users,dc=autonlab,dc=org by any, in namespace
dc=autonlab,dc=org
Apr 23 23:20:26.245 [18682] 259 scanned, 0 matched, 0 dups
Apr 23 23:20:26.245 [18682] sending response 5 with result 0
Apr 23 23:20:26.245 [18682] finished search on msgid 7

Re: understanding ldapd log error messages

[Predrag Punosevac]

Robert Klein  wrote:

> Hi,
> 
> On Sat, 22 Apr 2017 21:55:58 -0400
> Predrag Punosevac  wrote:
> 
> > Predrag Punosevac write:
> > > Hi misc,
> > > 
> > > ldapd on one of my two ldap servers stop working overnight
> > >   
> > 
> > ldapd died again overnight. I noticed that this started happening not
> > right after the upgrade to 6.1 but less than 24h  after I added a
> > person to my LDAP database. How do I go about debugging a daemon? I am
> > reading
> > 
> > http://man.openbsd.org/rc.d
> > 
> > and I have used option -d when a daemon fails to start but I really
> > need to catch what happens when ldapd dies and redirect to the log
> > file. 
> 
> 
> Use the options "-dv" at first.  If you need to see th BER messages use
> "-dvv"  (see also "man ldapd").
> 
> Could you post an example setup, i.e. ldapd.conf and a LDIF file?

# more /etc/ldapd.conf
#   $OpenBSD: ldapd.conf,v 1.2 2010/06/29 02:50:22 martinh Exp $

schema "/etc/ldap/core.schema"
schema "/etc/ldap/inetorgperson.schema"
schema "/etc/ldap/nis.schema"

listen on lo0 tls certificate atlas
listen on em1 tls certificate atlas
listen on "/var/run/ldapi"

namespace "dc=autonlab,dc=org" {
rootdn  "cn=admin,dc=autonlab,dc=org"
rootpw  "{SSHA}iV3eDxcQ9LM9EJN6ltigbmHFUwuS/tE/"
index   sn
index   givenName
index   cn
index   mail
}


This is an example of newuser.ldif file used to add new users to the
database.  Note the following file is sanitized for trailing white
spaces. The white spaces you see in my e-mail are not in the database.

# more new_user.ldif 
dn: cn=jsmith,ou=group,dc=autonlab,dc=org
cn: jsmith
objectClass: top
objectClass: posixGroup
gidNumber: 1120
memberUid: jsmith
description: User Private Group


dn: uid=jsmith,ou=users,dc=autonlab,dc=org
uid: jsmith
cn: John Smith
sn: Smith
givenName: John
displayName: John Smith
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 1492716996
userPassword: {SSHA}E7VQcALE0zXe4lehOulF/fXIdi2kUQ6b
shadowMin: 1
shadowMax: 180
shadowWarning: 7
shadowInactive: 30
shadowExpire: -1
shadowFlag: 0
loginShell: /bin/bash
uidNumber: 1120
gidNumber: 1120
homeDirectory: /zfsauton/home/jsmith
mail: jsm...@web.de
gecos: John Smith
title: MSc student
postalAddress: NSH 3128
postalAddress: CMU
businessCategory: Graduate Student
telephoneNumber: (412) ???-
o: Auton Lab




> 
> Best regards
> Robert

hotplugd attach script

[Edgar Pettijohn]

I'm working on a gui tool for mounting usb sticks.  I want it to launch 
from hotplugd, but so far I am unsuccessful.


#/etc/hotplug/attach

#!/bin/sh

DEVCLASS=$1

DEVNAME=$2


case $DEVCLASS in

2)

/usr/local/bin/xmount.py /dev/"$DEVNAME"a

;;

esac


The script is executable.  However, the log shows "child exit status: 1" 
and the program doesn't startup.  If I run "xmount.py /dev/sd1a" from an 
xTerm it works as expected. Is there some special magic I need to add to 
the attach script?



Thanks,


Edgar

Re: flaky network connection after 6.1 upgrade

[Stefan Sperling]

On Sun, Apr 23, 2017 at 10:46:56PM +0200, Stefan Sperling wrote:
> Your other option is to stop reading now, forget about athn for now,
> and use some other AP.

I got mixed up between problem reports in my inbox. You have an athn
client, not an athn AP. Sorry about that.

A pcap file showing your athn client interacting with your AP would still be
very interesting. Please collect separate pcaps for 11b, 11g, and 11n mode.

Re: flaky network connection after 6.1 upgrade

[Stefan Sperling]

On Sat, Apr 22, 2017 at 03:49:35PM -0500, Colton Lewis wrote:
> I applied the patch and compiled a new kernel using the stable branch.
> 11n and 11g both work now,
> but with significantly worse performance than 11b. Downloads are about
> 40% slower.
> 
> $ curl http://download.thinkbroadband.com/200MB.zip -O
> was my test.

Thanks for testing this fix. I will commit it shortly.

The performance issues with athn are known and unrelated to my diff.
Performance with athn is worse than what e.g. iwm(4) clients get with
commercial APs. Obviously there is a lot of work left to do and
very many things to fix.

My own priority right now is that 11n support with athn is stable,
i.e. does not crash and does not drop out entirely for no good reason.
So far, this seems to be the case.

It is already fast enough for my own needs inspite of some issues.
E.g. my athn AP never transmits with rates higher than MCS 12. I don't
know why it never goes up to MCS 15. It sucks pretty badly on 2 GHz but
works fine on 5. There are many networks on 2 GHz around here which are
very active at times. I have gotten reports from people living out
in the country where they can use 2 GHz just fine, though.

It's not entirely clear to me where issues other people are reporting are
coming from. Do they see what I see or is it actually worse for them?
I have no way of knowing.

So far nobody who complained about performance has provided pcap files
of their traffic that are actually useful for debugging. Before I can do
anything to improve performance, you must capture some interesting pcap data.
Your other option is to stop reading now, forget about athn for now,
and use some other AP.

To capture a pcap file, you need an iwn interface.

Associate your client and figure out the channel of your AP.
Below I will use channel 5 as an example.

On your iwn device, prepare monitor mode (assuming unconfigured default state):

ifconfig iwn0 mediaopt monitor
ifconfig iwn0 chan 5
ifconfig iwn0 up

Verify that iwn is receiving on channel 5:

tcpdump -n -i iwn0 -y IEEE802_11_RADIO

The last part of each line should show the channel:



I have seen a quirk every now and then where the channel is not
set up correctly the first time through. If it's not listening
on the right channel yet, try again with:

ifconfig iwn0 down
ifconfig iwn0 chan 5
ifconfig iwn0 up
tcpdump -n -i iwn0 -y IEEE802_11_RADIO

Once the channel is OK, you can run this to capture any frames the
hardware can receive:

tcpdump -n -i iwn0 -y IEEE802_11_RADIO -s 4096 -w /tmp/iwn.pcap

Now do whatever on the client to provoke the low performance situation.
Leave the monitor running during this time. Ideally, give the monitor
30 seconds of margin around your experiments so we can see what's
going on while your client is idle.

Now zip the pcap file and send it to me, and tell me the MAC addresses
of your AP and your client involved in the speed test.

I will run wireshark (as non-root) to view the pcap file:

wireshark /tmp/iwn.pcap

The interesting bits of information can be seen in the lower pane in the
'802.11 radio information' section and the '802.11 ... frame' section.
The 'Wireless' -> 'WLAN Traffic' statistics menu is also useful.

Things I will be looking for include:

What transmit rates are reported for packets sent from/to your client?
Are there beacons, RTS and/or data frames from other networks?
How many frames are marked as retries?
What is the ratio of RTS vs data frames?
Is the client doing power saving and how does the AP handle this?

Ideally, we'll be able to figure out what kind of traffic the available
air time on your channel is spent on, and whether the AP is actually
misbehaving in some way.

Re: nvi(1)

[Florian Ermisch]

Am 23. April 2017 15:30:02 MESZ schrieb Unixway1 :
>Dear,
>
>I started to use nvi(1) OpenBSD base editor, the manpage isn't clean
>about:
>1- How copy and paste between xterms? 
> Should I use Marks? is it possible or not?

Use one terminal with tmux, split it into 
several panes, then use tmux' copy mode?
You'll find a quick intro into copy & paste 
in tmux under [0].
That's how I work these days.

Regards, Florian 

[0]: https://awhan.wordpress.com/2010/06/20/copy-paste-in-tmux/

> […]

multi-USB flash did not work with bsd.rd but manual install fine

[Chris Bennett]

I have everything split apart into two flash drives to get enough
diskspace. I couldn't get bsd.rd to work since not all of the partitions
were mounted. Any reasonable fix good for this problem? I was doing
upgrade to 6.1 from an older 6.1 -current.

Since everything is mounted when system is running manual install worked
fine.

Are there any other solutions?
This is the first time I've split the OBSD partitions across multiple
drives.
I have in the past split things like /home and /usr/local, but they
don't matter during upgrades or a fresh install.

Is there another method to accomplish this or just this way?

How common is it to split things up this way?
IMHO, it doesn't seem quite common enough to merit a note in the FAQ.
Figuring this out myself was educational. And a new install works fine
without any special tricks.

I always run dmesg|head after an upgrade to be sure it worked right.
Glad I did this!

Might that be worth adding to the FAQ? Do that before and then after
upgrade? I know I've grabbed the wrong filesets before!

Happy to have fixed my problem!

Chris Bennett

HP StorageWorks Ultrium 960 "misprobed" by mpi(4)

[Mark Hesselink]

Dear misc readers,

Recently I upgraded the SCSI card and the tape drive in my home server
to the following:

mpi0 at pci1 dev 2 function 0 "Symbios Logic 53c1030" rev 0x08: apic 3
int 7
mpi0: 0, firmware 1.3.39.0
scsibus2 at mpi0: 16 targets, initiator 7
st0 at scsibus2 targ 3 lun 0:  SCSI3
1/sequential removable naa.500110a0010dafe6
mpi0: target 3 Sync at 10MHz width 16bit offset 64 QAS 0 DT 0 IU 0

According to HP the tape drive, a StorageWorks Ultrium 960, should
support bus speeds up to U320 allowing the tape drive to back up data at
speeds up to 80MB/s. As a result I believe the tape drive is "misprobed"
as only supporting a 10MHz bus speed; I would have expected the mpi(4)
driver to report a bus speed of 160MHz based on HP's claims. The low bus
speed negotiated between the SCSI card and the tape drive unfortunately
causes the tape drive to back up data at roughly 16-17MB/s instead of
the expected 30-60MB/s (*). This is causing full backups to take way
longer than I hoped for.

Would it be possible that the "misprobing" is caused by the mpi(4)
driver probing the bus speed at attachment time instead of media
insertion time? Prior to using a mpi(4) SCSI card, I used a siop(4) card
(see also attached full dmesg). This card would only negotiate a speed
with the tape drive when a tape was inserted into the drive.

Kind regards,

Mark

(*) I am using Ultrium 2 tapes in a Ultrium 3 tape drive which prevents
the tape drive from reaching its maximum speed of 80MB/s. According to
HP however the tape drive should be able to reach speeds in the range
30-60MB/s depending on the amount of compression achieved.


dmesg.out
Description: Binary data

Re: BeagleBone Black GPIO

[Mark Kettenis]

> Hello Misc,

This is probably a discussion for tech@; anyway:

> I'm trying to get a BeagleBone Black talking onewire and i2c via GPIO to
> several off-board ICs through gpioow(4) and gpioiic(4) respectively.

As a warning, let me say that tinkering with hardware like this isn't
very high on the list of things we support in OpenBSD as it often
conflicts with the security goals we have.

> I've got the following in /etc/rc.securelevel:
> 
> # Set GPIO pin directions for USR LEDs and give them names
> gpioctl gpio1 21 set out USR0
> gpioctl gpio1 22 set out USR1
> gpioctl gpio1 23 set out USR2
> gpioctl gpio1 24 set out USR3
> 
> # Attach a onewire(4) bus on a gpioow(4) device using 1 GPIO pin
> gpioctl gpio1 attach gpioow 29 0x1
> 
> # Attach a i2c(4) bus on a gpioiic(4) device using 2 GPIO pins
> gpioctl gpio2 attach gpioiic 2 0x3

I'm not at all sure how well gpioow(4) and gpioiic(4) work.  There are several 
reasons why it might not:

* The omgpio(4) driver or hardware might not support all the pin
  configurations/states that are required to implement
  gpioow(4)/gpioiic(4).

* The timing accuracy of the raw bit banging that these drivers do
  isn't good enough.

* Your i2c devices live on an address not probed by i2c_scan().

* Your i2c devices are not recognized by i2c_scan().

If you want to get this to work, you'll probably have to start
debugging i2c_scan() and onewire_search() to see where things are
going wrong.

An alternative could be to use the i2c controllers provided by omap to
hook up your devices.  In that case you'll want to modify the device
tree you're using and add your devices to the tree such that they are
automatically discovered.

nvi(1)

[Unixway1]

Dear,

I started to use nvi(1) OpenBSD base editor, the manpage isn't clean about:
1- How copy and paste between xterms? Should I use Marks? is it possible or not?
2- On thinkpad and I usually select the text and paste with middle button,
but I noticed the original text format isn't preserved, eg tabs are replaces by 
spaces.

Cheers,
CL

Re: Bad kernel for OpenBSD 6.1 sparc64 ?

[Stefan Sperling]

On Sat, Apr 22, 2017 at 04:31:02PM -0600, Jeff wrote:
> Booting from sr0a seemed to do the trick to get my system upgraded to
> 6.1.  Unfortunately, it's now panicing frequently with, "panic:
> psycho0: uncorrectable DMA error" but on different commands each time.

Please follow the steps in https://www.openbsd.org/report.html

In the past we have found bugs in drivers where the hardware ends up
doing an out of bounds access during DMA transactions. On most platforms
those bugs don't get noticed but psycho on sparc64 is catching them
which results in this panic.

> Question: After upgrading to 6.1, it's still booting with "OpenBSD
> BOOT 1.7" but I noticed when booting from the burned install61.iso
> CD, it reports BOOT 1.9.  I tried running "installboot sd2"  but
> there's no change.  Is there another method I'm overlooking to
> update the boot image?

Is sd2 your softraid disk? What does installboot -n -v sd2 say?

Re: printf(3): extra parameters, %b token, and cpp antics

[Otto Moerbeek]

On Sun, Apr 23, 2017 at 06:01:18PM +1000, Damian McGuckin wrote:

> On Sun, 23 Apr 2017, Jonathan Gray wrote:
> 
> > http://man.openbsd.org/printf.9
> 
> Is the use of '%b' an addressing-out-of-bounds bug waiting to happen or is
> there some sort of inbuilt protection that I cannot see?
> 
> Regards - Damian

Well, you can look at the implementation and decide that for yourself,
If you spot a bug we would like ot know ;-)

-Otto

Re: printf(3): extra parameters, %b token, and cpp antics

[Damian McGuckin]

On Sun, 23 Apr 2017, Jonathan Gray wrote:


http://man.openbsd.org/printf.9


Is the use of '%b' an addressing-out-of-bounds bug waiting to happen or is 
there some sort of inbuilt protection that I cannot see?


Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Re: printf(3): extra parameters, %b token, and cpp antics

[Jonathan Gray]

On Sun, Apr 23, 2017 at 03:39:22AM -0400, Ian Sutton wrote:
> I noticed some strange code in src/sys/arch/armv7/omap/ommmc.c
> 
> This preprocessor define seems to map intr. state bit positions with
> strings describing them:
> 
> 149 #define  MMCHS_STAT_FMT "\20" \
> 150 "\x09d_BADA" \
> 151 "\x09c_CERR" \
> 152 "\x098_ACE" \
> 153 "\x096_DEB" \
> 154 "\x095_DCRC" \
> 155 "\x094_DTO" \
> 156 "\x093_CIE" \
> 157 "\x092_CEB" \
> 158 "\x091_CCRC" \
> 159 "\x090_CTO" \
> 160 "\x08f_ERRI" \
> 161 "\x089_OBI" \
> 162 "\x088_CIRQ" \
> 163 "\x085_BRR" \
> 164 "\x084_BWR" \
> 165 "\x082_BGE" \
> 166 "\x081_TC" \
> 167 "\x080_CC"
> 
> It's used later as an extra printf() argument (edited for clarity):
> 
> 1174 printf("%s: interrupt status=%b\n", DEVNAME(sc), status, MMCHS_STAT_FMT);
> 
> Whenever the above is called, the string counterpart to each interupt
> bit set in 'status' is printed, for example:
> 
> mmmc0: interrupt status=20008000<_BADA,_ERRI>
> 
> Where BADA and ERRI are intr. status bits at positions 29 and 15
> respectively.
> 
> So through some combination of:
>   * CPP multi-string define with unclear hex escapes prepended
>   * printf() call with one too many parameters
>   * undocumented %b printf() token

http://man.openbsd.org/printf.9

Re: printf(3): extra parameters, %b token, and cpp antics

[Sebastien Marie]

On Sun, Apr 23, 2017 at 03:39:22AM -0400, Ian Sutton wrote:
> 
> So through some combination of:
>   * CPP multi-string define with unclear hex escapes prepended
>   * printf() call with one too many parameters
>   * undocumented %b printf() token

you didn't look at the right printf man page. This is kernel code, so
you should look at printf(9) and not at printf(3).

$ man 9 printf
...
 The kernel functions support some additional formatting specifiers:

 %b Bit field expansion.  This format specifier is useful for decoding
bit fields in device registers.  It displays an integer using a
specified radix (base) and an interpretation of the bits within
that integer as though they were flags.  It requires two arguments
from the argument vector, the first argument being the bit field
to be decoded (of type int, unless a width modifier has been
specified) and the second being a decoding directive string.
... 

Thanks.
-- 
Sebastien Marie

printf(3): extra parameters, %b token, and cpp antics

[Ian Sutton]

I noticed some strange code in src/sys/arch/armv7/omap/ommmc.c

This preprocessor define seems to map intr. state bit positions with
strings describing them:

149 #define  MMCHS_STAT_FMT "\20" \
150 "\x09d_BADA" \
151 "\x09c_CERR" \
152 "\x098_ACE" \
153 "\x096_DEB" \
154 "\x095_DCRC" \
155 "\x094_DTO" \
156 "\x093_CIE" \
157 "\x092_CEB" \
158 "\x091_CCRC" \
159 "\x090_CTO" \
160 "\x08f_ERRI" \
161 "\x089_OBI" \
162 "\x088_CIRQ" \
163 "\x085_BRR" \
164 "\x084_BWR" \
165 "\x082_BGE" \
166 "\x081_TC" \
167 "\x080_CC"

It's used later as an extra printf() argument (edited for clarity):

1174 printf("%s: interrupt status=%b\n", DEVNAME(sc), status, MMCHS_STAT_FMT);

Whenever the above is called, the string counterpart to each interupt
bit set in 'status' is printed, for example:

mmmc0: interrupt status=20008000<_BADA,_ERRI>

Where BADA and ERRI are intr. status bits at positions 29 and 15
respectively.

So through some combination of:
* CPP multi-string define with unclear hex escapes prepended
* printf() call with one too many parameters
* undocumented %b printf() token

We get this handy functionality where names of intr. statuses are
derrived from their associated bit positions and conditionally printed
when set.

Does anyone have any idea of why this works the way it does?

Ian

Re: understanding ldapd log error messages

[Robert Klein]

Hi,

On Sat, 22 Apr 2017 21:55:58 -0400
Predrag Punosevac  wrote:

> Predrag Punosevac write:
> > Hi misc,
> > 
> > ldapd on one of my two ldap servers stop working overnight
> >   
> 
> ldapd died again overnight. I noticed that this started happening not
> right after the upgrade to 6.1 but less than 24h  after I added a
> person to my LDAP database. How do I go about debugging a daemon? I am
> reading
> 
> http://man.openbsd.org/rc.d
> 
> and I have used option -d when a daemon fails to start but I really
> need to catch what happens when ldapd dies and redirect to the log
> file. 


Use the options "-dv" at first.  If you need to see th BER messages use
"-dvv"  (see also "man ldapd").

Could you post an example setup, i.e. ldapd.conf and a LDIF file?

Best regards
Robert