ypldap and ldap paged results
Hi all, I try to use ypldap with a userbase > 1 entries. It stops (with error!) after 1000 entries, because the ldap server is ADS and has a page limit of 1000 entries. So the question is: is there a newer ypldap that can handle paged results? Thanks, -- Wilhelm
Re: ypldap and ldap paged results
Am 13.09.2010 11:45, schrieb Martin Hedenfalk: > 13 sep 2010 kl. 09.30 skrev Wilhelm: > > >> Hi all, >> >> I try to use ypldap with a userbase > 1 entries. It stops (with >> error!) after 1000 entries, because the ldap server is ADS and has a >> page limit of 1000 entries. >> >> So the question is: is there a newer ypldap that can handle paged results? >> > No, there is no newer ypldap. Is it possible to increase the limit in ADS? > No, that is not an option. Well, I try to use simple LDAP scripts now. Do you know if there is work in progress? > -martin > > >> Thanks, >> >> -- >> Wilhelm >> >> > -- Wilhelm
Re: ypldap and ldap paged results
Am 13.09.2010 12:32, schrieb Martin Hedenfalk: > I am (slowly) working on the ldap client bits. I'll have paged results in > mind, but don't expect anything soon. > Ok, thanks for the info. Meanwhile I use a patch login_ldap: after successfull getting the user dn and successfull bind to the ldap-server (user is now authenticated) the login_ldap now calls a post-auth script. This then adds then querys all user attributes and adds the user locally. Not elegant, but it works. > -martin > > 13 sep 2010 kl. 12.16 skrev Wilhelm: > > >> Am 13.09.2010 11:45, schrieb Martin Hedenfalk: >> >>> 13 sep 2010 kl. 09.30 skrev Wilhelm: >>> >>> >>> >>>> Hi all, >>>> >>>> I try to use ypldap with a userbase > 1 entries. It stops (with >>>> error!) after 1000 entries, because the ldap server is ADS and has a >>>> page limit of 1000 entries. >>>> >>>> So the question is: is there a newer ypldap that can handle paged results? >>>> >>>> >>> No, there is no newer ypldap. Is it possible to increase the limit in ADS? >>> >>> >> No, that is not an option. >> >> Well, I try to use simple LDAP scripts now. >> >> Do you know if there is work in progress? >> >>> -martin >>> >>> >>> >>>> Thanks, >>>> >>>> -- >>>> Wilhelm >>>> >>>> >>>> >>> >> >> -- >> Wilhelm >> >> >> > -- Wilhelm
OpenBSD roadtrip: Berlin Germany 2007-05-30 - 2007-06-02
Hi, after Pentecost OpenBSD/OpenSSH is at the LinuxTag in Berlin/Germany from 2007-05-30 until 2007-06-02 There will be a BSD Day with talks on friday 2007-06-01 http://www.linuxtag.org/2007/en/conf/events/vp-freitag.html Feel free to drop by and say hello Wilhelm and Wim 2007/5/9, Wim Vandeputte <[EMAIL PROTECTED]>: Hey, in Ede, at the "NLUUG Voorjaarsconferentie 2007" in Krakow, Poland for "Confidence 2007" =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= https://kd85.com/notforsale.html
CfP OpenBSD-Talks at LinuxTag 2006 in Wiesbaden/Germany
Hello, we are looking for people, who want to give a talk about a BSD-related topic at LinuxTag May 3.- 6. 2006 in Wiesbaden/Germany (near Frankfurt/Main Airport). Talks can be given in English or German. LinuxTag is Europes largest event about Free Software and Open Source and was founded as a Linux-Event in 1996. OpenBSD had a booth at LinuxTag the last years (thanks to Wim) and OpenBSD will have a booth at LinuxTag 2006. Do not hesitate to contact me for more information. Yours, Wilhelm Buehler Weblinks: Infos in German (translation is still under construction) http://www.linuxtag.org/2006/de/home/cfp.html The mountains near Wiesbaden are called Taunus http://en.wikipedia.org/wiki/Taunus
OpenBSD in April's issue of the CACM
I was just reading the April's issue of the Communications of the ACM (the flagship magazine of the Association for Computing Machinery), and noticed that OpenBSD and its developers were mentioned in one article, in a rather negative way: "Unfortunately, there is a segment of the open source community that is incapable of playing well with others, when those others don't play the way they want them to. For those who have not had to deal with these people, it's a bit like talking to a four-year-old. When you explain checkers to your niece, she might decide that she doesn't like your rules and follows her own rules. You humor her, she's being creative, and this is amusing in a four-year-old. If you were playing chess with a colleague who suddenly told you that the king could move one, two, or three places in one go, you would be pissed off, because this person would obviously be screwing with you, or insane. Have I lost my mind?! What does this have to do with VRRP or network protocols? The OpenBSD team, led as always by their Glorious Leader (their words, not mine), decided that a RAND license just wasn't free enough for them. They wrote their own protocol, which was completely incompatible with VRRP. Well, you say, that's not so bad; that's competition, and we all know that competition is good and brings better products, and it's the glorious triumph of Capitalism. But there is one last little nit to this story. The new protocol dubbed CARP (Common Address Redundancy Protocol) uses the exact same IP number as VRRP (112). Most people, and KV includes himself in this group, think this was a jerk move. "Why would they do this?" I hear you cry. Well, it turns out that they believe themselves to be in a war with the enemies of open source, as well as with those opposed to motherhood and apple pie. Stomping on the same protocol number was, in their minds, a strike against their enemies and all for the good. Of course, it makes operating devices with both protocols in the same network difficult, and it makes debugging the software that implements the protocol nearly impossible." Here is the link to the article: http://cacm.acm.org/magazines/2012/4/147357-the-network-protocol-battle/abstr act If you are not a member of the ACM, you can read it in ACM Queue, in which it was published in January: http://queue.acm.org/detail.cfm?id=2090149 I somehow feel this is a very distorted view of what really happened. Perhaps it would be good if somebody "official" wrote a Letter to the Editor (Communications of the ACM publish them in every issue)? Wil.
Re: [PATCH] [cwm] config option to run all apps maximized
On Mon, 22 Apr 2024, Slava Voronzoff wrote: Hello, list! I wrote little patch that add option "maximizeall" to cwmrc (default is no) so new windows created maximized. Nice addition. There is one bug: If an application requests an initial size, it will open in that size. At the same time, it will be tagged "maximized". Therefore, it has to be maximized twice: First time to unmaximize it. Second time to finally maximize it. I've noticed this with schismtracker. Dirk
Re: [PATCH] [cwm] config option to run all apps maximized
On Wed, 24 Apr 2024, Slava Voronzoff wrote: вт, 23 апр. 2024 г. в 11:00, Dirk-Wilhelm Peters : Nice addition. There is one bug: If an application requests an initial size, it will open in that size. At the same time, it will be tagged "maximized". Therefore, it has to be maximized twice: First time to unmaximize it. Second time to finally maximize it. I've noticed this with schismtracker. Hi, can you explain more of your steps? Tested it right now and cant reproduce. I installed schismtracker and launch it and got it fullscreen out of box, also tried some x apps with "-geometry" - worked too. Any ignores in configs or Xresources? Autogroups? None that I am aware of. Just tried this again with a minimal .cwmrc: maximizeall yes and an .xinitrc with just "cwm". I have also removed the configuration directory $HOME/.schism before running schismtracker. It still comes up in its "natural" size. This is on OpenBSD 7.5 with xenocara sources from 7.5. By the way, milkytracker (another SDL application) also comes up in its "historic" size. It might be a configuration issue on my end, but I cannot think of anything right now.
Heirloom troff on OpenBSD 4.4 / libc / i386
Hello, I am trying to get the excellent Heirloom troff[1] running on OpenBSD. It compiles and installs fine. However, running the compiled troff results in random segmentation faults; sometimes it works, most of the time it does not. I contacted the author (G. Ritter) who suggested to compile the program with the debug flag (-g), and to subsequently run it in gdb. I did that, but not being a developer, the output did not tell me anything useful. Anyway, here is the output I got: -- cut here $ gdb /opt/ucb/troff GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd4.4"...(no debugging symbols found) (gdb) run Starting program: /opt/ucb/troff Program received signal SIGSEGV, Segmentation fault. 0x1c006af0 in ?? () (gdb) bt full #0 0x1c006af0 in ?? () No symbol table info available. #1 0x2309c324 in _toupper_tab_ () from /usr/lib/libc.so.48.0 No symbol table info available. #2 0x0800 in ?? () No symbol table info available. #3 0xcfbe2878 in ?? () No symbol table info available. #4 0x0001 in ?? () No symbol table info available. #5 0x0006 in ?? () No symbol table info available. #6 0x8530b720 in ?? () No symbol table info available. #7 0xcfbe28a8 in ?? () No symbol table info available. #8 0x1c006dbd in ?? () No symbol table info available. #9 0x0001 in ?? () No symbol table info available. #10 0xcfbe2880 in ?? () No symbol table info available. #11 0x in ?? () No symbol table info available. -- cut here To my untrained eye, this looks like there might be something wrong in libc, but honestly, it does not make sense to me. Something else that might be related (from the README): -- cut here The locale-dependent character input in troff assumes that the C library represents wchar_t values as Unicode characters. This is the case on any modern Unix system. -- cut here Has anybody been able to successfully run Heirloom troff on OpenBSD? And, if yes, how to enable support for UTF-8 input files? Thanks for any hint. Dirk
Re: Heirloom troff on OpenBSD 4.4 / libc / i386
On Wed, 7 Jan 2009 18:29:54 -0800
"Philip Guenther" wrote:
> > I contacted the author (G. Ritter) who suggested to compile the program
> > with the debug flag (-g), and to subsequently run it in gdb.
> > I did that, but not being a developer, the output did not tell me
> > anything useful.
> ...
> > This GDB was configured as "i386-unknown-openbsd4.4"...(no debugging
> > symbols found)
>
> You may have built it with -g to include debugging symbols, but the
> binary was apparently stripped along the way. If the -s option is
> passed when doing the final linking, then remove it. If the 'strip'
> command is being run, comment it out or disable it. Then try running
> it under gdb again.
I disabled the strip command. Now, I get the output below from gdb.
I think, I'll best report it to the author of the software, as it does
not make an awful lot of sense to me.
Thanks for your support.
$ gdb troff
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd4.4"...
(gdb) run
Starting program: /opt/ucb/troff
Program received signal SIGSEGV, Segmentation fault.
0x1c006b06 in addlig (f=1, from=0xcfbf6620, to=0) at t6.c:1340
1340if (codetab[f][fitab[f][LIG_FF-32]] < 32)
(gdb) bt full
#0 0x1c006b06 in addlig (f=1, from=0xcfbf6620, to=0) at t6.c:1340
i = 1
j = 2
lp = (struct lgtab *) 0x0
#1 0x1c006dbd in setlig (f=1, j=6) at t6.c:1413
from = {102, 105, 0, 0}
to = -8377880580443839399
#2 0x1c008774 in loadafm (nf=1, rq=82, file=0x7cd053ed "R", supply=0x0,
required=1, spec=SPEC_PUNCT) at t6.c:2084
st = {st_dev = 16, st_ino = 8548, st_mode = 33188, st_nlink = 1, st_uid
= 1000, st_gid = 0, st_rdev = 36424, st_lspare0 = -685213332, st_atimespec =
{tv_sec = 1231455322,
tv_nsec = 586991087}, st_mtimespec = {tv_sec = 1231455322, tv_nsec =
586991087}, st_ctimespec = {tv_sec = 1231455322, tv_nsec = 606989709}, st_size
= 31354, st_blocks = 64,
st_blksize = 16384, st_flags = 0, st_gen = 0, st_lspare1 = -685641728,
__st_birthtimespec = {tv_sec = -685641696, tv_nsec = 5}, st_qspare =
{233159961, 42353225560}}
fd = 1
path = 0x8849f400 "/opt/ucblib/doctools/font/devps/R.afm"
contents = 0x861f5ba4 ""
a = (struct afmtab *) 0x84aa9a00
i = 1
have = 0
np = (struct namecache *) 0x6459
#3 0x1c001b2b in ptinit () at t10.c:237
i = 1
nw = 0
filebase = 0x7cd0540d ""
p = 0x7cd0540d ""
descp = 0x0
#4 0x1c00aed4 in init2 () at ../n1.c:447
i = 25689
j = 0
#5 0x1c00aa27 in main (argc=0, argv=0xcfbf6830) at ../n1.c:309
p = 0xcfbf6988 "/opt/ucb/troff"
j = 25689
oargv = (char **) 0xcfbf6830
No sound on ThinkPad X220 using current snapshot
Hi,
after a recent update to the latest snapshot on my ThinkPad X220, there
is no sound after returning from suspend mode. The problem persists
even after a reboot. I have to shutdown/restart the machine to enable
audio output again. Headphone output is not affected.
I have noticed a couple suspend-related emails recently, so maybe this
specific problem is already known.
Please let me know if you need further information.
Regards
Dirk
sndiod_flags="-L - -z 480 -b 960 -r 48000 -f rsnd/0 -v 127 -s default -mmon -s
mon -mplay,rec -t slave -s mmc -F rsnd/1"
The output of "mixerctl -v" and "sndioctl -v" does not change
after suspend:
# mixerctl -v
inputs.dac-0:1_mute=off [ off on ]
inputs.dac-0:1=222,222
inputs.dac-2:3_mute=off [ off on ]
inputs.dac-2:3=222,222
inputs.beep=108
record.adc-2:3_source=mic3 [ sel sel2 mic3 mix ]
record.adc-2:3_mute=off [ off on ]
record.adc-2:3=126,126
record.adc-0:1_source=sel [ sel sel2 mic3 mix ]
record.adc-0:1_mute=off [ off on ]
record.adc-0:1=126,126
record.adc-4:5_source=sel [ sel sel2 mic3 mix ]
record.adc-4:5_mute=off [ off on ]
record.adc-4:5=126,126
inputs.sel_source=mic [ mic mic2 ]
outputs.sel=126,126
inputs.sel2_source=mic [ mic mic2 ]
outputs.sel2=126,126
outputs.hp_source=dac-0:1 [ dac-0:1 dac-2:3 ]
outputs.hp_boost=off [ off on ]
outputs.mic_dir=input-vr80 [ none input input-vr50 input-vr80 ]
outputs.mic2_source=dac-0:1 [ dac-0:1 dac-2:3 ]
outputs.mic2_dir=input-vr80 [ none output input input-vr50 input-vr80 ]
outputs.mic2_eapd=on [ off on ]
outputs.hp2_source=dac-0:1 [ dac-0:1 dac-2:3 ]
outputs.spkr_source=dac-2:3 [ dac-0:1 dac-2:3 ]
inputs.mic3=126,126
inputs.mix_source=dac-0:1,dac-2:3 { dac-0:1 dac-2:3 }
inputs.mix_dac-0:1=126,126
inputs.mix_dac-2:3=126,126
outputs.hp_sense=unplugged [ unplugged plugged ]
outputs.mic_sense=unplugged [ unplugged plugged ]
outputs.mic2_sense=unplugged [ unplugged plugged ]
outputs.hp2_sense=unplugged [ unplugged plugged ]
outputs.spkr_muters=hp,mic2,hp2 { hp mic2 hp2 }
outputs.master=255,255
outputs.master.mute=off [ off on ]
outputs.master.slaves=dac-0:1,dac-2:3 { dac-0:1 dac-2:3 beep sel sel2 }
record.volume=126,126
record.volume.mute=off [ off on ]
record.volume.slaves=adc-2:3,adc-0:1,adc-4:5 { adc-2:3 adc-0:1 adc-4:5 mic3 }
record.enable=sysctl [ off on sysctl ]
$ sndioctl -v
input[0].level=0.494
input[1].level=0.494
input[0].mute=0
input[1].mute=0
output[0].level=1.000
output[1].level=1.000
output[0].mute=0
output[1].mute=0
server.device=0
app/aucat0.level=1.000
$ dmesg
OpenBSD 7.0-current (GENERIC.MP) #325: Thu Feb 10 12:26:12 MST 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 12746092544 (12155MB)
avail mem = 12342591488 (11770MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (67 entries)
bios0: vendor LENOVO version "8DET52WW (1.22 )" date 09/15/2011
bios0: LENOVO 4290W1B
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT
DMAR UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3)
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 797.56 MHz, 06-2a-07
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 797.42 MHz, 06-2a-07
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 797.42 MHz, 06-2a-07
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IB
Re: No sound on ThinkPad X220 using current snapshot
"Theo de Raadt" wrote: > > OpenBSD 7.0-current (GENERIC.MP) #325: Thu Feb 10 12:26:12 MST 2022 > > Your subject says "current snapshot". But then you show a 4-day old > kernel. > > You can do better. Yes. Kernel #334 is also silent after returning from suspend mode.
Re: No sound on ThinkPad X220 using current snapshot
Matthias Schmidt wrote: > * Alexandre Ratchov wrote: > > On Mon, Feb 14, 2022 at 01:11:09PM +0100, Dirk-Wilhelm Peters wrote: > > > Hi, > > > > > > after a recent update to the latest snapshot on my ThinkPad X220, there > > > is no sound after returning from suspend mode. The problem persists > > > even after a reboot. I have to shutdown/restart the machine to enable > > > audio output again. Headphone output is not affected. > > > > > > > This is recent regression, right? Yes. The latest snapshot fixes the problem. > > FWIW mixer settings are saved during suspend and restored on > > resume. Working headphones suggests this may be caused by parts of the > > system (speaker amplifiers) not being powered. > > FYI, I had the same issue with a Thinkpad X250 and the recent snapshot > from this morning fixed it for me. > > OpenBSD 7.0-current (GENERIC) #336: Wed Feb 16 01:14:53 MST 2022 I have just upgraded my machine (X220) and can confirm that the problem has been fixed. OpenBSD 7.0-current (GENERIC.MP) #346: Tue Feb 15 11:51:21 MST 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12746092544 (12155MB) avail mem = 12342587392 (11770MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (67 entries) bios0: vendor LENOVO version "8DET52WW (1.22 )" date 09/15/2011 bios0: LENOVO 4290W1B acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT DMAR UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 797.54 MHz, 06-2a-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 797.41 MHz, 06-2a-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 797.42 MHz, 06-2a-07 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 797.41 MHz, 06-2a-07 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 5 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus -1 (EXP7) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x104a rev 0x4e acpibat0 at acpi0: BAT0 model "42T4861" serial 5709 type LION oem "SANYO" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured
Re: Generic MIDI controller freezes OpenBSD 7.6 on disconnect
Hi Alexandre, On Fri, 10 Jan 2025, Alexandre Ratchov wrote: > On Fri, Jan 10, 2025 at 11:42:11AM +0100, Dirk-Wilhelm Peters wrote: > > I have an old Behringer BCF 2000 generic MIDI controller which refuses to > > work on my DeskMini X300-based computer running OpenBSD 7.6. When I turn > > on the controller, it is (mal)discovered in the following way: > > > > umidi0 at uhub1 port 1 configuration 1 interface 1 "BEHRINGER BCF2000" rev > > 1.10/1.00 addr 2 > > umidi0: (genuine USB-MIDI) > > umidi0: disabled. > > ugen1 at uhub1 port 1 configuration 1 "BEHRINGER BCF2000" rev 1.10/1.00 > > addr 2 > > > > If I then turn it off or disconnect the USB cable, the system completely > > freezes and I have to force power off by keeping the power button > > pressed. I have tried all USB ports on the system with no better > > results. Also, a different cable did not change anything. > > > > I've one, but mine doesn't panic. Which mode are you using (press > Edit+Store keys and use the first encoder). It was set to USB mode 1. Switching to USB modes 2, 3, and 4 did not change anything. It still connects as "umidi0: disabled" and freezes the system when removed/turned off. > Could you try other USB ports and see if the same happens? It shows the same behavior on all USB ports.
Re: Generic MIDI controller freezes OpenBSD 7.6 on disconnect
On Fri, 10 Jan 2025, Alexandre Ratchov wrote:
> On Fri, Jan 10, 2025 at 02:30:48PM +0100, Dirk-Wilhelm Peters wrote:
> >
> > It was set to USB mode 1. Switching to USB modes 2, 3, and 4 did not
> > change anything. It still connects as "umidi0: disabled" and freezes
> > the system when removed/turned off.
> >
> > > Could you try other USB ports and see if the same happens?
> >
> > It shows the same behavior on all USB ports.
> >
>
> thank you. Here's a diff that should fix the crashes (could you
> confirm it does?) but it's still unclear why the device fails to
> attach
Thanks, I have applied the patch and rebuilt the GENERIC.MP kernel.
Unfortunately, it does not fix the crash and subsequent freezing of the
system.
> Index: umidi.c
> ===
> RCS file: /cvs/src/sys/dev/usb/umidi.c,v
> retrieving revision 1.57
> diff -u -p -r1.57 umidi.c
> --- umidi.c 23 May 2024 03:21:09 - 1.57
> +++ umidi.c 10 Jan 2025 14:15:20 -
> @@ -213,7 +213,6 @@ umidi_attach(struct device *parent, stru
> return;
> error:
> printf("%s: disabled.\n", sc->sc_dev.dv_xname);
> - usbd_deactivate(sc->sc_udev);
> }
>
> int
>
>
Generic MIDI controller freezes OpenBSD 7.6 on disconnect
I have an old Behringer BCF 2000 generic MIDI controller which refuses to work on my DeskMini X300-based computer running OpenBSD 7.6. When I turn on the controller, it is (mal)discovered in the following way: umidi0 at uhub1 port 1 configuration 1 interface 1 "BEHRINGER BCF2000" rev 1.10/1.00 addr 2 umidi0: (genuine USB-MIDI) umidi0: disabled. ugen1 at uhub1 port 1 configuration 1 "BEHRINGER BCF2000" rev 1.10/1.00 addr 2 If I then turn it off or disconnect the USB cable, the system completely freezes and I have to force power off by keeping the power button pressed. I have tried all USB ports on the system with no better results. Also, a different cable did not change anything. Here is what I transcribed from a picture taken from the panic message: $ uvm_fault(0x828b76c8, 0x10, 0, 1) -> e kernel: page fault trap, code=0 Stopped at umidi detach+0x2c7: movq 0xfFfFfff8(%r13,%r15,1),%rdi TIOPID UIDPRFLAGSPFLAGS CPU COMMAND *356252 12133 00x14000 0x2000K usbtask umidi_detach(81faa600,1) at umidi_detach+0x2c7 config_detach(ffFf81faa600,1) at config_detach+0x166 usbd_detach(81739300,808cff00) at usbd_detach+0x5a uhub_port_connect(808cff00,1,2a0) at uhub port_connect+0x82 uhub_explore(8091d500) at uhub_explore+0xb8 usb_explore(8091d400) at usb_expLore+0x13c usb_task_thread(8000380a31d0) at usb_task_thread+0x110 end trace frame: 0x0, count: 8 I tested another generic MIDI controller (KORG nanoKONTROL), and it works fine on this system under OpenBSD. There is also a Linux partition on this machine. The Behringer works fine there, so it does not seem to be an obvious hardware issue. $ usbdevs -v Controller /dev/usb0: addr 01: 1022: AMD, xHCI root hub super speed, self powered, config 1, rev 1.00 driver: uhub0 addr 02: 0bda:5411 Generic, 4-Port USB 2.0 Hub high speed, self powered, config 1, rev 1.27 driver: uhub2 addr 03: 046a:c12a CHERRY, CHERRY USB KEYBOARD full speed, power 100 mA, config 1, rev 1.00 driver: uhidev0 driver: uhidev1 addr 04: 145f:01c8 vendor 0x145f, Trust Wireless Mouse full speed, power 100 mA, config 1, rev 2.00 driver: uhidev2 addr 05: 05e3:0608 Genesys Logic, USB2.0 Hub high speed, self powered, config 1, rev 88.32 driver: uhub3 addr 06: 0582:00e7 Roland, UA-25EX full speed, power 480 mA, config 1, rev 1.01 driver: uaudio0 addr 07: 0bda:0411 Generic, 4-Port USB 3.0 Hub super speed, self powered, config 1, rev 1.27 driver: uhub4 addr 08: 0944:010f KORG INC., nanoKONTROL full speed, power 100 mA, config 1, rev 1.00 driver: umidi1 Controller /dev/usb1: addr 01: 1022: AMD, xHCI root hub super speed, self powered, config 1, rev 1.00 driver: uhub1 addr 02: 1397:00bc BEHRINGER, BCF2000 full speed, self powered, config 1, rev 1.00 driver: umidi0 driver: ugen0 To rule out a problem with OpenBSD, I connected the Behringer to my laptop, which is also running OpenBSD 7.6: umidi0 at uhub3 port 2 configuration 1 interface 1 "BEHRINGER BCF2000" rev 1.10/1.00 addr 3 umidi0: (genuine USB-MIDI) umidi0: out=1, in=1 midi0 at umidi0: ugen0 at uhub3 port 2 configuration 1 "BEHRINGER BCF2000" rev 1.10/1.00 addr 3 It works flawlessly on the laptop. I could record and play back fader movements using midish. Maybe I am missing something obvious, but I don't see it right now.OpenBSD 7.6 (GENERIC.MP) #338: Mon Sep 30 08:55:35 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 14939992064 (14247MB) avail mem = 14463836160 (13793MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xdce24000 (24 entries) bios0: vendor American Megatrends Inc. version "P3.60" date 10/28/2019 bios0: ASRock A300M-STX efi0 at bios0: UEFI 2.7 efi0: American Megatrends rev 0x5000e acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT MCFG AAFT HPET UEFI VFCT IVRS SSDT CRAT CDIT BGRT SSDT SSDT SSDT WSMT acpi0: wakeup devices GPP0(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GP17(S4) XHC0(S4) XHC1(S4) GP18(S4) GPP1(S4) PTXH(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 5 3400G with Radeon Vega Graphics, 3700.00 MHz, 17-18-01, patch 08108102 cpu0: cpuid 1 edx=178bfbff ecx=76d8320b cpu0: cpuid 6 eax=4 ecx=1 cpu0: cpuid 7.0 ebx=209c01a9 cpu0: cpuid d.1 eax=f cpu0: cpuid 8001 edx=2fd3fbff ecx=35c233ff cpu0: cpuid 8007 edx=6599 cpu0: cpuid 8008 ebx=1007 cpu0: cpuid 801F eax=f ecx=f cpu0: 32KB 64b/line 8-way D-cache, 64KB 64b/line 4-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
