Re: Issue with acpi0 on Intel NUC11TNHi3
On 1/16/23 03:01, Bradley Latus wrote:
Hello Stuart,
I noticed that someone else had a similar issue on the openbsd-bugs list..
https://marc.info/?l=openbsd-bugs=166497715729842=2
I was able to apply a patch I found from another user (Joe Miller)
which masks out
GPE_L6F messages and the problem was resolved.
https://gist.github.com/joemiller/9f5698c5634d4a93d101985dc5238365
https://news.ycombinator.com/item?id=33279037
After applying his patch (removing the additional printing parts)
My system was restored to what should be expected.
I can confirm the issue, cpu0 mainly busy with something ACPI related,
cpu1 spinning a lot, the whole system being slow, barely usable.
Applying the patch to mask/ignore the offending interrupt appears to
solve the problem for me.
regards,
Remco
Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.418
diff -u -p -u -p -r1.418 acpi.c
--- acpi.c 13 Sep 2022 17:14:54 - 1.418
+++ acpi.c 18 Jan 2023 17:32:34 -
@@ -2300,6 +2300,12 @@ acpi_gpe(struct acpi_softc *sc, int gpe,
struct aml_node *node = arg;
uint8_t mask, en;
+ /* mask/ignore the GPE_L6F interrupt */
+ if (gpe == 0x6f) {
+ if ( (sc->gpe_table[gpe].flags & GPE_LEVEL) )
+ return (0);
+ }
+
dnprintf(10, "handling GPE %.2x\n", gpe);
aml_evalnode(sc, node, 0, NULL, NULL);
Re: What determines source IP of traffic from OpenBSD box ?
On 26-02-2021 11:53, Rachel Roch wrote: Hi Let's say I'm running "pkg_add -u" on a OpenBSD-based router with multiple interfaces. What determines the source IP ? Building on that, there is no "source interface" flag for pkg_add like there is for ping and certain others. Is there a way for me to configure a default interface for utilities such as pkg_add to use ? Thanks ! Rachel I've never used this myself, so this is just an idea, Maybe setting up a routing domain and running pkg_add using route(8)'s "exec" command will do the job ?
Re: Show driver attached to a PCI device
On 01-05-2020 13:49, Andrey Ponomarenko wrote:
Hello,� Is there a way to show driver attached to a PCI device?� The
pcidump utility doesn't show attached drivers.� Thanks.� Andrey�
I think the following should show you something reasonable for the
currently running kernel:
grep "at pci" /var/run/dmesg.boot
This includes devices without attached driver. ("not configured")
Re: RNG question
On 30-07-19 09:51, Peter J. Philipp wrote: Hi, I had considered doing some programming in visual studio on windows and I really miss the easy arc4random*() routines there. You may be able to get the arc4ramdon interface on systems other than OpenBSD by extracting the necessary files from: - src/lib/libc/crypt/ - src/lib/libcrypto/arc4random/ This appears to work fine on Linux, I haven't tried it on Windows.
Re: One-shot upgrade script
On 25-04-19 01:02, Christian Weisgerber wrote: I don't remember if I ever posted it, but I've been using an "upgrade" script to download bsd.rd, verify it, move it to /bsd, and reboot. With florian@'s additions in -current, I have now extended the script to download the sets and kick off an unattended upgrade. In the best case, you simply run # ./upgrade and the machine will upgrade itself without any further intervention. #!/bin/sh -e ... cp bsd.rd /bsd.upgrade ... I don't think this matches your description.
Re: pip install (python3) requires some development libraries
Op 08/27/18 om 12:09 schreef Максим:
Sorry, I was wrong.
There is a file "lber.h" on the system (/usr/local/include/lber.h)
But the installer doesn't seem to know where to find it.
So the question remains.
--
Maksim Rodin
Maybe you need to use the CFLAGS -I option to include /usr/local/include
in the include search path, something like:
env CFLAGS="${CFLAGS} -I/usr/local/include"
Re: Daily insecurity output on valid users using key with valid shell and without password.
Op 07/01/18 om 19:22 schreef Daniel Ouellet: I find this annoying and sometime I over look this because I always get the example: == Running security(8): Checking the /etc/master.passwd file: Login share is off but still has a valid shell and alternate access files in home directory are still readable. Login xxx is off but still has a valid shell and alternate access files in home directory are still readable. = Is there a better or different way to do this? I always disable the login password on users with * oppose to password in the master.passwd file after keys are installed as I DO NOT want to allow login password when ssh keys are use, but still get the above warning daily on multiples servers & users. The Running security(8): is nice as you see possible changes done by sys admin and you get the feedback, but getting daily warning for the same things sometime will get overlook because of noise. Is there a better way to disable login and not get these warning for ssh key users and keep the valid idea and use of the cronjob as is? Daniel I think you need to use 13 asterisks for the password, passwd(5) has a brief mentioning of this.
Re: Documenting library promises.
Op 04/06/18 om 16:57 schreef Kristaps Dzonsons: Hi folks, Short: what do you recommend for documenting an external library's pledge(2) requirements? Longer: https://bsd.network/@florian/99802355448571943 The question raised in this... um... toot?... is which promises are required by an external library call, in this case khttp_parse(3) in kcgi. Sure, we can always just run the program, look in /var/log/messages for failure, and edit our promises. But just... no. In this particular case, I've documented this function's requirements unofficially here and there---tutorials and such. But it's not canonical. What I'd like is to put these directly into the manpages. Something like: .Sh SANDBOXING On .Ox , the .Fn khttp_parse function requires the .Qq stdio proc promises to .Xr pledge 2 . This encourages developers to use the tightest possible promises. And as mdoc(7) is meant not to be system-specific, this might also include information on, say, .Fx's Capsicum, or maybe whatever Linux uses this week. It already has "SECURITY CONSIDERATIONS", but that just doesn't seem quite right. Thoughts? Kristaps What about having some sort of function yourlib_pledge_set_promises() that sets up these requirements ? I think this also has the advantage of automatically separating pledge specific code (and a man page) from generic code as well as lessening the chance of users of your library setting up incorrect promises for your library. Or in light of updates to your library, users may not need to change their program's pledges since the updated yourlib_pledge_set_promises function will hopefully be sufficient to take care of that.
spontaneous reboot during upgrade using bsd.rd on VIA C3.
0 port 0x2e/2: VT1211 rev 0x02, HM, WDG not activated
viasio1 at isa0 port 0x4e/2: VT1211 rev 0x02, HM not activated, WDG not
activated
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
uhub4 at uhub0 port 5 configuration 1 interface 0 "Genesys Logic USB2.0
Hub" rev 2.00/6.0b addr 2
uhidev0 at uhub4 port 3 configuration 1 interface 0 "Silitek USB
Keyboard" rev 1.10/2.00 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub4 port 4 configuration 1 interface 0 "vendor 0x15ca USB
Optical Mouse" rev 2.00/5.12 addr 4
uhidev1: iclass 3/1
ums0 at uhidev1: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (d51ed4c1b244ce66.a) swap on wd0b dump on wd0b
--- /home/remco/dmesg.boot-6.1 Sun Oct 15 12:44:46 2017
+++ /home/remco/dmesg.boot-6.2 Sun Oct 15 13:19:27 2017
@@ -1,9 +1,9 @@
-OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017
+OpenBSD 6.2 (GENERIC) #163: Tue Oct 3 19:51:20 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: VIA Nehemiah ("CentaurHauls" 686-class) 1.01 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE
real mem = 251088896 (239MB)
-avail mem = 233578496 (222MB)
+avail mem = 232251392 (221MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
@@ -19,7 +19,6 @@
acpiprt1 at acpi0: bus 1 (AGPB)
acpicpu0 at acpi0: !C3(@900 io@0x415), !C2(@90 io@0x414), C1(@1 halt!)
acpibtn0 at acpi0: PWRB
-"PNP0501" at acpi0 not configured
"PNP0401" at acpi0 not configured
"VIA3076" at acpi0 not configured
bios0: ROM list: 0xc/0xe000 0xd/0x8000! 0xd8000/0x9800
@@ -88,8 +87,13 @@
uhidev1: iclass 3/1
ums0 at uhidev1: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
+umass0 at uhub0 port 6 configuration 1 interface 0 "SMI Corporation USB
DISK" rev 2.00/11.00 addr 5
+umass0: using SCSI over Bulk-Only
+scsibus1 at umass0: 2 targets, initiator 0
+sd0 at scsibus1 targ 1 lun 0: <Sharkoon, Flexi-Drive EC2, 1100> SCSI0
0/direct removable serial.090c11287458
+sd0: 3871MB, 512 bytes/sector, 7928832 sectors
vscsi0 at root
-scsibus1 at vscsi0: 256 targets
+scsibus2 at vscsi0: 256 targets
softraid0 at root
-scsibus2 at softraid0: 256 targets
-root on wd0a (d51ed4c1b244ce66.a) swap on wd0b dump on wd0b
+scsibus3 at softraid0: 256 targets
+root on sd0a (98c12b4f06354f7d.a) swap on sd0b dump on sd0b
Re: 6.1 syspatch installed SP kernel on MP system
Antoine, I noticed "/obsd" on my system. Does it make sense to handle this as "previously installed kernel" as part of a kernel update ? AFAICT this is how the manual procedure works as well. Regards, Remco
Re: OpenBSD as a non-routing access point
Op 04/08/17 om 00:06 schreef Jordon: My new wifi adapter finally arrived today (AR9271) so I want to give hostap a try with its new 802.11n support. Unfortunately, all the examples I’ve found center around creating a router/AP when all I want to make is an AP - as in, no DHCP or routing. I just want to bridge my wired network to the wireless one. I want all DHCP requests from wireless devices to get passed to my router so it assigns the address (192.168.77.x). My interfaces are configured like this: /etc/hostname.re0 dhcp /ets/hostname.athn0 media autoselect mode 11n media opt host ap chan 1 nwid testytesterson wpakey testingx inet 192.168.77.253 255.255.255.0 /etc/hostname.bridge0 add athn0 add re0 up A client laptop (running linux mint) sees the access point but will not connect to it. Am I on the right track? Should a bridge be adequate or do I need to configure pf to route between the interfaces? Perhaps the configs for a simple AP-only setup would be a good example for the faq. Thanks Jordon You may want to use tcpdump(8) on the various interfaces, including pflog0, to see what's going on. It's not clear to me whether the bridge needs IP forwarding enabled. Assuming that it does, and you don't have it active, see sysctl.conf(5) for an example to enable it. (I'd say only do this if there's really no traffic at all from the one interface to the other)
Re: Is privilege separated TLS protocol handling of interest ?
Op 01/10/17 om 08:17 schreef Theo de Raadt: I also worry about one process that does decapsulation, on behalf of others. Now all the risk is in one place, and an attack against it which can remain persistant is very worrying - it can see all future traffic. Just in case there is a misunderstanding, the tls_client and kex helper are two additional processes per connection. They're not long lived. There actually is a long lived process, tls_socketd, that executes these programs but it's not involved in the actual TLS handling. (I'm not sure I should elaborate on that) Instead, we've designed daemons which use tls in much narrower domain-specific ways. For a good example, see how ntpd has a completely privilege seperated tls speaker for the "constraint" feature. No memory sharing. Furthermore pledge allows that data flow (and interpretation, which is safe) to sit inside a single address space, with very limited system call operations. That process cannot even do fd passing once it gets going. Though difficult to compare, it looks a lot like with I did, with the big difference that the TLS parts runs in two additional processes. I experimented with pledge in tls_client some time ago. To the best of my knowledge, as soon as the application data exchange begins it can run pledged with "stdio". I haven't thought about re-keying half way, this might change the pledge.
Is privilege separated TLS protocol handling of interest ?
I'm a bit reluctant here because I don't know what I'm getting myself into and I don't really want to spend more time on this than I already do. Anyway, a couple of years ago I wondered what TLS was all about and I tried to understand it by writing code to do TLS as a hobby project. Trying to play with privilege separation as well, things got kind of out of hand and eventually, more or less by accident, I ended up with something looking like the following, e.g., this is what a connection may look like of someone connecting to a service over TLS: application o-o tls_client o-o network (plaintext)(crypto)(ciphertext) o | key exchange (temporary) o kex helper Example of the accompanying public API: int tls_client_socket_unix(int s, ...); The idea is to run the TLS protocol in different processes (tls_client, kex helper) by impersonal users. All TLS/crypto code lives in those processes, the user's application doesn't know about TLS/crypto and does not need to be linked against it. The user application only needs to be able to talk to a daemon over an UNIX socket to exchange a file descriptor. The user doesn't own any keying material, which is set up per user, per key exchange, per role (client/server), per hostname. Only kex helpers have access on behalf of the user. Roughly every key exchange type has its own handler program. A configuration file is involved, only to be changed by a system administrator. The tls_client_socket_unix function is used as follows: - open an ordinary TCP socket "s". - before exchanging application data, pass this socket to the tls_client_socket_unix function, upon successful return, the socket is protected by the TLS protocol and application data can be sent back and forth as if it were an ordinary socket, upon failure the socket is useless. The tls_client_socket_unix function could also be implemented natively in scripting languages supporting file descriptor transfer over an UNIX socket, e.g. Perl, Python, Ruby, without the need for any TLS/crypto modules. Something similar can be done for a service accepting TLS connections. I think I have this working to some extent for ftp(1), httpd(8) and possibly acme-client(1), as well as simple Perl, Python and Ruby modules. What I did is by no means complete or perfect, or even cryptographically secure, still, would it be useful to have this code available ? It seems like a bit of a waste to just let it sit on my hard drive not really doing anything useful. Regards, Remco
Syntax / parsing problem IPv6 nat-to filter rule in PF
Hi all,
In my packet-filter file (/etc/pf.conf) the following line does *not* work:
match out on $rd6_if inet6 proto tcp to any port 119 nat-to {
2A01:1234:5678:9ABC::1/126 } round-robin
If I however use the following syntax, it *does* work:
match out on $rd6_if inet6 proto tcp to any port 119 nat-to {
2A01:1234:5678:9ABC::1, 2A01:1234:5678:9ABC::2, 2A01:1234:5678:9ABC::3,
2A01:1234:5678:9ABC::4 } round-robin
You can imagine I prefer the first shown, shorter syntax. But why doesn't it
work?
Who can tell me how it should be formatted?
Regards,
Remco van den Berg
Re: Updated documentation question: pkg_add manpage
Op 09/05/16 om 05:01 schreef LenLynch: Thanks for all the updates to the man pages and documentation! Is there any special about the pkg_add man page? I followed the guidance for upgrading from 5.9 to 6.0 and removed the old directory for man pages, You did that before starting the actual upgrade, didn't you ? If there isn't anything special about this page, then it just appears to be missing from man60.tgz. I doubt that it is, did you check the actual content of the archive ? # find / -name "pkg_add*" /usr/sbin/pkg_add # man pkg_add man: No entry for pkg_add in the manual. # Of course it's entirely possible that I've done something wrong. If so, please point me toward my error. So far, this is the only manpage that doesn't work... Which ones do work, only the ones from packages ? Did you check if anything exists after the install in /usr/share/man ?
Re: Problem using RFID reader (ucom0 at uslcom0 portno 0)
Op 08/29/16 om 14:28 schreef Martijn Rijkeboer: Hi, I'm having trouble using the Stronglink SL500 RFID reader with OpenBSD. The SL500 is a USB based RFID reader that attaches to ucom. When I write data to it and try to read the response, I'm often getting wrong results. Sometimes the program even lock and unplugging the device is the only option. I'm using the test program attached below. This program should produce the following output (as it always does on Linux): $ ./test received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05 received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05 When I run the program on OpenBSD-current (AMD64) I get the following: $ ./test received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05 received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05 $ ./test received: 0x0a 0xbb 0x06 0x00 0x00 0x00 0x07 0x01 0x02 0x04 received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05 $ ./test received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05 received: 0x0a 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 $ ./test received: 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 0x05 received: 0x0a 0xaa 0xbb 0x06 0x00 0x11 0x12 0x07 0x01 0x00 In the output above the first run is correct. In the second run the first response is incorrect. In the third and fourth run the second response is incorrect. Any suggestions what is wrong? To me it looks like a bug in ucom or uslcom, but I could also be doing something wrong... I've included the test program, lsusb output and dmesg output below. Kind regards, Martijn Rijkeboer Test program O_NONBLOCK: not sure this is necessary. Check return values, at least of read and write (EAGAIN, partial read/write ?), they will probably tell you what's wrong.
Re: convert rsa public key to hex
Marko Cupa? wrote: > Hi, > > I'm trying to set up ipsec-protected gre tunnel from OpenBSD to Cisco, > and - not only thanks to all the useful advices I got in my earlier > thread https://marc.info/?l=openbsd-misc=145043287011537=2, but > also 10x to http://bsdsupport.org/setting-up-ipsec-over-gre-on-openbsd/ > - I've so far managed to successfully establish non-protected gre > tunnel. Also OSPF works through it! > > I want to dive further into ipsec and rsa keys (which BTW I have > successfully configured numerous times in OpenBSD - OpenBSD and > Cisco - Cisco setups, but never in a OpenBSD - Cisco setup), but I've > stumbled upon an obstacle I haven't encountered before: Cisco asks for > public keys in hex number format, similar to: > > 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B2GD66 > 569171F2 0BCEAE31 5DCDD33A AA3E908C C93A46ED 267AA65A 70150BEC F0BAF97C > 3348DDAB 7FB26194 739D3BB2 4114F5BC 87A1F8BD 67DD656C 34540314 0EAD1301 > 40A4FB2C B37438F3 F37F8182 C0C0286C 1200F3A0 73E2D021 D9CAFE2C 547CABCF > 43ED95EE 12C9B4C0 633DA4C4 D7FAF832 31F7AFEA C88DCDCB BBB735D9 CB020301 > 0001 > > ... while OpenBSD's local.pub is similar to: > > -BEGIN PUBLIC KEY- > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ9AMIIBCgKCAQEAtBdefJzPO8VhBUx28wLV > xLk0DeLDTIDU6m+v7DCC1dge3NLK2i+G5wkqUvlOK/vmPkKRydOzioViUiwhoP1q > q6oHE8aQvVCbD7R6lMibx+4Rcejwc3pBzx5K1ibCqj9zhkrVI1SD5PIMAyBF/WxG > rR47c+cXZwwUFspXBddqODaJcH9pFKW1gUhMo58j8MVw2HYyMdQo7nbx5TKybUWd > 9+skXFiTqWumZGqV2OsKqVKsWmbq6jojUwpobRgEXqj0ndHKsGK39YP/XqAx8nYm > pAkaDvFmCE4ntoVHoG/nfKtgpryPEb1nQ3e1t97WgoJUOw3iqutji3XQ+/tDfvWq > HQIDAQAB > -END PUBLIC KEY- > > Any idea on how to convert OpenBSD's /etc/isakmpd/local.pub to hex > number format? > Assuming the key is a hex format of the DER encoding, this may get you in the right direction: openssl pkey -pubin -in /etc/isakmpd/local.pub -outform DER | hexdump -C
Re: multiple headphone sockets and sndiod on Lenovo M83/Tiny-in-One 23
mark hellewell wrote: > Hi, > > I have a Lenovo M83 dropped into a Tiny-in-One 23 and would like to find > out how to get headphone audio working through the socket on the side > of the Tiny-in-One screen. > > Headphone sensing and output works by default when I plug headphones > in to the socket built directly into the M83, but when the unit is plugged > into the screen then plugging headphones into the screen's socket > doesn't seem to do anything. > > All I've really tried so far is setting outputs.hp_source to the other > mixers > identified by the system, but that achieved nothing. I have no idea what > I'm doing with this :( > > Maybe this is something simple? Maybe it is impossible at the moment? > Perhaps I will have to keep the M83 out of the receptacle designed for it > on the back of the screen and use the built-in headphone socket. > > More generally, OpenBSD 5.7 stable seems to run very nicely on this > computer :) The only other issue I've encountered is when switching > from X to console and back again, using Ctrl-Alt-F keys, X seems to > lose acceleration. > > audioctl, mixerctl, dmesg included below. > > Thanks! > > Mark > > > audioctl: > > name=HD-Audio > encodings=slinear_le:16:2:1,slinear_le:20:4:1,slinear_le:24:4:1 > properties=full_duplex,independent > hiwat=9 > lowat=8 > mode=play,record > play.rate=48000 > play.channels=2 > play.precision=16 > play.bps=2 > play.msb=1 > play.encoding=slinear_le > play.samples=4002708480 > play.pause=0 > play.active=1 > play.block_size=3840 > play.errors=10560 > record.rate=48000 > record.channels=2 > record.precision=16 > record.bps=2 > record.msb=1 > record.encoding=slinear_le > record.samples=4002750720 > record.pause=0 > record.active=1 > record.block_size=3840 > record.errors=0 > > > mixerctl: > > inputs.dac-2:3=174,174 > inputs.dac-0:1=174,174 > record.adc-0:1_mute=off > record.adc-0:1=124,124 > record.adc-2:3_mute=off > record.adc-2:3=124,124 > inputs.mix_source=mic,mic2 > inputs.mix_mic=120,120 > inputs.mix_mic2=120,120 > inputs.mix2_source=dac-2:3,mix > inputs.mix3_source=dac-0:1,mix > outputs.spkr_source=mix2 > outputs.spkr_mute=off > outputs.spkr_eapd=on > inputs.mic=85,85 > outputs.mic_dir=input-vr80 > inputs.mic2=85,85 > outputs.mic2_dir=input-vr80 > outputs.hp_source=mix3 > outputs.hp_mute=off > outputs.hp_boost=off > outputs.hp_eapd=on > record.adc-2:3_source=mic,mic2,mix > record.adc-0:1_source=mic,mic2,mix > outputs.mic_sense=unplugged > outputs.mic2_sense=unplugged > outputs.hp_sense=unplugged > outputs.spkr_muters=hp > outputs.master=255,255 > outputs.master.mute=off > outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp > record.volume=124,124 > record.volume.mute=off > record.volume.slaves=adc-0:1,adc-2:3 > > > dmesg: > ... > azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi > azalia0: No codecs found > azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x05: msi > azalia1: codecs: Realtek/0x0233 > audio0 at azalia1 > uaudio0 at uhub4 port 3 configuration 1 interface 0 "CONEXANT > Tiny-in-One 23" rev 2.00/0.04 addr 7 > uaudio0: audio rev 1.00, 5 mixer controls > audio1 at uaudio0 You've got 3 separate audio devices, azalia0, azalia1 and uaudio0. azalia0: probably HDMI audio which isn't supported yet AFAICT azalia1: on-board audio detected as audio0, sndiod normally attaches to this device so all audio played on your systems is played through that. uaudio0: your USB "Tiny-in-One 23" device, sndiod doesn't attach to this by default. To make sndiod use both devices you can add a line to your rc.conf.local: sndiod_flags="-f rsnd/0 -f rsnd/1" where rsnd/0 represents audio0, exposed as snd/0 by sndiod, and rsnd/1 represents audio/1, exposed as snd/1. Specifying either snd/0 or snd/1 in your application determines which device the audio is played on. If you want the USB device to be your default device you could try swapping the parameters: sndiod_flags="-f rsnd/1 -f rsnd/0" If that doesn't work, try: sndiod_flags="-f rsnd/0 -f rsnd/1 -s default" I hope this helps.
Re: sndio non-blocking with kqueue
Sam Good wrote: From sndio design, it looks like non-blocking (like in sio_write) can be done with poll. sio_pollfd can be used to obtain the pollfd struct which contains the file descriptor fd. The fd descriptor seems to be equivalent to the unix stream for the sound playing device. Would it be possible to use the file descriptor fd with kqueue instead of poll? (I wanted to adapt an application that uses kqueue for internet/TCP server listening, and be able to add an audio playing capability; I wanted to try to use kqueue for both. I also wanted to learn more about using kqueue) I wrote a basic program that gets the sndio playing device file descriptor fd from sio_pollfd, and then adds that fd to the kevent with filter EVFILT_WRITE. Then loop with kevent appears to return that the fd is ready for WRITE, and the kevent return data shows '4096' (available space in buffer for write) but sio_write returns with value 0, indicating that no bytes could be written into the output buffer. Is there something different about the file descriptor for the sndio output device, that kqueue/kevent can't be used? thanks. Did you start the device before writing to it ? (read sio_start(3))
Re: hardware support
Joseph Oficre wrote: I got this with VESA driver enabled: [ 1011.000] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem (Operation not permitted) Check that you have set 'machdep.allowaperture=1' in /etc/sysctl.conf and reboot your machine refer to xf86(4) for details Did you act upon this message ? Googled, but nothing helpful :(
Re: man shutdown 8 diff in BSDs
Christian Weisgerber wrote:
--- shutdown.c 16 Jan 2015 06:40:01 - 1.38
+++ shutdown.c 19 Jan 2015 12:03:03 -
@@ -134,6 +134,7 @@ main(int argc, char *argv[])
nosync = 1;
break;
case 'p':
+dohalt = 1;
dopower = 1;
break;
case 'r':
I don't like this. Instead, all the places that handle dohalt and
doreboot should be extended with dopower; see the FreeBSD code.
Is this more to your liking ?
Make -h, -p and -r distinct, incompatible, options. (removes support for -hp)
Like FreeBSD, it seems reasonable to also mark -k as incompatible with the
other three options.
Give -p a distinct code path, sort of.
BTW the previous patch emitted an incorrect message when specifying -pr.
Index: shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.38
diff -u -p -r1.38 shutdown.c
--- shutdown.c 16 Jan 2015 06:40:01 - 1.38
+++ shutdown.c 20 Jan 2015 11:13:46 -
@@ -153,14 +153,9 @@ main(int argc, char *argv[])
shutdown: incompatible switches -f and -n.\n);
usage();
}
- if (doreboot dohalt) {
+ if (dohalt + killflg + dopower + doreboot 1) {
(void)fprintf(stderr,
- shutdown: incompatible switches -h and -r.\n);
- usage();
- }
- if (dopower !dohalt) {
- (void)fprintf(stderr,
- shutdown: switch -p must be used with -h.\n);
+ shutdown: incompatible switches -h, -k, -p and -r.\n);
usage();
}
getoffset(*argv++);
@@ -363,7 +358,7 @@ die_you_gravy_sucking_pig_dog(void)
syslog(LOG_ERR, shutdown: can't exec %s: %m., _PATH_REBOOT);
warn(_PATH_REBOOT);
}
- else if (dohalt) {
+ else if (dohalt || dopower) {
execle(_PATH_HALT, halt, -l,
(dopower ? -p : (nosync ? -n : (dodump ? -d : NULL))),
(nosync ? -n : (dodump ? -d : NULL)),
Re: man shutdown 8 diff in BSDs
Ted Unangst wrote:
On Tue, Jan 20, 2015 at 19:29, Remco wrote:
Christian Weisgerber wrote:
--- shutdown.c 16 Jan 2015 06:40:01 - 1.38
+++ shutdown.c 19 Jan 2015 12:03:03 -
@@ -134,6 +134,7 @@ main(int argc, char *argv[])
nosync = 1;
break;
case 'p':
+ dohalt = 1;
dopower = 1;
break;
case 'r':
I don't like this. Instead, all the places that handle dohalt and
doreboot should be extended with dopower; see the FreeBSD code.
Is this more to your liking ?
Make -h, -p and -r distinct, incompatible, options. (removes support for
-hp) Like FreeBSD, it seems reasonable to also mark -k as incompatible
with the other three options.
I hate this. I type shutdown -hp all the time.
I think this is the best I can come up with in making -p imply -h without
changing anything else:
Index: shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.38
diff -u -p -r1.38 shutdown.c
--- shutdown.c 16 Jan 2015 06:40:01 - 1.38
+++ shutdown.c 20 Jan 2015 10:51:56 -
@@ -158,9 +158,9 @@ main(int argc, char *argv[])
shutdown: incompatible switches -h and -r.\n);
usage();
}
- if (dopower !dohalt) {
+ if (dopower doreboot) {
(void)fprintf(stderr,
- shutdown: switch -p must be used with -h.\n);
+ shutdown: incompatible switches -p and -r.\n);
usage();
}
getoffset(*argv++);
@@ -363,7 +363,7 @@ die_you_gravy_sucking_pig_dog(void)
syslog(LOG_ERR, shutdown: can't exec %s: %m., _PATH_REBOOT);
warn(_PATH_REBOOT);
}
- else if (dohalt) {
+ else if (dohalt || dopower) {
execle(_PATH_HALT, halt, -l,
(dopower ? -p : (nosync ? -n : (dodump ? -d : NULL))),
(nosync ? -n : (dodump ? -d : NULL)),
Re: man shutdown 8 diff in BSDs
f5b wrote:
Want
Power off host at the specified time using shutdown
OpenBSD
# shutdown -ph 1501161730
other BSDs
# shutdown -p 1501161730
Why? Will we sync?
man shutdown 8 in OpenBSD
-h The system is halted at the specified time when shutdown execs
halt(8).
-p The -p flag is passed on to halt(8), causing machines which
support automatic power down to do so after halting.
It makes sense to me to imply -h when specifying -p.
To me the man page already implies the -h option when passing -p.
The code appears to require -h to be set for -p to work. I think making -h
implicit when specifying -p meets this requirement.
This patch changes that, it also removes a check that I think cannot be
triggered anymore.
(tested only once, use at your own risk !)
Index: shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.38
diff -u -p -u -r1.38 shutdown.c
--- shutdown.c 16 Jan 2015 06:40:01 - 1.38
+++ shutdown.c 19 Jan 2015 12:03:03 -
@@ -134,6 +134,7 @@ main(int argc, char *argv[])
nosync = 1;
break;
case 'p':
+ dohalt = 1;
dopower = 1;
break;
case 'r':
@@ -156,11 +157,6 @@ main(int argc, char *argv[])
if (doreboot dohalt) {
(void)fprintf(stderr,
shutdown: incompatible switches -h and -r.\n);
- usage();
- }
- if (dopower !dohalt) {
- (void)fprintf(stderr,
- shutdown: switch -p must be used with -h.\n);
usage();
}
getoffset(*argv++);
Re: OpenBSD sound system
Alfonso Sabato Siciliano wrote: hello, I am willing to know the sound system of OpenBSD, so I started to read the manpages. I summarized with a graph below, it is right? I'm not the expert but it seems about right to me. I think you could draw two additional connections for raw device access. One from sio_open(3) to audio(4) (rsnd) and one from mio_open(3) to midi(4) (rmidi).
Re: problems compiling i386 from source (patching)
li...@ggp2.com wrote: I applied the newest unbound patch to several amd64 machines without trouble, and have had issues on several of my i386 boxes. The initial error was probably the same as below, but led me to believe I may have had some kind of kernel or system frankenbox behavior. I used cvs to pull all the latest sources (cvs -q up -rOPENBSD_5_6 -Pd is what I ran, so it should be the latest patch branch code), compiled/installed/rebooted to the new kernel, then ran through the steps for a make build. make build bombed out on nsd with a similar error. in unbound, running make -f Makefile.bsd-wrapper obj works fine, but make -f Makefile.bsd-wrapper produces the error (which I believe is what I initially saw): ... checking for ctime_r... yes checking if make supports $ with implicit rule in scope... yes configure: Stripping extension flags... configure: creating ./config.status Bad system call (core dumped) config.status: creating Makefile Bad system call (core dumped) config.status: error: could not create Makefile *** Error 1 in /usr/src/usr.sbin/unbound (Makefile.bsd-wrapper:65 '/usr/src/usr.sbin/unbound/obj/config.status') I ran into this as well, and found a similar problem on the net. Unfortunately I didn't preserve the link but read on for a possible solution. If your machine is upgraded all the time you may have /usr/bin/nawk getting in the way, which should have been removed during the 5.5-5.6 upgrade. (section 2. Files to delete and move) It seems I did at least the nsd part of this section, so I just (re)ran the first set of rm-s, which includes /usr/bin/nawk, and the problem was gone.
Re: enumerate sndio devices
In article 5451b32e.7060...@outband.net you wrote: I feel as if i am overlooking somthing obvious, but.. Is there a way to list sndio endpoints? Unless someone has a better idea, I think you need to look at your dmesg. Look for lines audioN at whatever. The audioN device should correspond to a (r)snd/N sndio device. AFAICT the rsnd/N devices are always accessible if a corresponding audioN device is available. The snd/N devices are made available by sndiod. If you have multiple audio devices I think it's necessary to specify them in /etc/rc.conf.local in order to make them available through sndiod. e.g. sndiod_flags=-f rsnd/0 -f rsnd/1 Specifically I was trying to attach a scope(probably one of the ffplay visualizations) to the main output. however I could not figure out what endpoints exist. I don't know if this is what you want, if I connect my USB camera I'm able to get a visualisation by tapping my finger on the camera while running: ffplay -f sndio snd/1
Re: 5.6-beta graphics on MacMini
Jan Stary wrote: This is 5.6-beta on a MacMini (see dmesg bellow). Once OpenBSD boots, it works fine, but the Radeon graphics radeondrm0 at pci0 dev 16 function 0 ATI Radeon 9200 rev 0x01 gets the GPU acceleration disabled. Indeed, when playing a movie with mplayer the image lags behind the sound and is visibly jumping from frame to frame. I remember these problems were not there back in 5.4 which had appeagp(4). Is there any way of getting the GPU acceleration back? Thank you Jan [ using 560188 bytes of bsd ELF symbol table ] console out [ATY,RockHopper2_A]console in [keyboard] , using USB using parent ATY,RockHopper2Paren:: memaddr 9800 size 800, : consaddr 9c008000, : ioaddr 9002, size 2: width 1280 linebytes 1280 height 1024 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org ... drm: initializing kernel modesetting (RV280 0x1002:0x5962 0x1002:0x5962). error: [drm:pid0:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM drm: Using device-tree clock info radeondrm0: VRAM: 128M 0x9800 - 0x9FFF (64M used) trying to bind memory to uninitialized GART ! error: [drm:pid0:radeon_ttm_backend_bind] *ERROR* failed to bind 1 pages at 0x error: [drm:pid0:radeon_wb_init] *ERROR* (-22) create WB bo failed error: [drm:pid0:r100_init] *ERROR* Disabling GPU acceleration drm: radeon: cp finalized drm: radeon: cp finalized Finalizing pool allocator ttm_pool_mm_shrink_fini stub drm: Zone kernel: Used memory at exit: 0 kiB drm: radeon: ttm finalized drm: Forcing AGP to PCI mode error: [drm:pid0:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM drm: Using device-tree clock info radeondrm0: VRAM: 128M 0x9800 - 0x9FFF (64M used) radeondrm0: GTT: 512M 0x7800 - 0x97FF drm: PCI GART of 512M enabled (table at 0x02947000). error: [drm:pid0:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware radeon-r200_cp error: [drm:pid0:r100_cp_init] *ERROR* Failed to load firmware! error: [drm:pid0:r100_startup] *ERROR* failed initializing CP (-2). error: [drm:pid0:r100_init] *ERROR* Disabling GPU acceleration You seem to be missing the firmware. Does running fw_update(1) install it ? (it should install a 'radeondrm-firmware' package and I think it needs a reboot for the firmware to be loaded) I don't know if beta requires a 5.6 firmware, which doesn't seem to exist yet, or, as an alternative, whether it's fine to 'pkg_add' the snapshots firmware at: http://firmware.openbsd.org/firmware/snapshots/radeondrm-firmware-20131002p0.tgz
Re: Change default audiodevice in OpenBSD-current
Johan Svensson wrote: I am trying to change my default output device from my builtin soundcard to an usb soundcard which is an output only device. I have tried: # audioctl -f /dev/audio1 audioctl: /dev/audio1: Device not configured It seems this device does not exist from the kernel's point of view. (there's also /dev/audioctl1, but using that probably doesn't make a difference) I think there should be some controller that you configuring the audio device. But i manually tried to change the symlinks in the dev directory: # ls -la * | grep -E mixer|audio lrwxr-xr-x 1 root wheel6 Jun 3 16:58 audio - audio1 crw-rw-rw- 1 root wheel 42, 128 Jun 3 17:01 audio0 crw-rw-rw- 1 root wheel 42, 129 May 28 19:07 audio1 crw-rw-rw- 1 root wheel 42, 130 May 28 19:07 audio2 lrwxr-xr-x 1 root wheel9 Jun 3 16:58 audioctl - audioctl1 crw-rw-rw- 1 root wheel 42, 192 May 28 19:07 audioctl0 crw-rw-rw- 1 root wheel 42, 193 May 28 19:07 audioctl1 crw-rw-rw- 1 root wheel 42, 194 May 28 19:07 audioctl2 lrwxr-xr-x 1 root wheel6 Jun 3 16:58 mixer - mixer1 crw-rw-rw- 1 root wheel 42, 16 May 28 19:07 mixer0 crw-rw-rw- 1 root wheel 42, 17 May 28 19:07 mixer1 crw-rw-rw- 1 root wheel 42, 18 May 28 19:07 mixer2 But it is still defaulting to my builtin soundcard. How can i change the default sounddevice from audio0 to audio1? I think using sndiod(1) is the answer, in the most simplistic form, something like this in your rc.conf.local(8) should suffice: sndiod_flags=-f rsnd/0 -s onboard -f rsnd/1 -s default This should make your audio0 device available as snd/0.onboard and your audio1 device as the default sound device. (Both should be available as snd/0 and snd/1 respectively as well IIRC). /Regards Johan Svensson DMESG: dmesg | grep audio audio0 at azalia0 audio0 at azalia0 audio0 at azalia0 audio0 at azalia0 uaudio0 at uhub2 port 1 configuration 1 interface 1 NuForce, Inc. NuForce \M-5DAC 2 rev 1.10/0.01 addr 3 uaudio0: ignored setting with type 8193 format If I'm correct format 8193 (== 0x2001) means IEC1937 AC-3. This is an encoded format. AFAICT the uaudio driver only supports plain PCM formats. (unencoded audio samples) Do you know if your device only supports AC-3 inputs or can it also handle PCM signals ? (running 'lsusb -v', from the usbutils package, on the device should give a good clue what your device supports) uaudio0: audio rev 1.00, 2 mixer controls audio1 at uaudio0
Re: getaddrinfo(3) chroot(2) with root
Denis Fondras wrote: Hello all, I am burning my last neurons with a behavior I can't explain. I wonder why getaddrinfo() fails when called after chroot() with root user. I have this piece of code : ... error = getaddrinfo(rpki.liopen.eu, NULL, NULL, ai_out); if (error) printf(getaddrinfo() failed\n); else printf(getaddrinfo() succeed\n); ... Apart from the other suggestions you got, I'm wandering why don't you try to get more information about the error using the gai_strerror(3) function ? (like in the example of getaddrinfo(3))
Re: Weird disklabel problem
fdisk before Disk: /dev/rsd0cgeometry: 121601/255/63 [1953523055 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] - -- 0: A6 0 32 33 - 121601 25 24 [2048: 1953519616 ] OpenBSD 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused Did you guys see my mail yesterday ? (albeit responding to the Problem booting OpenBSD-current AMD64 thread) First of all I'd expect OpenBSD to create its fdisk partition on the partition with id 3, starting at LBA offset 64. (don't know if this changed) Is the partition 0 starting at offset 2048 a Linux left-over ? Anyway, my Gigabyte board used to work fine with a fdisk partition starting at either offset 63 or 64, respectively. Not so much after installing Linux the other day, which put the starting offset at 2048. This happens using the on-board Intel AHCI controller. Fortunately my board also has a non-Intel controller which does work, so being able to use that I didn't put more time into investigating this.
Re: Problem booting OpenBSD-current AMD64
Martijn Rijkeboer wrote: I've installed OpenBSD-current AMD64 on my new computer without problems, but as soon as I reboot the system, it freezes in the post. The only way to go past the post is wiping the first few megabytes of the harddisk using another computer and than start again. After installing I can't even enter the bios setup. The system contains the following components: - Motherboard: Gigabyte GA-B85M-DS3H - CPU: Intel Core i3 4130T - Memory: Kingston ValueRAM 8 GB DDR3-1600 Kit I've configured the bios the following way: - Windows 8 Features: Other OS - Boot Mode Selection: Legacy Only - VGA Support: Auto (Enables legacy option) The system is working since I can install and run Ubuntu 14.04 AMD64 without problems. Any suggestions on how to fix this? Kind regards, Martijn Rijkeboer Experienced something similar today with a Gigabyte board from the Core 2 Duo era. (this may not be an OpenBSD problem in my opinion) Used an disk with a working Fedora 20/OpenBSD 5.4 install on it to do a clean install of OpenSUSE 13.1. Upon first boot the system hangs in the Intel AHCI screen. Normally a list of SATA ports and connected disks would appear but nothing happens. Eventually the simple solution for me was to use the second SATA controller this board has. So it may be an issue with how the Intel SATA BIOS detects the disks. I don't want to waste more time on this so I'm posting some minimal info which may or may not useful: The disk originally had its first partitions start at offset 63: Disk: sd0 geometry: 9729/255/63 [156301488 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- *0: 83 5660 19 56 - 5723 208 53 [90929152: 1024000 ] Linux files* 1: 8E 5723 208 54 - 9729 78 13 [91953152:64348160 ] Linux LVM 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 3: A6 0 1 1 - 5659 254 63 [ 63:90927837 ] OpenBSD Now, in the non-working situation, it starts at 2048 (first MB was reserved by the OpenSUSE installer). Another disk that used to work has its first partition start at offset 64: Disk: sd0 geometry: 7297/255/63 [117231408 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 0 1 2 - 7297 36 27 [ 64: 117228536 ] OpenBSD
Re: OpenSMTPD exits with value 1 when clients attempd to authenticate
Gregor Best wrote: Hi people, I'm running OpenSMTPD 5.4.3 from -current on my private mail server. After a recent update, using authentication for sending mail cause smtpd to exit with exit value 1. A (stripped down) configuration that exhibits the issue is the following: pki server certificate /etc/mail/certs/server.crt pki server key /etc/mail/certs/server.key listen on egress port submission tls-require pki server auth tag AUTH accept tagged AUTH from local for any relay When running smtpd with that configuration and attempting to send an email, this is the output I get from smtpd -dv: [... Usual smtpd startup for OpenSMTPD 5.4.3 ...] debug: smtp: new client on listener: 0x768b632a000 smtp-in: New session 5d471824a3b1c9d2 from host eduroam-75-222.uni-paderborn.de [131.234.75.222] debug: lka: looking up pki server debug: session_start_ssl: switching to SSL smtp-in: Started TLS on session 5d471824a3b1c9d2: version=TLSv1/SSLv3, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256 smtpd: session_imsg: unexpected IMSG_LKA_AUTHENTICATE imsg warn: lka - pony: pipe closed warn: parent - pony: pipe closed warn: mfa - pony: pipe closed warn: queue - pony: pipe closed warn: control - pony: pipe closed warn: scheduler - control: pipe closed [... After this, smtpd has exited with status 1 ...] The client (mail/msmtp from ports) prints the following: msmtp: cannot read from TLS connection: a protocol violating EOF occured The debug output from msmtp is the following: loaded system configuration file /etc/msmtprc loaded user configuration file /home/gbe/.msmtprc using account unobtanium from /home/gbe/.msmtprc host = unobtanium.de port = 587 timeout = off protocol = smtp domain= localhost auth = choose user = gbe password = * passwordeval = (not set) ntlmdomain= (not set) tls = on tls_starttls = on tls_trust_file= (not set) tls_crl_file = (not set) tls_fingerprint = EB:8E:EA:3A:BC:3A:1D:6C:C4:80:5F:FB:A8:24:C8:EB:C8:24:71:5D tls_key_file = (not set) tls_cert_file = (not set) tls_certcheck = on tls_force_sslv3 = off tls_min_dh_prime_bits = (not set) tls_priorities= (not set) auto_from = off maildomain= (not set) from = g...@unobtanium.de dsn_notify= (not set) dsn_return= (not set) keepbcc = off logfile = /home/gbe/log/msmtp/log syslog= (not set) aliases = (not set) reading recipients from the command line -- 220 neon.unobtanium.de ESMTP OpenSMTPD -- EHLO localhost -- 250-neon.unobtanium.de Hello localhost [131.234.75.222], pleased to meet you -- 250-8BITMIME -- 250-ENHANCEDSTATUSCODES -- 250-SIZE 36700160 -- 250-DSN -- 250-STARTTLS -- 250 HELP -- STARTTLS -- 220 2.0.0: Ready to start TLS TLS certificate information: Owner: Common Name: gbe.ring0.de Issuer: Common Name: CAcert Class 3 Root Organization: CAcert Inc. Organizational unit: http://www.CAcert.org Validity: Activation time: Sun Jul 7 18:28:15 2013 Expiration time: Tue Jul 7 18:28:15 2015 Fingerprints: SHA1: EB:8E:EA:3A:BC:3A:1D:6C:C4:80:5F:FB:A8:24:C8:EB:C8:24:71:5D MD5: 69:40:AD:DD:02:63:41:C1:67:55:34:3E:63:95:06:6A -- EHLO localhost -- 250-neon.unobtanium.de Hello localhost [131.234.75.222], pleased to meet you -- 250-8BITMIME -- 250-ENHANCEDSTATUSCODES -- 250-SIZE 36700160 -- 250-DSN -- 250-AUTH PLAIN LOGIN -- 250 HELP -- AUTH PLAIN AGdiZQA0bjRyY2hZXw== Yes, the certificate is weird (common name does not match the host name), but that should not cause the smtp daemon to exit. The setup worked before my last update, but I can't pinpoint the previous version of OpenSMTPD because the maillog rotated away before I noticed the issue. What am I doing wrong here? And how can I debug this further? Is this commit the culprit: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/cert.pem?rev=1.24
Re: pf.conf - block in all - seems to be ignored
Mario Kothe wrote: ... block drop in all pass all flags S/SA keep state (if-bound) ... It's been a while since I played with PF but doesn't the 'pass' rule cancel the effect of the 'block' rule in this case ?
Re: radeondrm errors (amd64) - Hoping bad things won't really happen
(forgot to send this to the list) --- Scott Vanderbilt wrote: I just upgraded a machine from source today. Using snapshots might be a safer bet, unless you have good reason to use sources instead. I then found a lot of interesting errors at the end of my dmesg, the likes of which I've never seen before. Clearly I'm doing something wrong, not because I know how to interpret the error messages, but because virtually every other error I've ever run into on OpenBSD is due to my having done something wrong. Might anyone be kind enough to tell me what it is this time? Not 100% sure, but maybe your card needs a firmware. When upgrading/installing from snapshots this firmware is installed automatically. I don't know if this is also the case when upgrading from source. Look at fw_update(1), running it manually to install missing firmware and doing a reboot to let the system pick it up might help. If fw_update runs as part of an install/upgrade you (or root) should receive a mail of what updates took place. (IIRC it also leaves info in your dmesg) ---
Re: opensmtpd relay via verify
Frank Brodbeck wrote: Hi, On Fri, Feb 14, 2014 at 07:24:32PM -0500, Ted Unangst wrote: I would try using a full path. pki example ca /etc/ssl/myca.pem I already tried it with full path. But I got it working now by specifying certificate and key, too: pki example certificate /etc/ssl/relay.crt pki example key /etc/ssl/private/relay.key pki example ca /etc/ssl/ca.crt and later on: accept from any for domain example.tld relay via tls://relay.example.tld pki example verify But I am still wondering if I am doing it right. Because normally it should be enough to have the signing certificate and it shouldn't be neccessary to provide the peer's cert and key or am I wrong here? From smtpd.conf(5) on OpenBSD 5.4: (You seem to run CURRENT, which I didn't check, so things might be different in your case) relay via host [certificate name] [auth auth] [as address] [source source] [helo names] ... If a certificate name is specified and exists in the /etc/mail/certs directory with a .crt extension, it will be used if the remote server requests a client certificate. Creation of certificates is documented in starttls(8). The way I understand it, this is useful when smtpd is used as a submission relay. It uses the key/cert pair to set up an encrypted connection to a remote server. At the remote end the certificate can potentially be used as a means of client authentication. In this case I think you shouldn't specify the peer's certificate but your host's certificate/key pair instead. You seem to want it the other way around, you want clients that set up an encrypted connection to your server to be verified (authenticated) by means of their certificate. I'm not aware if this is possible with smtpd, but I've never looked into it either.
Re: 1 bit wide unsigned int and regular signed int
Ted Roby wrote:
Consider the following structs. The first struct uses 1 bit wide unsigned
integers
for two flags set by the user during runtime. The second struct performs
the same
function, but used a regular signed integer instead of an unsigned integer
with
a defined bit width.
typedef struct {
char *dev; /* the device we will
monitor */
pcap_t *dev_handle; /* the handle to this
device after opening */
struct pcap_stat ps;/* packet statistics
struct
*/
pcap_dumper_t *pd; /* dump file pointer */
int link_int; /* datalink int of device
*/
int timeout;/* datalink timeout per
packet */
int pcount; /* packets captured */
const char *link_desc; /* datalink description of
device */
const char *link_name; /* datalink name of device
*/
char errbuf[PCAP_ERRBUF_SIZE]; /* pcap err buffer */
bpf_u_int32 net;/* network of sniffing
interface */
bpf_u_int32 mask; /* netmask of sniffing
interface */
char netstr[INET_ADDRSTRLEN]; /* network string */
char maskstr[INET_ADDRSTRLEN]; /* netmask string */
unsigned int use_dumper : 1;/* flag to use dump file
*/
unsigned int use_filter : 1;/* flag to compile filter
*/
char dumpfile[FILESIZE];/* file to dump packets */
struct bpf_program fp; /* compiled filter
expression */
char filter_exp[FILTER_SIZE]; /* filter expression */
} ether_dev_t;
typedef struct {
char *dev; /* the device we will
monitor */
pcap_t *dev_handle; /* the handle to this
device after opening */
struct pcap_stat ps;/* packet statistics
struct
*/
pcap_dumper_t *pd; /* dump file pointer */
int link_int; /* datalink int of device
*/
int timeout;/* datalink timeout per
packet */
int pcount; /* packets captured */
const char *link_desc; /* datalink description of
device */
const char *link_name; /* datalink name of device
*/
char errbuf[PCAP_ERRBUF_SIZE]; /* pcap err buffer */
bpf_u_int32 net;/* network of sniffing
interface */
bpf_u_int32 mask; /* netmask of sniffing
interface */
char netstr[INET_ADDRSTRLEN]; /* network string */
char maskstr[INET_ADDRSTRLEN]; /* netmask string */
int use_dumper; /* flag to use dump file
*/
int use_filter; /* flag to compile filter
*/
char dumpfile[FILESIZE];/* file to dump packets */
struct bpf_program fp; /* compiled filter
expression */
char filter_exp[FILTER_SIZE]; /* filter expression */
} ether_dev_t;
when I run size on the compiled binary and its stripped version there
seems to be a difference of 32 bits in the text portion and overall size.
$ size regular_int regular_int.stripped
textdatabss dec hex
9023744 352 10119 2787regular_int
9023744 352 10119 2787regular_int.stripped
$ size one_bit_u_int one_bit_u_int.stripped
textdatabss dec hex
8991744 352 10087 2767one_bit_u_int
8991744 352 10087 2767one_bit_u_int.stripped
However, when I run ls -l on these files the non-stripped
one bit integer binary is larger, which I did not expect.
$ ls -l one_bit_u_int{,.stripped}
-rwxr-xr-x 1 user user 29014 Jan 10 16:58 one_bit_u_int
-rwxr-xr-x 1 user user 12440 Jan 10 16:59 one_bit_u_int.stripped
$ ls -l regular_int{,.stripped}
-rwxr-xr-x 1 user user 28942 Jan 10 16:57 regular_int
-rwxr-xr-x 1 user user 12472 Jan 10 16:57 regular_int.stripped
Why is the non-stripped, one bit wide integer binary larger than
the non-stripped, regular integer binary?
These were compiled on amd64 -current
For regular integers, usually having a size that match the size of processor
registers and places in memory, I expect the compiler to generate very little
code, probably just a single machine instruction, to deal with those
integers.
Maybe the compiler generates extra code to deal with your one bit sized
variables. It may not be able to
Re: Cannot set stty parameters and read from /dev/ttyU0
Jurjen Oskam wrote: uftdi0 at uhub3 port 6 FTDI P1 Converter Cable rev 2.00/6.00 addr 3 ucom0 at uftdi0 portno 1 But now I can't figure out how to read from /dev/ttyU0. I usually use /dev/cuaU0 when reading from serial-to-USB converters. Unless your cable is different in some way I think running cu(1) on a cua(4) device (something like cu -l/dev/cuaU0 -s9600) may show you the desired information.
Re: Transparent proxy with Squid on OpenBSD 5.4
Romain FABBRI - Alien Consulting wrote:
Hi,
Im trying to do a transparent webfiltering bridge with squid.
Ive used the packages for 5.4 which are squid-3.3.8 and squidGuard-1.4p6
Squid is working fine when the browser uses the vether0 administration
interface of the bridge.
I mean sites are cached and squidGuard is filtering according to my tests
rules.
But its not working when using the bridge as a transparent proxy (without
specifying a proxy server).
If someony could give me some advice that would be really helpfull.
Here is my /etc/pf.conf
# Macros Tables
ext_if=bge0
int_if=bge1
# Options
set skip on lo
set skip on {pfsync}
set reassemble yes no-df
# Redirect www to our transparent squid proxy
pass in quick log on $ext_if inet proto tcp to port 80 divert-to 127.0.0.1
port 3128
pass out quick from 127.0.0.1 divert-reply
# Allow SSH
pass quick inet proto tcp from any to 192.168.200.253 port ssh
# Allow mail
pass out quick proto tcp from $int_if to any port { 25, 143, 993, 995 }
keep state
# Allow Ping/Traceroute/DNS
pass quick inet proto udp from any to any port domain
pass quick inet proto tcp from any to any port domain flags S/SA synproxy
state
pass quick inet proto icmp all icmp-type { echoreq, unreach } keep state
Ive tried almost every tutorial on the net but I had no luck with any of
them using OpenBSD 5.4 and Squid 3.3.8
So Im posting to know if anybody has done this kind of configuration
successfully.
Happy New Year
Romain
In /etc/squid/squid.conf I have configured ports like that :
http_port 3128
http_port 127.0.0.1:3129 intercept
Is it possible that some of your rules are never processed, and therefore have
no effect, because of the skip rule on interface lo ?
Re: [OpenBSD-5.4/amd64] Lenovo T430 hangs in X
Alexei Malinin wrote: Hello. My notebook hangs while working in X (at random times, several times per day). I could not find any information related to the above problemin syslogs. I would like to get a good advice about how to find possible sources of the problem. -- Alexei Malinin Did you read http://www.openbsd.org/report.html ? The section about setting sysctl ddb.console=1 might help you get more information.
Re: Help with USB speakers
leona...@sympatico.ca wrote: I am running openbsd -current 5.4 GENERIC.MP#171 amd64 on a lenovo X1C I just received some USB speakers with DAC and amplifier. The system can see the speakers but I cannot get them to be used when playing music In messages I see: Dec 12 17:09:16 genetraveller /bsd: uaudio0 at uhub3 port 3 configuration 1 interface 0 KEF KEF X300A Speaker rev 1.10/1.07 addr 5Dec 12 17:09:16 genetraveller /bsd: uaudio0: sync ep address mismatchDec 12 17:09:16 genetraveller /bsd: uaudio0: sync ep address mismatchDec 12 17:09:16 genetraveller /bsd: uaudio0: no usable endpoint foundDec 12 17:09:16 genetraveller /bsd: uaudio0: audio descriptors make no sense, error=4Dec 12 17:09:16 genetraveller /bsd: uhidev0 at uhub3 port 3 configuration 1 interface 2 KEF KEF X300A Speaker rev 1.10/1.07 addr 5Dec 12 17:09:16 genetraveller /bsd: uhidev0: iclass 3/0, 1 report idDec 12 17:09:16 genetraveller /bsd: uhid0 at uhidev0 reportid 1: input=15, output=15, feature=0Dec 12 17:09:16 genetraveller /bsd: ugen0 at uhub3 port 3 configuration 1 KEF KEF X300A Speaker rev 1.10/1.07 addr 5 Does anyone know how to debug this and get it working? Thanks. Len Zaifman If you use the lsusb command from the usbutils package on this device you can check its USB descriptors. Look for: AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 If bcdADC says something other than 1.00, I think you're out-of-luck. I suspect it reads 2.00. AFAICT Universal Serial Bus Device Class Definition for Audio Devices Release 2.0 isn't supported by OpenBSD. Unless someone else has a better solution, quite likely the uaudio driver will need somebody able to update it for your device to work.
Re: failure to build nginx after errata 004_nginx.patch
Marko Cupa? wrote: On three of four of my 5.4's, after applying 004_nginx.patch, rebuilding and reinstalling nginx went fine. On one of them it is failing with the following message: objs/src/http/modules/ngx_http_ssl_module.o(.text+0xb36): In function `ngx_http_ssl_merge_srv_conf': src/http/modules/ngx_http_ssl_module.c:627: undefined reference to `ngx_ssl_stapling' objs/src/http/modules/ngx_http_ssl_module.o(.text +0xcb8): In function `ngx_http_ssl_init': src/http/modules/ngx_http_ssl_module.c:794: undefined reference to `ngx_ssl_stapling_resolver' collect2: ld returned 1 exit status *** Error 1 in obj (objs/Makefile:348 'objs/nginx') *** Error 1 in obj (Makefile:8 'build') *** Error 1 in /usr/src/usr.sbin/nginx (Makefile.bsd-wrapper:38 'all') This is 5.4-RELEASE, patched with erratta patches 001, 002 and 003: # uname -a OpenBSD nat1.kappastar.com 5.4 GENERIC#1 i386 Any help? Possible previously compiled left-overs in your object directory ? If I'm not mistaken, cleaning out /usr/obj/ will help.
Re: AnonCVS server data
Jordan Earls wrote: ... My goal with this is to allow for more people to easily take a glance at the source code of OpenBSD. If you mean browsing CVS like the web interface on www.openbsd.org, cvsweb is in ports and is very easy to set up on top of a cvsync-ed CVS repository. (especially when using an unchrooted Apache instance, otherwise the pkg-readme for cvsweb tells you how to run it in a chroot environment) P.S.: if you choose to run cvsweb and appear to be missing some decorative icons, see: http://marc.info/?l=openbsd-portsm=138296871608555w=2.
Re: dump(8) and permissions
Rodolfo Gouveia wrote: On Fri, Oct 11, 2013 at 09:04:16AM -0400, Jiri B wrote: Try `su' to your user on that system and try to `ls -lR' those dirs, I suppose he won't be able to do that. j. Thanks Jiri. Indeed he can't. I've looked at this closer and I found out that on some machines dump doesn't give any error even though the user 'backup' can't list the contents of the folder: $ whoami backup $ ls -lhd /var/audit drwxrws--- 2 root wheel 512B Mar 13 2013 /var/audit $ ls -lhR /var/audit ls: audit: Permission denied The difference I found between those machines is the partition layout. Machine with no errors: $ mount /dev/sd0a on / type ffs (local) /dev/sd0g on /home type ffs (local, nodev, nosuid) /dev/sd0d on /tmp type ffs (local, nodev, nosuid) /dev/sd0f on /usr type ffs (local, nodev) /dev/sd0e on /var type ffs (local, nodev, nosuid) Machine with errors: $ mount /dev/sd0a on / type ffs (local) So the difference is that when '/var' is a real partition, dump doesn't complain at all. Does this make sense? Possibly, yes, but I don't think you're supplying all information necessary to determine that. The exact command you run isn't clear to me. e.g. when specifying 'files-to-dump' as: 1) a list of files and directories, I expect the user running dump to need sufficient access to be able to make a backup of each of the individual files and directories. 2) a mountpoint, I suspect the underlying device node is accessed to make the backup. Guess what ? $ ls -l /dev/sd0a brw-r- 1 root operator4, 0 May 7 19:13 /dev/sd0a AFAICT device nodes are readable by the operator group an thus can be backed up by members of that group. To the best of my knowledge dump can be used to backup whole filesystems by accessing them through the underlying device node as a member of the operator group. Also see dump(8) and the FAQ.
Re: BeagleBone Black cereal
Jan Stary wrote: Dear BBB users, I just bought me a BeagleBone Black board, and want to install the latest snapshot. Firstly, OpenBSD/beagle is dead, replaced by OpenBSD/armv7, right? Secondly, I need a serial cable to connect to the board. http://circuitco.com/support/index.php?title=BeagleBone_Black_Serial mentions 6pin cables that do not quite look like the serial cable I have always used. I just received the Olimex USB-Serial-Cable-F. On my OpenBSD workstation it attached as: uplcom0 at uhub8 port 4 Prolific Technology Inc. USB-Serial Controller rev 1.10/3.00 addr 6 ucom1 at uplcom0 Seems to work fine as a serial connection to the BBB, I can see the boot messages of the stock Angstrom distribution fly by.
Re: Intel hd4000 - no Xvideo support
Otto Kurunczi wrote: First of all, your attachments were removed (information needs to be inline). I am new with OpenBSD, installed 5.3. Modified xorg.conf too. Mplayer cannot play videos as there is no Xvideo support for my video card. Dmesg and xorg.conf attached. How can I get Xvideo support? Thank you. Personally I use VLC which has options to select other types of video output, like e.g. SDL. Is this possible with mplayer ? I've got an ATI card that appears to lack XVideo support as well. For me Xvideo support is available when I run CURRENT which has newer video drivers for my particular hardware. For your Intel hardware there are possibly improved drivers in either the upcoming 5.4 release or CURRENT. (Lacking the hardware, I can't confirm this myself) [demime 1.01d removed an attachment of type application/octet-stream which [had a name of dmesg.boot] [demime 1.01d removed an attachment of type application/octet-stream which [had a name of xorg.conf] Since this information was automatically removed, no one can tell if something is misconfigured.
Re: how routing multicast traffic?
Koenig, Thomas wrote: Hello, I try to route some multicast traffic between two networks, but it does not work. em0: inet 10.100.1.1 netmask 0x broadcast 10.100.255.255 em1: inet 192.168.251.251 netmask 0xff00 broadcast 192.168.251.255 Multicast address: 239.192.1.1 Port 12345 Sender in em1, client in em0 network. changes in /etc/rc.conf: mrouted_flags=NO multicast_router=YES changes in /etc/sysctl.conf: net.inet.ip.mforwarding=1 full /etc/igmpproxy.conf: phyint em1 upstream ratelimit 0 threshold 1 altnet 239.0.0.0/8 phyint em0 downstream ratelimit 0 threshold 1 phyint lo0 disabled igmpproxy log: Current routing table (Insert Route); - Debu: #5: Dst: 239.192.1.1, Age:2, St: I, OutVifs: 0x0001 tcpdump -npi em1 multicast tcpdump: listening on em1, link-type EN10MB 12:31:50.348887 192.168.251.1.51946 239.192.1.1.12345: udp 30 (DF) [ttl 1] 12:31:51.349844 192.168.251.1.51946 239.192.1.1.12345: udp 30 (DF) [ttl 1] 12:31:52.350939 192.168.251.1.51946 239.192.1.1.12345: udp 30 (DF) [ttl 1] 12:31:53.351810 192.168.251.1.51946 239.192.1.1.12345: udp 30 (DF) [ttl 1] 12:31:54.352781 192.168.251.1.51946 239.192.1.1.12345: udp 30 (DF) [ttl 1] I'm not 100% sure how to interpret the [ttl 1] value. Assuming it's the ttl as received by the router, in order to cross the router you need to send packets with a ttl 1. I found this in my personal notes: Every router will decrease the TTL by one. So the TTL determines how many routers can be crossed and how far packets will travel. TTL (sender) destination 0 host 1 local network 1 beyond local network tcpdump on em0: - no packets What I'm doing wrong? Thx in advance for any help. Regards, Thomas
Re: Gnome would not start
Roelof Wobben wrote: Hello, I did all the steps from this tutorial (http://callfortesting.org/gnome3) And I did all the steps that the pkg-readmes/gnome-3.6 says. But still I see a login screen from xdm and fvvm starts up. How can I take care that gnome is starting. Roelof I suspect you need to learn the difference between startx/.xinitrc and xdm/.xsession. The website's FAQ, section 11.5 Customizing X, is probably a good start.
Re: uaudio0: audio descriptors make no sense, with Schiit Bifrost USB DAC
Martijn Rijkeboer wrote: I have a Schiit Bifrost USB DAC that includes an uaudio device for audio playback. When I plug the device in I'm getting uaudio0: audio descriptors make no sense, error=4. Any suggestions on how to make this work? Here are the relevant lines from usbdevs -v (debugging enabled for uaudio): Looks like the audio descriptor of your device doesn't match what uaudio(4) expects. A quirk might be needed. Could you please install the usbutils package and post the output of lsusb -v for your device? Below are the relevant lines of lsusb -v. Before I ran lsusb I've re-installed the system with current (i386). Bus 000 Device 002: ID 0d8c:0319 C-Media Electronics, Inc. ... Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 32 iInterface 2 Schiit USB Audio Device AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) -- bcdADC 2.00 -- If I'm interpreting this correctly your device is an USB Audio 2.0 device. AFAICT there's currently no support for such a device in OpenBSD.
Re: Focusrite Scarlett 2i2 and uaudio error 4 audio descriptors make no sense
gjones wrote: The Focusrite Scarlett 2i2 gives me an uaudio error=4 audio descriptors make no sense Googling, there was a patch made to Freebsd's uaudio last April, http://freebsd.1045724.n5.nabble.com/snd-uaudio-2-0-class-support-for-24-bit-samples-with-bSubslotSize-4-td5806141.html; but I am unable to figure out how to translate this into a patch for OpenBSD's uaudio.c. I don't think this is the problem. Can anyone point me in the right direction? Greg __ $ usbdevs -a 3 -d -v Controller /dev/usb0: addr 3: high speed, power 500 mA, config 1, Scarlett 2i2 USB(0x8006), Focusrite(0x1235), rev 0.cc uaudio0 ugen0 _ from dmesg: ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 . . . . uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2 uaudio0 at uhub2 port 1 configuration 1 interface 0 Focusrite Scarlett 2i2 USB rev 2.00/0.cc addr 3 uaudio0: audio descriptors make no sense, error=4 ugen0 at uhub2 port 1 configuration 1 Focusrite Scarlett 2i2 USB rev 2.00/0.cc addr 3 AFAICT this fails during detection of the device, the uaudio driver isn't able to interpret your device's USB descriptors. Looking at the FreeBSD post, your device seems to adhere to the USB Audio 2.0 specification. I don't think OpenBSD has support for USB Audio 2.0 and that's the reason it fails to detect your device. (note that USB Audio 2.0 is NOT the same as USB 2.0, for which OpenBSD DOES have support)
Re: Bind with GSSAPI
Jeff Powell wrote: I've been tearing my hair out trying to get this to work. I'm running OpenBSD 5.3 x64 and I'm trying to build isc-bind from ports using the -with-gssapi in the Makefile (I want to have the -g option in nsupdate so I can use iscp-dhcp to register dynamic DNS updates against a secure Windows nameserver). I've specified --with-gssapi=/usr in the Makefile. Now, OpenBSD seems to put the gssapi.h in /usr/include/kerberosV, and krb5.h is there too. You need to tell the compiler to look for include files in that directory. Setting up CFLAGS to do so might help. Scanning the ports tree to see how other ports deal with this may be worthwhile too. Yet, when I make the port it gives the following errors: checking for GSSAPI library... looking in /usr/lib checking gssapi.h usability... no checking gssapi.h presence... no checking for gssapi.h... no checking gssapi/gssapi.h usability... no checking gssapi/gssapi.h presence... no checking for gssapi/gssapi.h... no configure: error: gssapi.h not found If the above doesn't help, did you check the output of config.log ? It may give you a more exact reason for this failure. I've tried adding symlinks here and there, but nothing works. I also see that the configure script wants to tack /lib onto the end of whatever path I enter for --with-gssapi=, even though the .h files aren't located in any such folder. Did you check whether this option actually modifies the include file search path in any way ? If it somehow sets a hardcoded path you probably need to cook up a patch yourself. Am I doing something wrong? I'd appreciate any insights. You're posting too often in too many places on a short notice. Thanks, Jeff
Re: Compiling and debugging custom ralink driver for 5.3 GENERIC (release)
On Wednesday 03 July 2013 19:11:19 Nathan Goings wrote: ... I would think if the attach failed it would be in /var/log/messages. How would I debug this? If the attach is failing, I might try crafting it to use a different driver. (guess I should try printf) I usually use printfs in places where I'd like to get more info. It's been a while since I looked into kernel programming so I'm digging most of this this up from my memory: /sys/kern/subr_autoconf.c - here the matching/attaching magic happens. It has an AUTOCONF_VERBOSE define that can be used to get more verbose output, though I don't remember how useful it is. Looking at config(8), I think you should be able to set it in your copy of the GENERIC file as: option AUTOCONF_VERBOSE=1 ...
Re: Compiling and debugging custom ralink driver for 5.3 GENERIC (release)
On Thursday 04 July 2013 20:33:16 Nathan Goings wrote: Thanks! I was just about to ask how to get more verbose output. What is printfs? It's my plural for printf. Finally, Is there a way to re-test the driver match/attach without rebooting? I don't think so, unless your device is hotplugable, like USB.
Re: Compiling and debugging custom ralink driver for 5.3 GENERIC (release)
Nathan Goings wrote: I purchased an Edimax EW-7128Gn that contains a ralink RT3060 chip and it's unrecognized. dmesg: vendor Ralink, unknown product 0x3060 (class network subclass miscellaneous, rev 0x00) at pci4 dev 0 function 0 not configured The documentation says a/g/n but this is a b/g/n. Ralink's drivers use the same firmware across what is supported and the 3060. The linux drivers are grouped in the 2860/3062 (which is supported). Plus the official drivers are open source! So my plan was to force the 3062 (later the 2860) onto the 3060 and see if it worked. Otherwise compare the linux drivers between 2860/3060/3062/3090 and compare the OpenBSD ralink between 2561/2561S/2661/2860 (per sys/dev/pci/if_ral_pci.c) and make the required changes (EEPROM? microcode?) Here's my problem, upon updating /sys/dev/pci/pcidevs (also changed pcidevs.h and pcidevs_data.h, unsure how they are auto-generated) AFAICT it's: - update /sys/dev/pci/pcidevs - run make in /sys/dev/pci/ (see /sys/dev/pci/Makefile for the details) I then updated sys/dev/pci/if_ral_pci.c (and associated cardbus) for pci_matchid ral_pci_devices so that the 3060 is matched by the ralink driver (and by default switch case the rt2860 is used) I still get unknown product 0x3060...not configured in dmesg. AFAIK this is step one. Assuming you added the PCI IDs correctly, the driver's attach function should run. However, to the best of my understanding, you chose a more or less random attach function for your unsupported device. My guess is that the attach function didn't run, or hasn't got the proper support for your device and therefore fails, leaving you with a not configured device. (Frankly, step one should be to first compare drivers and see if OpenBSD has the code necessary to support your device and add the missing pieces, instead of semi-randomly trying to run some OpenBSD code on your unsupported device. Also beware of differences in how the code is licensed in case you want to literally copy stuff.) pcidevs entry: (and correct changes in .h and _data.h) product RALINK RT30600x3060RT3060 and for completeness, I'm successfully building and installing a GENERIC kernal *and* userland. First, how do I correctly compile and associate a not configured product to a specific driver, and second, how do I debug such an association?
Re: who is using obsd
Mark Duller wrote: I wasn't able to get the webcam working this time (in previous versions I got it working, though not reliably). I used the 'video' command but it just gives 'video: could not find a usable encoding' even trying various options. dmesg shows the following but uvideo0 doesn't actually exist in /dev/, perhaps that is related to the issue. uvideo0 at uhub0 port 2 configuration 1 interface 0 Apple Inc. FaceTime HD Camera (Built-in) rev 2.00/5.16 addr 6 video0 at uvideo0 video0 at uvideo0 means you access uvideo0 through /dev/video0. The video(1) tool uses the Xv(3) API to display the video stream. I noticed that the necessary support isn't always available, e.g., on my system: $ xvinfo X-Video Extension version 2.2 screen #0 no adaptors present $ video video: could not find a usable encoding I think the video tool failure could be related to the absence of a Xv capable graphics adapter. I don't know if this is a driver or a configuration issue.
Re: HDMI audio
Ville Valkonen wrote:
On 10 June 2013 23:44, Ville Valkonen weezeld...@gmail.com wrote:
Hello,
I wonder if there's support for HDMI audio (or am I missing something
obvious here)?
Tried play around with mixerctl but no success. These were the most
appropriate values I found and changed:
$ mixerctl -v |grep outputs |grep mix
outputs.spkr_source=mix3 [ mix2 mix3 ]
outputs.hp_source=mix2 [ mix2 mix3 ]
outputs.mic2_source=mix2 [ mix2 mix3 ]
and
outputs.master.slaves=hp { dac-0:1 dac-2:3 spkr hp mic2 }
I confirmed with Linux that the sound through HDMI is enabled and
working on the TV.
So, hints are welcome.
Thanks,
Ville Valkonen
..with this time dmesg included. In addition, sound works perfectly
via speakers and headphones.
snip
azalia0 at pci0 dev 27 function 0 Intel 7 Series HD Audio rev 0x04: msi
azalia0: codecs: Realtek ALC269, Intel/0x2806, using Realtek ALC269
audio0 at azalia0
/snip
I'm not sure if the Intel/0x2806 codec is the HDMI codec.
Anyway, AFAICT HDMI codecs are hardcoded to be disabled. I suppose the
necessary code to make it work is missing.
From the azalia_init_codecs function in src/sys/dev/pci/azalia.c:
/* Use the first codec capable of analog I/O. If there are none,
* use the first codec capable of digital I/O. Skip HDMI codecs.
*/
Also on the TODO list in src/sys/dev/pci/azalia.c:
* TO DO:
* - multiple codecs (needed?)
* - multiple streams (needed?)
I have an ATI graphics board with a separate azalia controller:
azalia0 at pci1 dev 0 function 1 ATI Radeon HD 5470 Audio rev 0x00: msi
azalia0: no supported codecs
In my case I think the only need is the addition of HDMI audio support to
azalia. In your case, assuming the Intel/0x2806 codec is your HDMI codec, I
think multiple codec support is needed as well.
For now I think you're out of luck with HDMI audio.
Re: strange error on openbsd
Philip Guenther wrote:
On Mon, May 6, 2013 at 6:06 PM, Friedrich Locke
friedrich.lo...@gmail.com wrote:
I am in need to write a simple program to return the passwd entry for a
given uid number.
Here you have it:
#include sys/types.h
#include errno.h
#include pwd.h
#include stdio.h
int
main(int argc, char **argv)
{
struct passwd *p;
int e;
e = errno, errno = 0;
p = getpwuid(0);
if (errno) {
This isn't right. To test for whether getpwuid() found an entry for
the UID, test whether its return value is not NULL. If it found the
UID it'll return non-NULL. If it didn't find the UID but didn't hit
any error (it could read the passwd file, etc), then it will return
NULL and not change errno. Only if it didn't find it because of an
error will it set errno.
To be clear, are you sure about this ?
The way I read the man page on my OpenBSD 5.2 system, as well as on the
www.openbsd.org web site, errno has no specific meaning when getpwuid
returns. It only tells you whether it succeeded or not, it doesn't say it
sets errno, nor does it provide a clear way to determine why the function
didn't succeed. (however, if you're right the man page may be lacking)
Re: strange error on openbsd
On Tuesday 07 May 2013 15:45:55 you wrote: On Tue, May 07, 2013 at 03:25:04PM +0200, Remco wrote: | The way I read the man page on my OpenBSD 5.2 system, as well as on the | www.openbsd.org web site, errno has no specific meaning when getpwuid | returns. It only tells you whether it succeeded or not, it doesn't say it Maybe this sentence would have been clearer as follows: The man page only tells you how to check whether the getpwuid function succeeded or not, it doesn't say it | sets errno, nor does it provide a clear way to determine why the function | didn't succeed. (however, if you're right the man page may be lacking) Where do you see that ? errno is not used to tell you wether a call succeeded or not. If a call did not succeed, errno would get set. If a call was successful, it never sets errno. From intro(2) (get there via the errno(2) mlink): When a system call detects an error, it returns an integer value indicating failure (usually -1) and sets the variable errno accordingly. (This allows interpretation of the failure on receiving a -1 and to take action accordingly.) Successful calls never set errno; once set, it remains until another error occurs. It should only be examined after an error. This is how errno should behave across the entire system. If you find a case where this is not true, please report it. Paul 'WEiRD' de Weerd It might be that errno gets set by getpwuid by doing system calls behind the scenes. However, my point was that errno has no specific meaning when getpwuid returns because it does not provide me with any useful context about what failed. (And simply put, the man page does not instruct me to check errno, so errno cannot have meaning here) Otherwise, if errno does have meaning anyway, I think the man page lacks that specific information about what errno values could possibly be set. Apart from being able to tell that some system call failed, I don't really see much point in checking errno as a way to check for specific errors upon returning from getpwuid. I feel that the OP's program behaves as expected and the way he checks for errors, by not adhering to the instructions in the man page, is simply asking for unnecessary trouble. I hope this clarifies my point.
Re: in current: chrootdirectory in ssh (cannot stat /usr/libexec/sftp-server)
Didier Wiroth wrote: Hello, (running current with OpenSSH_6.2, OpenSSL 1.0.1c 10 May 2012) I'm trying to setup chrootdirectory in sshd_config as a test configuration without success. Here is a snip from my sshd_config #(this is the default line) Subsystem sftp/usr/libexec/sftp-server #added the following match block Match Group remote-sync, Address 127.0.0.1 ChrootDirectory /home/chroot/%u ForceCommand internal-sftp -f LOCAL0 -l INFO AllowAgentForwarding no AllowTcpForwarding no GatewayPorts no X11Forwarding no --- The home directory /home/chroot/sync is owned by root:wheel. When I try to connect I get the following error: cannot stat /usr/libexec/sftp-server: No such file or directory What do I miss? Don't know if you missed the obvious. AFAICS the server first chroots to your ChrootDirectory and then tries to find the sftp-server relative to this directory as this has become your new root. I doubt you have /home/chroot/%u/usr/libexec/sftp-server on your system, so it can't be found. What is wrong with my test config? I don't run configs like this but so I can only make an educated guess. Man sshd_config(5) talks about the in-process sftp-server called 'internal-sftp', that's probably what you're after. Thanks for any input!!! Didier See the entire output here: $ sudo /usr/sbin/sshd -D -d -p -f /etc/ssh/sshd_config debug1: sshd version OpenSSH_6.2, OpenSSL 1.0.1c 10 May 2012 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: read PEM private key done: type ECDSA debug1: private host key: #2 type 3 ECDSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-d' debug1: rexec_argv[3]='-p' debug1: rexec_argv[4]='' debug1: rexec_argv[5]='-f' debug1: rexec_argv[6]='/etc/ssh/sshd_ config' debug1: Bind to port on 0.0.0.0. Server listening on 0.0.0.0 port . debug1: Bind to port on ::. Server listening on :: port . debug1: fd 5 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 127.0.0.1 port 31875 debug1: Client protocol version 2.0; client software version OpenSSH_6.2 debug1: match: OpenSSH_6.2 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2 debug1: permanently_set_uid: 27/27 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client-server aes128-ctr hmac-md5-...@openssh.com z...@openssh.com [preauth] debug1: kex: server-client aes128-ctr hmac-md5-...@openssh.com z...@openssh.com [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug1: KEX done [preauth] debug1: userauth-request for user sync service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug1: user sync matched group list remote-sync, at line 124 debug1: connection from 127.0.0.1 matched 'Address 127.0.0.1' at line 124 debug1: userauth_banner: sent [preauth] debug1: userauth-request for user sync service ssh-connection method publickey [preauth] debug1: attempt 1 failures 0 [preauth] debug1: test whether pkalg/pkblob are acceptable [preauth] debug1: temporarily_use_uid: 1001/999 (e=0/0) debug1: trying public key file /home/chroot/sync/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: matching key found: file /home/chroot/sync/.ssh/authorized_keys, line 3 Found matching RSA key: c9:1b:a7:00:9c:52:08:44:1b:2f:7e:28:94:f4:e0:af debug1: restore_uid: 0/0 Postponed publickey for sync from 127.0.0.1 port 31875 ssh2 [preauth] debug1: userauth-request for user sync service ssh-connection method publickey [preauth] debug1: attempt 2 failures 0 [preauth] debug1: temporarily_use_uid: 1001/999 (e=0/0) debug1: trying public key file /home/chroot/sync/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: matching key found: file /home/chroot/sync/.ssh/authorized_keys, line 3 Found matching RSA key: c9:1b:a7:00:9c:52:08:44:1b:2f:7e:28:94:f4:e0:af debug1: restore_uid: 0/0 debug1: ssh_rsa_verify: signature correct Accepted publickey for sync from 127.0.0.1 port 31875 ssh2 debug1: monitor_child_preauth: sync has been authenticated by privileged process debug1: Enabling compression at level 6. [preauth] debug1: monitor_read_log: child log fd closed User child is on pid 2371 Changed root directory to /home/chroot/sync debug1: Entering interactive session for SSH2. debug1:
Re: Spamassassin fails to start after upgrade to latest snapshot
James Griffin wrote: Hi Basically, as the subject says: I upgraded to the latest snapshot and now spamassassin fails start. This is the error out when I try to start it from the command-line: Bad arg length for NetAddr::IP::Util::mask4to6, length is 128, should be 32 at /usr/local/libdata/perl5/site_perl/amd64-openbsd/NetAddr/IP/Lite.pm line 625. Compilation failed in require at /usr/local/libdata/perl5/site_perl/amd64-openbsd/NetAddr/IP.pm line 7. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/amd64-openbsd/NetAddr/IP.pm line 7. Compilation failed in require at /usr/local/libdata/perl5/site_perl/Mail/SpamAssassin/NetSet.pm line 25. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/Mail/SpamAssassin/NetSet.pm line 25. Compilation failed in require at /usr/local/libdata/perl5/site_perl/Mail/SpamAssassin/Conf.pm line 86. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/Mail/SpamAssassin/Conf.pm line 86. Compilation failed in require at /usr/local/libdata/perl5/site_perl/Mail/SpamAssassin.pm line 71. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/Mail/SpamAssassin.pm line 71. Compilation failed in require at /usr/local/bin/spamassassin line 80. BEGIN failed--compilation aborted at /usr/local/bin/spamassassin line 80. Not sure exactly what the problem is. Has anyone else seen this and does anyone know what I can do to fix it? Cheers, Jamie. Maybe you're bitten by the perl update as described in http://www.openbsd.org/faq/current.html.
Re: Logitech Webcam Support
James Griffin wrote: [- Thu 7.Mar'13 at 15:47:12 +0100 Erwin Geerdink :-] On Thu, 7 Mar 2013 13:32:59 + James Griffin j...@kontrol.kode5.net wrote: Hi My desktop is a Lenovo Think centre, and i' stuck a logitech hd 720p webcam in it. I wondered if anyone has had success with these - do they work on OpenBSD and what packages might I need/consider to use it. I ran sudo fw_update and it installed uvideo-firmware-1.2p0. The webcam has a built-in microphone, would that work as well? I haven't tried using a webcam on OpenBSD to-date so just thought i'd ask here about others' experiences with this. Cheers, Jamie I have a Logitech C270 (HD 720p), video works fine with the uvideo driver. I did not test the built-in microphone though Ok, cheers. It seems the microphone aspect of the webcam might be an issue: uvideo0 at uhub1 port 4 configuration 1 interface 0 Logitech product 0x081b rev 2.00/0.10 addr 2 video0 at uvideo0 uaudio0 at uhub1 port 4 configuration 1 interface 2 Logitech product 0x081b rev 2.00/0.10 addr 2 uaudio0: audio descriptors make no sense, error=4 --- What should/can I do to configure this, is it possible using existing drivers in the GENERIC kernel? Will I need to modify the kernel config and recompile it or add some new software for it? Is there a section in the docs about these type of webcams. Cheers, Jamie. I believe this to be a problem with the device that might possibly be worked around, though I don't have a solution, and I don't know of anyone verifying my claim made in this thread: http://marc.info/?l=openbsd-miscm=127952275021290w=2
Re: Merging pf redirection rules with macros?
pekka wrote:
Hi,
is there a way to shorten these redirection rules with some macros
server1 = 192.168.140.1
server2 = 192.168.140.2
server3 = 192.168.140.3
server4 = 192.168.140.4
rdp_port1 = 10001
rdp_port2 = 10002
rdp_port3 = 10003
rdp_port4 = 10004
pass in log on $ext_if proto tcp from any to $ext_if port $rdp_port1 \
rdr-to $server1 port 3389
pass in log on $ext_if proto tcp from any to $ext_if port $rdp_port2 \
rdr-to $server2 port 3389
pass in log on $ext_if proto tcp from any to $ext_if port $rdp_port3 \
rdr-to $server3 port 3389
pass in log on $ext_if proto tcp from any to $ext_if port $rdp_port4 \
rdr-to $server4 port 3389
The port number is always server number + 1
The manual says port ranges are supported with:
pass in on tl0 proto tcp from any to any port 10001:10004 \
rdr-to 192.168.140.1 port 3389
but is there a way to use similar accemding ordering for servers
somehow like this:
pass in on tl0 proto tcp from any to any port 10001:10004 \
rdr-to 192.168.140.1:192.168.140.4 port 3389
-pekka-
I'm not aware of such functionality.
If it's not too much trouble I'd like to suggest using a script to generate
these rules, e.g.:
#!/bin/sh
start=10;
i=${start};
port=0;
server=192.168.0.;
nsrv=2;
while [ $i != $((nsrv+start)) ];
do
echo port $((port+i)) rdr-to ${server}${i};
i=$((i+1));
done
generates:
port 10 rdr-to 192.168.0.10
port 11 rdr-to 192.168.0.11
(I'll leave it to you to fill in the blanks)
If you redirect the output to a file, e.g. /etc/pf/rdp.rules, you can include
that in your main pf.conf.
Re: External USB microphone
Beni wrote: Hello everyone, Please forgive my newbie question but I tried for hours to figure this out and it's still unsolved. I tied to use my Samson meteor USB mic with OpenBSD. When I attach it, dmesg tells me that it found an new audio device. The /dev/audioctl1 and /dev/mixer1 both work for the device. Now when I try to play white noise on the integrated headphone port with cat /dev/urandom /dev/audio1 I get cat: stdout: Input/output error and the following messages in dmesg: ehci0: Error opening low/full speed isoc endpoint. A low/full speed device is attached to a USB2 hub, and transaction translations are not yet supported. Reattach the device to the root hub instead. uaudio_chan_open: error creating pipe: err=INVAL endpt=0x01 My microphone is attached to the root hub of the machine, so I don't really get what's this all about. Are you absolutely sure ? You can deduct that from your dmesg or check/post your USB topology using usbdevs(8). I'm able to connect a working USB audio to device not only to a USB 2.0 root hub directly, but also to an USB 1.x hub connected to an USB 2.0 root hub. As long as there's no USB 2.0 hub requiring transaction translation (TT) in between I expect it to work. (so the USB 1.x hub connected to an USB 2.0 hub requiring TT connected to an USB 2.0 root hub won't work) I'm not sure it's possible that your USB 2.0 root hub requires TT, in which case I fear that you're out of luck. Though if such a thing exists someone might be able to point that out by checking what USB host controller chips(s) your computer has. The full relevant part of dmesg output: To most people only the full dmesg is relevant. (your partial dmesg is missing vital information about your host controller(s) and available USB buses)
Re: how to make power off button work like halt -p
??? wrote: i need to install openbsd on a blind computer(without monitor).so i need to press power off button to shutdown the computer.i know that use ssh is a right way. but press power off is more effective way. in the version 5.2, i just press power off, and the computer shutdown directly without clean the file system. i think this would do harm to the database server. i want to know how to make power off button work link halt -p command. You may need to enable something in your BIOS along the lines of press the power button for 4 seconds in order to power off. From the software perspective, I think you also need the acpibtn(4) device. (check your dmesg for that)
Re: how to make power off button work like halt -p
??? wrote: do you mean that i should compile the acpictn device to the kernel.default 5.2 kernel have acpi device, but without acpibtn. If your dmesg doesn't show a acpibtn device, apart from checking hardware setup (e.g. BIOS settings), I'm out of ideas. -- Original --From: Remcore...@d-compu.dyndns.org;Date: Fri, Nov 23, 2012 04:00 AMTo: ç¼éècob...@qq.com; miscmisc@openbsd.org; Subject: Re: how to make power off button work like halt -p ??? wrote: i need to install openbsd on a blind computer(without monitor).so i need to press power off button to shutdown the computer.i know that use ssh is a right way. but press power off is more effective way. in the version 5.2, i just press power off, and the computer shutdown directly without clean the file system. i think this would do harm to the database server. i want to know how to make power off button work link halt -p command. You may need to enable something in your BIOS along the lines of press the power button for 4 seconds in order to power off. From the software perspective, I think you also need the acpibtn(4) device. (check your dmesg for that)
Re: CPU max frequency
rustyBSD wrote: Hi, that's maybe a stupid question, but how can I get the max frequency of my cpu ? I saw sysctl has hw.cpuspeed and hw.setperf, but can I get the maximum frequency without setting setperf to 100%, getting cpuspeed and then restoring setperf to the value it has before ? Thanks ! AFAICT these dmesg lines tell me the possible frequency settings of my CPU: $ dmesg |grep acpicpu acpicpu0 at acpi0: FVS, 2400, 1600 MHz acpicpu1 at acpi0: FVS, 2400, 1600 MHz Is that what you're after ?
Re: portmap didn't start at boot OpenBSD5.2
Mike Korbakov wrote: Hi, misc ! I've changed /etc/rc.conf to run portmap at startup: portmap_flags=# for normal use: But it not running after boot, see below: You're not supposed to edit rc.conf, but put your config in rc.conf.local.
Re: nasm problem - Probably not.
Chris Bennett wrote:
I went and tried files I had produced many months ago and I get same
error!
./cat[1]: syntax error: `(' unexpected
I don't think the problem is with nasm, but something else?
Chris Bennett
Is it possible you somehow mixed up i386/amd64 libraries/binaries ?
I'd use file to get an impression what arch your files were created for:
e.g.:
$ file ./cat
$ file /usr/lib/libc.so.*
Re: OpenBSD 5.2 song - and pre-orders for 5.2!
Bob Beck wrote: We have made available the song that will come out with the 5.2 release. The song and details of it are linked from: http://openbsd.org/lyrics.html http://www.openbsd.org/lyrics.html is more interesting at present. (it has actual lyrics and commentary) Go have a look and a listen! The details for the upcoming 5.2 release are available at http://www.openbsd.org/52.html A reminder to you all that Pre-orders for 5.2 are can be made by starting from: http://openbsd.org/orders.html Is http://www.openbsd.org/orders.html preferred here as well ? Please consider buying a CD or three. Sales of CD's and merchandise are vital to OpenBSD's continued existence. It is only this revenue stream that keeps the power and air conditionong on, and keeps us all hacking. Thanks!
Re: relayd log file
Bogdan Andu wrote: Hello, I have a reverse proxy based on relayd. however I am unable to see who accesses the server. general directive 'log all' writes the client_ip - actual_web_server_ip in file /var/log/daemon which is enough but that file rotates to quickly and I do not want to change its default setup. How can I tell relayd to log in a file log other than /var/log/daemon ? Thank you, Bogdan I can think of two ways: 1) use the -d switch and redirect the output to a file of your choice. 2) this may be more to your liking, add the following to /etc/syslog.conf: !!relayd *.* /var/log/relayd !* Make sure you have an empty log file, touch /var/log/relayd, and restart (or maybe reload is good enough) syslogd.
Re: inteldrm0 gpu hung
Steve wrote: OK Thanks, Have you found any workaround ? I read in a somewhat unrelated thread someone suggesting to disable drm in the kernel but once I do that X fails to load. Thanks again. Checking /var/log/Xorg.*.log (or possibly ~/.xession-errors) might give a clue what's wrong. Configuring your card to use the vesa driver may also give a workable environment.
Re: wifi not detected during installation
Tomasz Marszal wrote: You can look in http://firmware.OpenBSD.org/firmware. You can look on the manufacturers spec if it support OpenBSD, There is a possibility to add unsupported hardware by compiling its driver in to the kernel if its not in GENERIC Although I am not an expert in server hardware i would look in mobo users manual if there is a jumper for disabling/enabling pcie and in bios. You didnt told us where the Atheros chip is situated is it on mother board on pcie card or is it external device. Best Regards Tomek If You use laptop You can look for the both sidec of the machine there shuld be a switch You told us it is a chip but no info about where is it s On Sat, 23 Jun 2012 17:48:41 +1000, Jonathan Gray j...@jsg.id.au wrote: On Fri, Jun 22, 2012 at 08:21:10PM -0700, Sha'ul wrote: I can't get the Atheros AR9485WB-EG wireless network adapter working. I think it might be tied into the Atheros AR3012 bluetooth 3.0 and Broadcom wireless utility. Looking at athn(4), is there no support for it? The kernel can't see the pcie device. Perhaps a pcie hotplug event is used along with a rfkill switch. Is there a hardware switch to enable/disable wireless on the machine? If I understand the dmesg (and OpenBSD device drivers) properly: OpenBSD 5.2-beta (GENERIC.MP) #0: Fri Jun 22 11:44:03 PDT 2012 sh...@fgsr.vc.shawcable.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP ... Home built kernel, did the OP make any source modifications ? ppb4 at pci0 dev 21 function 0 AMD Hudson-2 PCIE rev 0x00 pci5 at ppb4 bus 5 Atheros AR9485 rev 0x01 at pci5 dev 0 function 0 not configured ... There's an Atheros AR9485 device connected to a PCIe bridge. Being not configured meaning that there's currently no driver support for this device. ... ugen0 at uhub4 port 1 Atheros Communications Bluetooth USB Host Controller rev 1.10/0.01 addr 2 ... Something similar here, an Atheros Communications Bluetooth USB Host Controller USB device is connected, but being attached to ugen, there's no driver for this device either, at present. (besides, AFAICT there's no bluetooth support anyway)
Re: libemu compilation
bofh wrote: Nevermind. Disabled the flags in the Makefile and I was done. Sounds like you're ignoring the problem which is usually a bad thing to do. You're probably missing a header, or possibly the sequencing of the header files is wrong. (inet(3) may help)
Re: Is not possible to disable sndiod process??
carlopmart wrote: On 06/09/2012 12:19 PM, Jérémie Courrèges-Anglas wrote: carlopmartcarlopm...@gmail.com writes: Hi all, How can I disable sndiod process?? I have configured under rc.conf: sndiod_flags=NO rc.conf isn't meant to be edited. use rc.conf.local Uhmm why?? I use rc.conf.local for daemons or options outside of openbsd soft base ... it's simple: - read rc.conf(8) for a better understanding (or study the /etc/rc.conf script and try to figure out what could cause your sndiod_flags to get lost, after all, if you edit this script you should also be able to figure out the consequences of your actions, since it's advised to NOT edit this file) - (older) aucat_flags could interfere with sndiod_flags but if you haven't got a rc.conf.local this is probably not your problem - follow Alexandre's advice
Re: No audio on auvia0 / VIA VT8233 AC97
Brett wrote: Hi, I've gotten an old computer and installed OpenBSD on it, to act as a media player. The problem is I have no sound. First attempt was i386-current, 2nd attempt was amd64-5.1. There are 2 audio minijack outputs, one from the sound ports attached to motherboard, the other is a plug leading to the front jack (there are 2 plugs to fit this connector, one labelled ac97 the other HD audio). I've tried of all these, and also disconnecting the front jack altogether. Sound is tested with mplayer, with files of mp4, avi, mkv formats. $ mplayer -cache 1000 -vo sdl -ao null file.avi results in a great picture, with no frame drops $ mplayer -cache 1000 -vo sdl file.avi results in either a blank screen, or a picture that plays for a brief moment then freezes. Jumping forward (page up or arrow) either repeats this brief playback at the new location, or has no effect. I tried changing bios settings but no difference (disabling/enabling onboard AC97 was the only one that seemed related, but I tried usb1/2 etc as well). I don't have windows available to update bios, but from reading AMD erratas 89 and 97, they don't seem related anyway (see dmesg). My understanding is that auvia(4) should work on this machine. Is there something else I can try before getting a PCI soundcard? .. # mixerctl outputs.master=199,199 outputs.master.mute=off outputs.mono=255 outputs.mono.mute=on outputs.mono.source=mixerout outputs.surround=255,255 outputs.surround.mute=on outputs.surround.lineinjack=off outputs.center=255 outputs.center.mute=on outputs.center.micjack=off outputs.lfe=255 outputs.lfe.mute=on outputs.lfe.micjack=off inputs.spkr=255 inputs.spkr.mute=off inputs.phone=191 inputs.phone.mute=on inputs.mic=191 inputs.mic.mute=on inputs.mic.preamp=off inputs.mic.source=mic0 inputs.line=191,191 inputs.line.mute=on inputs.cd=191,191 inputs.cd.mute=off inputs.video=255,255 inputs.video.mute=off inputs.aux=191,191 inputs.aux.mute=on inputs.dac=191,191 inputs.dac.mute=off record.source=mic record.volume=255,255 record.volume.mute=off outputs.extamp=off outputs.spdif=off A bit of a long shot, I once had a sound card that needed 'outputs.extamp=on' to work.
Re: pfstat -t does not work for me (pfstat-2.3p1)
Ivo Chutkin wrote: Hello, I am collecting interface statistics with pfstat on OpenBSD 4.9. Everything works fine except pfstat -t (days). The .db files getting big so I want to clear old entries, unfortunately it does not work. Here is what I do: root@storage. ~ # du -h /var/db/pfstat.db 801M/var/db/pfstat.db root@storage. ~ # /usr/local/bin/pfstat -t 30:45 -d /var/db/pfstat.db root@storage. ~ # du -h /var/db/pfstat.db 801M/var/db/pfstat.db root@storage. ~ # The .db file is at least 6 months old, so there should be entries to delete. I miss something obvious? What did you expect, a smaller file ? I'm not familiar with pfstat but I suppose you could check if the old records still exist. If not, I suspect that, in general, when records are deleted from a database, the actual storage isn't freed up. This way the database program can reuse it for storing new records. You could check if pfstat has an option to purge/shrink the database or reclaim the database storage. Or maybe a tool exists to shrink a .db file.
Re: all freezes when I move windows in twm
Alexei Malinin wrote: Hello. Please give me an advice how to resolve this annoying problem. At a time when I listen to music on the xmms and simultaneously begin to move any X window, the sound stops. The sound resumes after finishing of moving of the window . I have i386 OpenBSD-4.9 and twm as the X window manager. There is no such problem in the same environment on i386 OpenBSD-4.2. Are you running aucat(1) (aka sndiod in 5.1) as a daemon/sound server ? At first, just try: aucat -l You might need to play a bit with the buffering. You can make it start at boot time by adding a aucat_flags= line (possibly with some additional parameters if needed) to rc.conf.local(8).
Re: Thank you OpenBSD
Alan Cheng wrote: simple clean, is one of the reasons I like OB ~ FUNNY ABBREVIATION ALERT ! Where I live OB is a brand of tampons, so you just made yourself sound like one of their slogans ! LOL
Re: How correctly build php subpackages from ports ?
irix wrote: When I try to build one or two subpackages for php 5.3 or 5.2, system try to build all available subpackages with their dependences. How I can avoid this ? (BTW ports related stuff might be best directed to ports@) I don't think you can. AFAICT php is one monolithic piece of software that can't easily be built as separate pieces. The port has as many optional components enabled to satisfy as many usage scenarios as possible. This means that at build time you get to build the whole lot. By subdividing the port into multiple (sub)packages one gets to choose which individual parts to install, instead of installing everything. In my opinion you can't expect any convenience from MULTI_PACKAGES at build time. MULTI_PACKAGES are convenient at install time to give you a choice to only install those pieces you really need/want. If you really want to influence the way a port is built, you might want to create a FLAVOR. But I doubt that's worth the trouble.
Re: [Kinda OT] Whereabouts of Jacob Meuser?
patrick keshishian wrote: Hi, I have not seen any activity from him on any OpenBSD lists for a while now. I attempted to email him directly but got a quota exceeded message back from the mail-server. Anyone know what's up with him? Hope all is well. --patrick I doubt he's still around. Check the ANNOUNCEMENT files for 4.9 and 5.0, if I didn't miss anything he's mentioned as a developer for 4.9 and not anymore for 5.0.
Re: c++ headers w/ -pedantic, overflow in implicit constant conversion
Stuart Henderson wrote:
There are a fair few of these in c++ builds which tend to obscure some
of the actually useful warnings. Antoine noticed it a while ago, Landry
noticed it recently, I see it from time to time..
Any suggestions other than not using -pedantic? (Actually I think
I have seen this without -pedantic too somewhere but I forget where).
Is this just a silly warning or is there actually a problem with the
headers?
This example is from chopping down a file from converters/wv2 (which
is itself a relatively small example) until the warning no longer
occurs then going back one step.
$ cat a.c
#include string
^D
$ c++ -pedantic -c a.c
In file included from /usr/include/g++/memory:60,
from /usr/include/g++/string:48,
from a.c:1:
/usr/include/g++/limits: In static member function 'static char
std::numeric_limitschar::min()': /usr/include/g++/limits:375: warning:
overflow in implicit constant conversion /usr/include/g++/limits: In
static member function 'static wchar_t
std::numeric_limitswchar_t::max()': /usr/include/g++/limits:530:
warning: overflow in implicit constant conversion
Not a solution, but hopefully helpful.
If I interpreted everything correctly, the macro __glibcxx_min
in /usr/include/g++/limits is used in std::numeric_limitschar::min().
It uses something like ((char)17) to determine the minimum value of a
char. I suspect that ((char)17), or (17) before being converted to
char, is interpreted as 128 in an intermediate stage of the processing.
When being pedantic 128 wouldn't fit in a char at that moment.
(AFAICT -128 = char = 127)
I suspect something similar is the case for the max function. 128 is used as
an intermediate result. Subtracting 1 gets the proper end result. But the
intermediate result (128) doesn't fit in a char when having a pedantic look
at this.
Attached is the simplest case I could come up with to reproduce this:
btw, this is on:
OpenBSD 5.0 (GENERIC.MP) #63: Wed Aug 17 10:14:30 MDT 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
make a file, e.g. t.cc, containing:
char
test1()
{
return ((char)16);
}
char
test2()
{
return ((char)17);
}
char
test3()
{
return ((char)18);
}
compile using C++ compiler:
being pedantic:
$ c++ -pedantic -c t.cc
t.cc: In function 'char test2()':
t.cc:11: warning: overflow in implicit constant conversion
t.cc: In function 'char test3()':
t.cc:18: warning: overflow in implicit constant conversion
NOT being pedantic:
$ c++ -c t.cc
t.cc: In function 'char test3()':
t.cc:18: warning: overflow in implicit constant conversion
copy to a .c file:
$ cp t.cc t.c
compile using C compiler:
being pedantic:
$ cc -pedantic -c t.c
t.c: In function 'test2':
t.c:11: warning: overflow in implicit constant conversion
t.c: In function 'test3':
t.c:18: warning: overflow in implicit constant conversion
NOT being pedantic:
$ cc -c t.c
t.c: In function 'test3':
t.c:18: warning: overflow in implicit constant conversion
Re: c++ headers w/ -pedantic, overflow in implicit constant conversion
sorry, this should have gone to ports@
Re: Which automake and autoconfig versions to compile NTOP v4?
Kaya Saman wrote: Hi, I'm trying to compile the latest NTOP version 4.1.0 on OpenBSD RELEASE 5.0 x64 but am running into issues regarding automake and autoconfig. Basically I installed: automake-1.11.1p2 autoconf-2.67 The install script comes up saying this: # ./autogen.sh Starting ntop automatic configuration system v.0.2.3 Please be patient, there is a lot to do... 1. Testing gnu tools You must have automake installed to compile ntop. Download the appropriate package for your distribution, or get the source tarball from ftp://ftp.gnu.org/pub/gnu/automake We recommend version 1.6.3 or higher You must have autoconf installed to compile autogen.sh. Download the appropriate package for your distribution, or get the source tarball from ftp://ftp.gnu.org/pub/gnu/autoconf We recommend version 2.53 or higher It's weird because both packages are installed and have confirmed that running: find / -name auto(conf and make). Can anyone suggest anything? try: automake --version autoconf --version The messages should be self-explanatory if you didn't define certain environment variables, e.g., I have this in my environment: $ set |grep AUTO AUTOCONF_VERSION=2.65 AUTOMAKE_VERSION=1.11
Re: xxxterm http download weirdness
Mihai Popescu wrote: Hello, I was starting a download of ports from http://ftp.openbsd.org/pub/openbsd/snapshots/ports.tar.gz to compare it with an old archive from a mirror. As you can see, the file size is listed as 20.7M, but what I got is a 220M file which is corrupted as reported by tar. The fact is that artfiles.org mirror works fine. If I watch the bigger file inside download window, it shows 20.7M but after that keeps incrementing till ~ 220M. Is anyone experiencing this ? Haven't tried this myself but I suspect that your HTTP client (xxxterm) tries to decompress the file in transit. AFAICT the HTTP protocol supports compression on the wire. e.g.: - you request index.html on a server - the server compresses the file using gzip - the compressed file is sent to your browser - your browser decompresses the gzipped content and renders the resulting HTML so you can view it I suspect the ports.tar.gz is seen as gzipped HTTP content and your browser tries to decompress it before doing something with it. If this is the case, I don't know how to avoid this. Maybe xxxterm has an option to avoid decompressing content that was already compressed before it was put on the wire. Or maybe someone can recommend another tool. (e.g., does 'ftp http://ftp.openbsd.org/pub/openbsd/snapshots/ports.tar.gz' suffer from this as well ?)
Re: Questions about clock_gettime and friends
Woodchuck wrote:
I. The system call clock_getres(2) and clock_gettime(2) show strange
results.
Consider this small program and its output on OpenBSD 5.0, amd64:
#include stdio.h
#include sys/time.h
main()
{
struct timespec tp;
int i;
clock_getres(CLOCK_REALTIME, tp);
printf(Resolution: %lu %lu\n, tp.tv_sec, tp.tv_nsec);
for (i = 0; i 10; i++) {
clock_gettime(CLOCK_REALTIME, tp);
printf(Performance: %lu %lu\n, tp.tv_sec, tp.tv_nsec);
}
return 0;
}
Resolution: 0 1000
Performance: 1331012858 566149475
Performance: 1331012858 566158834
Performance: 1331012858 566164422
Performance: 1331012858 566169031
Performance: 1331012858 566173152
Performance: 1331012858 566177202
Performance: 1331012858 566181253
Performance: 1331012858 566189075
Performance: 1331012858 566195570
Performance: 1331012858 566219945
Surely the clock is resolving better than 10 milliseconds?
I encounter a similar limit trying to send uncompressed audio over the
network using SIGALRM. (over UDP, I can't really make packets small enough
to fit them into the network MTU and get them delivered in time)
I vaguely remembered reading about a 10 ms limit somewhere. Don't know for
sure this relates to your problem since I'm taking this out of the
context of setitimer(2), which says:
Time values smaller than the resolution of the system clock are rounded
up to this resolution (typically 10 milliseconds).
Don't want to pretend to know what I'm talking about but this thread
suggests to me that OpenBSD potentially has this limitation inside its CPU
scheduler. (http://marc.info/?l=openbsd-techm=131842430012097w=2)
Re: how to update cpu microcode ?
??? wrote: Hello! I observe strange problem on Supermicro X8DTN+-F with OpenBSD-5.0/amd64, when I reboot it, sometime it gets broken, i.e. it doesn't start, I cannot manage it via IPMI. I suspect cpu microcode (it is put via ACPI into unconditional state), is there a way to install microcode on OpenBSD ? as far, as I understand, I need to load microcode every time cpu start. cheers, Ilya Shipitsin AFAICT microcode is included in, and loaded by, your BIOS. So a BIOS update might help. IPMI controllers might have their own firmware and possibly need to be updated independently.
Re: A neat twist on nginx + php-fpm = no input file selected
Scott McEachern wrote: And here's where it can't find the file: 23595 php-fpm-5.3 GIO fd 2 wrote 100 bytes ERROR: Unable to open primary script: /var/nginx/html/who_is_online.php (No such file or directory) ... This problem is a real mystery to me, and I'm hoping I didn't miss something crazy-simple. Can anyone explain it? I'm not familiar with nginx but in general, the crazy-simple explanation I can think of is that you're running from a chroot. So the daemon will look for files relative to its chroot. I stuck with the default php-fpm.conf file, except changing the user:group to _nginx and the chroot dir, so I'll just post a diff: snip # diff php-fpm.conf php-fpm.conf.dist 132,135c132,133 ;user = www ;group = www user = _nginx group = _nginx --- user = www group = www 442,443c440 ;chroot = /var/www chroot = /var/nginx --- chroot = /var/www /snip If the file on your file system is /var/nginx/html/who_is_online.php, a daemon chrooted to /var/nginx will see it as /html/who_is_online.php. If the daemon chrooted to /var/nginx should really see /var/nginx/html/who_is_online.php, the file should live in /var/nginx/var/nginx/html/who_is_online.php on your file system. Hope this helps.
Re: record off of uaudio device (help?)
patrick keshishian wrote: I should have been more specific with my question and subject line: I don't see where aucat's -f device values are documented. I suppose you overlooked sndio(7). Googling finds old (google-cached) current.html pages, circa 2009, suggesting using 'aucat -f sun:1' for /dev/audio1. However, this at first failed: $ aucat -f sun:1 -m rec -o /tmp/test.wav sio(sun:1|): busy loop, disconnecting This should work, unfortunately (according to ratchov@) there's possibly a bug in the (obscure) buffering of USB audio devices which makes this fail for some devices. (Mine happens to be 2-ch, 24-bit @ 44100 Hz, in case that matters) A bit more googling finds this post[1] suggesting addition of -z 256 to aucat, which seems to make things work. $ aucat -z 256 -f sun:1 -o /tmp/test.wav ^C So, yes, in this case it's necessary to specify a buffer size. (in my experience many buffer sizes will work, the one aucat calculates just doesn't)
Re: record off of uaudio device (help?)
On Sunday 19 February 2012 11:32:25 you wrote: On Sun, Feb 19, 2012 at 12:54 AM, Remco re...@d-compu.dyndns.org wrote: patrick keshishian wrote: I should have been more specific with my question and subject line: I don't see where aucat's -f device values are documented. I suppose you overlooked sndio(7). Nope, I read that page. There is no mention of 'sun:x' in that page. There is, however, a reference to 'rsnd/0' being 'First hardware audio device', but trying it and having it fail (before learning of '-z nframes' option) brought me to misc@. I think this can be documented better in aucat(1) with a concrete example or two. --patrick I missed that you're running CURRENT (I was referring to 5.0). AFAICT the sun:x names are deprecated in CURRENT though they may still work. I think you should be able to access the device by the 'rsnd/1' name, albeit specifying the buffer size would still be a necessity.
Re: Hidden Long Filenames and mount_cd9660
Nick Guenther wrote: Here's what cd-info(1) (for the archives: this is from package libcdio) has to say about a DVD that OpenBSD shows LFNs for: ~$ cd-info --dvd cd-info version 0.80 i386-unknown-openbsd4.9 Copyright (c) 2003, 2004, 2005, 2007, 2008 R. Bernstein This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. CD location : /dev/rcd0c CD driver name: OpenBSD access mode: READ_CD Vendor : TSSTcorp Model : CD/DVDW TS-H652D Revision: GA01 Hardware : CD-ROM or DVD Can eject : Yes Can close tray: Yes Can disable manual eject : Yes Can select juke-box disc : No Can set drive speed : No Can read multiple sessions (e.g. PhotoCD) : Yes Can hard reset device : Yes Reading Can read Mode 2 Form 1 : Yes Can read Mode 2 Form 2 : Yes Can read (S)VCD (i.e. Mode 2 Form 1/2) : Yes Can read C2 Errors : Yes Can read IRSC : Yes Can read Media Channel Number (or UPC) : Yes Can play audio : Yes Can read CD-DA : Yes Can read CD-R : Yes Can read CD-RW : Yes Can read DVD-ROM: Yes Writing Can write CD-RW : Yes Can write DVD-R : Yes Can write DVD-RAM : Yes Can write DVD-RW: No Can write DVD+RW: No __ Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (501) truncated to 99. 170: 99:24:74 447224 leadout (1003 MB raw, 873 MB formatted) __ CD Analysis Report CD-ROM with ISO 9660 filesystem and joliet extension level 3 ISO 9660: 2256224 blocks, label `GOSHA_DOCUMENTS ' Application: NERO BURNING ROM Preparer : Publisher : System : Volume : GOSHA_DOCUMENTS Volume Set : ~$ and one that OpenBSD shows SFNs for: ~$ cd-info --dvd [snip common drive info] Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (507) truncated to 99. 170: 99:16:26 446576 leadout (1001 MB raw, 872 MB formatted) __ CD Analysis Report ISO 9660: 2279017 blocks, label `G Save B 6 ' Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003 ROXIO, INC. Preparer : Publisher : System : Volume : G Save B 6 Volume Set : UDF: version 0.00 and another: Disc mode is listed as: DVD-R CD-ROM Track List (1 - 1) #: MSF LSNType Green? Copy? 1: 00:02:00 00 data false no ++ WARN: number of minutes (505) truncated to 99. 170: 99:57:63 449688 leadout (1008 MB raw, 878 MB formatted) __ CD Analysis Report ISO 9660: 2269454 blocks, label `G Save B 7 ' Application: EASY CD CREATOR 6.0 (171) COPYRIGHT (C) 1999-2003 ROXIO, INC. Preparer : Publisher : System : Volume : G Save B 7 Volume Set : UDF: version 0.00 So, obviously, the clue is that Roxio obviously didn't put Joliet data on the discs (grrr), which Nero did on the other one. But nevertheless the long file names *are* there because linux reads them. Is there any way to make OpenBSD find the long names anyway? Thanks to all you lovely misc@ers, -Nick If I'm not mistaken your LFN disc only show ISO9660, the SFN discs have an additional UDF: version 0.00 marker. I've never used it so I don't know if it's the right tool for the job but there is mount_udf(8) on OpenBSD. I'll leave it to you if you want to risk trying it, or wait for more knowledgeable people to chime in.
Re: Trouble getting gpsk31 to connect with sound device...
Tracy Bales wrote: OK...I did a system reboot. And now I'm finding out that the azalia driver will not change the sample rate from 48 KHz to 8 KHz. I also tried using audioctl record.sample_rate=8000 but it returns with record.sample_rate: 48000 - 48000 So, is the problem with the azalia driver or my hardware? Can others running the azalia driver change their sample_rate to anything else but 48000? The ALC888 chip supports 44.1/48/96/192 kHz, but that's not necessarily a show stopper. On Sat, Jan 21, 2012 at 10:09 PM, Tracy Bales balestr...@gmail.com wrote: I'm running OpenBSD 5.0/i386. I used pkg_add to install the gpsk31 package. I tried running the program with the following sound devices: default, /dev/audio, /dev/audioctl and /dev/sound. Each attempt to execute gpsk31 returns the following: init_audio: can't open /dev/audio Cannot initialize audio device: /dev/audio -1 AFAICT /dev/audioctl can't be used to play audio. Unfortunately the error message is a bit vague, the program doesn't really tell the reason of the failure. In general you're most likely best of by not using these audio devices directly. Try running aucat(1) as a daemon (e.g.: aucat -l), this would also take care of sample rate conversions. (usually automatically) To have aucat start up at boot time you'll need at least an empty aucat_flags= in your rc.conf.local file. I don't know gpsk31 and whether it has been converted to use OpenBSD's libsndio, but I reckon it has, otherwise you're probably out of luck. If it has, you should be able to use sndio(7) device names. (e.g. aucat:0 i.o. /dev/audio) I also advise to read the mentioned man pages.
Re: OpenBSD 5.0-current (GENERIC) #65: Thu Nov 3 00:58:36 MDT 2011
Martin Pelikan wrote: On Thu, Jan 19, 2012 at 06:16:59PM +0100, Francois Pussault wrote: I use this : # echo $PKG_PATH ftp://ftp.openbsd.org/pub/OpenBSD/5.0/packages/sparc64/ In case someone googles that and would think it's a good idea to set the variable like so, here's a better alternative: echo 'export PKG_PATH=ftp://ftp.XX.openbsd.org/pub/OpenBSD/`uname -r`/packages/`uname -m`/' ~/.profile for -release and -stable, or echo 'export PKG_PATH=ftp://ftp.XX.openbsd.org/pub/OpenBSD/snapshots/packages/`uname -m`/' ~/.profile for guess what? -current of course! Even that your -current might not be exactly the same one these packages were built on. I was advised some time ago that using `uname -m` is wrong: (`arch -s` should be a better choice) http://marc.info/?l=openbsd-miscm=131694698627338w=2
Re: 'pkg_add -u' question
Dave Anderson wrote: I have a notebook with a couple of devices which require non-free firmware. When I installed 5.0-release (amd64 from CD) it asked me if I wanted those files downloaded on first boot; when I said YES it proceeded to find and download them and everything 'just worked'. (This was very convenient; my thanks to the developers who made it happen.) But when I upgraded to a 5.0-current snapshot (and later rebuilt from source, most recently as of 9 January 2012) and then ran 'pkg_add -ui' it was unable to update those files: Couldn't find updates for uvideo-firmware-1.2p0, iwn-firmware-5.6p0. I don't think the firmware files live in the same place as ordinary packages. I expect that the place these files reside is not in your PKG_PATH. If I remember correctly you should have a similar check for firmware files option during upgrades as during install. Did you check your (or root's) mail ? I think there might be a message telling whether it was necessary to update any firmware files. I'd expect that making 'pkg_add -u' able to find these files would be fairly simple (either by giving it access to the same data used by the installer or by recording where it was found with any package added from a source not in PKG_PATH), and it would certainly make life a bit more convenient when upgrading. Am I missing something important, is this on someone's TODO list, do the installer and pkg_add developers not talk to each other, or what? AFAICT the tool used is fw_update(1). $ file /usr/sbin/fw_update /usr/sbin/fw_update: Bourne shell script text executable You could check this script to see if it has any clues to help you fulfill your expectations.
Is iscsid usable ?
I wanted to try out iscsid to see if it's of any use to me. However, iscsi.conf(5) doesn't seem to exist, neither am I able to find any documentation on how to use and configure iscsid. So I'm wondering, am I missing something, or is it not yet usable ?
Re: Fwd: mSATA failure on 6501 w/ OpenBSD 5.0
Chris Cappuccio wrote: here is the key error message. it means your whole ahci disk has disappeared (and anything you can still run is happening from cache.) -- ahci0: stopping the port, softreset slot 31 was still active. ahci0: failed to reset port during timeout handling, disabling it -- likely a reboot will fix it. this is a known problem with ahci driver and intel ahci controllers. I am not so sure this is a driver problem. I think I accidentilly emulated this problem the other day on my desktop system (not a 6501): Nov 28 16:38:44 ws0001 /bsd: ahci1: stopping the port, softreset slot 31 was still active. Nov 28 16:38:44 ws0001 /bsd: ahci1: failed to reset port during timeout handling, disabling it I have this external drive bay connected through e-SATA. After unmounting the drive I switched off the external drive's power. Running disklabel on the drive resulted in the above failures, which I guess makes sense, after all, I made the drive disappear. the failed to reset port and softreset slot was still active problems become really obvious once you start maxing out disks on an ahci controller with a softraid array. they rarely present problems in normal use! but, the SSD sata drive may evoke different behavior for some reason. i think continuous runs of iogen over a RAID1 array might bring out similar issues all by itself, even with regular hard disks Maxing out disks sounds like having more activity on the disks, possibly making them draw more power. Could these errors relate to bad power cabling or insufficient power supply ? If multiple disks with an insufficiently powered system are the problem, one solution might be a power supply that can deliver more power, another possible solution might be using external drive bays, each having their own power supply. For stuff purely SSD related, a motherboard BIOS update and/or SSD firmware update may help as well.
Re: OpenBSD 4.9 with softraid
Ben Short wrote: When I get to the step where I need to copy whats on the first drive to the second but I get the following error # dd if=/dev/sd0a of=/dev/sd1a dd: /dev/sd0a: Device busy I suppose /dev/sd0a is mounted. I think you need to do the copying by dd when sd0a isn't mounted. You could boot from the ramdisk kernel (bsd.rd) and work from its shell. Another viable option might be dump/restore. (a.o., read dump(8), restore(8), FAQ 10.2 and 14.10)
Re: rc_scripts
Vijay Sankar wrote: Is it possible that you are installing packages from the wrong version? I have done that a couple of times because I copied .profile files from the wrong server Is your PKG_PATH set to /pub/OpenBSD/4.9/packages/amd64, for example? To avoid release/architecture mixups you could use something like /pub/OpenBSD/`uname -r`/packages/`uname -m`/. I haven't got a CURRENT system available right know but I reckon `uname -r` could also be used to conditionally set package path to /pub/OpenBSD/snapshots/packages/`uname -m`/ when running a non-release version.
Re: OpenBSD 4.9 + Sound Blaster Live!
James Colannino wrote: On 08/17/11 06:23, Alexandre Ratchov wrote: could you provide a dmesg and the list of commands that you run and that didn't work? Sorry it took me so long to get back to everyone. I've been having all sorts of other issues at work that have prevented me from responding sooner. Here's the output of dmesg, audioctl and mixerctl: James First of all, I think you forgot to tell which command/application you're using and what kind of audio you're trying to play (WAV, MP3, AU, AIFF, Ogg/Vorbis, FLAC, ...). Is there any output on your screen or in /var/log/* showing anything problematic while playing sounds ? One way for me to get a lot of noise is accidentilly playing a file with an unexpected format, like this: aucat -i somefile.au About your audioctl: name=SB Live! .. play.error=1 .. play.errors=2961 Some errors though I don't expect this to necessarily be the problem. About your mixerctl: outputs.master=255,255 outputs.master.mute=off Your output levels are maxed out, I'd start off from e.g. outputs.master=100,100, going up if necessary. inputs.spkr=255 inputs.spkr.mute=off I'd mute this, I think it might pick up noise. record.source=mic record.volume=255,255 record.volume.mute=off You may not need this, so trying to mute it to see if it makes a difference probably doesn't hurt. About your dmseg: OpenBSD 4.9 (GENERIC.MP) #819: Wed Mar 2 06:57:49 MST 2011 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3128442880 (2983MB) avail mem = 3031142400 (2890MB) .. acpiec0 at acpi0acpiec _REG failed, broken BIOS .. cpu0: unknown i686 model 0x2a, can't get bus clock .. ... unknown product 0x0100 ... .. ... not configured .. Realtek 8168 rev 0x06: unknown ASIC (0x2c80), apic 0 int 18 (irq 11), address ff:ff:ff:ff:ff:ff rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5 .. io address conflict 0x2000d000/0x100 It seems you've got pretty new hardware, not fully supported by your 4.9 installation. I recommend using a snapshot to get an OS which is likely a better match to you hardware. I hope any of this helps. regards, Remco
Re: [OT] io event triggered file system synchronisation
frantisek holop wrote: hi there, sorry for the offtopic but there are probably many knowledgeable admins on this list as well. i am looking for a solution that keeps monitoring file system io for all stuff under a certain path and whenever files change/get added/removed it synchronises these changes with multiple remote locations. basically sql replication for file system :] anybody using something like this? -f I've never used it, I don't know how well it works, but it might fit your needs: http://en.wikipedia.org/wiki/Andrew_File_System
Re: sysmerge doesn't work on snapshot upgrade (FIXED)
On Tuesday 12 July 2011 21:19:15 you wrote: On Tue, 12 Jul 2011, Remco wrote: During a snapshot upgrade for both i386 and amd64 OpenBSD 4.9-current (GENERIC.MP) #10: Mon Jul 11 12:31:05 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP OpenBSD 4.9-current (GENERIC.MP) #19: Mon Jul 11 12:20:24 MDT 2011 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP the option to run sysmerge at the end doesn't work: Merge the new etc/xetc install sets using sysmerge(8)? [no] yes ftp: Can't open file ///mnt2/4.9/amd64/etc49.tgz: No such file or directory ftp: Can't open file ///mnt2/4.9/amd64/xetc49.tgz: No such file or directory *** ERROR: please specify a valid path to src or (x)etcXX.tgz usage: sysmerge [-bd] [-s [src | etcXX.tgz]] [-x xetcXX.tgz] I (re)tried an upgrade on i386 and everything appears to work just fine: OpenBSD 5.0-beta (GENERIC.MP) #19: Mon Jul 18 15:37:10 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP thanks Antoine
snapshot upgrade defaults to fetching sets from http i.o. cd
A snapshot upgrade for both i386 and amd64 OpenBSD 4.9-current (GENERIC.MP) #10: Mon Jul 11 12:31:05 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP OpenBSD 4.9-current (GENERIC.MP) #19: Mon Jul 11 12:20:24 MDT 2011 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP seem to want to fetch the installation sets over http instead of from cd, even though a cd with the sets on them is in the cd drive: Let's upgrade the sets! Location of sets? (cd disk ftp http or 'done') [http] cd I don't know if this is intentional or an oversight, but it doesn't make much sense to me. Regards, Remco
