Re: Any Audigy users here?
On Sun, Mar 30, 2008 at 04:56:59AM +0200, Zbigniew Baniewski wrote: I'm unable to have sound on both outputs available in Audigy. Perhaps any Audigy owner could make a tip, how can I achieve that (if that's possible at all, using current audio driver)? OpenBSD 4.2 the original Audigy and Audigy2 cards are supported, but changing the dac volume doesn't work. other Audigy variants aren't supported at all. last I tried/heard, Creative wants an NDA to give out hardware specs. I've looked at adding multi-channel support to emu(4). I'm guessing that's what you mean by sound on both outputs. it's not likely to happen. emu(4) is ugly wrt channel handling :( Audigy and Audigy2 support was back-ported from the Haiku driver for emu10k1, which is based on the emuxki driver we have. if you really want to extend emu(4), your best bet is to do more back-porting from there. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: About Squid port for OpenBSD 4.2
yes i did
i precise that i have installed openldap-client package before to get
the ldap libraries and this is what i get when building Squid:
Rosen Iliev a C)crit :
Hi,
I guess you didn't install openldap-client package?
Rosen
ComC(te wrote:
Hi,
i'm trying to recompile SQUID 2.6-STABLE13 port for OpenBSD 4.2
with LDAP auth helpers and ldap_group helpers support and get errors
during the compilation. This is what i modified in the Makefile:
...
CONFIGURE_ARGS+=--datadir=${PREFIX}/share/squid \
--enable-auth=basic digest \
--enable-arp-acl \
--enable-basic-auth-helpers=NCSA YP LDAP \
--enable-digest-auth-helpers=password \
--enable-external-acl-helpers=ip_user unix_group
ldap_group \
--enable-removal-policies=lru heap \
--enable-ssl \
--enable-storeio=ufs diskd null \
--localstatedir=${SQUIDDIR}
...
i precise that i have installed openldap-client package before to get
the ldap libraries and this is what i get when building Squid:
# make
Making all in LDAP
if cc -DHAVE_CONFIG_H -I.
-I/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP
-I../../../include
-I/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/include -O2
-pipe -MT squid_ldap_auth.o -MD -MP -MF .deps/squid_ldap_auth.Tpo -c
-o squid_ldap_auth.o
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c;
then mv -f .deps/squid_ldap_auth.Tpo .deps/squid_ldap_auth.Po; else
rm -f .deps/squid_ldap_auth.Tpo; exit 1; fi
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:121:18:
lber.h: No such file or directory
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:122:18:
ldap.h: No such file or directory
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:135:
error: `LDAP_SCOPE_SUBTREE' undeclared here (not in a function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:139:
error: `LDAP_DEREF_NEVER' undeclared here (not in a function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:145:
error: `LDAP_NO_LIMIT' undeclared here (not in a function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:152:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:206:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_errno':
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:208:
error: `ld' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:208:
error: (Each undeclared identifier is reported only once
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:208:
error: for each function it appears in.)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
At top level:
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:211:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_set_aliasderef':
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:213:
error: `ld' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:213:
error: `deref' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
At top level:
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:216:
error: syntax error before '*' token
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
In function `squid_ldap_set_referrals':
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:218:
error: `referrals' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:219:
error: `ld' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:219:
error: `LDAP_OPT_REFERRALS' undeclared (first use in this function)
/usr/obj/ports/squid-2.6.STABLE13/squid-2.6.STABLE13/helpers/basic_auth/LDAP/squid_ldap_auth.c:
At top level:
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Douglas A. Tutty wrote: ... Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this... Nick Holland wrote: config strictly deactivates the drivers, it doesn't reduce memory consumption or disk footprint. ... Digressing slightly into config and what's in the FAQ regarding why or why not to deviate from GENERIC... Using config to modify the GENERIC kernel's settings can apparently improve boot speed. So maybe config should be mentioned in section 5.6 of the FAQ, Why do I need a custom kernel? to steer those wondering about improving boot time away from trying unnecessarily to create a custom kernel. e.g. for B' 5.6, Why do I need a custom kernel? Removing device drivers may speed the boot process on your system, but can complicate recovery should you have a hardware problem, and is very often done wrong. config can be used instead of re-compiling to modify kernel parameters and speed booting. See the section of the config(8) man page on kernel modification Since OpenBSD uses a monolithic kernel, it is outside the ability of config to physically remove the deactivated drivers. ... That could also be useful to have in the FAQ somewhere. It's explicit in the kernel's nature, but could be mentioned for those who miss the ramifications of using a monolithic kernel. Removing drivers for reduced memory is really a for advanced users only task, and you VERY QUICKLY run into diminishing returns. That can be emphasized more heavily by moving forward one sentence in section 5.6, and adding that in. e.g. for the very start of B' 5.6: Actually, you probably don't. Only the most advanced and knowledgeable users with the most demanding applications need to worry about a customized kernel or system, and even then you very quickly run into diminishing returns. Regards, -Lars
Re: About Squid port for OpenBSD 4.2
openldap includes are installed in /usr/local/include/ and libraries in /usr/local/lib/.
DNSRBl
Dear all haloo everyone, how to make my openbsd machine working like opendns or rbldns ... -- sonjaya http://sicute.blogspot.com
Re: Any Audigy users here?
On Sat, Mar 29, 2008 at 09:02:21PM -0700, Predrag Punosevac wrote: The question is which Audigy? Creative makes wide variety of cards sold under that name and even the known one are sometime sold with different chip version (usually undocumented when they switch a chip). It's Sound Blaster Audigy SB1394 SB0230 Not tried the recording, but playing is OK - with the exception, that I can't use both outputs. OSS of course is not ported for OpenBSD because until recently was closed source binary only package. OSS is now released under BSD license. You mean: presently one can't rely on the drivers from 4Front Technologies? -- pozdrawiam / regards Zbigniew Baniewski
Re: Any Audigy users here?
On Sun, Mar 30, 2008 at 07:29:03AM +, Jacob Meuser wrote: last I tried/heard, Creative wants an NDA to give out hardware specs. I've looked at adding multi-channel support to emu(4). I'm guessing that's what you mean by sound on both outputs. it's not likely to happen. emu(4) is ugly wrt channel handling :( And it was not possible to find the needed information in ALSA sources? Audigy and Audigy2 support was back-ported from the Haiku driver for emu10k1, which is based on the emuxki driver we have. if you really want to extend emu(4), your best bet is to do more back-porting from there. Perhaps the only option for today, as I see... -- pozdrawiam / regards Zbigniew Baniewski
Re: About Squid port for OpenBSD 4.2
Thanks but that doesn't help me, could you explain please ? Alexander Schrijver a icrit : openldap includes are installed in /usr/local/include/ and libraries in /usr/local/lib/.
Re: About Squid port for OpenBSD 4.2
On Sun, Mar 30, 2008 at 3:22 PM, Comhte [EMAIL PROTECTED] wrote: Thanks but that doesn't help me, could you explain please ? Alexander Schrijver a icrit : openldap includes are installed in /usr/local/include/ and libraries in /usr/local/lib/. I dont know how autoconf works which squid uses, except for basic compiling. but this should probably work: export LDFLAGS=-L -L/usr/local/lib/ export CFLAGS=-I/usr/local/include ./configure etc Or if you want to make a package you should patch I believe it is configure.in, to include these options with the default LDFLAGS/CFLAGS. But you should probably read the autoconf docs before doing that.
Tunnel snmp through ssh
Hello list, is it possible to tunnel snmp through ssh? From what I've found on the web openssh can't tunnel udp. Just want to collect snmp data from ~10 hosts all over my network without having snmp listen on an public available ip address. -- Thank you Chris
Re: Tunnel snmp through ssh
check out ssh-based vpn: ssh (1) BR, Stijn Chris Cohen wrote: Hello list, is it possible to tunnel snmp through ssh? From what I've found on the web openssh can't tunnel udp. Just want to collect snmp data from ~10 hosts all over my network without having snmp listen on an public available ip address. -- Thank you Chris
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sun, Mar 30, 2008 at 01:04:09PM +0300, Lars Nood??n wrote: Douglas A. Tutty wrote: ... Shrinking the kernel would be the only reason I would have of touching the kernel as I'm not into trying out experimental features. It would be too bad if config doesn't do this... Nick Holland wrote: config strictly deactivates the drivers, it doesn't reduce memory consumption or disk footprint. ... Digressing slightly into config and what's in the FAQ regarding why or why not to deviate from GENERIC... Using config to modify the GENERIC kernel's settings can apparently improve boot speed. So maybe config should be mentioned in section 5.6 of the FAQ, Why do I need a custom kernel? to steer those wondering about improving boot time away from trying unnecessarily to create a custom kernel. e.g. for B' 5.6, Why do I need a custom kernel? Removing device drivers may speed the boot process on your system, but can complicate recovery should you have a hardware problem, and is very often done wrong. config can be used instead of re-compiling to modify kernel parameters and speed booting. See the section of the config(8) man page on kernel modification Since OpenBSD uses a monolithic kernel, it is outside the ability of config to physically remove the deactivated drivers. ... That could also be useful to have in the FAQ somewhere. It's explicit in the kernel's nature, but could be mentioned for those who miss the ramifications of using a monolithic kernel. Removing drivers for reduced memory is really a for advanced users only task, and you VERY QUICKLY run into diminishing returns. That can be emphasized more heavily by moving forward one sentence in section 5.6, and adding that in. e.g. for the very start of B' 5.6: Actually, you probably don't. Only the most advanced and knowledgeable users with the most demanding applications need to worry about a customized kernel or system, and even then you very quickly run into diminishing returns. I know that on a regular i386 machine, its far easier to add a bit of ram than to fitz with the kernel. I had seen on this list a while ago someone needing to fitz with the kernel for putting OBSD on some imbedded device. He (she?) wasn't building on the imbedded device, just wanted to pare down memory usage as much as possible. So perhaps to add to this entry for the FAQ, something that address this desire to shrink the kernel to save memory: ... For standard i386 old computers with little ram, recompiling the kernel does not provide enough free memory to affect what you can then do with that old computer. You are far better to just add a bit more ram. I know that other distros have dropped actual 386 CPUs from their supported list so that i386 actually needs minimum 486. The reasoning I've heard is that the amount of memory required is too much for any remaining actual 386 boxes to actually have. I know that my old PS/2 Model 70-A21 was a 386 with 4 MB Ram (at $1K per MB) and I think it could take a maximum 16 MB (but my memory from 1988 is very fuzzy). Where there any 386 boxes that could take 32MB ram, and do any still exist? Doug.
Re: Any Audigy users here?
Zbigniew Baniewski wrote: On Sat, Mar 29, 2008 at 09:02:21PM -0700, Predrag Punosevac wrote: The question is which Audigy? Creative makes wide variety of cards sold under that name and even the known one are sometime sold with different chip version (usually undocumented when they switch a chip). It's Sound Blaster Audigy SB1394 SB0230 Not tried the recording, but playing is OK - with the exception, that I can't use both outputs. Check their hardware notes but if I remember well those cards are supported by OSS. OSS of course is not ported for OpenBSD because until recently was closed source binary only package. OSS is now released under BSD license. You mean: presently one can't rely on the drivers from 4Front Technologies? That is exactly what I meant. They have the binary package for i-386 OpenBSD 3.9 on their web-site so you can try to to see if it works. I have to warn you though that work on drivers is in constant progress so for instance the driver for my Audigy SE was included only last September. If you have newer Audigy card it was probably not supported by that package. Also obviously you do want to run 4.3 soon not to go back to unsupported 3.9. Probably the best approach would be to isolate the driver you need and try to port to OpenBSD. Cheers, Predrag Punosevac
Re: Any Audigy users here?
Zbigniew Baniewski wrote: On Sun, Mar 30, 2008 at 07:29:03AM +, Jacob Meuser wrote: last I tried/heard, Creative wants an NDA to give out hardware specs. I've looked at adding multi-channel support to emu(4). I'm guessing that's what you mean by sound on both outputs. it's not likely to happen. emu(4) is ugly wrt channel handling :( And it was not possible to find the needed information in ALSA sources? You lost me here. Do you think that ALSA driver will help you any how to produce oss driver? You are aware of the fact that ALSA is 100% incompatible with oss and that even 4Front Technologies have no intension in incorporating ALSA emulator into their OSS. Their package have however very, very limited ALSA compatibility. Audigy and Audigy2 support was back-ported from the Haiku driver for emu10k1, which is based on the emuxki driver we have. if you really want to extend emu(4), your best bet is to do more back-porting from there. Perhaps the only option for today, as I see...
Re: Any Audigy users here?
On Sun, Mar 30, 2008 at 11:17:13AM -0700, Predrag Punosevac wrote: You lost me here. Do you think that ALSA driver will help you any how to produce oss driver? You are aware of the fact that ALSA is 100% incompatible with oss and that even 4Front Technologies Yes, you're right; but I didn't mean porting ALSA to OpenBSD. I was hoping, that one could find there some additional information f.e. about register setting, and so on. But no - didn't try it personally (yet). -- pozdrawiam / regards Zbigniew Baniewski
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
I believe it was mentioned aways back in the message stream, but perhaps it's worth reconsidering at this juncture... Keep the low emi/rfi 386 machine user-proximity but convert it to an X server with the more capable X client (app server) machine farther away. -Original Message- From: Douglas A. Tutty [EMAIL PROTECTED] To: misc misc@openbsd.org Subject: Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD) Date: Sun, 30 Mar 2008 13:12:57 -0400 Mailer: Mutt/1.5.13 (2006-08-11) Delivered-To: [EMAIL PROTECTED] On Sun, Mar 30, 2008 at 01:04:09PM +0300, Lars Nood??n wrote: Douglas A. Tutty wrote: I know that other distros have dropped actual 386 CPUs from their supported list so that i386 actually needs minimum 486. The reasoning I've heard is that the amount of memory required is too much for any remaining actual 386 boxes to actually have. I know that my old PS/2 Model 70-A21 was a 386 with 4 MB Ram (at $1K per MB) and I think it could take a maximum 16 MB (but my memory from 1988 is very fuzzy). Where there any 386 boxes that could take 32MB ram, and do any still exist? Doug.
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sun, Mar 30, 2008 at 01:04:09PM +0300, Lars Nood?n wrote: Using config to modify the GENERIC kernel's settings can apparently improve boot speed. So maybe config should be mentioned in section 5.6 of the FAQ, Why do I need a custom kernel? to steer those wondering about improving boot time away from trying unnecessarily to create a custom kernel. no, for the same reason that people should not recompile a kernel. you might end up disabling something you need. Lars, the FAQ, this list, they are really for people who need help, not for people to tweak their machines for silly reasons. you say, config makes me boot faster. so then people go and config their kernel, and then we get problem reports about broken kernels. that's fine if you want to go break your machines. don't try telling others to do the same. -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: Any Audigy users here?
On Sun, Mar 30, 2008 at 01:41:26PM +0200, Zbigniew Baniewski wrote: On Sat, Mar 29, 2008 at 09:02:21PM -0700, Predrag Punosevac wrote: The question is which Audigy? Creative makes wide variety of cards sold under that name and even the known one are sometime sold with different chip version (usually undocumented when they switch a chip). It's Sound Blaster Audigy SB1394 SB0230 Not tried the recording, but playing is OK - with the exception, that I can't use both outputs. OSS of course is not ported for OpenBSD because until recently was closed source binary only package. OSS is now released under BSD license. You mean: presently one can't rely on the drivers from 4Front Technologies? probably not on OpenBSD. AFAIK, they expect audio(4) and all the other device dependent drivers to not be there. 4Front asked us to make audio(4) modular, which isn't going to happen any time soon, if ever. if you want surround sound, check cmpci(4), uaudio(4), auvia(4) (though, recording is broken on 8233 based devices) or maybe azalia(4). and definitely upgrade to 4.3 when it's released (or run -current, especially if you want to do fun stuff with audio ;). -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: Any Audigy users here?
On Sun, Mar 30, 2008 at 08:52:33PM +0200, Zbigniew Baniewski wrote: On Sun, Mar 30, 2008 at 11:17:13AM -0700, Predrag Punosevac wrote: You lost me here. Do you think that ALSA driver will help you any how to produce oss driver? You are aware of the fact that ALSA is 100% incompatible with oss and that even 4Front Technologies Yes, you're right; but I didn't mean porting ALSA to OpenBSD. I was hoping, that one could find there some additional information f.e. about register setting, and so on. But no - didn't try it personally (yet). as I said, look at the Haiku driver. it's based on our driver (and is BSD licensed). that's what I did for the Audgiy support we have now. trying to read a driver to get register information kind of works, it's certainly not a substitute for real documentation. the problem with emu(4) in particular, is that the way it handles channels is very complex. it's not really a simple, oh, I need to write 0x0030 to 0x72. been there, done that. I _thought_ I had made the correct changes to enable 4 channel output on emu(4) with stac9701 codecs, but it was totally busted. feel free to poke around in it though ;) -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: Any Audigy users here?
On Sun, Mar 30, 2008 at 07:52:20PM +, Jacob Meuser wrote: if you want surround sound, check cmpci(4), uaudio(4), auvia(4) (though, recording is broken on 8233 based devices) or maybe azalia(4). and definitely upgrade to 4.3 when it's released (or run -current, especially if you want to do fun stuff with audio ;). You know, the problem is, that: 1. I've got exactly an Audigy, which I wouldn't to replace with other, just because it gives quite good sound quality, and it has firewire on-board (didn't made use of this until now, but perhaps one day...). 2. It's not the question of surround sound; pay attention, that it would be very comfortable to have both outputs activated, just because there's no need to manually switch from headphones to speakers (or back), when you want to listen something on private. Just to change mixer setting could be enough in such case, and both speakers and headphones can be connected all the time. 3. I'm asking about this, because I'm wondering, how difficult could be to port softphone application to OpenBSD - I'm considering two: linphone and tclphone. It's very likely, that the latter would be much easier. And exactly when using softphones having a possibility to mute one output and activate the second one (and the opposite, when talk is finished) is very comfortable solution. Yes, perhaps I must complete my (very narrow at the moment) knowledge about soundcards and soundcard-drivers, and then to make a try to activate that second output. -- pozdrawiam / regards Zbigniew Baniewski
Re: Any Audigy users here?
On Sun, Mar 30, 2008 at 11:05:16PM +0200, Zbigniew Baniewski wrote: On Sun, Mar 30, 2008 at 07:52:20PM +, Jacob Meuser wrote: if you want surround sound, check cmpci(4), uaudio(4), auvia(4) (though, recording is broken on 8233 based devices) or maybe azalia(4). and definitely upgrade to 4.3 when it's released (or run -current, especially if you want to do fun stuff with audio ;). You know, the problem is, that: 1. I've got exactly an Audigy, which I wouldn't to replace with other, just because it gives quite good sound quality, and it has firewire on-board (didn't made use of this until now, but perhaps one day...). probably not with OpenBSD. at least, the firewire support that was once there is long gone. the Audigy cards are ok. I really can't tell a difference between them and cmcpi(4), but then again, but maybe my ears just aren't that sensitive. 2. It's not the question of surround sound; pay attention, that it would be very comfortable to have both outputs activated, just because there's no need to manually switch from headphones to speakers (or back), when you want to listen something on private. Just to change mixer setting could be enough in such case, and both speakers and headphones can be connected all the time. ;) this is exactly what I was trying to get working. copy front to surround, but let them be separately controllable. it seems, you still have to touch the channel stuff, but maybe I was missing something. this is usually a function of the codec rather than the controller, at least on most other AC97 devices. 3. I'm asking about this, because I'm wondering, how difficult could be to port softphone application to OpenBSD - I'm considering two: linphone and tclphone. It's very likely, that the latter would be much easier. And exactly when using softphones having a possibility to mute one output and activate the second one (and the opposite, when talk is finished) is very comfortable solution. please use 4.3 or -current. there were full-duplex issues, especially in osaudio(3) in 4.2 and before. pjsua is in ports/telephony. if you can use portaudio v19, that's a bonus, because there is a port/package for that in 4.3. Yes, perhaps I must complete my (very narrow at the moment) knowledge about soundcards and soundcard-drivers, and then to make a try to activate that second output. good luck :) -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: Any Audigy users here?
On 2008-03-30, Jacob Meuser [EMAIL PROTECTED] wrote: 3. I'm asking about this, because I'm wondering, how difficult could be to port softphone application to OpenBSD - I'm considering two: linphone and tclphone. It's very likely, that the latter would be much easier. And exactly when using softphones having a possibility to mute one output and activate the second one (and the opposite, when talk is finished) is very comfortable solution. please use 4.3 or -current. there were full-duplex issues, especially in osaudio(3) in 4.2 and before. pjsua is in ports/telephony. It works pretty well, but isn't great at alerting you to incoming calls. It has a big advantage over a lot of the early linux-centric softphones though: it has the ability to resample audio to a hardware-supported rate.
Re: Ethernet on ASUS EEE PC?
There have recently been some changes that make that driver work much better, try again with a newer snapshot in a few days. On Sat, Mar 29, 2008 at 07:55:16PM -0700, James Hartley wrote: As opposed to previous mention that the Ethernet interface is correctly identified on a 28 Jan -current snapshot: http://marc.info/?l=openbsd-miscm=120177549104133w=2 ...the behaviour I'm seeing from the 25 Mar snapshot is similar to the following: http://marc.info/?l=openbsd-miscm=120185685618399w=2 http://marc.info/?l=openbsd-miscm=119802047918588w=2 Perhap different hardware revisions are being employed by ASUS. I'm using a EEE PC 4G Surf. My dmesg follows. Any suggestions or requests are welcomed. Jim ==8 OpenBSD 4.3-current (GENERIC) #723: Mon Mar 24 18:23:49 MDT 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Celeron(R) M processor 900MHz (GenuineIntel 686-class) 631 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF real mem = 2138140672 (2039MB) avail mem = 2059415552 (1964MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 01/04/08, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xf06c0 (37 entries) bios0: vendor American Megatrends Inc. version 0703 date 01/04/2008 bios0: ASUSTeK Computer INC. 701 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 3.0 @ 0xf/0x1 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf76b0/176 (9 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82801FB LPC rev 0x00) pcibios0: PCI bus #5 is the last bus bios0: ROM list: 0xc/0xf800! 0xcf800/0x1000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82915GM Host rev 0x04 vga1 at pci0 dev 2 function 0 Intel 82915GM Video rev 0x04 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) agp0 at vga1: aperture at 0xd000, size 0x1000 Intel 82915GM Video rev 0x04 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 Intel 82801FB HD Audio rev 0x04: irq 5 azalia0: codec[s]: Realtek/0x0662 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801FB PCIE rev 0x04: irq 5 pci1 at ppb0 bus 4 ppb1 at pci0 dev 28 function 1 Intel 82801FB PCIE rev 0x04: irq 11 pci2 at ppb1 bus 3 Attansic Technology L2 rev 0xa0 at pci2 dev 0 function 0 not configured ppb2 at pci0 dev 28 function 2 Intel 82801FB PCIE rev 0x04: irq 10 pci3 at ppb2 bus 1 uhci0 at pci0 dev 29 function 0 Intel 82801FB USB rev 0x04: irq 7 uhci1 at pci0 dev 29 function 1 Intel 82801FB USB rev 0x04: irq 3 uhci2 at pci0 dev 29 function 2 Intel 82801FB USB rev 0x04: irq 10 uhci3 at pci0 dev 29 function 3 Intel 82801FB USB rev 0x04: irq 5 ppb3 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xd4 pci4 at ppb3 bus 5 ichpcib0 at pci0 dev 31 function 0 Intel 82801FBM LPC rev 0x04: PM disabled pciide0 at pci0 dev 31 function 2 Intel 82801FBM SATA rev 0x04: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 1 drive 0: SILICONMOTION SM223AC wd0: 1-sector PIO, LBA, 3815MB, 7815024 sectors wd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4 ichiic0 at pci0 dev 31 function 3 Intel 82801FB SMBus rev 0x04: irq 3 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 2GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM usb0 at uhci0: USB revision 1.0 uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1 usb1 at uhci1: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci2: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci3: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at ichpcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 biomask e7fd netmask e7fd ttymask mtrr: Pentium Pro MTRR support umass0 at uhub2 port 1 configuration 1 interface 0 ENE UB6225 rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets sd0 at scsibus0 targ 1 lun 0: USB2.0, CardReader SD0, 0100 SCSI0 0/direct removable sd0: drive offline softraid0 at root root on wd0a swap on wd0b dump on wd0b WARNING: / was not properly unmounted uhub4 at uhub0 port 2 Prolific Technology Inc. USB Embedded Hub rev 2.00/1.00 addr 2 umass1 at uhub4 port 1 configuration 1 interface 0 Prolific Technology Inc. USB Mass Storage Device rev 2.00/1.00 addr 3 umass1: using ATAPI
Re: Any Audigy users here?
Zbigniew Baniewski wrote: On Sun, Mar 30, 2008 at 07:52:20PM +, Jacob Meuser wrote: if you want surround sound, check cmpci(4), uaudio(4), auvia(4) (though, recording is broken on 8233 based devices) or maybe azalia(4). and definitely upgrade to 4.3 when it's released (or run -current, especially if you want to do fun stuff with audio ;). You know, the problem is, that: 1. I've got exactly an Audigy, which I wouldn't to replace with other, just because it gives quite good sound quality, and it has firewire on-board (didn't made use of this until now, but perhaps one day...). 2. It's not the question of surround sound; pay attention, that it would be very comfortable to have both outputs activated, just because there's no need to manually switch from headphones to speakers (or back), when you want to listen something on private. Just to change mixer setting could be enough in such case, and both speakers and headphones can be connected all the time. 3. I'm asking about this, because I'm wondering, how difficult could be to port softphone application to OpenBSD - I'm considering two: linphone and tclphone. It's very likely, that the latter would be much easier. And exactly when using softphones having a possibility to mute one output and activate the second one (and the opposite, when talk is finished) is very comfortable solution. OpenBSD 4.3 is including PJSUA http://www.pjsip.org/pjsua.htm I tried it and I really like it. If you compare various SIP clients you should see that PJSUA should be a first choice for security minded user which prefers simplicity and capability instead of GUI non-sense. I personally would much rather see you and other people interested in phone applications taking part in testing and making sure PJSUA works as expected than waisting time trying to port another SIP client. At least for now, I think that community should really help to make sure OpenBSD has fully working simple SIP client. Cheers, Predrag Punosevac Yes, perhaps I must complete my (very narrow at the moment) knowledge about soundcards and soundcard-drivers, and then to make a try to activate that second output.
Re: Any Audigy users here?
On Sun, Mar 30, 2008 at 05:22:14PM -0700, Predrag Punosevac wrote: OpenBSD 4.3 is including PJSUA http://www.pjsip.org/pjsua.htm I tried it and I really like it. If you compare various SIP clients you should see that PJSUA should be a first choice for security minded user which prefers simplicity and capability instead of GUI non-sense. Thanks, I prefer text mode - so, the conclusion for me is to wait for 4.3 final; as I can see on the web pages, it'll be not more, than a month. -- pozdrawiam / regards Zbigniew Baniewski
4.2 still has X tree dependency?
I am running 4.1 on several servers, one thing I found was the surprise on needing the X package to install some of the non x-windows ports due to dependencies within that tree. I think it was for the graphics libraries, either way, I installed the x packages and all is well. But I remember reading in a FAQ or release notes somewhere that this was a mistake and would be fixed in the next version of OpenBSD (ie, remove the dependency on the x-windows system for these libraries). I am about to install a bunch of 4.2 servers, is this dependency fixed in 4.2? Or is that a 4.3 target? Regards Mikel
Re: 4.2 still has X tree dependency?
On Sun, Mar 30, 2008 at 6:20 PM, Mikel Lindsaar [EMAIL PROTECTED] wrote: I am running 4.1 on several servers, one thing I found was the surprise on needing the X package to install some of the non x-windows ports due to dependencies within that tree. http://openbsd.org/faq/upgrade42.html#libexpat But I remember reading in a FAQ or release notes somewhere that this was a mistake and would be fixed in the next version of OpenBSD (ie, remove the dependency on the x-windows system for these libraries). http://openbsd.org/faq/upgrade43.html#libexpat
Re: 4.2 still has X tree dependency?
Mikel Lindsaar wrote: I am running 4.1 on several servers, one thing I found was the surprise on needing the X package to install some of the non x-windows ports due to dependencies within that tree. I think it was for the graphics libraries, either way, I installed the x packages and all is well. But I remember reading in a FAQ or release notes somewhere that this was a mistake and would be fixed in the next version of OpenBSD (ie, remove the dependency on the x-windows system for these libraries). I am about to install a bunch of 4.2 servers, is this dependency fixed in 4.2? Or is that a 4.3 target? To my knowledge dependency first time occurred in 4.2. It is already fixed in 4.3. If you are installing servers with 4.2 and you do not want to install xbase due to the security concerns you can just extract a single library which was mistakenly put into xbase. If you search misc you can find how to. Cheers, Predrag Regards Mikel
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
Douglas A. Tutty wrote: ... So perhaps to add to this entry for the FAQ, something that address this desire to shrink the kernel to save memory: ... For standard i386 old computers with little ram, recompiling the kernel does not provide enough free memory to affect what you can then do with that old computer. You are far better to just add a bit more ram. much closer to something I'd consider adding. :) I know that other distros have dropped actual 386 CPUs from their supported list so that i386 actually needs minimum 486. The reasoning I've heard is that the amount of memory required is too much for any remaining actual 386 boxes to actually have. Same thing was done recently with OpenBSD, actually. There are better reasons, however... The big one was the 80386 was a first generation 32 bit processor for Intel, and there were a lot of ugly work-arounds in the OpenBSD kernel for 80386 systems that didn't need to be there for 80486 and later systems. Dropping support for the 80386 simplified the kernel code, and as we know, that's a very good thing. There were some practical reasons why you don't want to use OpenBSD on an 80386 system: 1) OpenBSD /requires/ a hardware FPU. The 80386 chip did not have it, you needed to add-on an 80387 Math coprocessor, and a relatively small number of 80386 machines had this. 2) There are things we just do today that were big deals back in the 80386 and before days, simple little things like compressing a file. Simply loading an 80386 system with OpenBSD was an all-day affair, due mostly to the time required to uncompress the *.tgz files! 3) IDE disks were not common on 80386 systems. You don't want to try to install OpenBSD on an MFM or ESDI drive. Even what should have been an easy retrofit was complicated by inflexible BIOSs. 4) 16M RAM was almost unheard of back then...and many of the 80386 systems of the day were using different RAM than more modern systems do, so the likelihood that you had an OpenBSD-capable 80386 was very low, and upgrading it to being OpenBSD-capable was cost-prohibitive. When this was done, no one had been sending in 80386 dmesg's for a long time. Even before then...the 80386 code spent some time broken around the 3.3 days..and only a couple people had even noticed (we didn't even realize it wasn't broke machines until we realized that several people were seeing the exact same problem!). I know that my old PS/2 Model 70-A21 was a 386 with 4 MB Ram (at $1K per MB) and I think it could take a maximum 16 MB (but my memory from 1988 is very fuzzy). Where there any 386 boxes that could take 32MB ram, and do any still exist? oh, most certainly. The VERY FIRST generation of non-IBM-brand 80386 (i.e., Zenith, Compaq, AST, etc.) systems were basically 80286 systems with a faster processor and almost everything else carried over from the 80286 siblings. However, by the time the second generation rolled around, the systems were starting to make use of the 80386 potential (though the OS and apps were still treating the 80386 as a really, really fast 8088, for the most part. I'm most familiar with the Zenith systems, as that's where I was at the time, but the second generation Zenith 80386 systems were capable of 20M on board (supposed to be 32M, but a bug was found with support for actual production 4M 72 pin SIMMs (which didn't even exist when the machine was first shipped!) that limited their use to only the lower four slots, so limit was 20M, though later boards fixed that and were able to use all 32M. I recall no customers complaining about this bug. :) I've got several of these second generation Zenith machines still, one of which was, according to the dmesg log, the last systems to run OpenBSD on an 80386. I also have a no-name clone board which I'd put 8x4M 30 pin SIMMs in for 32M, as well. By the time I had the resources to do this, I'd long got and retired much better machines that were capable of running OpenBSD. I'd actually be surprised if the IBM Model 70 was design limited to 16M, though it is likely there was just no physical way to put more than that in. The PS/2 MCA machines were much more advanced than the ISA-standard machines of the day, though a pain in the butt to work with and incompatable, but I'm pretty sure all 32 bits of address lines made it out to the bus. HOWEVER, the 80386sx was a non-starter for a long time: these machines only had 24 bit address buses, so it had a max of 16M, and being they were cheap machines, the actual potential of most of the hardware they were used in was 12M, 8M, or way, way less. I don't know that I have ever seen an 80387SX chip -- kinda bizarre thing, an expensive accelerator for a machine you bought because you didn't need much speed... Nick.
Re: Dangers to upgrading without install kernel
On Thu, 27 Mar 2008 21:00:54 -0400, Juan Miscaro wrote: The online upgrade documentation [1] is fairly vehement about its recommendation regarding the use of the install kernel when upgrading. I was wondering why? What dangers await someone going down the remote upgrade path? /juan [1] http://www.openbsd.org/faq/upgrade42.html#upgrade Depending on your setup and hardware, a remote upgrade is pretty decently easy. Here I have the privilege of serial console, and then the remote upgrade is identical to the local one; except of rebooting to bsd.rd instead of the CDROM. Uwe
Re: configuring the GENERIC kernel (was Re: Issue compiling a program on OpenBSD)
On Sun, Mar 30, 2008 at 11:04:34PM -0400, Nick Holland wrote: HOWEVER, the 80386sx was a non-starter for a long time: these machines only had 24 bit address buses, so it had a max of 16M, and being they were cheap machines, the actual potential of most of the hardware they were used in was 12M, 8M, or way, way less. I don't know that I have ever seen an 80387SX chip -- kinda bizarre thing, an expensive accelerator for a machine you bought because you didn't need much speed... I think it more likely that most people bought the 386SX because they didn't have much money rather than they didn't need much speed. That's certainly the reason I and a couple of friends did. There was also the 80386SL variation which used less power and was particularly good for laptops. As it happens I bought three 80387SL FP co-processors, for my Toshiba T3300SL laptop, for my desktop and one as a Christmas gift. It made a huge difference in number-crunching times. (The 80387SL seems to have replaced the 387SX rather early.) The laptop dual-booted DOS and COHERENT, a commercial 16-bit UNIX-like operating system. When there were no readily-available 32-bit OSs, the 386SX/SL processors seemed to make sense. No good reason for them later... Emilio
Trouble using :peer modifier correctly
Hello, We're trying to use the :peer modifier to minimize the number of macros in our pf configuration files. For some reason we can't get it to work: # cat /etc/pf.conf set skip on lo block log pass in quick on fxp0 inet proto tcp from fxp0:peer to fxp0 port ssh # pfctl -n -f /etc/pf.conf no IP address found for fxp0:peer /etc/pf.conf:5: could not parse host specification # ifconfig fxp0 fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr 00:a0:c9:5c:a6:72 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.1.1 netmask 0xfffc broadcast 192.168.1.3 inet6 fe80::2a0:c9ff:fe5c:a672%fxp0 prefixlen 64 scopeid 0x2 We're testing with OpenBSD 4.2 (Release). Kind regards, -- Egbert Krook System/Network Engineer Amarin Printing and Publishing Public Co., Ltd.
Re: Trouble using :peer modifier correctly
We're trying to use the :peer modifier to minimize the number of macros in our pf configuration files. For some reason we can't get it to work: # cat /etc/pf.conf set skip on lo block log pass in quick on fxp0 inet proto tcp from fxp0:peer to fxp0 port ssh # pfctl -n -f /etc/pf.conf no IP address found for fxp0:peer /etc/pf.conf:5: could not parse host specification :peer Translates to the point to point interface's peer ad- dress(es). That won't work. Your fxp is not a point-to-point interface. It is a broadcast interface. It has many peers, not one.
