HP dx5150 and USB not working when running /amd64/ kernel.
Just an FYI, I will attempt to get dmesg's when I have a moment at home to pull it off. The AMD 3200+ Athlon 64 - based SFF desktop from HP, (dx5150) can see USB devices when it is running i386 version of 4.6 RAMDISK, (It also can see USB devices when 4.4 RAMDISK was running (How I got i386 4.6 bsd.rd) ) but when I restarted in amd64 version of 4.6 GENERIC when I plugin USB devices (MS Intellimouse, Blackberry 7250, and PS3 EYEcam.) the is no message, and usbdevs -v don't see anything. -sean _ IM on the go with Messenger on your phone http://go.microsoft.com/?linkid=9712960
Read_Write buffers for dd WAS: little cp diff
Moving this to m...@... Would part of this discussion usefully related to such issues like using 'dd' for diskwipes/copies/reformatting and slow data movement speeds? There are times when I am wiping (for reuse) hard disks using 'dd' and I set the BlockSize to 512 (like 1M or so sometimes) and the transfer speeds are quite a lot slower than for using 'dd' on some other Operating systems. (Linux or Windows) Mind you, for a lot of this, I am using oBSD RamDISK, so I am not anticipating a full-fledged OS support for the ATA or SCSI or USB2 platforms. But for those systems where I am using -stable or -current, the speeds are still comparably slow. I concur with Theo's point on portability and making a sysctl for kernel is hazardous, but what am I seeing in the above for 'dd' that would be causing the poor performance? (* BTW, I am using if=/dev/zero for the baseline, other if=/...'es may have lower performance as an input for compare*) Just my 2 cents. -sean Subject: Re: little cp diff 2010/2/8 Theo de Raadt dera...@cvs.openbsd.org: For those of you who asked why cp needs to be portable, come on. You've got it all wrong. If cp isn't written in a portable fashion, then what is the point of doing anything else in a portable fashion. This is good and reasonable answer. So I think we should stop discussion. antonvm _
This is what Linus Torvalds calls openBSD crowd
We need a Button. Reminds me of the advert in Comic Books of my youth, for Sea Monkeys, Maybe we need Puffy looking concerned, with Sea Monkeys facing away from the perspective doing something that most Prudes would find offensive.. Nothing Obvious mind-you, just a perspective of backs of Sea Monkeys'. Oooh Sea-Monkey...:- -sean http://www.sea-monkeys.com/ http://en.wikipedia.org/wiki/Sea-Monkeys . _ Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games! http://g.msn.ca/ca55/207
Re: How to HIDE OpenBSD as user-agent?
Now this idea: I don't have an issue with. For HoneyPot systems, obviously, you want to Attract attention, you setup attractive, known buggy user agent strings and the like for other services. Then watch who attempts. For Silent Lurker systems, you want an obscure response to thinks like the HTTP User Agent string but if you use things like Opera, Firefox, or Apple's Safari, You could select a false User-Agent string to send. For other Services the Silent Lurker is going to respond to, you could be more obscure: Like not send anything at all... But then Again. I would tend to use the Silent Lurker method If I was surfing for 'Pr0n' but instead I just use an expendable Windows 2000 system running firefox *With Delete everything when done* setting turned on in a PF'ed DMZ lan segment, logged in as administrator (with full rights) with a machine name of IDONTCARE or something like that. When it goes Zoop, I ghost a copy back over. -sean Subject: Re: How to HIDE OpenBSD as user-agent? On 4/29/08 5:32 PM, Ross Cameron wrote: This is an obscurity hack and an all round bad idea. Yes it's an obscurity hack, but that doesn't make it a bad idea in general. When I'm browsing from my work computer I'm very easy to trace anywhere in logs because of the OpenBSD, KDE and Seamonkey combination. From a security point of view it's plain stupid, but regarding privacy the question isn't a bad idea. +++chefren _ Find hidden words, unscramble celebrity names, or try the ultimate crossword puzzle with Live Search Games. Play now! http://g.msn.ca/ca55/212
Alpha onboard PCI VGA console color issue.
Hello 'alpha' / 'misc' Alpha console color question. I got a DS20E 833 uniprocessor Alpha with onboard PCI VGA ( vga0 at pci0 dev 7 function 0 3D Labs Oxygen GVX1 rev 0x01 ) Running 4.1-GENERIC and have seen this since oBSD 3.8 when I began running oBSD on the unit. (nearly 2 years ago, wow!) OK my question is: Is there any one else running OpenBSD on an alpha in VGA console mode with wscons, and have when in multi-user mode, the console running with a blue background? The Blue background is present in all wscons displays. From MacPPC, and i386, Kernel Messages show up with Blue Background highlighting, and the background is black with nominal grey test. But on alpha, the background is always Blue, and may be triggered to black when running some utilities like vi. However even with the black background, the blue returns. and other highlights (bold text) do not appear. I would like to know in what direction I can look for the background color settings when wscons sets up the displays. There may be an update for the color palette that can be tested. Any pointers would help. -sean _ Get More out of Messenger - Get a Windows Live Space http://spaces.live.com/?mkt=en-ca
OPENBSD_4_1 (-stable) userland build on alpha.
Interesting.
Decided to update non-production critical system and ran into the following
on the arch/alpha processor blend during the (make build) portion of the
userland builds.
arch/i386 works fine. So this could possibly be a compiler setting.,,
Although,, I am having userland compile issue on httpd on a PII system in
production I am doing a userland build on, and THAT may be because I need to
re-build the /usr/src tree from CVS.
I'm cross-referencing the problem on my test i386 unit at home.
CVS branch I'm using. Not expecting it to be rock solid, would like to try
to correct/test if possible
#cvs -d$CVSROOT up -rOPENBSD_4_1 -Pd
dmesg further below.
-snip-
*** make build ***
.
.
.
.
rm -f bfd-tmp.h
cp bfd-in3.h bfd-tmp.h
/bin/sh /usr/src/gnu/usr.bin/binutils/bfd/../move-if-change bfd-tmp.h bfd.h
rm -f bfd-tmp.h
touch stmp-bfd-h
# we don't install ansidecl.h, we merge it into the file that
# needs it instead.
sed -e '/^#include
ansidecl.h/r/usr/src/gnu/usr.bin/binutils/include/ansidecl.h' -e '//d'
bfd/bfd.h bfd/mybfd.h
preparing in /usr/src/include/../gnu/lib/libstdc++
PATH=/bin:/usr/bin:/sbin:/usr/sbin INSTALL_PROGRAM=install -c -s
CC=cc CXX=c++ CFLAGS=-O2 -pipeCXXFLAGS=-O2 -pipe/bin/sh
/usr/src/gnu/lib/libstdc++/libstdc++/configure --prefix=/usr --disable-nls
--enable-shared --disable-multilib --with-gnu-ld
--with-gxx-include-dir=/usr/include/g++ touch config.status
creating cache ./config.cache
checking host system type... alpha-unknown-openbsd4.1
checking target system type... alpha-unknown-openbsd4.1
checking build system type... alpha-unknown-openbsd4.1
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether ln -s works... yes
checking for gcc... cc
checking whether we are using GNU C... yes
checking whether cc accepts -g... yes
checking for c++... c++
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking for GCC version number... 2.95.3
checking for strerror in -lcposix... no
checking for as... as
checking for ar... ar
checking for ranlib... ranlib
checking for a BSD compatible install... /usr/bin/install -c
checking whether to enable maintainer-specific portions of Makefiles... no
CPU config directory is cpu/alpha
OS config directory is os/bsd/openbsd
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking how to recognise dependant libraries... unknown
checking for object suffix... o
checking for ranlib... (cached) ranlib
checking for strip... strip
checking how to run the C++ preprocessor... c++ -E
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking whether -lc should be explicitly linked in... yes
checking for objdir... .libs
checking for cc option to produce PIC... -fPIC -DPIC
checking if cc PIC flag -fPIC -DPIC works... yes
checking if cc static flag -static works... yes
finding the maximum length of command line arguments... 98305
checking if cc supports -c -o file.o... yes
checking if cc supports -fno-rtti -fno-exceptions ... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... openbsd4.1 ld.so
checking command to parse /usr/bin/nm -B output... ok
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for dlopen in -ldl... no
checking for dlopen... yes
checking for dlfcn.h... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... Wrong dl
symbols!
no
creating libtool
updating cache ./config.cache
loading cache ./config.cache
loading cache ./config.cache within ltconfig
checking host system type... alpha-unknown-openbsd4.1
checking build system type... alpha-unknown-openbsd4.1
checking for objdir... .libs
checking for c++ option to produce PIC... -fPIC -DPIC
checking if c++ PIC flag -fPIC -DPIC works... yes
checking if c++ static flag -static works... yes
finding the maximum length of command line arguments... (cached) 98305
checking if c++ supports -c -o file.o... (cached) yes
checking if c++ supports -fno-rtti -fno-exceptions ... yes
checking whether the linker (/usr/bin/ld) supports shared libraries...
checking how to hardcode library paths into programs...
Re: Compile Issue in libssl/crypto.
Understood, -- Just being pedantic, before I move to -rstable, I usually do a build with -rOPENBSD_X_x first when I do a Vanilla system. Answer of Use -rstable. is your answer. libssl/crypto has issues with -rOPENBSD_4_0. shrug Cross Posting to misc@ to satisfy request. Still posting to tech@ so I get a backup copy. -sean Subject: Re: Compile Issue in libssl/crypto. you haven't followed the instructions. http://www.openbsd.org/stable.html (this sort of question belongs on misc@, not tech@) i386 system, doing a Vanilla system from a bsd.rd boot from floppy and FTP distro build. FTP'ed src.tar.gz, unpacked, cvs up'ed from anoncvs.ca.openbsd.org using -rOPENBSD_4_0 Conf'ed to GENERIC, compiled /bsd, moved, rebooted, and am building userland and I run into this: *** Extended Blah Blah Blah removed *** Should I try doing the CVS with -rstable vs -rOPENBSD_4_0? Prior to this, I have built about 6-7 systems in the same manner and have not run into this compile issue. -sean _ Windows Live Spaces: share your New Year pictures! http://discoverspaces.live.com/?loc=en-CA
