From lennert at vanalboom.org Fri Feb 15 08:32:04 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Fri, 15 Feb 2013 14:32:04 +0100 Subject: [Simh] VAX and disk device size oddness Message-ID: <20130215133203.GE26627@ziff.soleus.nu> Hello, I just started playing with a simh vax again. Built the 3.9 vax binary (on linux/powerpc), and it works fine. Odd thing though: I cannot use RAUSER, it seems. I tried the following line: SET RQ1 RAUSER=20000 Which should result in a 20GB disk. No dice though: simh claims "invalid parameter". I tried lowering the size to 10000, 5000, ... no difference. I then tried replacing the RAUSER by RA92, which should be supported and have a ~8GB size. This was accepted. However, from the OS (VMS 7.3), after an INIT/ERASE the disk reports 2940951 blocks which is somewhat under 1.5GB. The RQ0 RA90 reports the expected 2376153 blocks or somewhat under 1.2GB. Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this what is causing this? If yes, can I work around it? I'd prefer something bigger than 1.5GB :-) Thanks, Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bqt at softjar.se Fri Feb 15 09:51:08 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 15 Feb 2013 15:51:08 +0100 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <20130215133203.GE26627@ziff.soleus.nu> References: <20130215133203.GE26627@ziff.soleus.nu> Message-ID: <511E4B5C.70704@softjar.se> Hi. On 2013-02-15 14:32, Lennert Van Alboom wrote: > Hello, > > > I just started playing with a simh vax again. Built the 3.9 vax binary (on > linux/powerpc), and it works fine. > > Odd thing though: I cannot use RAUSER, it seems. I tried the following line: > > SET RQ1 RAUSER=20000 > > Which should result in a 20GB disk. No dice though: simh claims "invalid > parameter". I tried lowering the size to 10000, 5000, ... no difference. > > I then tried replacing the RAUSER by RA92, which should be supported and have a > ~8GB size. This was accepted. However, from the OS (VMS 7.3), after an > INIT/ERASE the disk reports 2940951 blocks which is somewhat under 1.5GB. The > RQ0 RA90 reports the expected 2376153 blocks or somewhat under 1.2GB. Don't know where you got that an RA92 would be 8G. It is really just 1.4G. The largest RA drives ever manufactured were the RA73 at 2G. > Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this what is > causing this? If yes, can I work around it? I'd prefer something bigger than > 1.5GB :-) RAUSER is what you need. I don't think simh even knows of the RA73... 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 From lennert at vanalboom.org Fri Feb 15 10:40:54 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Fri, 15 Feb 2013 16:40:54 +0100 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <511E4B5C.70704@softjar.se> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> Message-ID: <20130215154054.GF26627@ziff.soleus.nu> On Fri, Feb 15, 2013 at 03:51:08PM +0100, Johnny Billquist wrote: > Hi. > > On 2013-02-15 14:32, Lennert Van Alboom wrote: > >Hello, > > > > > >I just started playing with a simh vax again. Built the 3.9 vax binary (on > >linux/powerpc), and it works fine. > > > >Odd thing though: I cannot use RAUSER, it seems. I tried the following line: > > > >SET RQ1 RAUSER=20000 > > > >Which should result in a 20GB disk. No dice though: simh claims "invalid > >parameter". I tried lowering the size to 10000, 5000, ... no difference. > > > >I then tried replacing the RAUSER by RA92, which should be supported and have a > >~8GB size. This was accepted. However, from the OS (VMS 7.3), after an > >INIT/ERASE the disk reports 2940951 blocks which is somewhat under 1.5GB. The > >RQ0 RA90 reports the expected 2376153 blocks or somewhat under 1.2GB. > > Don't know where you got that an RA92 would be 8G. It is really just > 1.4G. The largest RA drives ever manufactured were the RA73 at 2G. Aha - so what I'm seeing is normal then. Not sure where I got the 8GB number - iirc from some usenet post. Guess I should check numbers before taking them for granted. > >Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this what is > >causing this? If yes, can I work around it? I'd prefer something bigger than > >1.5GB :-) > > RAUSER is what you need. I don't think simh even knows of the RA73... I would, but that doesn't give me decent size disks... after some trial & error it seems like I'm hitting the 2GB barrier. RAUSER=2047 works, RAUSER=2048 fails. I don't suppose I can work around this on a 32bit host system, or can I? Thanks, Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From Mark at infocomm.com Fri Feb 15 10:45:09 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Fri, 15 Feb 2013 07:45:09 -0800 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <20130215154054.GF26627@ziff.soleus.nu> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> <20130215154054.GF26627@ziff.soleus.nu> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> On Friday, February 15, 2013 at 7:41 AM, Lennert Van Alboom wrote: > On Fri, Feb 15, 2013 at 03:51:08PM +0100, Johnny Billquist wrote: > > Hi. > > > > On 2013-02-15 14:32, Lennert Van Alboom wrote: > > >Hello, > > > > > > > > >I just started playing with a simh vax again. Built the 3.9 vax > > >binary (on linux/powerpc), and it works fine. > > > > > >Odd thing though: I cannot use RAUSER, it seems. I tried the following > line: > > > > > >SET RQ1 RAUSER=20000 > > > > > >Which should result in a 20GB disk. No dice though: simh claims > > >"invalid parameter". I tried lowering the size to 10000, 5000, ... no > difference. > > > > > >I then tried replacing the RAUSER by RA92, which should be supported > > >and have a ~8GB size. This was accepted. However, from the OS (VMS > > >7.3), after an INIT/ERASE the disk reports 2940951 blocks which is > > >somewhat under 1.5GB. The > > >RQ0 RA90 reports the expected 2376153 blocks or somewhat under > 1.2GB. > > > > Don't know where you got that an RA92 would be 8G. It is really just > > 1.4G. The largest RA drives ever manufactured were the RA73 at 2G. > > Aha - so what I'm seeing is normal then. Not sure where I got the 8GB > number - iirc from some usenet post. Guess I should check numbers before > taking them for granted. > > > >Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this > > >what is causing this? If yes, can I work around it? I'd prefer > > >something bigger than 1.5GB :-) > > > > RAUSER is what you need. I don't think simh even knows of the RA73... > > I would, but that doesn't give me decent size disks... after some trial & error > it seems like I'm hitting the 2GB barrier. RAUSER=2047 works, RAUSER=2048 > fails. I don't suppose I can work around this on a 32bit host system, or can I? A 32bit kernel should not be a limiting factor since MANY 32bit OS environments have been capable of disk file access to files larger than 2GB for a very long time. You fail to get specific about what OS you are actually using, since several are available which will run on that hardware? Please spell out exactly how you built the simulator you are working with as well? If changes need to be made to naturally support your platform, we can readily add these to the code base. Please pickup the latest code from https://github.com/simh/simh/archive/master.zip and let me know the answers to the above questions and if you still have a problem if you merely: $ mkdir simh $ cd simh $ unzip ../master.zip $ make vax I'm looking forward to your feedback. - Mark Pizzolato From lennert at vanalboom.org Fri Feb 15 11:10:31 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Fri, 15 Feb 2013 17:10:31 +0100 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> <20130215154054.GF26627@ziff.soleus.nu> <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> Message-ID: <20130215161031.GG26627@ziff.soleus.nu> On Fri, Feb 15, 2013 at 07:45:09AM -0800, Mark Pizzolato - Info Comm wrote: > > > RAUSER is what you need. I don't think simh even knows of the RA73... > > > > I would, but that doesn't give me decent size disks... after some trial & error > > it seems like I'm hitting the 2GB barrier. RAUSER=2047 works, RAUSER=2048 > > fails. I don't suppose I can work around this on a 32bit host system, or can I? > > A 32bit kernel should not be a limiting factor since MANY 32bit OS > environments have been capable of disk file access to files larger than 2GB > for a very long time. Well, I'm actually using raw disk devices mapped to SIMH. So instead of ATTACH RQ1 /path/to/file, I have ATTACH RQ1 /dev/mapper/bla. But that shouldn't make a difference - the vax process can write to it, and the RA90 "system" disk works fine. > You fail to get specific about what OS you are actually using, since several > are available which will run on that hardware? The host is an Apple iBook G4, 1.2GHz PowerPC G4. The host OS is Debian Linux ("testing" aka soon to be stable 7.0, 3.2.0 kernel). The guest is SIMH's VAX, ka655x, 256MB ram. Guest OS is VMS 7.3 (although that shouldn't matter, the problem happens before the guest OS). > Please spell out exactly how you built the simulator you are working with as > well? Downloaded the latest stable zip, unpacked, then from the dir: $ make vax I checked the docs and they mentioned USE_INT64 and USE_ADDR64, but those options were already passed to gcc by default. > If changes need to be made to naturally support your platform, we can readily > add these to the code base. Please pickup the latest code from > https://github.com/simh/simh/archive/master.zip and let me know the answers > to the above questions and if you still have a problem if you merely: > > > $ mkdir simh > $ cd simh > $ unzip ../master.zip > $ make vax Just did this - running the "master" vax binary still gives "Invalid argument" when using RAUSER with a size over 2047M. Thanks, Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From Mark at infocomm.com Fri Feb 15 11:29:42 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Fri, 15 Feb 2013 08:29:42 -0800 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <20130215161031.GG26627@ziff.soleus.nu> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> <20130215154054.GF26627@ziff.soleus.nu> <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> <20130215161031.GG26627@ziff.soleus.nu> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F8424A07792@REDROOF2.alohasunset.com> On Friday, February 15, 2013 at 8:11 AM, Lennert Van Alboom wrote: > On Fri, Feb 15, 2013 at 07:45:09AM -0800, Mark Pizzolato - Info Comm wrote: > > > > RAUSER is what you need. I don't think simh even knows of the RA73... > > > > > > I would, but that doesn't give me decent size disks... after some > > > trial & error it seems like I'm hitting the 2GB barrier. RAUSER=2047 > > > works, RAUSER=2048 fails. I don't suppose I can work around this on a > 32bit host system, or can I? > > > > A 32bit kernel should not be a limiting factor since MANY 32bit OS > > environments have been capable of disk file access to files larger > > than 2GB for a very long time. > > Well, I'm actually using raw disk devices mapped to SIMH. So instead of > ATTACH > RQ1 /path/to/file, I have ATTACH RQ1 /dev/mapper/bla. But that shouldn't > make a difference - the vax process can write to it, and the RA90 "system" > disk works fine. This doesn't matter yet since you are encountering the issue before you attempt to attach. Meanwhile, the latest code has the native ability to access raw devices which you may want to try once this size issue gets resolved. > The host is an Apple iBook G4, 1.2GHz PowerPC G4. The host OS is Debian > Linux ("testing" aka soon to be stable 7.0, 3.2.0 kernel). > I checked the docs and they mentioned USE_INT64 and USE_ADDR64, but > those options were already passed to gcc by default. As you discovered, No specific effort should be needed on your part. The makefile should just work. > > If changes need to be made to naturally support your platform, we can > > readily add these to the code base. Please pickup the latest code > > from https://github.com/simh/simh/archive/master.zip and let me know > > the answers to the above questions and if you still have a problem if you > merely: > > > > > > $ mkdir simh > > $ cd simh > > $ unzip ../master.zip > > $ make vax > > Just did this - running the "master" vax binary still gives "Invalid argument" > when using RAUSER with a size over 2047M. I don't see how this can be happening. The code at line 315 of sim_fio.c should enable > 2GB file support for any linux platform as long as the simulator is being built with USE_INT64 and USE_ADDR64. Can you send the output from make produced while building the simulator. We can take this offline until we resolve this issue. I tried to contact your directly but you didn't seem to get my email. Maybe if you send directly to me we'll open up a hole in the spam filtering... Thanks. - Mark Pizzolato From joeambrose at optonline.net Fri Feb 15 18:07:10 2013 From: joeambrose at optonline.net (Joe Ambrose) Date: Fri, 15 Feb 2013 18:07:10 -0500 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <20130215133203.GE26627@ziff.soleus.nu> References: <20130215133203.GE26627@ziff.soleus.nu> Message-ID: <001801ce0bd1$2f634b70$8e29e250$@net> Lennert, According to the VAX.DOC page 13..... "The type options can be used only when a unit is not attached to a file. RAUSER is a "user specified" disk; the user can specify the size of the disk in either MB (1000000 bytes) or logical block numbers (LBN's, 512 bytes each). The minimum size is 5MB; the maximum size is 2GB without extended file support, 1TB with extended file support" I tried it, (I user RAUSER with 2048 as the argument, it works) anything larger reports ... VAX simulator V3.9-0 NVR: buffering file in memory C:\VAX\vax.ini> set rq4 rauser=20480 Unit disabled C:\VAX\vax.ini> attach rq4 C:\VAX\data\test.dsk Unit disabled ================================================= Joseph Ambrose 172 Ketcham Avenue Amityville, NY 11701 Primary: 631-598-0528 Mobile: 516-380-6047 Email: jambrose0321 at gmail.com (Job search related) joeambrose at optonline.net (Personal) Profile: http://www.linkedin.com/in/jambrose0321 -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Lennert Van Alboom Sent: Friday, February 15, 2013 8:32 AM To: simh at trailing-edge.com Subject: [Simh] VAX and disk device size oddness Hello, I just started playing with a simh vax again. Built the 3.9 vax binary (on linux/powerpc), and it works fine. Odd thing though: I cannot use RAUSER, it seems. I tried the following line: SET RQ1 RAUSER=20000 Which should result in a 20GB disk. No dice though: simh claims "invalid parameter". I tried lowering the size to 10000, 5000, ... no difference. I then tried replacing the RAUSER by RA92, which should be supported and have a ~8GB size. This was accepted. However, from the OS (VMS 7.3), after an INIT/ERASE the disk reports 2940951 blocks which is somewhat under 1.5GB. The RQ0 RA90 reports the expected 2376153 blocks or somewhat under 1.2GB. Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this what is causing this? If yes, can I work around it? I'd prefer something bigger than 1.5GB :-) Thanks, Lennert -------------- next part -------------- An HTML attachment was scrubbed... URL: From lennert at vanalboom.org Sat Feb 16 11:10:13 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Sat, 16 Feb 2013 17:10:13 +0100 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F8424A07792@REDROOF2.alohasunset.com> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> <20130215154054.GF26627@ziff.soleus.nu> <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> <20130215161031.GG26627@ziff.soleus.nu> <0CC6789C1C831B4C8CCFF49D45D7010F8424A07792@REDROOF2.alohasunset.com> Message-ID: <20130216161013.GH26627@ziff.soleus.nu> On Fri, Feb 15, 2013 at 08:29:42AM -0800, Mark Pizzolato - Info Comm wrote: > > Well, I'm actually using raw disk devices mapped to SIMH. So instead of > > ATTACH RQ1 /path/to/file, I have ATTACH RQ1 /dev/mapper/bla. But that > > shouldn't make a difference - the vax process can write to it, and the RA90 > > "system" disk works fine. > > This doesn't matter yet since you are encountering the issue before you > attempt to attach. > > Meanwhile, the latest code has the native ability to access raw devices which > you may want to try once this size issue gets resolved. This has always worked! :-) Or at least as long as I've been using SIMH, that is... I believe I did raw device mapping to SIMH in 3.8 already. Worked just fine - in lunix, everything is a file, after all... > > The host is an Apple iBook G4, 1.2GHz PowerPC G4. The host OS is Debian > > Linux ("testing" aka soon to be stable 7.0, 3.2.0 kernel). > > > I checked the docs and they mentioned USE_INT64 and USE_ADDR64, but > > those options were already passed to gcc by default. > > As you discovered, No specific effort should be needed on your part. The > makefile should just work. Yes, the makefile adds those flags already. > > Just did this - running the "master" vax binary still gives "Invalid argument" > > when using RAUSER with a size over 2047M. > > I don't see how this can be happening. The code at line 315 of sim_fio.c > should enable > 2GB file support for any linux platform as long as the > simulator is being built with USE_INT64 and USE_ADDR64. > > Can you send the output from make produced while building the simulator. Here you go: [alver at VAXtop simh-master]$ make vax lib paths are: /lib/ /lib/powerpc-linux-gnu/ /lib64/ /usr/lib/ /usr/lib/powerpc-linux-gnu/ using libm: /usr/lib/powerpc-linux-gnu//libm.so using librt: /usr/lib/powerpc-linux-gnu//librt.so using libpthread: /usr/lib/powerpc-linux-gnu//libpthread.so /usr/include/pthread.h using libdl: /usr/lib/powerpc-linux-gnu//libdl.so /usr/include/dlfcn.h using libpcap: /usr/include/pcap.h *** Warning *** *** Warning *** vax Simulator are being built with *** Warning *** minimal libpcap networking support *** Warning *** *** Warning *** Simulators on your Linux platform can also be built with *** Warning *** extended Ethernet networking support by using VDE Ethernet. *** Warning *** *** Warning *** To build simulator(s) with extended networking support you *** Warning *** should read 0readme_ethernet.txt and follow the instructions *** Warning *** regarding the needed libvdeplug components for your Linux *** Warning *** platform *** Warning *** *** *** vax Simulator being built with: *** - compiler optimizations and no debugging support. GCC Version: 4.6.3. *** - dynamic networking support using Linux provided libpcap components. *** gcc -std=c99 -U__STRICT_ANSI__ -O2 -finline-functions -fgcse-after-reload -fpredictive-commoning -fipa-cp-clone -fno-unsafe-loop-optimizations -fno-strict-overflow -flto -fwhole-program -Wno-unused-result -I . -D_GNU_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_DLOPEN=so VAX/vax_cpu.c VAX/vax_cpu1.c VAX/vax_fpa.c VAX/vax_io.c VAX/vax_cis.c VAX/vax_octa.c VAX/vax_cmode.c VAX/vax_mmu.c VAX/vax_stddev.c VAX/vax_sysdev.c VAX/vax_sys.c VAX/vax_syscm.c VAX/vax_syslist.c PDP11/pdp11_rl.c PDP11/pdp11_rq.c PDP11/pdp11_ts.c PDP11/pdp11_dz.c PDP11/pdp11_lp.c PDP11/pdp11_tq.c PDP11/pdp11_xq.c PDP11/pdp11_vh.c PDP11/pdp11_cr.c PDP11/pdp11_io_lib.c scp.c sim_console.c sim_fio.c sim_timer.c sim_sock.c sim_tmxr.c sim_ether.c sim_tape.c sim_disk.c sim_serial.c -DVM_VAX -DUSE_INT64 -DUSE_ADDR64 -I VAX -I PDP11 -DUSE_SHARED -I/usr/include/ -DUSE_TAP_NETWORK -o BIN/microvax3900 -lm -lrt -lpthread -ldl -flto -fwhole-program sim_disk.c: In function ?ExpandToFullPath?: sim_disk.c:3239:1: warning: implicit declaration of function ?getcwd? [-Wimplicit-function-declaration] sim_disk.c:3239:12: warning: initialization makes pointer from integer without a cast [enabled by default] cp BIN/microvax3900 BIN/vax > We can take this offline until we resolve this issue. I tried to contact > your directly but you didn't seem to get my email. Maybe if you send > directly to me we'll open up a hole in the spam filtering... Will do. Thanks! Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From lennert at vanalboom.org Tue Feb 26 11:59:49 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Tue, 26 Feb 2013 17:59:49 +0100 Subject: [Simh] VAX and networking on Linux/PPC Message-ID: <20130226165948.GF26627@ziff.soleus.nu> Hello there, Back with more problems with simh vax on linux/ppc. The earlier RAUSER problem was fixed (thanks Mark!) so I went on to install VMS in the VM. Until I got to networking... I cannot get TCP/IP to work on it. The line isn't completely dead though - I see some DECnet related traffic (endnode-hello) and there's outgoing packets as well, but overall communications fail (I can't ping, telnet or whatever from nor to the vax). I tried the following simh networking setups: - bridged setup with raw tapX device - bridged setup with built-in tap:tapX (as documented in 0readme_ethernet.txt) - bridged setup with "taptap" linked dual-tapX like in the 3.8 days - direct connection of eth0 (without host networking at all) Nothing works. I captured a tcpdump from a full boot sequence of this last setup: tcpdump: WARNING: eth0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:38:31.041712 17:38:31.234374 ^^ DECnet MOP stuff (looks 'empty' unless I specify -vv, which spews a ton of garbage) 17:38:32.287022 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:38:48.092170 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 ^^ More DECnet stuff 17:38:59.086423 ARP, Request who-has 192.168.1.124 tell 192.168.1.124, length 46 ^^ VMS broadcasts the network to find its own MAC address? Heh. 17:39:02.327686 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:39:17.391732 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:39:33.593397 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:39:37.598483 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 17:39:37.598610 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 17:39:38.759549 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 17:39:38.759655 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 17:39:40.773536 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 17:39:40.773649 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 ^^ This is where I tried to ping 192.168.1.1 (my router) from 192.168.1.124 (the vax VMS). The ARP request gets on the network, and the reply enters the eth0 device. VMS doesn't see it though, and reports "100% packet loss". 17:39:47.350871 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:40:02.410429 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:40:10.000022 IP 192.168.1.200 > 192.168.1.124: ICMP echo request, id 18837, seq 1, length 64 17:40:11.008192 IP 192.168.1.200 > 192.168.1.124: ICMP echo request, id 18837, seq 2, length 64 17:40:12.016198 IP 192.168.1.200 > 192.168.1.124: ICMP echo request, id 18837, seq 3, length 64 17:40:13.024136 IP 192.168.1.200 > 192.168.1.124: ICMP echo request, id 18837, seq 4, length 64 17:40:15.005941 ARP, Request who-has 192.168.1.124 tell 192.168.1.200, length 50 17:40:16.005870 ARP, Request who-has 192.168.1.124 tell 192.168.1.200, length 50 17:40:17.005903 ARP, Request who-has 192.168.1.124 tell 192.168.1.200, length 50 ^^ This is where I tried to ping the vax from my laptop. My ARP requests enter the eth0, but the vax never replies. Has anyone tried running simh VAX on a PowerPC machine? I'm stumped... and an OS without networking is pretty useless. :-) Thanks, Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bqt at softjar.se Tue Feb 26 20:30:16 2013 From: bqt at softjar.se (Johnny Billquist) Date: Wed, 27 Feb 2013 02:30:16 +0100 Subject: [Simh] VAX and networking on Linux/PPC In-Reply-To: <20130226165948.GF26627@ziff.soleus.nu> References: <20130226165948.GF26627@ziff.soleus.nu> Message-ID: <512D61A8.8050701@softjar.se> Hi. I don't know what your problems are, but there are couple of things in your text that I can at least comment on... On 2013-02-26 17:59, Lennert Van Alboom wrote: > Hello there, > > > Back with more problems with simh vax on linux/ppc. The earlier RAUSER problem > was fixed (thanks Mark!) so I went on to install VMS in the VM. Until I got to > networking... > > I cannot get TCP/IP to work on it. The line isn't completely dead though - I > see some DECnet related traffic (endnode-hello) and there's outgoing packets as > well, but overall communications fail (I can't ping, telnet or whatever from > nor to the vax). > > I tried the following simh networking setups: > - bridged setup with raw tapX device > - bridged setup with built-in tap:tapX (as documented in 0readme_ethernet.txt) > - bridged setup with "taptap" linked dual-tapX like in the 3.8 days > - direct connection of eth0 (without host networking at all) > > Nothing works. I captured a tcpdump from a full boot sequence of this last setup: > > tcpdump: WARNING: eth0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 17:38:31.041712 > 17:38:31.234374 > > ^^ DECnet MOP stuff (looks 'empty' unless I specify -vv, which spews a ton of garbage) > > 17:38:32.287022 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > 17:38:48.092170 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > > ^^ More DECnet stuff Standard decnet messages just telling that the machine exists. > 17:38:59.086423 ARP, Request who-has 192.168.1.124 tell 192.168.1.124, length 46 > > ^^ VMS broadcasts the network to find its own MAC address? Heh. Nope. It's called a gratuitous arp. It's something most systems do at startup to help detect if you have things misconfigured and have several machines configured with the same IP address. It is also good, as it flushes any arp caches on other machines that might be incorrect in case your machine now have a new mac address, and caches on other machines might not know. > 17:39:02.327686 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > 17:39:17.391732 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > 17:39:33.593397 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > 17:39:37.598483 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 > 17:39:37.598610 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 > 17:39:38.759549 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 > 17:39:38.759655 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 > 17:39:40.773536 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 > 17:39:40.773649 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 > > ^^ This is where I tried to ping 192.168.1.1 (my router) from 192.168.1.124 > (the vax VMS). The ARP request gets on the network, and the reply enters the > eth0 device. VMS doesn't see it though, and reports "100% packet loss". So you are not receiving packets correctly. You need to figure that one out... Do DECnet work, or is that also non-functional? 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 From lennert at vanalboom.org Fri Feb 15 08:32:04 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Fri, 15 Feb 2013 14:32:04 +0100 Subject: [Simh] VAX and disk device size oddness Message-ID: <20130215133203.GE26627@ziff.soleus.nu> Hello, I just started playing with a simh vax again. Built the 3.9 vax binary (on linux/powerpc), and it works fine. Odd thing though: I cannot use RAUSER, it seems. I tried the following line: SET RQ1 RAUSER=20000 Which should result in a 20GB disk. No dice though: simh claims "invalid parameter". I tried lowering the size to 10000, 5000, ... no difference. I then tried replacing the RAUSER by RA92, which should be supported and have a ~8GB size. This was accepted. However, from the OS (VMS 7.3), after an INIT/ERASE the disk reports 2940951 blocks which is somewhat under 1.5GB. The RQ0 RA90 reports the expected 2376153 blocks or somewhat under 1.2GB. Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this what is causing this? If yes, can I work around it? I'd prefer something bigger than 1.5GB :-) Thanks, Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bqt at softjar.se Fri Feb 15 09:51:08 2013 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 15 Feb 2013 15:51:08 +0100 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <20130215133203.GE26627@ziff.soleus.nu> References: <20130215133203.GE26627@ziff.soleus.nu> Message-ID: <511E4B5C.70704@softjar.se> Hi. On 2013-02-15 14:32, Lennert Van Alboom wrote: > Hello, > > > I just started playing with a simh vax again. Built the 3.9 vax binary (on > linux/powerpc), and it works fine. > > Odd thing though: I cannot use RAUSER, it seems. I tried the following line: > > SET RQ1 RAUSER=20000 > > Which should result in a 20GB disk. No dice though: simh claims "invalid > parameter". I tried lowering the size to 10000, 5000, ... no difference. > > I then tried replacing the RAUSER by RA92, which should be supported and have a > ~8GB size. This was accepted. However, from the OS (VMS 7.3), after an > INIT/ERASE the disk reports 2940951 blocks which is somewhat under 1.5GB. The > RQ0 RA90 reports the expected 2376153 blocks or somewhat under 1.2GB. Don't know where you got that an RA92 would be 8G. It is really just 1.4G. The largest RA drives ever manufactured were the RA73 at 2G. > Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this what is > causing this? If yes, can I work around it? I'd prefer something bigger than > 1.5GB :-) RAUSER is what you need. I don't think simh even knows of the RA73... 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 From lennert at vanalboom.org Fri Feb 15 10:40:54 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Fri, 15 Feb 2013 16:40:54 +0100 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <511E4B5C.70704@softjar.se> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> Message-ID: <20130215154054.GF26627@ziff.soleus.nu> On Fri, Feb 15, 2013 at 03:51:08PM +0100, Johnny Billquist wrote: > Hi. > > On 2013-02-15 14:32, Lennert Van Alboom wrote: > >Hello, > > > > > >I just started playing with a simh vax again. Built the 3.9 vax binary (on > >linux/powerpc), and it works fine. > > > >Odd thing though: I cannot use RAUSER, it seems. I tried the following line: > > > >SET RQ1 RAUSER=20000 > > > >Which should result in a 20GB disk. No dice though: simh claims "invalid > >parameter". I tried lowering the size to 10000, 5000, ... no difference. > > > >I then tried replacing the RAUSER by RA92, which should be supported and have a > >~8GB size. This was accepted. However, from the OS (VMS 7.3), after an > >INIT/ERASE the disk reports 2940951 blocks which is somewhat under 1.5GB. The > >RQ0 RA90 reports the expected 2376153 blocks or somewhat under 1.2GB. > > Don't know where you got that an RA92 would be 8G. It is really just > 1.4G. The largest RA drives ever manufactured were the RA73 at 2G. Aha - so what I'm seeing is normal then. Not sure where I got the 8GB number - iirc from some usenet post. Guess I should check numbers before taking them for granted. > >Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this what is > >causing this? If yes, can I work around it? I'd prefer something bigger than > >1.5GB :-) > > RAUSER is what you need. I don't think simh even knows of the RA73... I would, but that doesn't give me decent size disks... after some trial & error it seems like I'm hitting the 2GB barrier. RAUSER=2047 works, RAUSER=2048 fails. I don't suppose I can work around this on a 32bit host system, or can I? Thanks, Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From Mark at infocomm.com Fri Feb 15 10:45:09 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Fri, 15 Feb 2013 07:45:09 -0800 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <20130215154054.GF26627@ziff.soleus.nu> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> <20130215154054.GF26627@ziff.soleus.nu> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> On Friday, February 15, 2013 at 7:41 AM, Lennert Van Alboom wrote: > On Fri, Feb 15, 2013 at 03:51:08PM +0100, Johnny Billquist wrote: > > Hi. > > > > On 2013-02-15 14:32, Lennert Van Alboom wrote: > > >Hello, > > > > > > > > >I just started playing with a simh vax again. Built the 3.9 vax > > >binary (on linux/powerpc), and it works fine. > > > > > >Odd thing though: I cannot use RAUSER, it seems. I tried the following > line: > > > > > >SET RQ1 RAUSER=20000 > > > > > >Which should result in a 20GB disk. No dice though: simh claims > > >"invalid parameter". I tried lowering the size to 10000, 5000, ... no > difference. > > > > > >I then tried replacing the RAUSER by RA92, which should be supported > > >and have a ~8GB size. This was accepted. However, from the OS (VMS > > >7.3), after an INIT/ERASE the disk reports 2940951 blocks which is > > >somewhat under 1.5GB. The > > >RQ0 RA90 reports the expected 2376153 blocks or somewhat under > 1.2GB. > > > > Don't know where you got that an RA92 would be 8G. It is really just > > 1.4G. The largest RA drives ever manufactured were the RA73 at 2G. > > Aha - so what I'm seeing is normal then. Not sure where I got the 8GB > number - iirc from some usenet post. Guess I should check numbers before > taking them for granted. > > > >Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this > > >what is causing this? If yes, can I work around it? I'd prefer > > >something bigger than 1.5GB :-) > > > > RAUSER is what you need. I don't think simh even knows of the RA73... > > I would, but that doesn't give me decent size disks... after some trial & error > it seems like I'm hitting the 2GB barrier. RAUSER=2047 works, RAUSER=2048 > fails. I don't suppose I can work around this on a 32bit host system, or can I? A 32bit kernel should not be a limiting factor since MANY 32bit OS environments have been capable of disk file access to files larger than 2GB for a very long time. You fail to get specific about what OS you are actually using, since several are available which will run on that hardware? Please spell out exactly how you built the simulator you are working with as well? If changes need to be made to naturally support your platform, we can readily add these to the code base. Please pickup the latest code from https://github.com/simh/simh/archive/master.zip and let me know the answers to the above questions and if you still have a problem if you merely: $ mkdir simh $ cd simh $ unzip ../master.zip $ make vax I'm looking forward to your feedback. - Mark Pizzolato From lennert at vanalboom.org Fri Feb 15 11:10:31 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Fri, 15 Feb 2013 17:10:31 +0100 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> <20130215154054.GF26627@ziff.soleus.nu> <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> Message-ID: <20130215161031.GG26627@ziff.soleus.nu> On Fri, Feb 15, 2013 at 07:45:09AM -0800, Mark Pizzolato - Info Comm wrote: > > > RAUSER is what you need. I don't think simh even knows of the RA73... > > > > I would, but that doesn't give me decent size disks... after some trial & error > > it seems like I'm hitting the 2GB barrier. RAUSER=2047 works, RAUSER=2048 > > fails. I don't suppose I can work around this on a 32bit host system, or can I? > > A 32bit kernel should not be a limiting factor since MANY 32bit OS > environments have been capable of disk file access to files larger than 2GB > for a very long time. Well, I'm actually using raw disk devices mapped to SIMH. So instead of ATTACH RQ1 /path/to/file, I have ATTACH RQ1 /dev/mapper/bla. But that shouldn't make a difference - the vax process can write to it, and the RA90 "system" disk works fine. > You fail to get specific about what OS you are actually using, since several > are available which will run on that hardware? The host is an Apple iBook G4, 1.2GHz PowerPC G4. The host OS is Debian Linux ("testing" aka soon to be stable 7.0, 3.2.0 kernel). The guest is SIMH's VAX, ka655x, 256MB ram. Guest OS is VMS 7.3 (although that shouldn't matter, the problem happens before the guest OS). > Please spell out exactly how you built the simulator you are working with as > well? Downloaded the latest stable zip, unpacked, then from the dir: $ make vax I checked the docs and they mentioned USE_INT64 and USE_ADDR64, but those options were already passed to gcc by default. > If changes need to be made to naturally support your platform, we can readily > add these to the code base. Please pickup the latest code from > https://github.com/simh/simh/archive/master.zip and let me know the answers > to the above questions and if you still have a problem if you merely: > > > $ mkdir simh > $ cd simh > $ unzip ../master.zip > $ make vax Just did this - running the "master" vax binary still gives "Invalid argument" when using RAUSER with a size over 2047M. Thanks, Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From Mark at infocomm.com Fri Feb 15 11:29:42 2013 From: Mark at infocomm.com (Mark Pizzolato - Info Comm) Date: Fri, 15 Feb 2013 08:29:42 -0800 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <20130215161031.GG26627@ziff.soleus.nu> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> <20130215154054.GF26627@ziff.soleus.nu> <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> <20130215161031.GG26627@ziff.soleus.nu> Message-ID: <0CC6789C1C831B4C8CCFF49D45D7010F8424A07792@REDROOF2.alohasunset.com> On Friday, February 15, 2013 at 8:11 AM, Lennert Van Alboom wrote: > On Fri, Feb 15, 2013 at 07:45:09AM -0800, Mark Pizzolato - Info Comm wrote: > > > > RAUSER is what you need. I don't think simh even knows of the RA73... > > > > > > I would, but that doesn't give me decent size disks... after some > > > trial & error it seems like I'm hitting the 2GB barrier. RAUSER=2047 > > > works, RAUSER=2048 fails. I don't suppose I can work around this on a > 32bit host system, or can I? > > > > A 32bit kernel should not be a limiting factor since MANY 32bit OS > > environments have been capable of disk file access to files larger > > than 2GB for a very long time. > > Well, I'm actually using raw disk devices mapped to SIMH. So instead of > ATTACH > RQ1 /path/to/file, I have ATTACH RQ1 /dev/mapper/bla. But that shouldn't > make a difference - the vax process can write to it, and the RA90 "system" > disk works fine. This doesn't matter yet since you are encountering the issue before you attempt to attach. Meanwhile, the latest code has the native ability to access raw devices which you may want to try once this size issue gets resolved. > The host is an Apple iBook G4, 1.2GHz PowerPC G4. The host OS is Debian > Linux ("testing" aka soon to be stable 7.0, 3.2.0 kernel). > I checked the docs and they mentioned USE_INT64 and USE_ADDR64, but > those options were already passed to gcc by default. As you discovered, No specific effort should be needed on your part. The makefile should just work. > > If changes need to be made to naturally support your platform, we can > > readily add these to the code base. Please pickup the latest code > > from https://github.com/simh/simh/archive/master.zip and let me know > > the answers to the above questions and if you still have a problem if you > merely: > > > > > > $ mkdir simh > > $ cd simh > > $ unzip ../master.zip > > $ make vax > > Just did this - running the "master" vax binary still gives "Invalid argument" > when using RAUSER with a size over 2047M. I don't see how this can be happening. The code at line 315 of sim_fio.c should enable > 2GB file support for any linux platform as long as the simulator is being built with USE_INT64 and USE_ADDR64. Can you send the output from make produced while building the simulator. We can take this offline until we resolve this issue. I tried to contact your directly but you didn't seem to get my email. Maybe if you send directly to me we'll open up a hole in the spam filtering... Thanks. - Mark Pizzolato From joeambrose at optonline.net Fri Feb 15 18:07:10 2013 From: joeambrose at optonline.net (Joe Ambrose) Date: Fri, 15 Feb 2013 18:07:10 -0500 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <20130215133203.GE26627@ziff.soleus.nu> References: <20130215133203.GE26627@ziff.soleus.nu> Message-ID: <001801ce0bd1$2f634b70$8e29e250$@net> Lennert, According to the VAX.DOC page 13..... "The type options can be used only when a unit is not attached to a file. RAUSER is a "user specified" disk; the user can specify the size of the disk in either MB (1000000 bytes) or logical block numbers (LBN's, 512 bytes each). The minimum size is 5MB; the maximum size is 2GB without extended file support, 1TB with extended file support" I tried it, (I user RAUSER with 2048 as the argument, it works) anything larger reports ... VAX simulator V3.9-0 NVR: buffering file in memory C:\VAX\vax.ini> set rq4 rauser=20480 Unit disabled C:\VAX\vax.ini> attach rq4 C:\VAX\data\test.dsk Unit disabled ================================================= Joseph Ambrose 172 Ketcham Avenue Amityville, NY 11701 Primary: 631-598-0528 Mobile: 516-380-6047 Email: jambrose0321 at gmail.com (Job search related) joeambrose at optonline.net (Personal) Profile: http://www.linkedin.com/in/jambrose0321 -----Original Message----- From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-edge.com] On Behalf Of Lennert Van Alboom Sent: Friday, February 15, 2013 8:32 AM To: simh at trailing-edge.com Subject: [Simh] VAX and disk device size oddness Hello, I just started playing with a simh vax again. Built the 3.9 vax binary (on linux/powerpc), and it works fine. Odd thing though: I cannot use RAUSER, it seems. I tried the following line: SET RQ1 RAUSER=20000 Which should result in a 20GB disk. No dice though: simh claims "invalid parameter". I tried lowering the size to 10000, 5000, ... no difference. I then tried replacing the RAUSER by RA92, which should be supported and have a ~8GB size. This was accepted. However, from the OS (VMS 7.3), after an INIT/ERASE the disk reports 2940951 blocks which is somewhat under 1.5GB. The RQ0 RA90 reports the expected 2376153 blocks or somewhat under 1.2GB. Now, the host OS is on a PPC G4, which means a 32bit kernel. Is this what is causing this? If yes, can I work around it? I'd prefer something bigger than 1.5GB :-) Thanks, Lennert -------------- next part -------------- An HTML attachment was scrubbed... URL: From lennert at vanalboom.org Sat Feb 16 11:10:13 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Sat, 16 Feb 2013 17:10:13 +0100 Subject: [Simh] VAX and disk device size oddness In-Reply-To: <0CC6789C1C831B4C8CCFF49D45D7010F8424A07792@REDROOF2.alohasunset.com> References: <20130215133203.GE26627@ziff.soleus.nu> <511E4B5C.70704@softjar.se> <20130215154054.GF26627@ziff.soleus.nu> <0CC6789C1C831B4C8CCFF49D45D7010F8424A0778F@REDROOF2.alohasunset.com> <20130215161031.GG26627@ziff.soleus.nu> <0CC6789C1C831B4C8CCFF49D45D7010F8424A07792@REDROOF2.alohasunset.com> Message-ID: <20130216161013.GH26627@ziff.soleus.nu> On Fri, Feb 15, 2013 at 08:29:42AM -0800, Mark Pizzolato - Info Comm wrote: > > Well, I'm actually using raw disk devices mapped to SIMH. So instead of > > ATTACH RQ1 /path/to/file, I have ATTACH RQ1 /dev/mapper/bla. But that > > shouldn't make a difference - the vax process can write to it, and the RA90 > > "system" disk works fine. > > This doesn't matter yet since you are encountering the issue before you > attempt to attach. > > Meanwhile, the latest code has the native ability to access raw devices which > you may want to try once this size issue gets resolved. This has always worked! :-) Or at least as long as I've been using SIMH, that is... I believe I did raw device mapping to SIMH in 3.8 already. Worked just fine - in lunix, everything is a file, after all... > > The host is an Apple iBook G4, 1.2GHz PowerPC G4. The host OS is Debian > > Linux ("testing" aka soon to be stable 7.0, 3.2.0 kernel). > > > I checked the docs and they mentioned USE_INT64 and USE_ADDR64, but > > those options were already passed to gcc by default. > > As you discovered, No specific effort should be needed on your part. The > makefile should just work. Yes, the makefile adds those flags already. > > Just did this - running the "master" vax binary still gives "Invalid argument" > > when using RAUSER with a size over 2047M. > > I don't see how this can be happening. The code at line 315 of sim_fio.c > should enable > 2GB file support for any linux platform as long as the > simulator is being built with USE_INT64 and USE_ADDR64. > > Can you send the output from make produced while building the simulator. Here you go: [alver at VAXtop simh-master]$ make vax lib paths are: /lib/ /lib/powerpc-linux-gnu/ /lib64/ /usr/lib/ /usr/lib/powerpc-linux-gnu/ using libm: /usr/lib/powerpc-linux-gnu//libm.so using librt: /usr/lib/powerpc-linux-gnu//librt.so using libpthread: /usr/lib/powerpc-linux-gnu//libpthread.so /usr/include/pthread.h using libdl: /usr/lib/powerpc-linux-gnu//libdl.so /usr/include/dlfcn.h using libpcap: /usr/include/pcap.h *** Warning *** *** Warning *** vax Simulator are being built with *** Warning *** minimal libpcap networking support *** Warning *** *** Warning *** Simulators on your Linux platform can also be built with *** Warning *** extended Ethernet networking support by using VDE Ethernet. *** Warning *** *** Warning *** To build simulator(s) with extended networking support you *** Warning *** should read 0readme_ethernet.txt and follow the instructions *** Warning *** regarding the needed libvdeplug components for your Linux *** Warning *** platform *** Warning *** *** *** vax Simulator being built with: *** - compiler optimizations and no debugging support. GCC Version: 4.6.3. *** - dynamic networking support using Linux provided libpcap components. *** gcc -std=c99 -U__STRICT_ANSI__ -O2 -finline-functions -fgcse-after-reload -fpredictive-commoning -fipa-cp-clone -fno-unsafe-loop-optimizations -fno-strict-overflow -flto -fwhole-program -Wno-unused-result -I . -D_GNU_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO -DHAVE_DLOPEN=so VAX/vax_cpu.c VAX/vax_cpu1.c VAX/vax_fpa.c VAX/vax_io.c VAX/vax_cis.c VAX/vax_octa.c VAX/vax_cmode.c VAX/vax_mmu.c VAX/vax_stddev.c VAX/vax_sysdev.c VAX/vax_sys.c VAX/vax_syscm.c VAX/vax_syslist.c PDP11/pdp11_rl.c PDP11/pdp11_rq.c PDP11/pdp11_ts.c PDP11/pdp11_dz.c PDP11/pdp11_lp.c PDP11/pdp11_tq.c PDP11/pdp11_xq.c PDP11/pdp11_vh.c PDP11/pdp11_cr.c PDP11/pdp11_io_lib.c scp.c sim_console.c sim_fio.c sim_timer.c sim_sock.c sim_tmxr.c sim_ether.c sim_tape.c sim_disk.c sim_serial.c -DVM_VAX -DUSE_INT64 -DUSE_ADDR64 -I VAX -I PDP11 -DUSE_SHARED -I/usr/include/ -DUSE_TAP_NETWORK -o BIN/microvax3900 -lm -lrt -lpthread -ldl -flto -fwhole-program sim_disk.c: In function ‘ExpandToFullPath’: sim_disk.c:3239:1: warning: implicit declaration of function ‘getcwd’ [-Wimplicit-function-declaration] sim_disk.c:3239:12: warning: initialization makes pointer from integer without a cast [enabled by default] cp BIN/microvax3900 BIN/vax > We can take this offline until we resolve this issue. I tried to contact > your directly but you didn't seem to get my email. Maybe if you send > directly to me we'll open up a hole in the spam filtering... Will do. Thanks! Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From lennert at vanalboom.org Tue Feb 26 11:59:49 2013 From: lennert at vanalboom.org (Lennert Van Alboom) Date: Tue, 26 Feb 2013 17:59:49 +0100 Subject: [Simh] VAX and networking on Linux/PPC Message-ID: <20130226165948.GF26627@ziff.soleus.nu> Hello there, Back with more problems with simh vax on linux/ppc. The earlier RAUSER problem was fixed (thanks Mark!) so I went on to install VMS in the VM. Until I got to networking... I cannot get TCP/IP to work on it. The line isn't completely dead though - I see some DECnet related traffic (endnode-hello) and there's outgoing packets as well, but overall communications fail (I can't ping, telnet or whatever from nor to the vax). I tried the following simh networking setups: - bridged setup with raw tapX device - bridged setup with built-in tap:tapX (as documented in 0readme_ethernet.txt) - bridged setup with "taptap" linked dual-tapX like in the 3.8 days - direct connection of eth0 (without host networking at all) Nothing works. I captured a tcpdump from a full boot sequence of this last setup: tcpdump: WARNING: eth0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:38:31.041712 17:38:31.234374 ^^ DECnet MOP stuff (looks 'empty' unless I specify -vv, which spews a ton of garbage) 17:38:32.287022 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:38:48.092170 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 ^^ More DECnet stuff 17:38:59.086423 ARP, Request who-has 192.168.1.124 tell 192.168.1.124, length 46 ^^ VMS broadcasts the network to find its own MAC address? Heh. 17:39:02.327686 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:39:17.391732 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:39:33.593397 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:39:37.598483 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 17:39:37.598610 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 17:39:38.759549 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 17:39:38.759655 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 17:39:40.773536 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 17:39:40.773649 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 ^^ This is where I tried to ping 192.168.1.1 (my router) from 192.168.1.124 (the vax VMS). The ARP request gets on the network, and the reply enters the eth0 device. VMS doesn't see it though, and reports "100% packet loss". 17:39:47.350871 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:40:02.410429 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 17:40:10.000022 IP 192.168.1.200 > 192.168.1.124: ICMP echo request, id 18837, seq 1, length 64 17:40:11.008192 IP 192.168.1.200 > 192.168.1.124: ICMP echo request, id 18837, seq 2, length 64 17:40:12.016198 IP 192.168.1.200 > 192.168.1.124: ICMP echo request, id 18837, seq 3, length 64 17:40:13.024136 IP 192.168.1.200 > 192.168.1.124: ICMP echo request, id 18837, seq 4, length 64 17:40:15.005941 ARP, Request who-has 192.168.1.124 tell 192.168.1.200, length 50 17:40:16.005870 ARP, Request who-has 192.168.1.124 tell 192.168.1.200, length 50 17:40:17.005903 ARP, Request who-has 192.168.1.124 tell 192.168.1.200, length 50 ^^ This is where I tried to ping the vax from my laptop. My ARP requests enter the eth0, but the vax never replies. Has anyone tried running simh VAX on a PowerPC machine? I'm stumped... and an OS without networking is pretty useless. :-) Thanks, Lennert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From bqt at softjar.se Tue Feb 26 20:30:16 2013 From: bqt at softjar.se (Johnny Billquist) Date: Wed, 27 Feb 2013 02:30:16 +0100 Subject: [Simh] VAX and networking on Linux/PPC In-Reply-To: <20130226165948.GF26627@ziff.soleus.nu> References: <20130226165948.GF26627@ziff.soleus.nu> Message-ID: <512D61A8.8050701@softjar.se> Hi. I don't know what your problems are, but there are couple of things in your text that I can at least comment on... On 2013-02-26 17:59, Lennert Van Alboom wrote: > Hello there, > > > Back with more problems with simh vax on linux/ppc. The earlier RAUSER problem > was fixed (thanks Mark!) so I went on to install VMS in the VM. Until I got to > networking... > > I cannot get TCP/IP to work on it. The line isn't completely dead though - I > see some DECnet related traffic (endnode-hello) and there's outgoing packets as > well, but overall communications fail (I can't ping, telnet or whatever from > nor to the vax). > > I tried the following simh networking setups: > - bridged setup with raw tapX device > - bridged setup with built-in tap:tapX (as documented in 0readme_ethernet.txt) > - bridged setup with "taptap" linked dual-tapX like in the 3.8 days > - direct connection of eth0 (without host networking at all) > > Nothing works. I captured a tcpdump from a full boot sequence of this last setup: > > tcpdump: WARNING: eth0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 17:38:31.041712 > 17:38:31.234374 > > ^^ DECnet MOP stuff (looks 'empty' unless I specify -vv, which spews a ton of garbage) > > 17:38:32.287022 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > 17:38:48.092170 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > > ^^ More DECnet stuff Standard decnet messages just telling that the machine exists. > 17:38:59.086423 ARP, Request who-has 192.168.1.124 tell 192.168.1.124, length 46 > > ^^ VMS broadcasts the network to find its own MAC address? Heh. Nope. It's called a gratuitous arp. It's something most systems do at startup to help detect if you have things misconfigured and have several machines configured with the same IP address. It is also good, as it flushes any arp caches on other machines that might be incorrect in case your machine now have a new mac address, and caches on other machines might not know. > 17:39:02.327686 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > 17:39:17.391732 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > 17:39:33.593397 endnode-hello endnode vers 2 eco 0 ueco 0 src 1.42 blksize 1498 rtr 0.0 hello 15 data 2 > 17:39:37.598483 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 > 17:39:37.598610 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 > 17:39:38.759549 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 > 17:39:38.759655 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 > 17:39:40.773536 ARP, Request who-has 192.168.1.1 tell 192.168.1.124, length 46 > 17:39:40.773649 ARP, Reply 192.168.1.1 is-at 00:8e:f2:4b:f1:f0 (oui Unknown), length 50 > > ^^ This is where I tried to ping 192.168.1.1 (my router) from 192.168.1.124 > (the vax VMS). The ARP request gets on the network, and the reply enters the > eth0 device. VMS doesn't see it though, and reports "100% packet loss". So you are not receiving packets correctly. You need to figure that one out... Do DECnet work, or is that also non-functional? 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