Re: OpenBSD/alpha Status
On Apr 18, 2007, at 12:53 AM, Henning Brauer wrote: * Bryan Vyhmeister [EMAIL PROTECTED] [2007-04-17 19:55]: Do you use any Alpha machines in production? not any more, and i would not quite recommend doing so, to be honest Did you stop using them for performance and age reasons or more for stability and reliability especially as it is related to The Alpha Bug? Bryan
Re: OpenBSD/alpha Status
On Tue, 17 Apr 2007 16:10:28 +0200 (CEST) Siegbert Marschall [EMAIL PROTECTED] wrote: Hi, Hm, this could point to violated hardware specifications, memory cells that aren't used fast enough and thus not auto-refreshed in time. I presume the Alpha-bug is OpenBSD-only so it's definitely not a hardware problem? Could be that OpenBSD uses certain parts not often enough. Slow down the clocks to see if it's in that direction? And if so, start reading the datasheets... If someone in The Netherlands is really interested I can provide 433 and 500MHz Miata's, we also have an original DEC Alpha AXP development board available, I presume with a 166MHz 21064, boots via Ethernet with bootp. Ethernet, yes the original version, we have a DEC Ethernet-BNC adapter for it too. Hi list, I own a fairly old 3000/300 i don't really use it but I kept an hard drive with OSF installed on are there some tests i can do ? The beast has also an hard drive with obsd 3.x (might be 3) Eventually i could trace something under both oses ...
Re: OpenBSD/alpha Status
On 4/16/07, J.C. Roberts [EMAIL PROTECTED] wrote: The trouble is, when you have a strange mystery bug floating out there, it may or may not be correctly blamed for any and all problems. So, that's the cause of global warming... :)
Re: OpenBSD/alpha Status
J.C. Roberts [EMAIL PROTECTED] writes: -- The trouble is, when you have a strange mystery bug floating out there, it may or may not be correctly blamed for any and all problems. naaah. //art
Re: OpenBSD/alpha Status
On Apr 17, 2007, at 8:44 AM, Artur Grabowski wrote: Bryan Vyhmeister [EMAIL PROTECTED] writes: 1. There is a potential fix for the alpha bug coming up Very good! I'm glad to hear that. Hm. I think I've heard that one before.. Hell, I've even said it many times before.. This doesn't sound so promising. I guess the basic idea is that I need to hope that any CS20 machines I get are not affected by the bug. Bryan
Re: OpenBSD/alpha Status
Hi, Hm, this could point to violated hardware specifications, memory cells that aren't used fast enough and thus not auto-refreshed in time. I presume the Alpha-bug is OpenBSD-only so it's definitely not a hardware problem? Could be that OpenBSD uses certain parts not often enough. Slow down the clocks to see if it's in that direction? And if so, start reading the datasheets... If someone in The Netherlands is really interested I can provide 433 and 500MHz Miata's, we also have an original DEC Alpha AXP development board available, I presume with a 166MHz 21064, boots via Ethernet with bootp. Ethernet, yes the original version, we have a DEC Ethernet-BNC adapter for it too. the main problem with the damned thing is that you can't reproduce it reliably. no matter what I do, the machines I have will crash likely within a week, but there is no guarantee even for that. I thought i found something, binding it to the cheaper cpus but according to other peoples experiences it just seems to spread over all alpha systems, just some have it and some don't. some less and some more. no common denominator to be found so far. I played with the machines for weeks and months and just couldn't find anything pointing in any real direction. nothing reliable. looks like everybody was banging it's head against that stuff for years and nothing worked so far... just turned them off after some time, had other things to do and was better for my electricity bill. ;) -sm
Re: OpenBSD/alpha Status
* Bryan Vyhmeister [EMAIL PROTECTED] [2007-04-17 18:29]: This doesn't sound so promising. I guess the basic idea is that I need to hope that any CS20 machines I get are not affected by the bug. they are, every alpha is. they seem to be affected least tho. it's been a while that i saw The Alpha Bug on my DS20L -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: OpenBSD/alpha Status
On Apr 17, 2007, at 10:19 AM, Henning Brauer wrote: * Bryan Vyhmeister [EMAIL PROTECTED] [2007-04-17 18:29]: This doesn't sound so promising. I guess the basic idea is that I need to hope that any CS20 machines I get are not affected by the bug. they are, every alpha is. they seem to be affected least tho. it's been a while that i saw The Alpha Bug on my DS20L Do you use any Alpha machines in production? Bryan
Re: OpenBSD/alpha Status
On Apr 16, 2007, at 3:17 AM, Henning Brauer wrote: * Bryan Vyhmeister [EMAIL PROTECTED] [2007-04-16 07:44]: The CS20 does seem to be a pretty nice machine. I noticed that there is one obvious CS20 in the newrack.jpg picture. Is power consumption pretty high on these? haven't measured... shouldn't be worse than a dual xeon or the like Good to know. Thanks. Bryan
Re: OpenBSD/alpha Status
On Sunday 15 April 2007 15:23, Bryan Vyhmeister wrote: On Apr 15, 2007, at 3:08 PM, Siegbert Marschall wrote: Hi, On the other hand, there seems to be a 'the alpha bug' around. I don't think it's solved yet, and it's been around for a long time. Apparently, it causes random crashes. only on some machines. Any idea if it surfaces on dual processor CS20 machines? I have the opportunity to pick up three dual 833 Mhz CS20 machines. Bryan I've been told the alpha bug has been with us since (at least) OpenBSD 3.0 and many people have tried to solve it. As one of the people who tried, and (miserably) failed, to find the alpha bug, I can say it is really an esoteric problem. A lot of information points to a rare race condition (i.e. software fault) on particular system under particular loads but no one has managed to prove it either way. Heck, for all I know it could even be an unknown hardware glitch that never received an errata because no one at DEC/Compaq/HP ever noticed it with supported operating systems. I've never seen the alpha bug on my DS20L (equivalent to the CS20) or my 500/500 but I have seen it on my PC* boxes. Other people have had the exact opposite experience. The only time I've hit the bug was during system builds and in contrast, others have reported hitting the bug at other times during normal operation. -- The trouble is, when you have a strange mystery bug floating out there, it may or may not be correctly blamed for any and all problems. -jcr
Re: OpenBSD/alpha Status
On Monday 16 April 2007 12:06, Maurice Janssen wrote: On Monday, April 16, 2007 at 11:30:29 -0700, Bryan Vyhmeister wrote: On Apr 16, 2007, at 10:39 AM, J.C. Roberts wrote: I've never seen the alpha bug on my DS20L (equivalent to the CS20) or my 500/500 but I have seen it on my PC* boxes. Other people have had the exact opposite experience. The only time I've hit the bug was during system builds and in contrast, others have reported hitting the bug at other times during normal operation. -- The trouble is, when you have a strange mystery bug floating out there, it may or may not be correctly blamed for any and all problems. Thank you for the followup. I guess I will just try and see what happens. I should dig out my PC164 whatever box and see if it exhibits the issue. FWIW: the bug seems to occur at my 3000/300X, but only during heavy load like 'make build'. I never finished such a build, but I only tried a few times. Maurice I just thought of something which might be worth a try on systems that show the bug during system builds; use nice(1) to lower the build priority. It's a long shot, and I haven't tried it, but it *might* be a useful work around. Then again, it might be a waste of time. -jcr
Re: OpenBSD/alpha Status
On Mon, Apr 16, 2007 at 12:33:09PM -0700, J.C. Roberts wrote: On Monday 16 April 2007 12:06, Maurice Janssen wrote: On Monday, April 16, 2007 at 11:30:29 -0700, Bryan Vyhmeister wrote: On Apr 16, 2007, at 10:39 AM, J.C. Roberts wrote: I've never seen the alpha bug on my DS20L (equivalent to the CS20) or my 500/500 but I have seen it on my PC* boxes. Other people have had the exact opposite experience. The only time I've hit the bug was during system builds and in contrast, others have reported hitting the bug at other times during normal operation. -- The trouble is, when you have a strange mystery bug floating out there, it may or may not be correctly blamed for any and all problems. Thank you for the followup. I guess I will just try and see what happens. I should dig out my PC164 whatever box and see if it exhibits the issue. FWIW: the bug seems to occur at my 3000/300X, but only during heavy load like 'make build'. I never finished such a build, but I only tried a few times. Maurice I just thought of something which might be worth a try on systems that show the bug during system builds; use nice(1) to lower the build priority. It's a long shot, and I haven't tried it, but it *might* be a useful work around. Then again, it might be a waste of time. Just curious: why do you think this helps? It's not like nice'ing the only process on the box that uses any real resources helps, does it? Joachim -- TFMotD: tl (4) - Texas Instruments ThunderLAN 10/100 Ethernet device
Re: OpenBSD/alpha Status
Hi, On Monday 16 April 2007 12:06, Maurice Janssen wrote: On Monday, April 16, 2007 at 11:30:29 -0700, Bryan Vyhmeister wrote: On Apr 16, 2007, at 10:39 AM, J.C. Roberts wrote: I've never seen the alpha bug on my DS20L (equivalent to the CS20) or my 500/500 but I have seen it on my PC* boxes. Other people have had the exact opposite experience. The only time I've hit the bug was during system builds and in contrast, others have reported hitting the bug at other times during normal operation. -- The trouble is, when you have a strange mystery bug floating out there, it may or may not be correctly blamed for any and all problems. Thank you for the followup. I guess I will just try and see what happens. I should dig out my PC164 whatever box and see if it exhibits the issue. FWIW: the bug seems to occur at my 3000/300X, but only during heavy load like 'make build'. I never finished such a build, but I only tried a few times. Maurice I just thought of something which might be worth a try on systems that show the bug during system builds; use nice(1) to lower the build priority. It's a long shot, and I haven't tried it, but it *might* be a useful work around. Then again, it might be a waste of time. oh mann, crap it. I have 2 3000-300LX and one 3000-300X. I had the LXs crashing on me, the X never crashed. swapped the CPU-Boards and I had the other machine crashing. okay, so the 300X modules crash, just mine doesn't or takes a _long_ time to do so. let's see what the upcoming patch does. do you also get funny LLSC memory error messages when you run the builtin tests ? I had the impression the stuff was related but couldn't find one with intimate enough knowledge of the hardware to dig it and the cpu-manuals one can download are rather useless in this context. apart from the fact that those errors should not show up in a single cpu-system. you have to run the test a few times to get them, they only show up sometimes. kind of explains why it's rare in DS20s, with multiple CPUs LLSC error make the machine useless on single CPUs they shouldn't be there but don't kill it since there is only one cache. however, right now they are all off. as soon as something to test comes up I will power them up again and test. -sm
Re: OpenBSD/alpha Status
I just thought of something which might be worth a try on systems that show the bug during system builds; use nice(1) to lower the build priority. It's a long shot, and I haven't tried it, but it *might* be a useful work around. Then again, it might be a waste of time. Just curious: why do you think this helps? It's not like nice'ing the only process on the box that uses any real resources helps, does it? It does not change anything wrt this problem. Miod
Re: OpenBSD/alpha Status
On Monday, April 16, 2007 at 12:33:09 -0700, J.C. Roberts wrote: On Monday 16 April 2007 12:06, Maurice Janssen wrote: FWIW: the bug seems to occur at my 3000/300X, but only during heavy load like 'make build'. I never finished such a build, but I only tried a few times. I just thought of something which might be worth a try on systems that show the bug during system builds; use nice(1) to lower the build priority. It's a long shot, and I haven't tried it, but it *might* be a useful work around. Then again, it might be a waste of time. Could be bad luck, but it seems to have the opposite effect. It panic'd after a few minutes (details below), while up to now it used to run many hours before it panic'd. Maurice panic: trap Stopped at Debugger+0x4: ret zero,(ra) RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND *15298 27518 17937 0 3 0x4006 netio cat 27518 22909 17937 0 3 0x4086 pause sh 22909 12217 17937 0 3 0x4086 pause sh 12217 9940 17937 0 3 0x4086 wait make 9940 13807 17937 0 3 0x4086 pause sh 13807 20226 17937 0 3 0x4086 wait make 20226 1148 17937 0 3 0x4086 pause sh 1148 17567 17937 0 3 0x4086 wait make 17567 17937 17937 0 3 0x4086 pause sh 17937 6783 17937 0 3 0x4086 wait make 6783 15405 6783 0 3 0x4086 pause ksh 15405 23322 15405 1000 3 0x4086 pause ksh 23322 9574 9574 1000 3 0x184 select sshd 9574918 9574 0 3 0x4184 netio sshd 19985 1 19985 1000 3 0x4086 ttyin ksh 8836 1 8836 0 30x84 select cron 24506 1 24506 0 3 0x40184 select sendmail 918 1918 0 30x84 select sshd 430 1430 0 3 0x184 select inetd 20290 0 0 0 30x100284 nfsidl nfsio 12060 0 0 0 30x100284 nfsidl nfsio 21537 0 0 0 30x100284 nfsidl nfsio 3000 0 0 0 30x100284 nfsidl nfsio 8612 1 8612 0 30x84 poll ntpd 24754 1 24754 83 3 0x184 poll ntpd 12430 13175 13175 73 3 0x184 poll syslogd 13175 1 13175 0 30x8c netio syslogd 8 0 0 0 30x100204 crypto_wa crypto 7 0 0 0 30x100204 aiodoned aiodoned 6 0 0 0 20x100204 update 5 0 0 0 30x100204 cleanercleaner 4 0 0 0 30x100204 reaper reaper 3 0 0 0 30x100204 pgdaemon pagedaemon 2 0 0 0 30x100204 pftm pfpurge 1 0 1 0 3 0x4084 wait init 0 -1 0 0 3 0x80204 scheduler swapper ddb trace Debugger(6, fc85ba38, 0, 0, fe00056df610, 8) at Debugger+0x4 panic(fc837e04, 1, 0, 2, fe00056df760, fe00056dfa2c) at panic+0 x130 trap(?, ?, 0, 2, fe00056df760, fe00056dfa2c) at trap+0x55c XentMM(?, ?, 0, 2, ?, fe00056dfa2c) at XentMM+0x20 pmap_activate(fc8e23a0, fe00056dc000, fc7cb3e9, 1400, 0, ff fffe00056dfa2c) at pmap_activate+0x24 cpu_switch(?, ?, fc7cb3e9, 1400, 0, fe00056dfa2c) at cpu_switch+0xfc cpu_switch(?, ?, fc7cb3e9, 1400, 0, fe00056dfa2c) at cpu_switch+0xfc cpu_switch(?, ?, fc7cb3e9, 1400, 0, fe00056dfa2c) at cpu_switch+0xfc cpu_switch(?, ?, fc7cb3e9, 1400, 0, fe00056dfa2c) at cpu_switch+0xfc cpu_switch(?, ?, fc7cb3e9, 1400, 0, fe00056dfa2c) at cpu_switch+0xfc cpu_switch(?, ?, fc7cb3e9, 1400, 0, fe00056dfa2c) at cpu_switch+0xfc this last line keeps repeating
Re: OpenBSD/alpha Status
On Monday 16 April 2007 14:14, Maurice Janssen wrote: I just thought of something which might be worth a try on systems that show the bug during system builds; use nice(1) to lower the build priority. It's a long shot, and I haven't tried it, but it *might* be a useful work around. Then again, it might be a waste of time. Could be bad luck, but it seems to have the opposite effect. It panic'd after a few minutes (details below), while up to now it used to run many hours before it panic'd. Damn. It didn't work but it was a long shot to begin with. At least we know timing/priority does affect when/how quickly the bug surfaces. Just out of curiosity, what exact command did you run to get the results you posted. Was it something like this: # cd /usr/src/sys/arch/alpha/conf # config GENERIC # cd ../compile/GENERIC # make clean make depend # nice make ? I think I'll dust off one the alphas and give this another shot. At the moment, I've got far too much hair which is in dire need of being pulled out in frustration... ;-) -jcr
Re: OpenBSD/alpha Status
J.C. Roberts wrote: On Monday 16 April 2007 14:14, Maurice Janssen wrote: I just thought of something which might be worth a try on systems that show the bug during system builds; use nice(1) to lower the build priority. It's a long shot, and I haven't tried it, but it *might* be a useful work around. Then again, it might be a waste of time. Could be bad luck, but it seems to have the opposite effect. It panic'd after a few minutes (details below), while up to now it used to run many hours before it panic'd. Hm, this could point to violated hardware specifications, memory cells that aren't used fast enough and thus not auto-refreshed in time. I presume the Alpha-bug is OpenBSD-only so it's definitely not a hardware problem? Could be that OpenBSD uses certain parts not often enough. Slow down the clocks to see if it's in that direction? And if so, start reading the datasheets... If someone in The Netherlands is really interested I can provide 433 and 500MHz Miata's, we also have an original DEC Alpha AXP development board available, I presume with a 166MHz 21064, boots via Ethernet with bootp. Ethernet, yes the original version, we have a DEC Ethernet-BNC adapter for it too. +++chefren
Re: OpenBSD/alpha Status
On Monday, April 16, 2007 at 15:17:32 -0700, J.C. Roberts wrote: On Monday 16 April 2007 14:14, Maurice Janssen wrote: Could be bad luck, but it seems to have the opposite effect. It panic'd after a few minutes (details below), while up to now it used to run many hours before it panic'd. Damn. It didn't work but it was a long shot to begin with. At least we know timing/priority does affect when/how quickly the bug surfaces. Just out of curiosity, what exact command did you run to get the results you posted. Was it something like this: # cd /usr/src/sys/arch/alpha/conf # config GENERIC # cd ../compile/GENERIC # make clean make depend # nice make ? The kernel was built a few days ago. What I did before this panic was: boot # rm -rf /usr/obj/* # cd /usr/src # make obj # cd /usr/src/etc env DESTDIR=/ make distrib-dirs # cd /usr/src # nice -n 20 make build After about 10 minutes, it paniced. /usr/src and /usr/obj are nfs mounts. BTW: the memory tests (as suggested by Siegbert) didn't show any LLSC errors. # dmesg [ using 536000 bytes of bsd ELF symbol table ] consinit: using prom console Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2006 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 4.0-stable (GENERIC) #0: Fri Apr 13 05:15:48 CEST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/alpha/compile/GENERIC DEC 3000 - M300X, 175MHz 8192 byte page size, 1 processor. total memory = 67108864 (65536K) (2097152 reserved for PROM, 65011712 used by OpenBSD) avail memory = 49037312 (47888K) using 793 buffers containing 6496256 bytes (6344K) of memory mainbus0 (root) cpu0 at mainbus0: ID 0 (primary), 21064-1 (pass 3) tcasic0 at mainbus0 tc0 at tcasic0: 12.5 MHz clock PMAGB-BA (Smart Frame Buffer (HX8)) at tc0 slot 6 offset 0x200 not configd ioasic0 at tc0 slot 5 offset 0x0: slow mode le0 at ioasic0 offset 0xc: address 08:00:2b:97:43:37 le0: 32 receive buffers, 8 transmit buffers scc0 at ioasic0 offset 0x10: console scc1 at ioasic0 offset 0x18 mcclock0 at ioasic0 offset 0x20: mc146818 or compatible AMD79c30 at ioasic0 offset 0x24 not configured tcds0 at tc0 slot 4 offset 0x0: TurboChannel Dual SCSI (baseboard) tcds0: fast mode set for chip 0 asc0 at tcds0 chip 0: NCR53C94, 25MHz, SCSI ID 7 scsibus0 at asc0: 8 targets sd0 at scsibus0 targ 0 lun 0: DEC, RZ26L (C) DEC, 442D SCSI2 0/direct fixed sd0: 1001MB, 3117 cyl, 8 head, 82 sec, 512 bytes/sec, 2050860 sec total sd1 at scsibus0 targ 3 lun 0: DEC, RZ26L (C) DEC, 442D SCSI2 0/direct fixed sd1: 1001MB, 3117 cyl, 8 head, 82 sec, 512 bytes/sec, 2050860 sec total MAGMA8+2 at tc0 slot 1 offset 0x0 not configured fta0 at tc0 slot 0 offset 0x0fta0: DEC DEFTA TC FDDI DAS Controller fta0: FDDI address 08:00:2b:b0:8b:47, FW=3.00, HW=0, SMT V7.2 fta0: FDDI Port[A] = A (PMD = ANSI Multi-Mode), FDDI Port[B] = B (PMD = ANSI Mu) root on sd0a swap on sd0b rootdev=0x800 rrootdev=0x800 rawdev=0x802
OpenBSD/alpha Status
I could have posted this on the alpha list but I thought I might get a better answer here since that list has very little traffic. OpenBSD/ cats is no longer around and is OpenBSD/alpha on its way out as well? I am not intending to cause any rumors or anything but I do have the opportunity to pick up some alpha machines but I am not going to if the platform is on its way out. I had a couple of cats machines that are doing nothing and I don't want to have alphas in the same boat. Thanks for the info. Bryan
Re: OpenBSD/alpha Status
On Sun, Apr 15, 2007 at 11:40:48AM -0700, Bryan Vyhmeister wrote: I could have posted this on the alpha list but I thought I might get a better answer here since that list has very little traffic. OpenBSD/ cats is no longer around and is OpenBSD/alpha on its way out as well? I am not intending to cause any rumors or anything but I do have the opportunity to pick up some alpha machines but I am not going to if the platform is on its way out. I had a couple of cats machines that are doing nothing and I don't want to have alphas in the same boat. Thanks for the info. While I am not a developer and not privy to Theo's thoughts, I did notice quite a bit of work on the alpha (some developer mentioned the switch to gcc 3). On the other hand, there seems to be a 'the alpha bug' around. I don't think it's solved yet, and it's been around for a long time. Apparently, it causes random crashes. Joachim -- PotD: security/libtasn1 - Abstract Syntax Notation One structure parser library
Re: OpenBSD/alpha Status
On Apr 15, 2007, at 12:27 PM, Joachim Schipper wrote: On Sun, Apr 15, 2007 at 11:40:48AM -0700, Bryan Vyhmeister wrote: I could have posted this on the alpha list but I thought I might get a better answer here since that list has very little traffic. OpenBSD/ cats is no longer around and is OpenBSD/alpha on its way out as well? I am not intending to cause any rumors or anything but I do have the opportunity to pick up some alpha machines but I am not going to if the platform is on its way out. I had a couple of cats machines that are doing nothing and I don't want to have alphas in the same boat. Thanks for the info. While I am not a developer and not privy to Theo's thoughts, I did notice quite a bit of work on the alpha (some developer mentioned the switch to gcc 3). That is a good sign. Another reason to keep it around is that alpha machines were commercially produced which the cats machines were just evaluation boards. Big difference. I had a very hard time finding the two cats boards I came up with. Alpha systems are much easier to come by and are a much more powerful architecture. On the other hand, there seems to be a 'the alpha bug' around. I don't think it's solved yet, and it's been around for a long time. Apparently, it causes random crashes. I was not aware of this bug. That is unfortunate. Hopefully this might be resolved at some point. Bryan
Re: OpenBSD/alpha Status
On Sun, Apr 15, 2007 at 02:30:02PM -0700, Bryan Vyhmeister wrote: On Apr 15, 2007, at 12:27 PM, Joachim Schipper wrote: On Sun, Apr 15, 2007 at 11:40:48AM -0700, Bryan Vyhmeister wrote: I could have posted this on the alpha list but I thought I might get a better answer here since that list has very little traffic. OpenBSD/ cats is no longer around and is OpenBSD/alpha on its way out as well? I am not intending to cause any rumors or anything but I do have the opportunity to pick up some alpha machines but I am not going to if the platform is on its way out. I had a couple of cats machines that are doing nothing and I don't want to have alphas in the same boat. Thanks for the info. While I am not a developer and not privy to Theo's thoughts, I did notice quite a bit of work on the alpha (some developer mentioned the switch to gcc 3). That is a good sign. Another reason to keep it around is that alpha machines were commercially produced which the cats machines were just evaluation boards. Big difference. I had a very hard time finding the two cats boards I came up with. Alpha systems are much easier to come by and are a much more powerful architecture. Yes, I think that was one of the reasons to can the cats architecture: it had pretty much done what it was intended to do, provide a springboard for zaurus and lately landisk, and there just aren't many machines around. On the other hand, there seems to be a 'the alpha bug' around. I don't think it's solved yet, and it's been around for a long time. Apparently, it causes random crashes. I was not aware of this bug. That is unfortunate. Hopefully this might be resolved at some point. I do hope so; but I might be wrong there. I've never owned an Alpha, an don't think it's very likely I'll acquire one in the nearish future, so I haven't followed too closely. Joachim -- TFMotD: hunt (6) - a multi-player multi-terminal game
Re: OpenBSD/alpha Status
Hi, On the other hand, there seems to be a 'the alpha bug' around. I don't think it's solved yet, and it's been around for a long time. Apparently, it causes random crashes. only on some machines. I was not aware of this bug. That is unfortunate. Hopefully this might be resolved at some point. I do hope so; but I might be wrong there. I've never owned an Alpha, an don't think it's very likely I'll acquire one in the nearish future, so I haven't followed too closely. Should be still there, didn't follow it to closely but didn't get any info about it being resolved. If somebody would've found it there'd likely been a post to the alpha list since this mystery is around for years. Have two machines down in the basement whicht have it and one which doesn't, travels with swapping the CPU-Boards as far as I could test it. But being honest I didn't turn them on in months and couldn't go into detail since to much other work had to be done. Just shooting in the blue it seemed to be something with MP and LLC, maybe putting CPUs with not working SMP Elements into SP machines and sometimes it wrecks the cache. Found only one guy though which had some knowledge about the Hardware there and he gave up on it after he got a faster CPU module which didn't show the LLC errors anymore. since SMP is slowly moving ahead, maybe something shows up... ;) -sm
Re: OpenBSD/alpha Status
On Apr 15, 2007, at 3:08 PM, Siegbert Marschall wrote: Hi, On the other hand, there seems to be a 'the alpha bug' around. I don't think it's solved yet, and it's been around for a long time. Apparently, it causes random crashes. only on some machines. Any idea if it surfaces on dual processor CS20 machines? I have the opportunity to pick up three dual 833 Mhz CS20 machines. Bryan
Re: OpenBSD/alpha Status
On Apr 15, 2007, at 2:50 PM, Joachim Schipper wrote: On Sun, Apr 15, 2007 at 02:30:02PM -0700, Bryan Vyhmeister wrote: That is a good sign. Another reason to keep it around is that alpha machines were commercially produced which the cats machines were just evaluation boards. Big difference. I had a very hard time finding the two cats boards I came up with. Alpha systems are much easier to come by and are a much more powerful architecture. Yes, I think that was one of the reasons to can the cats architecture: it had pretty much done what it was intended to do, provide a springboard for zaurus and lately landisk, and there just aren't many machines around. I think you meant armish rather than landisk but the point is well taken. The cats boards were difficult to deal with. On the other hand, there seems to be a 'the alpha bug' around. I don't think it's solved yet, and it's been around for a long time. Apparently, it causes random crashes. I was not aware of this bug. That is unfortunate. Hopefully this might be resolved at some point. I do hope so; but I might be wrong there. I've never owned an Alpha, an don't think it's very likely I'll acquire one in the nearish future, so I haven't followed too closely. I have two alpha machines right now and I haven't touched either one in a while. One is a PC164LX machine as I recall and I have no idea if it would work or not. I should try it. The other is an AlphaServer 4100 which I picked up and never pulled out of the crate. After I bought it, I realized that the power consumption was going to be ridiculous and so I have never used it. I think it might even be 230v which made it even harder to deal with. I am not going to give that crazy thing its own circuit with the ridiculous California power rates. Bryan
Re: OpenBSD/alpha Status
* Bryan Vyhmeister [EMAIL PROTECTED] [2007-04-16 00:32]: On Apr 15, 2007, at 3:08 PM, Siegbert Marschall wrote: Hi, On the other hand, there seems to be a 'the alpha bug' around. I don't think it's solved yet, and it's been around for a long time. Apparently, it causes random crashes. only on some machines. Any idea if it surfaces on dual processor CS20 machines? I have the opportunity to pick up three dual 833 Mhz CS20 machines. all alphas, but it seems to happen more often on miatas than on cs20s. my cs20 is pretty stable. the cs20 is probably the nicest alpha we support. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: OpenBSD/alpha Status
Don't lament, 1. There is a potential fix for the alpha bug coming up 2. The cats boards are junk, you didn't want them anyways, As reported by miod@ Make it clear that it was the hardware which turned out to be unreliable, not the software (and after having a cats board catch fire here, I dare you to prove me wrong... how can a I-need-no-watts-really board catch fire?) Bryan Vyhmeister [EMAIL PROTECTED] wrote: I could have posted this on the alpha list but I thought I might get a better answer here since that list has very little traffic. OpenBSD/ cats is no longer around and is OpenBSD/alpha on its way out as well? I am not intending to cause any rumors or anything but I do have the opportunity to pick up some alpha machines but I am not going to if the platform is on its way out. I had a couple of cats machines that are doing nothing and I don't want to have alphas in the same boat. Thanks for the info. Bryan -- It's beneficial to your health to try and believe a few impossible things before breakfast. -- Lewis Carroll
Re: OpenBSD/alpha Status
On Apr 15, 2007, at 3:48 PM, Henning Brauer wrote: all alphas, but it seems to happen more often on miatas than on cs20s. my cs20 is pretty stable. the cs20 is probably the nicest alpha we support. The CS20 does seem to be a pretty nice machine. I noticed that there is one obvious CS20 in the newrack.jpg picture. Is power consumption pretty high on these? Bryan
