But the mailing list is up!
Al7amdulilah al rubb al 'alameen.
Sampsa
On 13 Aug 2012, at 05:40, Oleg Safiullin wrote:
On 08/09/2012 07:02 PM, Johnny Billquist wrote:
On 2012-08-09 09:05, Mark Benson wrote:
On 8 Aug 2012, at 23:56, Johnny Billquist wrote:
On 2012-08-08 15:42, Bob Armstrong wrote:
I notice that the bridge is down again this morning. Is it just me?
Nope. I noticed that Psilo was down, but only now did I recheck and as psilo was back up, I restarted the bridge.
I've restarted mine several times and I'm still not getting anything outside my LAN. :\
Hum. So psilo rebooted again a few hours ago... Restarted the bridge right now.
Johnny
bridge is down again :)
--
NCP SHO ACT NOD
Active nodes summary as of 13-AUG-12 04:38:59
Executor node = 1.13 (MIM)
State = On, Identification = "RSX system at Update, Sweden"
Remote Active Next
Node State Links Delay Circuit Node
8.400 (GORVAX) 0 4
18.1 (GATE18) 0 4
18.101 (RENO) 0 4
52.555 (LABVAX) 0 4
52.556 (KUHAVX) 0 4
On 08/09/2012 07:02 PM, Johnny Billquist wrote:
On 2012-08-09 09:05, Mark Benson wrote:
On 8 Aug 2012, at 23:56, Johnny Billquist wrote:
On 2012-08-08 15:42, Bob Armstrong wrote:
I notice that the bridge is down again this morning. Is it just me?
Nope. I noticed that Psilo was down, but only now did I recheck and as psilo was back up, I restarted the bridge.
I've restarted mine several times and I'm still not getting anything outside my LAN. :\
Hum. So psilo rebooted again a few hours ago... Restarted the bridge right now.
Johnny
bridge is down again :)
--
>NCP SHO ACT NOD
Active nodes summary as of 13-AUG-12 04:38:59
Executor node = 1.13 (MIM)
State = On, Identification = "RSX system at Update, Sweden"
Remote Active Next
Node State Links Delay Circuit Node
8.400 (GORVAX) 0 4
18.1 (GATE18) 0 4
18.101 (RENO) 0 4
52.555 (LABVAX) 0 4
52.556 (KUHAVX) 0 4
>
Hi guys,
Anyone experiencing DECNET/HECNET connecting problems at the moment?
I noticed that http://www.update.uu.se/~bqt/hecnet.html is not currently responding.
It might be the setup at this end, but I've tried most things although I do appear to have a link through to psilo.update.uu.se:
192.168.1.127 4711 4711 130.238.19.25 4711 3 0
Non-authoritative answer:
psilo.update.uu.se canonical name = Psilocybe.update.uu.se.
Name: Psilocybe.update.uu.se
Address: 130.238.19.25
It could quite possibly be a problem at this end, given that SLAVE has not been up for a while...
Regards, Mark
Yeah, I think I had an older copy. Pulled the latest down and it built cleanly other than the MAX redefinition warning and the "openbsd thinks you're a moron for using strcpy()" warning.
All appears well as Sampsa can talk to HECnet via a bridge to me tunneled over OpenVPN. Ugly, but functional. :)
-brian
On 8/10/2012 6:54 AM, Johnny Billquist wrote:
Brian, could you verify that you have the latest version? I did some work to try and get rid of warnings a while back, and even though I'm sure some issues might be because of 64 bit issues, I would have expected some of the warnings you reported to have been fixed already...
Johnny
On 2012-08-09 21:00, Brian Hechinger wrote:
I'm trying to get the bridge built on OpenBSD 5.1 64-bit but it keep
segfaulting. Anyone ever get this working?
# cc -O2 -Wall -o bridge bridge.c -lpcap
bridge.c:65:1: warning: "MAX" redefined
In file included from /usr/include/netdb.h:90,
from bridge.c:32:
/usr/include/sys/param.h:191:1: warning: this is the location of the
previous definition
bridge.c: In function 'add_bridge':
bridge.c:241: warning: implicit declaration of function 'inet_aton'
bridge.c:263: warning: format '%d' expects type 'int', but argument 2
has type 'char *'
bridge.c:263: warning: format '%d' expects type 'int', but argument 3
has type 'char *'
bridge.c: In function 'add_service':
bridge.c:276: warning: format '%s' expects type 'char *', but argument 3
has type 'struct BRIDGE *'
bridge.c: In function 'dump_data':
bridge.c:524: warning: implicit declaration of function 'inet_ntoa'
bridge.c:531: warning: format '%s' expects type 'char *', but argument 4
has type 'int'
bridge.c: In function 'main':
bridge.c:564: warning: unused variable 'port'
bridge.c:561: warning: unused variable 'len'
/tmp//cc69aRp2.o(.text+0x934): In function `add_bridge':
: warning: strcpy() is almost always misused, please use strlcpy()
# cp bridge /var/bridge/
# cd /var/bridge/
# ./bridge 4711
Adding router ''local''. 00000000:0
Adding router ''sampsa''. 0afc2a0a:4711
Adding DECnet bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding DECnet bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Adding LAT bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding LAT bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Host table:
Segmentation fault (core dumped)
-brian
What I meant is that the os fit was done in firmware. Not, like the VAX, where the instruction set was designed to match demands from the os. IIRC the queue instructions aren't part of the Alpha instruction set.
On or off topic? It's Digital Lore, right :-)
-----Original Message-----
From: Phil Mendelsohn <phil at rephil.org>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 16:29:00
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
On 10/08/2012 3:10 PM, Paul_Koning at Dell.com wrote:
On Aug 10, 2012, at 4:07 PM, <hvlems at zonnet.nl>
wrote:
Correct, Windows started off on four platforms so the intimacy of VMS with the VAX was just not there. But VMS was a lot farther away from Alpha too.
I don't think that's accurate.
Most operating systems are not closely tied to a specific platform. And in the case of VMS, the Alpha architecture had some specific attributes that were meant to make porting VMS easier.
I agree. Alpha architecture was done with a posteriori and first-hand
internal knowledge of VMS and where it was headed / what it's customers
needed. I had a pre-release AXP Architecture Handbook which would
confirm, if I could lay my hands on the tree ware.
But this is OT, I suppose.
Phil M
--
"Worry is a misuse of imagination." -- Some Guy Called Dan Zadra
On 10/08/2012 3:10 PM, Paul_Koning at Dell.com wrote:
On Aug 10, 2012, at 4:07 PM, <hvlems at zonnet.nl>
wrote:
Correct, Windows started off on four platforms so the intimacy of VMS with the VAX was just not there. But VMS was a lot farther away from Alpha too.
I don't think that's accurate.
Most operating systems are not closely tied to a specific platform. And in the case of VMS, the Alpha architecture had some specific attributes that were meant to make porting VMS easier.
I agree. Alpha architecture was done with a posteriori and first-hand internal knowledge of VMS and where it was headed / what it's customers needed. I had a pre-release AXP Architecture Handbook which would confirm, if I could lay my hands on the tree ware.
But this is OT, I suppose.
Phil M
--
"Worry is a misuse of imagination." -- Some Guy Called Dan Zadra
On 08/10/2012 05:21 PM, Paul_Koning at Dell.com wrote:
Try adding -fomit-frame-pointer; that will free up a register, which
is pretty important on register-starved architectures such as x86 and
x86_64. (depending on your -O<n> level, it might already be turned on
though)
According to the manpage, that's already the default as of GCC V4.6. I'm currently doing some tests with GCC 4.7.0, the latest release.
Cool. But...the default? With no frame pointers, debugging is pretty
difficult. I assume it's only enabled with -O[n], and disabled with
-g[xxx]?
No, but you can enable frame pointers if you need them. Depending on the debugger, you may not need them. For example, MIPS seems to have them in theory, but in practice there is no reason to use them (except if a function calls alloca() in which case GCC forces a frame pointer for that one function).
Interesting! I didn't know that. Thanks for the info!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Aug 10, 2012, at 5:06 PM, Dave McGuire wrote:
On 08/10/2012 04:29 PM, Paul_Koning at Dell.com wrote:
Try adding -fomit-frame-pointer; that will free up a register, which
is pretty important on register-starved architectures such as x86 and
x86_64. (depending on your -O<n> level, it might already be turned on
though)
According to the manpage, that's already the default as of GCC V4.6. I'm currently doing some tests with GCC 4.7.0, the latest release.
Cool. But...the default? With no frame pointers, debugging is pretty
difficult. I assume it's only enabled with -O[n], and disabled with
-g[xxx]?
No, but you can enable frame pointers if you need them. Depending on the debugger, you may not need them. For example, MIPS seems to have them in theory, but in practice there is no reason to use them (except if a function calls alloca() in which case GCC forces a frame pointer for that one function).
paul
