HP 735/125 for donation in Adelaide, Australia
This unit has been gathering dust for too long now and I figure someone else may as well have a play with it. Its pretty heavy, maybe 25kg, so I'd prefer local pickup. I'd rather give it to a developer, but if there is no interest I may change my mind. No monitor or keyboard etc. It has two 50 pin SCSI drives (2gb, 1gb), one of which is not well secured. The most recent dmesg I have from it is below. -Graham [ using 325628 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.2 (GENERIC) #42: Thu Aug 9 22:28:09 CEST 2007 kette...@faure.sibelius.xs4all.nl:/usr/src/sys/arch/hppa/compile/GENERIC HP 9000/735/130 (Snake Cheetah) PA-RISC 1.1a real mem = 184549376 (524288 reserved for PROM, 5885952 used by OpenBSD) avail mem = 174346240 mainbus0 at root [flex fff8] pdc0 at mainbus0 power0 at mainbus0: not available mem0 at mainbus0 offset ffbf000: size 176MB cpu0 at mainbus0 offset ffbe000 irq 31: PCXL L1-A 125MHz, FPU PCXT (Rolex - CMOS-26B) rev 1 cpu0: 256K(32b/l) Icache, 256K(32b/l) wr-back Dcache, 120 coherent TLB, 16 BTLB mongoose0 at mainbus0 offset c00 irq 17: HWPC000 rev 34, 33 MHz eisa0 at mongoose0 isa at mongoose0 not configured asp0 at mainbus0 offset 82f000 irq 28: Hardball rev 20, lan 1 scsi 7 gsc0 at asp0: wordleds harmony0 at gsc0 offset 100 irq 13: rev 0 audio0 at harmony0 siop0 at gsc0 offset 83 irq 3 hpa=f083: NCR53C720 rev 2 scsibus0 at siop0: 16 targets lpt0 at gsc0 offset 824000 irq 7 com1 at gsc0 offset 822000 irq 6: ns16550a, 16 byte fifo com0 at gsc0 offset 823000 irq 5: ns16550a, 16 byte fifo com0: console hil0 at gsc0 offset 821000 irq 1 ie0 at gsc0 offset 826000 irq 8: i82596DX v0.0, address 08:00:09:1b:e8:fd oosiop0 at gsc0 offset 825000 irq 9: NCR53C700 rev 0, 31MHz, SCSI ID 7 scsibus1 at oosiop0: 8 targets sd0 at scsibus1 targ 0 lun 0: SCSI2 0/direct fixed sd0: 2157MB, 6300 cyl, 4 head, 175 sec, 512 bytes/sec, 4419464 sec total sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct fixed sd1: 1006MB, 2700 cyl, 9 head, 84 sec, 512 bytes/sec, 2061108 sec total sti0 at mainbus0 offset 800 irq 11: HPA1659A rev 8.02;10, ID 0x26D1482A40A00499 sti0: 2048x1024 frame buffer, 1280x1024x8 display, offset 768x0 sti0: 10x20 font type 1, 40 bpc, charset 0-255 biomask 0x7 netmask 0xf ttymask 0x3f bootpath: 2/0/1.0 class=1 flags=c0 hpa=0xf0825000 spa=0x0 io=0x6abc hil0: no devices wsdisplay0 at sti0 mux 1 wsdisplay0: screen 0 added (std, vt100 emulation) root on sd0a swap on sd0b dump on sd0b
COMPAT_43 discouraged, yet enabled by default?
I'm a little confused that options(4) says COMPAT_43 is discouraged, while it's on by default in /sys/conf/GENERIC. Can someone hit me with a cluestick? Cheers, Graham
Re: Support Needed for GPS and Time Signal Station Receiver Development
- GPS devices, serially and UPS attached (consumer grade) USB?
ugen.4 patch
Here's another. Is misc@ really the right place for silly patches like these? Graham --- ugen.4.orig Sat May 13 16:57:59 2006 +++ ugen.4 Sat May 13 16:58:23 2006 @@ -281,7 +281,7 @@ .Fa interface_desc-*(GtbNumEndpoints . The .Fa config_index -should set to +should be set to .Dv USB_CURRENT_CONFIG_INDEX and .Fa alt_index
i386/amd64 boot.8 patch
This patch should be applied to both sys/arch/i386/stand/boot/boot.8 and sys/arch/amd64/stand/boot/boot.8 Graham --- boot.8.origSat May 13 14:48:39 2006 +++ boot.8 Sat May 13 14:49:05 2006 @@ -210,7 +210,7 @@ .Pp .Dl [+-]@ .Pp -Meaning to add(+) or exempt(-) the specified by the +Meaning to add(+) or exempt(-) .Ar amount of memory at the location specified by the .Ar
Re: Anyone Interested in Programmable AMD Coprocessors?
On 24/04/06, Marti Martinez <[EMAIL PROTECTED]> wrote: > Give it time -- FPGA's are getting more and more academic attention > every year, and our computer engineering students are getting more > opportunities to work with them in school. Before long, the support > and demmand will catch up to their potential. The real problem with FPGA development is the lack of free development tools. Uploading to an FPGA depends on the use of non free (i.e. big, bloated and buggy) software. Graham
Re: Twisted
On 01/04/06, Andrew Smith <[EMAIL PROTECTED]> wrote: > I'm wondering if anyone has taken a look at, or spotted anything nasty in > the Twisted Python framework. Last year I administrated a network for a distributed web application written in Python. It was initially designed use Twisted 2.0. We came to the conclusion that Twisted's asynchronous handling of sockets was completely non-scalable. http://twistedmatrix.com/trac/ticket/578 I can't comment as to quality of code, but I'd look for an alternative if you're expecting large volumes of traffic to/from your web app.
Re: network distributed storage with windows?
On 22/02/06, A Rossi <[EMAIL PROTECTED]> wrote: > Very interesting. > > > export all via nfs > > But is NFS a requirement, or can I make do with windows XP's SMB > implementation? Remember, the partitions are under windows, I want > OpenBSD to be the computer that does the backing up onto those. > I had put s/nfs/samba/ under the url, but gmail is stupid and appended it to the url. > I will try this one. But it lacks the error-recovery I was hoping for. Alas. A CCD mirror is about as good as you'll get. Graham
Re: network distributed storage with windows?
On 22/02/06, A Rossi <[EMAIL PROTECTED]> wrote: > > You may want to experiment with hiding the drives through GP, > > "hidden" might not fit your definition of "can't access". > I'd probably hide it and change permissions for no access. I can do > both, right? > > > Sure, you should just be able to browse to \\server\e$ (or > > equivalent) and access the drive. > Unfortunately, that doesn't really answer my question. > Pretty much what I'm going for is a distributed networked RAID 5 (or 1) > between Windows and *BSD (hopefully OpenBSD) that the windows users > cannot mess with. > This sounds like some fantastical crazy idea that does not yet exist. > Someday when I learn to program, I'll write something that does > explicitly this... > http://marc.theaimsgroup.com/?l=openbsd-misc&m=105358689405500&w=2 s/nfs/samba/
Re: Could someone, running latest snapshots confirm this problem
On 13/02/06, Didier Wiroth <[EMAIL PROTECTED]> wrote: > Hi, > If you are running the latest snapshot with x11 can you confirm the > following command gives you an error message: > setxkbmap fr_CH > > Thank you for taking the time to try this, it only takes 1 or 2 seconds > to test it and reply to this email with a yes or no. > > Regards > Didier > > $ setxkbmap fr_CH Error loading new keyboard description
Re: Pf que for voip
[EMAIL PROTECTED] wrote: Before tinkering with queues, you might like to figure out your usable upload bandwidth to know what you're playing with. I would consider my VoIP altq rules a work in progress at the moment, but defining the upload bandwidths seem to be quite sensitive. I have ADSL PPPoA 1536/256 kbit/s and define my upload bandwidth as 212kbit/s and VoIP seems to be working great (quality at both ends). However if I define my upload bandwidth as 213kbit/s then it is as if I have just switched altq off. Setting it lower than 212kbit/s then gradually hurts download speeds (with pri of empty acks to minimize that problem coming second to VoIP). So it might be a good idea to know what you have to play with first. If you estimate too high, your VoIP queues are not going to be effective and you might waste lots of time trying to figure out why queues which should be working fine, are not. This begs the question, what should you do if your bandwidth is variable? In my neck of the woods ADSL2 has been rolled out, which allows theoretical 24000/1000 kbit/s. Of course, actual speeds depend on the distance from the exchange. When the line resynchs, speeds change. One day I might get 8000/900, another day its 7500/850. How do I tune altq for that? I suppose those on dialup have similar problems. Graham
Re: request for new dmesg reports
On 11/01/06, Bill <[EMAIL PROTECTED]> wrote: > On Sat, 07 Jan 2006 19:23:59 -0700 > Theo de Raadt <[EMAIL PROTECTED]> spake: > > > We're getting about halfway between releases, and around now it is > > nice for us to see what kind of hardware people are seeing out there, > > and how well it is supported. > > > > If people have 3.8 dmesg's that they can mail in to > > > > [EMAIL PROTECTED] > > > > that would be much appreciated. > > > > If they are able to test -current, that is even better. > > > > In the mail Subject, please detail the release (or -current) and > > roughly state what the machine is. In the body, you can perhaps > > perhaps provide some other details about what does or does not work. > > For our parsers, it is better if the mail is not MIME encoded, but > > just plain boring ascii. > > > > As well as telling us what works, and what doesn't work, it also > > gives us hints as to what new hardware people are starting to see > > in their machines... > > > > Thanks a lot. > > > > Does this include older hardware, or just newer stuff? I have a few > machines I can run go and run current on, but none of them are terribly > new. > > H(ope)TH > > Older hardware can also show up bugs. Send them along. Someone may be interested. Graham
Re: nforce3 problem
> /* > * forcedeth: Ethernet driver for NVIDIA nForce media access controllers. > * > * Note: This driver is a cleanroom reimplementation based on reverse > * engineered documentation written by Carl-Daniel Hailfinger > * and Andrew de Quincey. It's neither supported nor endorsed > * by NVIDIA Corp. Use at your own risk. > > Do you reckon this documentation could also be used to write a *BSD > driver? No, I contacted Carl-Daniel Hailfinger last year for said documentation and he was not helpful at all. He claimed that nvidia would not like it, so he would not give out his reverse engineered documentation - any BSD driver would need to reverse engineer the GPL code. Graham
Re: rdr for outgoing packets
> On 6/10/05, Jason Crawford <[EMAIL PROTECTED]> wrote: > > It's very simple, try reading the ftp-proxy man page, as it has an > > example for exactly what you're doing, something like: > > rdr on $int_if inet proto tcp from $int_net to any port ftp -> > > 127.0.0.1 port 8021 > > this works only for packets that *come to* OpenBSD box to be > routed, not the packets that are *originated* at the OpenBSD box. Are you by chance using a rule such as: rdr on $int_if inet proto tcp from ($int_if) to any port foo -> bar instead of: rdr on $int_if inet proto tcp from !($ext_if) to any port foo -> bar ? Graham
Re: nfsd send error 55
I had a similar problem with nfs after enabling packet queueing (CBQ) on the interface. I've since disabled queueing on the internal interface as an interim solution, but am planning on installing an additional NIC for nfs stuff. I experienced the nfsd send error 55 with a linux client too. btw, $ grep 55 /usr/src/sys/sys/errno.h #define ENOBUFS 55 /* No buffer space available */ Graham
