HECnet March 2013

hecnet@lists.dfupdate.se

30 participants
319 discussions

RSX-11M v4.1 SYSGEN - OK, I give up - what am I doing wrong?

by jeep＠scshome.net

(14) Highest Interrupt Vector. The default is zero (0). I am pretty sure that must be changed to reflect the hardware installed. -Steve -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Johnny Billquist Sent: Monday, March 11, 2013 17:31 To: hecnet at Update.UU.SE Cc: Bob Armstrong Subject: Re: [HECnet] RSX-11M v4.1 SYSGEN - OK, I give up - what am I doing wrong? On 2013-03-11 21:37, Bob Armstrong wrote: I'm trying to SYSGEN an 11M 4.1 system from the distribution on RL01s using a dual RL PDP-11/23+ (which is simh in this case, so I know the hardware works). I'm letting it autoconfigure and I'm taking pretty much the default answer for everything. The build seems to go without error and yet the resulting system crashes as soon as it boots. I give up - what am I doing wrong? Somebody give me a clue, please! The simh log is attached. When RSX is building the system, it at one point creates the new system image to run, called [1,54]RSX11M.SYS. The relevant line is PIP RSX11M.SYS/CO/NV/BL:498.=RSX11M.TSK Now, your machine only have 128kW. That is 256 kByte. Of this, 8 kByte goes away because of the I/O page. Leaving 248 kByte. This is 496 disk blocks. It *might* be that your disk file is too big, making the system assume that it can place stuff in memory that don't exist. RSX11M.SYS is pretty close to just a memory dump. Try creating a new RSX11M.SYS, which is a bit smaller, and then rerun the VMR command, and try booting that file instead and see if that helps? Johnny

11 years, 8 months

RSX-11M v4.1 SYSGEN - OK, I give up - what am I doing wrong?

by b4＠gewt.net

On 11 Mar 2013, at 16:37, "Bob Armstrong" <bob at jfcl.com> wrote: I'm trying to SYSGEN an 11M 4.1 system from the distribution on RL01s using a dual RL PDP-11/23+ (which is simh in this case, so I know the hardware works). I'm letting it autoconfigure and I'm taking pretty much the default answer for everything. The build seems to go without error and yet the resulting system crashes as soon as it boots. I give up - what am I doing wrong? Somebody give me a clue, please! The simh log is attached. Thanks, Bob Armstrong <install.log> Oops, looks like my email server was misconfigured and my message got lost. What version of simh?

11 years, 8 months

RSX-11M v4.1 SYSGEN - OK, I give up - what am I doing wrong?

by bqt＠softjar.se

On 2013-03-11 21:37, Bob Armstrong wrote: I'm trying to SYSGEN an 11M 4.1 system from the distribution on RL01s using a dual RL PDP-11/23+ (which is simh in this case, so I know the hardware works). I'm letting it autoconfigure and I'm taking pretty much the default answer for everything. The build seems to go without error and yet the resulting system crashes as soon as it boots. I give up - what am I doing wrong? Somebody give me a clue, please! The simh log is attached. When RSX is building the system, it at one point creates the new system image to run, called [1,54]RSX11M.SYS. The relevant line is >PIP RSX11M.SYS/CO/NV/BL:498.=RSX11M.TSK Now, your machine only have 128kW. That is 256 kByte. Of this, 8 kByte goes away because of the I/O page. Leaving 248 kByte. This is 496 disk blocks. It *might* be that your disk file is too big, making the system assume that it can place stuff in memory that don't exist. RSX11M.SYS is pretty close to just a memory dump. Try creating a new RSX11M.SYS, which is a bit smaller, and then rerun the VMR command, and try booting that file instead and see if that helps? Johnny

11 years, 8 months

RSX-11M v4.1 SYSGEN - OK, I give up - what am I doing wrong?

by bob＠jfcl.com

I'm trying to SYSGEN an 11M 4.1 system from the distribution on RL01s using a dual RL PDP-11/23+ (which is simh in this case, so I know the hardware works). I'm letting it autoconfigure and I'm taking pretty much the default answer for everything. The build seems to go without error and yet the resulting system crashes as soon as it boots. I give up - what am I doing wrong? Somebody give me a clue, please! The simh log is attached. Thanks, Bob Armstrong

11 years, 8 months

Announcing a new TCP/IP for RSX

by wilson＠dbit.com

From: Johnny Billquist <bqt at softjar.se> Ok. The time is drawing near to actually get my new TCP/IP for RSX out the door. So I'm looking for possible interested people who would like to try things out. This is like field testing, so expect there to be some issues, and helpful feedback would be appreciated. Awesome!!! Yes please. It's great that you've taken it so far. The API is not compatible with any Unix like one at this time, Excellent. (Don't get me started!) Nice work -- that's really cool! John Wilson D Bit

11 years, 8 months

Announcing a new TCP/IP for RSX

by bqt＠softjar.se

Ok. The time is drawing near to actually get my new TCP/IP for RSX out the door. So I'm looking for possible interested people who would like to try things out. This is like field testing, so expect there to be some issues, and helpful feedback would be appreciated. The state right now is that the protocols seems to work fine. They have been tested by myself for many years, and the last week a first external person started testing, which means I'm right now trying to get a distribution kit together that is usable. What is in there? Nice of you to ask. Of course the basic protocols - ARP, IP, ICMP, UDP and TCP. In addition, there are libraries for using this from MACRO-11 and from high level languages (the one tested extensively so far is BASIC+2, but libraries for F77 and C will also be in there). Additional suggestions are welcome. In addition, a few example pieces exist, such as a web server, TFTP daemon, RWHOD daemon, IRC client, and an IRC robot, and a few well known TCP services (ECHO, SINK, DAYTIME and QUOTD). Additionally I am working on FTP right now (both server and client), and both a TELNET server and client is planned, but will take a little more time. This TCP/IP requires a RSX-11M-PLUS system. It has only been tested on V4.6, but I believe it should work ok on any V4. It might also work on previous versions, but there are possible issues. Let me know if you want to test it on something like that. The package will not work on 11M. Mostly because some pieces really need the split I/D space. It would be possible to work around that, but it would be a rather big project, and unless someone actually needs it enough to pay for that work, it will not happen. The whole system runs as device drivers and one ACP. It can coexist with DECnet, or use the XE: device driver for Unibus machines. Qbus machines without DECnet is not possible right now, but is something I will address eventually. The whole TCP/IP takes little resources. It uses a small amount of pool, and a little CPU, but not really noticeable under normal operation. It creates its own memory region which it uses for most memory consumption. The API is not compatible with any Unix like one at this time, although adding such a layer is definitely possible, and might be something I'll do if enough people want to waste the memory. However, the actual API existing is really easy to use, and very versatile. There is a reference system online. You can telnet to mim.update.uu.se (or set host to MIM::), and login with guest/guest if you want to look at it (emulated 11/74, so this address does not point at the TCP/IP stack of RSX). You can also point your web browser at madame.update.uu.se, which is the RSX systems web server. So, please contact me if this interest you. My address is bqt at softjar.se. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

11 years, 8 months

Vt100 tester

by sampsa＠mac.com

On 7 Mar 2013, at 15:46, Johnny Billquist <bqt at softjar.se> wrote: Ah. That is another issue. If your terminal (xterm in this case) is configured to use UTF-8, then you will not work well against a machine that do not use UTF-8 (it's a mess). Johnny Oh god, just had a horrid flashback to calling BBSes in Finland in the early 90s with people using {}\| for etc. In Portugal they just gave up and used apostrophes for accents, acute goes before the letter, grave goes after. Wait or is it the other way around? sampsa <sampsa at mac.com> mobile +961 788 10537

11 years, 8 months

Vt100 tester

by bqt＠softjar.se

On 2013-03-07 12:45, Jordi Guillaumes i Pons wrote: Al 07/03/13 00:59, En/na Johnny Billquist ha escrit: I hope you are aware of the fact that telnet by default is not 8-bit clean. :-) Well, sort of. The same xterm configuration displays (and inputs) 8 bit characters if I telnet to a linux box... That is probably because at connection time, telnets negotiate the capabilities between them. You can get very different behavior depending on what you have on each side. I think it is related to the usage of UTF-8 in the unix machine... I have reconfigured my ubuntu laptop to use ISO-8859-15 and it now _seems_ to work. Ah. That is another issue. If your terminal (xterm in this case) is configured to use UTF-8, then you will not work well against a machine that do not use UTF-8 (it's a mess). Johnny

11 years, 8 months

Vt100 tester

by system＠TMESIS.COM

Cory Smelosky <b4 at gewt.net> writes: On 6 Mar 2013, at 21:48, "Brian Schenkenberger, VAXman-" = <system at TMESIS.COM> wrote: "Jerome H. Fine" <jhfinedp3k at compsys.to> writes: =20 {...snip...} Seriously, has anyone ever successfully developed a virus for a VMS system? I think I heard that there was a yearly contest to see if anyone could compromise a VMS system and it failed every year. =20 A few (2-3) years ago, there was a reported security elevation exploit = that involves a stupid buffer contamination exploit in = SMG$READ_COMPOSED_LINE and any VMS utility that employed it and that was installed with = privileges. It turned out that the INSTALL utility could be exploited. It was NOT = simple to do but it could be done. I implemented a weaponized PoC to exploit = the security vulnerabity. It was, happily, quickly addressed. =20 =20 There was also another exploit wherein one could send, via VMS mail, = the equivalent of an attachment using /FOREIGN. If the attachment was = created with SUBMIT-ON-CLOSE and the file was read by a privileged user, all = bets were off. Again, this was quickly subdued before it became a = widespread exploit. That, IIRC, was about a decade ago. =20 Not a bad record at one vulnerability per decade. ;) The only real = success stories of infiltrating VMS all stemmed from social engineering and = not, to my knowledge, from security holes in the OS. I was recently watching a DEFCON talk about breaking in to VMS=85no = remote vulnerabilities were found. They all required human stupidity or = an existing account. http://www.youtube.com/watch?v=3DXf7gVma6_3g The vulnerability I spoke to WRT the SMG$READ_COMPOSED_LINE is discussed in this video; however, these VMS neophytes (and I still believe that the fellow discussing the SMG$ issue was given information about this from a disgruntled VMS engineer as he clearly does NOT know what he is speaking about) were tutored by others. The nonsense about using a logical name still makes me spew a mouthful of coffee, assuming I'm drinking it, upon my screen and keyboard when I watch that video you've linked. To exploit the security hole (now patched) required self-modifying Alpha code. It's not very likely that these guys had the wherewithal to accomplish such a feat with their neanderthal approach to the subject they presented. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG Well I speak to machines with the voice of humanity.

11 years, 8 months

Vt100 tester

by jg＠jordi.guillaumes.name

Al 07/03/13 00:59, En/na Johnny Billquist ha escrit: I hope you are aware of the fact that telnet by default is not 8-bit clean. :-) Well, sort of. The same xterm configuration displays (and inputs) 8 bit characters if I telnet to a linux box... I think it is related to the usage of UTF-8 in the unix machine... I have reconfigured my ubuntu laptop to use ISO-8859-15 and it now _seems_ to work.

11 years, 8 months

← Newer
1
...
17
18
19
20
21
22
23
...
32
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet March 2013