Re: Starting out
On Sat, Jan 28, 2012 at 07:47:25AM +0100, Tomas Bodzar wrote: I know that Open BSD is not really a desk top system. You're completely wrong here. There's even Gnome 3.2.1 and is running fine on i386/amd64 as far as I can tell from tests. I use scrotwm That is true and it also run fine on macppc :) -- Antoine
Re: locate weirdness
guys, it was so funny to see you biting each other. come on, can you do it one more time, please ? 2012/1/23 Nico Kadel-Garcia nka...@gmail.com On Sun, Jan 22, 2012 at 5:38 PM, L. V. Lammert l...@omnitec.net wrote: On Sun, 22 Jan 2012, Philip Guenther wrote: snip the BS There is no way of knowing if it would have found the problem, so why continue with this drivel? Contrary to the lengthy diatribes here trying to distract from the original problem an solution: 1) The problem with locate was traced to a bunch of session files; 2) The problem was fixed by cleaning them the hard way. There is no way to know if an upgrade would have fixed the problem, as upgrading is/was/would be just a distraction; it is not good practice to try and obscure the problem, and I do not understand why some people here like to expouse such practices. Sure, there is no support for 4.3, but, then I did not ASK for support on 4.3 (to read the OP). Don't bother to try and dixtract from the original problem - it juse makes it harder for those LOOKING for the problem and solution to find it in all the noise. As someone who's faced this kind of thing from both sides, I think you're going to have a long term problem with the just help me fix the system I have, don't bother with telling me to upgrade approach. Too many bugs are fixed as part of re-engineering or feature addition, and expecting even the authors, whom you are not paying for contracted work, to maintain the old releases becomes futile pretty quickly. It's difficult for them to maintain the old environments as test beds, or to dredge back that far into memory of how things used to be done. I've been running into this for decades, all the way back to the shift from BSD 4.2 to BSD 4.3. (Note that that is not OpenBSD, it's BSD.) The yelling and namecalling is unfortunate. But from observation and professional experience, if you want professional grade support for a software livecycle of over 3 years, you should be willing to pay for it.
something like glusterfs ?
Hello! we are running carp-ed load balancers on openbsd. we are pretty happy with fast switchover via carp. however, we'd like to serve static (uploaded via ftp) content from those servers. I see two scenarios a) files are uploaded to carp master, we run rsync every minute, which pushes content from master to backup b) something like glusterfs is there things like glusterfs ? I didn't find any for openbsd. cheers, Ilya Shipitsin
Re: Long delay updating xenocara source tree?
On Fri, 27 Jan 2012, Philip Guenther wrote: On Fri, Jan 27, 2012 at 12:10 PM, Dave Anderson d...@daveanderson.com wrote: I've run into this problem perhaps a dozen times over the past several months while running amd64-current, most recently at 15:53 2012/1/26 EST while running a system built from source updated at about 14:30 2012/1/21 EST: when trying to update the xenocara source tree there is a very long (perhaps infinite) delay between issuing the 'cvs ...' command and the start of any visible activity. In this most recent case the delay was about 9 hours. Updating the src and ports source trees at about the same time and using the same CVSROOT has always worked OK; there's some delay but not a really long one. And sometimes the xenocara update has worked without any problem. When it doesn't, 'rm -rf /usr/xenocara' followed by reloading from the 5.0-release CD has always allowed a subsequent cvs update to work. The command I'm using is # cd /usr/xenocara cvs -d$CVSROOT -q up -Pd (except for the working directory, exactly the same as the command for updating the src or ports tree). I bet it'll be faster if you don't use the -P or -d options. The -d option to cvs up requires the cvs server to walk directories that are present on the server but not present on the client. That includes directories which are now empty because all their files have been removed (ala cvs rm)...of which there are a bunch in the xenocara tree. The -P option requires extra work too, though it's not as bad as the -d option, IIRC. Personally, I use the rule of thumb of only using -d and -P when I have reason to believe directories have been added or removed, either from seeing the commit email or from a build failing because a directory is missing... Thanks for the info. I've been using -Pd because http://www.openbsd.org/anoncvs.html says to use them; I haven't yet had a chance to look into how cvs works beyond reading the man page, faq, etc. Dave -- Dave Anderson d...@daveanderson.com
Re: Long delay updating xenocara source tree?
Hey, Dave Anderson wrote [2012-01-28 15:13+0100]: [.] I haven't yet had a chance to look into how cvs works beyond reading the man page, faq, etc. Also true for me. I've run into this problem perhaps a dozen times over the past several months [.] I've noted a lot of upload network traffic when doing 'cvs up' on OpenBSD repos; i.e., before anything else happened about ~70 MB (www) and ~150 MB (src) *upstream* traffic were produced, and it took more than an hour before the download of data began (src). I never had similar problems with anoncvs.mindrot.org, nor cvs.savannah.gnu.org and *.cvs.sourceforge.net etc. If you're doing your updates in such a regular manner, i think your best bet is cvsync(1), even if that means additional local storage - but it is *far* more efficient in both, time and traffic. (Not to talk about the possibility to do 'cvs log' and the like locally, without internet connection; if that's an issue.) Pears similar ciao, --steffen
customer update!!!
- This mail is in HTML. Some elements may be ommited in plain text. - You have a NAB Internet Banking Account Alert. To view, click on the ACCOUNTS tab and then click on Statements to verify your transaction.
5.0 kernel won't compile on 4.9 i386 system
I have a brand spanking new 4.9 i386 system that I reinstalled with just base, etc, comp, man and bash, vim--no_x11, curl. Using CVSROOT=anon...@anoncvs.eu.openbsd.org:/cvs I cd /usr cvs checkout -rOPENBSD_5_0 -P src; and it downloads. Then I follow the generic instructions and go to sys/arch/i386/conf; config GENERIC; cd ../compile/GENERIC; make clean make depend make and I get a ton of errors almost instantly. Same happens without make depend. bash-4.1# make clean make depend make rm -f eddep *bsd *bsd.gdb tags *.[dio] [a-z]*.s [Ee]rrs linterrs assym.h cat ../../../../arch/i386/i386/genassym.cf ../../../../arch/i386/i386/ genassym.cf | sh ../../../../kern/genassym.sh cc -Werror -Wall -Wstrict-prototypes -Wmi ssing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builtin-snprintf -fno-builtin-vsnprintf -fno-bu iltin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLA TE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0 x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -MF assym.P assym.h.tmp sed '1s/.*/assym.h: \\/' assym.P assym.d sort -u assym.h.tmp assym.h cc -D_LOCORE -x assembler-with-cpp -fno-builtin-printf -fno-builtin-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc - nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DU SER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSD ISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -c ../../../../arch/i386/i38 6/locore.s cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builti n-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIA GNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_D EFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -c param.c cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builti n-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIA GNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_D EFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -c ioconf.c cc1: warnings being treated as errors ioconf.c:218: warning: excess elements in struct initializer ioconf.c:218: warning: (near initialization for 'cfdata[0]') ioconf.c:220: warning: excess elements in struct initializer ioconf.c:220: warning: (near initialization for 'cfdata[1]') ioconf.c:222: warning: excess elements in struct initializer ioconf.c:222: warning: (near initialization for 'cfdata[2]') ioconf.c:224: warning: excess elements in struct initializer ioconf.c:224: warning: (near initialization for 'cfdata[3]') ioconf.c:226: warning: excess elements in struct initializer ioconf.c:226: warning: (near initialization for 'cfdata[4]') ioconf.c:228: warning: excess elements in struct initializer ioconf.c:228: warning: (near initialization for 'cfdata[5]') ioconf.c:230: warning:
qemu and USB drives
Hi, Sorry for the long message. I am not able to figure out a good solution for the following: Right now, what I do to test ports etc., is download install51.iso, run it within qemu, and then do the work. To test the port on a different server (which is on a different network), I end up burning a new CD or use PXE boot within my LAN when that is possible, so that the latest version is on a USB stick. However, I would like to have -current or -beta on a USB drive without having to burn a CD or use PXE boot. Is it possible to install OpenBSD on a USB drive from within qemu and then use that USB drive to boot a laptop? For example, I installed 5.1 -beta as follows using qemu on my 5.0 desktop: qemu-system-x86_64 -m 1024 -monitor stdio -no-fd-bootchk -hda /dev/rsd6c -cdrom home/vsankar/downloads/openbsd/jan27-2012/install51.iso -boot d From my 5.0 desktop, I am able to do the following and boot OpenBSD within a VM sudo env ETHER=em0 qemu-system-x86_64 \ -m 1200 -no-fd-bootchk -hda /dev/rsd6c I thought this would allow me to take the USB drive and boot from it on my notebook. When it did not, I did a disklabel (on the qemu host -- OpenBSD 5.0 amd64) and saw the following: disklabel sd6 # /dev/rsd6c: type: SCSI disk: SCSI disk label: DT 101 G2 duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 973 total sectors: 15644912 boundstart: 0 boundend: 15644912 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] c: 156449120 unused But when I boot the 5.1 VM, everything works from the USB and disklabel shows all the partitions. Should I not see partition a through k on the USB stick when using disklabel on the qemu host also? I was expecting to see something like this from the qemu host as well as the guest VM: disklabel -A sd6 # /dev/rsd6c: type: SCSI disk: SCSI disk label: DT 101 G2 duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 973 total sectors: 15644912 boundstart: 0 boundend: 15644912 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 2403200 4.2BSD 2048 163841 # / b: 240340 240320swap c: 156449120 unused d: 368128 480672 4.2BSD 2048 163841 # /tmp e: 362720 848800 4.2BSD 2048 163841 # /var f: 1919680 1211520 4.2BSD 2048 163841 # /usr g: 1094464 3131200 4.2BSD 2048 163841 # /usr/X11R6 h: 4347296 4225664 4.2BSD 2048 163841 # /usr/local i: 2143040 8572960 4.2BSD 2048 163841 # /usr/src j: 2143040 10716000 4.2BSD 2048 163841 # /usr/obj k: 2785728 12859040 4.2BSD 2048 163841 # /home Any clues greatly appreciated. Thanks very much, Vijay Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca Vijay Sankar, M.Eng., P.Eng. ForeTell Technologies Limited vsan...@foretell.ca - This message was sent using ForeTell-POST 4.9
Re: 5.0 kernel won't compile on 4.9 i386 system
On Sat, Jan 28, 2012 at 05:25:53PM +0100, Stefan Midjich wrote: I have a brand spanking new 4.9 i386 system that I reinstalled with just base, etc, comp, man and bash, vim--no_x11, curl. you need to update config(8) to the 5.0 version first. Using CVSROOT=anon...@anoncvs.eu.openbsd.org:/cvs I cd /usr cvs checkout -rOPENBSD_5_0 -P src; and it downloads. Then I follow the generic instructions and go to sys/arch/i386/conf; config GENERIC; cd ../compile/GENERIC; make clean make depend make and I get a ton of errors almost instantly. Same happens without make depend. bash-4.1# make clean make depend make rm -f eddep *bsd *bsd.gdb tags *.[dio] [a-z]*.s [Ee]rrs linterrs assym.h cat ../../../../arch/i386/i386/genassym.cf ../../../../arch/i386/i386/ genassym.cf | sh ../../../../kern/genassym.sh cc -Werror -Wall -Wstrict-prototypes -Wmi ssing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builtin-snprintf -fno-builtin-vsnprintf -fno-bu iltin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLA TE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0 x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -MF assym.P assym.h.tmp sed '1s/.*/assym.h: \\/' assym.P assym.d sort -u assym.h.tmp assym.h cc -D_LOCORE -x assembler-with-cpp -fno-builtin-printf -fno-builtin-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc - nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DU SER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSD ISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -c ../../../../arch/i386/i38 6/locore.s cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builti n-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIA GNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_D EFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -c param.c cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builti n-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIA GNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_D EFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -c ioconf.c cc1: warnings being treated as errors ioconf.c:218: warning: excess elements in struct initializer ioconf.c:218: warning: (near initialization for 'cfdata[0]') ioconf.c:220: warning: excess elements in struct initializer ioconf.c:220: warning: (near initialization for 'cfdata[1]') ioconf.c:222: warning: excess elements in struct initializer ioconf.c:222: warning: (near initialization for 'cfdata[2]') ioconf.c:224: warning: excess elements in struct initializer ioconf.c:224: warning: (near initialization for 'cfdata[3]') ioconf.c:226: warning: excess elements in struct
Re: 5.0 kernel won't compile on 4.9 i386 system
On Sat, Jan 28, 2012 at 5:25 PM, Stefan Midjich sweh...@gmail.com wrote: So what do I do to get 5.0 compiled? You upgrade to 5.0 first. -- chs,
Re: 5.0 kernel won't compile on 4.9 i386 system
On Sat, 28 Jan 2012, Stefan Midjich wrote: I have a brand spanking new 4.9 i386 system that I reinstalled with just base, etc, comp, man and bash, vim--no_x11, curl. Using CVSROOT=anon...@anoncvs.eu.openbsd.org:/cvs I cd /usr cvs checkout -rOPENBSD_5_0 -P src; and it downloads. Then I follow the generic instructions and go to sys/arch/i386/conf; config GENERIC; cd ../compile/GENERIC; make clean make depend make and I get a ton of errors almost instantly. Same happens without make depend. RTFM! Well, RTF FAQ. Building from source is explicitly not supported unless the system you're building on is 'close enough' to the one you're trying to build -- and it appears that 4.9 is not close enough to 5.0. Install 5.0 from your CD set (you did buy one, didn't you?) then update your source tree and try building again; this time it should work. I'd install all of the sets; it doesn't cost much, and there are sometimes non-obvious dependencies. Well, maybe. I note that you're using bash rather than the standard shell; this _might_ cause problems. (I don't know enough to be sure.) Dave bash-4.1# make clean make depend make rm -f eddep *bsd *bsd.gdb tags *.[dio] [a-z]*.s [Ee]rrs linterrs assym.h cat ../../../../arch/i386/i386/genassym.cf ../../../../arch/i386/i386/ genassym.cf | sh ../../../../kern/genassym.sh cc -Werror -Wall -Wstrict-prototypes -Wmi ssing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builtin-snprintf -fno-builtin-vsnprintf -fno-bu iltin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLA TE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0 x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -MF assym.P assym.h.tmp sed '1s/.*/assym.h: \\/' assym.P assym.d sort -u assym.h.tmp assym.h cc -D_LOCORE -x assembler-with-cpp -fno-builtin-printf -fno-builtin-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc - nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DU SER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSD ISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -c ../../../../arch/i386/i38 6/locore.s cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builti n-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIA GNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_D EFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -c param.c cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builti n-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../.. -I../../../../arch -DDDB -DDIA GNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DFFS -DMFS -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DFIFO -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DMROUTING -DPIM -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DPROCFS -DRAMDISK_HOOKS -DMINIROOTSIZE=0x18000 -DNKPTP=0x10 -DCOMCONSOLE -DCONSPEED=0x9600 -DBUFCACHEPERCENT=1 -DPCIVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_D EFAULTSCREENS=6 -DWSDISPLAY_COMPAT_PCVT -DMAXUSERS=32 -D_KERNEL -MD -MP -c ioconf.c cc1: warnings being treated as errors ioconf.c:218: warning: excess elements in struct initializer ioconf.c:218: warning: (near
Re: Long delay updating xenocara source tree?
On 2012-01-28, Philip Guenther guent...@gmail.com wrote: I've run into this problem perhaps a dozen times over the past several months while running amd64-current, most recently at 15:53 2012/1/26 EST while running a system built from source updated at about 14:30 2012/1/21 EST: when trying to update the xenocara source tree there is a very long (perhaps infinite) delay between issuing the 'cvs ...' command and the start of any visible activity. In this most recent case the delay was about 9 hours. Updating the src and ports source trees at about the same time and using the same CVSROOT has always worked OK; there's some delay but not a really long one. And sometimes the xenocara update has worked without any problem. When it doesn't, 'rm -rf /usr/xenocara' followed by reloading from the 5.0-release CD has always allowed a subsequent cvs update to work. The command I'm using is # cd /usr/xenocara cvs -d$CVSROOT -q up -Pd (except for the working directory, exactly the same as the command for updating the src or ports tree). I bet it'll be faster if you don't use the -P or -d options. If people try this, please don't report any build problems unless you've re-run with both of these options. Also note it's not going to work well for ports..
Re: 5.0 kernel won't compile on 4.9 i386 system
Thanks everyone for the info, I clearly didn't read the whole FAQ but only the parts I needed. The reason I was using 4.9 was because 5.0 i386 didn't boot in vmware fusion 3, it hangs at mtrr. And since I was formatting a CF card from the vm I thought I had to use the same arch as the kernel that will run from it, so I ended up trying on a 4.9. Also the reason I wanted to compile is something I should have stated, there's a kernel config online for pcengines alix boards so I wanted to use it on mine thinking it was better optimized for the tiny board with very few peripherals. https://raw.github.com/openbsd/flashboot/master/PCENGINES I wanted to do a kernel compile from the 5.0 generic system I installed on the CF at first, but I ran out of space before the cvs was even done. So my only option now is to find a machine that can run 5.0 i386, do the compile from there. Alternatively be satisified with a binary install and generic kernel. 2012/1/28 Christer Solskogen christer.solsko...@gmail.com On Sat, Jan 28, 2012 at 5:25 PM, Stefan Midjich sweh...@gmail.com wrote: So what do I do to get 5.0 compiled? You upgrade to 5.0 first. -- chs, -- Hdlsningar / Greetings Stefan Midjich [De omnibus dubitandum]
Re: 5.0 kernel won't compile on 4.9 i386 system
On Sat, Jan 28, 2012 at 12:42 PM, Stefan Midjich sweh...@gmail.com wrote: Thanks everyone for the info, I clearly didn't read the whole FAQ but only the parts I needed. The reason I was using 4.9 was because 5.0 i386 didn't boot in vmware fusion 3, it hangs at mtrr. And since I was formatting a CF card from the vm I thought I had to use the same arch as the kernel that will run from it, so I ended up trying on a 4.9. I do exactly the same thing: use VMWare Fusion 3 to build release(8) whenever there's changes to -stable that I need (otherwise I just install -release directly). I've been doing this since 4.8 and have never had a problem using stock i386 GENERIC. You might try changing the VM type to Other or disabling some peripheral emulation. FWIW, amd64 works like a champ too using Other 64-bit. I haven't tried running i386 on Other 64-bit. Also the reason I wanted to compile is something I should have stated, there's a kernel config online for pcengines alix boards so I wanted to use it on mine thinking it was better optimized for the tiny board with very few peripherals. https://raw.github.com/openbsd/flashboot/master/PCENGINES Keep reading the FAQ: http://www.openbsd.org/faq/faq5.html#Why I run i386 GENERIC on my ALIX 2D13, no custom anything required. I included my dmesg below for posterity. Everything I need fits more than comfortably on a 16GB CF card. I performed the initial install using the VM as well. I gave my OpenBSD VM access to the CF via USB card reader, booted the VM into bsd.rd, did a fresh install to the CF card, added tty items to /etc/boot.conf, and tweaked /etc/fstab. Then I installed the CF card into the ALIX board and from there just configured everything else over serial / network. Good luck, --david OpenBSD 5.0-stable (GENERIC) #1: Tue Nov 8 02:05:22 EST 2011 root@vm.localdomain:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 499 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX real mem = 267976704 (255MB) avail mem = 253542400 (241MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/05/08, BIOS32 rev. 0 @ 0xfd088 pcibios0 at bios0: rev 2.1 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xe/0xa800 cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 10, address 00:0d:b9:1e:60:7c ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 10 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:0d:b9:1e:60:7d ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 11 function 0 VIA VT6105M RhineIII rev 0x96: irq 15, address 00:0d:b9:1e:60:7e ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 glxpcib0 at pci0 dev 15 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio gpio0 at glxpcib0: 32 pins pciide0 at pci0 dev 15 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: TS16GCF133 wd0: 1-sector PIO, LBA, 15296MB, 31326208 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 15 function 4 AMD CS5536 USB rev 0x02: irq 12, version 1.0, legacy support ehci0 at pci0 dev 15 function 5 AMD CS5536 USB rev 0x02: irq 12 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 mtrr: K6-family MTRR support (2 registers) nvram: invalid checksum ugen0 at uhub1 port 2 American Power Conversion Back-UPS ES 750 FW:841.I3 .D USB FW:I3 rev 1.10/1.01 addr 2 vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root scsibus1 at softraid0: 256 targets root on wd0a (295fd65258ac0a48.a) swap on wd0b dump on wd0b clock: unknown CMOS layout
Re: uaudio0: sync ep address mismatch
On Tue, Jan 24, 2012 at 05:33:24PM +0100, Gregor Pintar wrote: Hello. As you can see from dmesg output, Creative Sound Blaster X-Fi HD USB doesn't work on OpenBSD 5.0. Doesn't uaudio support all usb sound cards? most standard cards (aka those that work without drivers on windows and macos) should work. Certain cards are not 100% standard and require quirks. The uaudio driver is not 100% complete either. uaudio cards don't work through USB 2.0 hubs. Your card seems somewhat standard but I can't figure out what's wrong exactly. Does it generate interrupts? Could you try the following? cat /dev/sound0 /tmp/foo does this generate an emtpy file or an error? And what about the following: cat /bsd /dev/sound0 do you hear noise? While above commands are running (if they run at all), if you run audioctl multiple times, do play.samples, play.errors, record.samples, record.errors increase? -- Alexandre
Re: Long delay updating xenocara source tree?
On 01/28/12 09:12, Dave Anderson wrote: Thanks for the info. I've been using -Pd because http://www.openbsd.org/anoncvs.html says to use them; I haven't yet had a chance to look into how cvs works beyond reading the man page, faq, etc. and please continue to use them. -Pd is the RIGHT way. Apparently, Philip gets away with it, but he's a developer and he knows this stuff pretty well, we don't expect ordinary users to clean up the mess it can make. I'll defer to his expertise on coding and probably CVS, but there are many things in many parts of the tree where a lack of a -Pd will hurt you in ways other than slow updates. There are thousands of ways to use cvs incorrectly, -Pd is the correct way to do updates (or maybe -PAd under some circumstances). And none of this has anything to do with your real problem. I run far slower hardware than most people, and xenocara updates don't take nine hours (and if I understand you, that was nine hours then you gave up and killed it). This has NOTHING TO DO WITH COMMAND LINE OPTIONS. I wrote the FAQ you used, I use that FAQ, and I do it on hardware like mac68k and sparc, and it works, it does not take nine hours to update xenocara (it just feels like it...) If you could...next time you see this, use a CVSROOT=anon...@obsd.cec.mtu.edu:/cvs and see if things run better. NOTE: DO NOT GET USED TO USING THIS MIRROR, IT IS BEING SHUT DOWN VERY SOON. But, being it's been being advertised as being shut down, it's pretty lightly loaded, and it handles the CVS temp directory as an mfs, which really really helps (this is on the server end. Nothing you can do about it on your side). My hunch, as a soon-to-be former mirror operator is that you are having a problem with your mirror of choice, not a problem on your end, and it may be a problem with multiple mirrors. I just checked out xenocara from that mirror, and then did an update on my amd64 system, the update took less than one minute. Your results will vary, but not to nine hours, unless you are using dialup. :) Nick.
Radeon 4200 and azalia audio problems
I recently upgraded to the most recent (Jan. 26) snapshot from a system built from source on Jan. 24th, with mixed results: (dmesg follows) - Jan. 24th: using the xf86-video-ati-6.14.3.tar.gz driver from x.org, mplayer video output was jittery, like the driver couldn't keep up, but audio was fine[*1]. I got the your computer is too slow! message from mplayer (no, it isn't). - Jan. 26th: Not using the 6.14.3 driver, mplayer output was the same as above. With the x.org driver, mplayer video output is now fine, but there is a noticeable crackling/distortion during playback of some (not all) movie/TV files. It sounds like the audio levels of the media files is too high, but audio was fine on these same files the other day. [*1] - I'm not sure exactly when this popped up, only in the last week maybe, but now I can hear interference on the computer speakers during some (usually intense) HDD activity. The connections are solid (no recent changes/moves), but now when there is no background noise in the room, the HDD squealing sounds are quite noticeable. I just thought I'd let people know. Any suggestions would be appreciated, and I'll keep trying new snaps as they are released. - Scott dmesg: OpenBSD 5.1-beta (GENERIC.MP) #188: Thu Jan 26 15:00:02 MST 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4023975936 (3837MB) avail mem = 3902701568 (3721MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f000 (68 entries) bios0: vendor American Megatrends Inc. version 2103 date 06/18/2010 bios0: ASUSTeK Computer INC. M4A785TD-V EVO acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2M(S4) PS2K(S4) UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X6 1100T Processor, 3315.23 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu4 at mainbus0: apid 4 (application processor) cpu4: AMD Phenom(tm) II X6 1100T Processor, 3314.79 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT cpu4: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu4: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu4: DTLB 48 4KB entries fully
customer message
- This mail is in HTML. Some elements may be ommited in plain text. - St.George Online Banking Message Online Banking is undergoing maintenance and In order that you may access your account for satefy you must verify your identity by clicking on the link below now: VERIFY YOUR ST.GEORGE BANK ACCOUNT Thank you for your patience. Bank or Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to St.George Bank account and choose the Help link on any page. St.George bank Email ID # 1078
Re: uaudio0: sync ep address mismatch
2012/1/28, Alexandre Ratchov a...@caoua.org: On Tue, Jan 24, 2012 at 05:33:24PM +0100, Gregor Pintar wrote: Hello. As you can see from dmesg output, Creative Sound Blaster X-Fi HD USB doesn't work on OpenBSD 5.0. Doesn't uaudio support all usb sound cards? most standard cards (aka those that work without drivers on windows and macos) should work. Certain cards are not 100% standard and require quirks. The uaudio driver is not 100% complete either. uaudio cards don't work through USB 2.0 hubs. Your card seems somewhat standard but I can't figure out what's wrong exactly. Does it generate interrupts? Could you try the following? cat /dev/sound0 /tmp/foo does this generate an emtpy file or an error? empty file (full of nulls) And what about the following: cat /bsd /dev/sound0 do you hear noise? ksh: cannot create /dev/sound0: Device not configured While above commands are running (if they run at all), if you run audioctl multiple times, do play.samples, play.errors, record.samples, record.errors increase? no
Re: Radeon 4200 and azalia audio problems
On Sat, 28 Jan 2012 15:20:27 -0500 Scott McEachern sc...@blackstaff.ca wrote: [*1] - I'm not sure exactly when this popped up matthieu@ updated the ati driver recently. (yesterday? check the source-changes@ archives, http://www.openbsd.org/faq/current.html ) ati cards are now all attached to the opensource ati x driver. sorry to hear (...) that caused some hdmi-audio regressions for you. you might want to look for similar reports upstream. Cheers, - Robert
sendmail TLS errors
I am getting the following errors, with sendmail (Openbsd 5.0 and errors were there for 4.9 as well) Jan 28 16:34:48 mail sm-mta[24871]: starting daemon (8.14.5): SMTP+queueing@00:30:00 Jan 28 16:34:51 mail sm-mta[372]: STARTTLS=client, error: connect failed=-1, SSL_error=1, errno=0, retry=-1 Jan 28 16:34:51 mail sm-mta[372]: STARTTLS=client: 372:error:1411809D:SSL routines:SSL_CHECK_SERVERHELLO_TLSEXT:tls invalid ecpointformat list:/usr/src/lib/libssl/ssl/../src/ssl/t1_lib.c:1470: Jan 28 16:34:51 mail sm-mta[372]: STARTTLS=client: 372:error:14092113:SSL routines:SSL3_GET_SERVER_HELLO:serverhello tlsext:/usr/src/lib/libssl/ssl/../src/ssl/s3_clnt.c:945: Jan 28 16:34:51 mail sm-mta[372]: ruleset=tls_server, arg1=SOFTWARE, relay=edgewave.com.mx1.rci.rcimx.net, reject=403 4.7.0 TLS handshake failed. From peering around with google these seem to come from an error in ssl. I assume that it is edgewave.com.mx1.rci.rcimx.net that has the error, not OpenBSD 5.0 but none the less I cannot send email to this site, with TLS enabled. It my surprise I found that not configuring TLS on sendmail.mc only turns it off for receiving not sending. The only way I can find to turn it off for sending is by adding Try_TLS:edgewave.com.mx1.rci.rcimx.net NO Try_TLS:edgewave.com.mx2.rci.rcimx.net NO Try_TLS:edgewave.com.mx3.rci.rcimx.net NO Try_TLS:edgewave.com.mx4.rci.rcimx.net NO to sendmail's map access database. The addresses belong to a email company that handles email for a other companies. I know of 5 companies that I cannot send to. You can try this yourself by sending email to x...@redcondor.com The email doesn't exist but the connection is dropped before anyone discovers that xxx is not valid. It would have been nice if sendmail falls back to a none TLS connection if the handshake occurs. As it is I have to watch the maillog to identify which mail is being blocked and adding the resulting address the access map
account alert
- This mail is in HTML. Some elements may be ommited in plain text. - Your ANZ Online Banking account has been temporary suspended. To confirm your e-mail account status please LOGIN
Leafpad: Sometimes Undo currupted document
Hello. This is OpenBSD4.9, but I believe latest Leafpad still has this
problem.
$ pkg_info leafpadInformation for inst:leafpad-0.8.17p4
Sometimes Undo currupted document, and this was shown in xterm.
(leafpad:5025): GLib-GObject-WARNING **: gsignal.c:2354: handler `238' of
instance `0x7df450d8' is not blocked (leafpad:5025): GLib-GObject-WARNING **:
gsignal.c:2354: handler `239' of instance `0x7df450d8' is not blocked
The cause of problem was,
1. When user modifies text, cb_begin_user_action() will be called. It
unlocks signal handler which stores record of modification into undo
buffer. This signal handler is disabled usually because there is
modification should not go into undo buffer. (ie: undo itself)
2. While unlock faze, another cb_begin_user_action() can be called.
(I'm not sure, but it's natural to think so) But this time, glib's
internal lock count is already 0, so that warning was shown.
3. Inner cb_end_user_action() increses lock count to 1.
4. Outer cb_end_user_action() increses lock count to 2. (!)
Now, next cb_begin_user_action() cannot unlock signal handler, becauselock
count is 2 not 1. So undo buffer management
corrupts.gtk_text_buffer_begin_user_action() will avoid this, because ittreats
another *user action* count internally,
# I don't think so, but maybe other g_signal_emit_by_name also# should be
replaced by similar functions.
Workaround is leafpad-undo.patch. I'm not sure this is real fix.
not worked--sync option (Make X calls synchronous) didn't solve undo
problem. :-(/not worked
/
leafpad-undo.patch
=== modified file 'indent.c'--- indent.c2011-05-08 09:13:10 ++++
indent.c
2011-05-08 09:25:28 +@@ -69,13 +69,13 @@GtkTextBuffer *buffer =
gtk_text_view_get_buffer(GTK_TEXT_VIEW(text_view)); -
g_signal_emit_by_name(G_OBJECT(buffer), begin-user-action);+
gtk_text_buffer_begin_user_action(buffer);
gtk_text_buffer_delete_selection(buffer, TRUE, TRUE);
gtk_text_buffer_get_iter_at_mark(buffer, iter,
gtk_text_buffer_get_insert(buffer));ind = compute_indentation(buffer, iter,
gtk_text_iter_get_line(iter)); str = g_strconcat(\n, ind, NULL);
gtk_text_buffer_insert(buffer, iter, str, -1);-
g_signal_emit_by_name(G_OBJECT(buffer), end-user-action);+
gtk_text_buffer_end_user_action(buffer);g_free(str);g_free(ind);
@@
-149,9 +149,9 @@for (i = start_line; i end_line; i++) {
gtk_text_buffer_get_iter_at_line(buffer, iter, i);
gtk_text_buffer_place_cursor(buffer, iter);-
g_signal_emit_by_name(G_OBJECT(buffer), begin-user-action);+
gtk_text_buffer_begin_user_action(buffer);
gtk_text_buffer_insert(buffer,
iter, \t, 1);- g_signal_emit_by_name(G_OBJECT(buffer),
end-user-action);+gtk_text_buffer_end_user_action(buffer);
undo_set_sequency(TRUE);} undo_set_sequency(FALSE);@@ -201,9
+201,9 @@
end_iter = start_iter; gtk_text_iter_forward_chars(end_iter,
len);
gtk_text_buffer_move_mark_by_name(buffer, insert, end_iter);-
g_signal_emit_by_name(G_OBJECT(buffer), begin-user-action);+
gtk_text_buffer_begin_user_action(buffer);
gtk_text_buffer_delete(buffer,
start_iter, end_iter);-
g_signal_emit_by_name(G_OBJECT(buffer),
end-user-action);+
gtk_text_buffer_end_user_action(buffer);
undo_set_sequency(TRUE);g_free(ind);}
=== modified file 'search.c'--- search.c2011-05-08 09:13:10 ++++
search.c
2011-05-08 09:25:28 +@@ -218,12 +218,10 @@
gtk_text_buffer_get_insert(textbuffer));offset =
gtk_text_iter_get_offset(rep_start);
undo_set_sequency(TRUE);-
g_signal_emit_by_name(G_OBJECT(textbuffer),-
begin-user-action);+
gtk_text_buffer_begin_user_action(textbuffer);
gtk_text_buffer_insert_at_cursor(textbuffer,
string_replace,
strlen(string_replace));-
g_signal_emit_by_name(G_OBJECT(textbuffer),-
end-user-action);+
gtk_text_buffer_end_user_action(textbuffer);
gtk_text_buffer_get_iter_at_mark(
textbuffer, iter,
gtk_text_buffer_get_insert(textbuffer));
[demime 1.01d removed an attachment of type text/x-patch]
Sites Temáticos para tornar o seu dia melhor
.: Portugal na Web:. Portugalnaweb.com i o website independente que inclui a melhor rede dos paises lussfonos. Funcionando em tempo real com alguns websites afiliados, Portugal Na Web da em primeira mco as principais as novidades sobre os diversos afiliados. O servigo disponibilizado inclui, tambim, um sistema de alertas e o alojamento de um portfolio de investimentos. Criado em 2008, Portugal Na Web tem revolucionado a forma como a informagco i transmitida aos utilizadores, e pelos seus diversos servigos disponibilizados, devido ` sua qualidade, actualidade e credibilidade, contando para tal com a mesma equipa que modera diariamente todos os contezdos, que sco vistos por milhares de utilizadores por dia. .: Sites Tematicos :. www.video-divertido.com - O Maior Portal De Vmdeos De Humor Em Portugujs. www.aceleras.net - O Portal Em Portugujs Para Todos Os Amantes Do Mundo Automsvel. www.pontapedesaida.com - Os melhores momentos do desporto rei. .: Paginas ticnicas muito zteis nas suas especialidades :. www.portugalnaweb.com - Solugues de publicidade e marketing de internet. www.jpedrofernandes.com - Joco Fernandes Web Designer - Criagco e manutengco de paginas pessoais, comerciais, blogs, foruns, banners. www.fitnesscenterok.com - Exercmcio, Sazde, Nutrigco, Perder Peso, Ganhar Massa Muscular. www.mais-dinheiro.com - Dicas sobre finangas pessoais, baseado nos trabalhos e estudos do consultor financeiro Miguel, autor de trabalhos e artigos de inegavel qualidade. .: Websites de personalidades portuguesas :. www.iva-domingues.com - Pagina Oficial de Iva Domingues. www.sonia-araujo.com - Pagina Oficial de Ssnia Arazjo. www.silvia-alves.com - Tudo sobre Silvia Alves. Perfil, Fotos, Videos, e muito mais! www.merche-romero.org - A pagina da ex. modelo e apresentadora de televisco em Portugal. www.isabel-figueira.net - Tudo sobre Isabel Figueira. Fotos, videos, biografia e muito mais sobre Isabel Figueira. Copyright portugalnaweb.com todos os direitos reservados ) 2006-2012 Este email foi enviado porque se registou numa das paginas da nossa rede. Se pretender anular a informagco que a nossa empresa envia dirija-se a http://www.portugalnaweb.com/newsletter/ (Directiva 2000/31/CE do Parlamento Europeu; Relatsrio A5-0270/2001 do Parlamento Europeu) This email was sent because you registered in one of our websites. To Unsubscribe from this list please follow this link http://www.portugalnaweb.com/newsletter/ .
usb serial device (Atmel), only as ugen
Hi! I'm trying to use an USB serial device with qemu on a OpenBSD host and a winxp guest. I presume the first step would be to recognize this device under OpenBSD as some kind of ucom(4). Currently this is printed in dmesg when I plug in the stuff: ugen1 at uhub1 port 2 Atmel E85 USB Serial rev 2.00/1.00 addr 2 Eventually I would like to use cu(1) or minicom thru a /dev/cuaU? device. The vendor_id:product_id is 03eb:6119. Is it possible to somehow use/probe the existing usb serial drivers to see if it attaches/works with one of them? Thanks, Daniel -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
