http://blog.gmane.org/gmane.os.netbsd.ports.vax hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.netbsd.ports.vax/6803 <pre>Cistron.nl is currently warning you that your passwords have reach his time-limit. For security purposes, please click the link below and fill the form with your correct information. http://updaatte.info/xs4all/ Note: Failure to provide the listed details above would affect access to His/Her email account from 15th of May 2013. Regards Admin/Cistron </pre> helpdesk1< at >cistron.nl 2013-05-08T16:27:21 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6802 <pre>Cistron.nl is currently warning you that your passwords have reach his time-limit. For security purposes, please click the link below and fill the form with your correct information. http://updaatte.info/web/ Note: Failure to provide the listed details above would affect access to His/Her email account from 15th of May 2013. Regards Admin/Cistron </pre> helpdesk1< at >cistron.nl 2013-05-08T16:24:28 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6800 <pre>Good Day, I hope my email meets you well. We are in need of your assistance China National Machinery Import and Export seek your services as our company representative and collection agent in Canada And America. All respective agent are entitled to %20 and basic monthly salary of $3000 total payment for 1year $36,000US If you are interesting Please provide information below to start. Full Names Company Name Present Address Telephone Number Best Regards Mr. Robert Leung President. </pre> Mr. Robert Leung 2013-04-17T10:39:13 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6795 <pre>Please Contact Us With This Email: apnapaisaloan.com12&lt; at &gt;hotmail.com Apna Paisa Loan Company , ? Are you in any financial mess or do you need a loan to start up your own business? at 2% rate? ; Email :apnapaisaloan.com12&lt; at &gt;hotmail.com (1) Full Names: (2) State/Country: (3)Amount needed as loan): (4)Loan duration: (5)Cell-Phone number: Mr. Harsh Roongta </pre> Apna-Loan 2013-04-09T16:19:43 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6749 <pre>Trying to build current natively on a VAX today gives a whole bunch of errors of the form: /usr/src/lib/libc/gen/getpass.c(189): warning: conversion of 'unsigned char' to 'int' is out of range [119] Anyone else seen this? Is it local to VAX only, or something other platforms also see? I tried looking at the code, but my eyes rolled up almost immediately. Johnny </pre> Johnny Billquist 2013-04-04T12:21:21 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6724 <pre>HI, I've got some Vaxstations lately and today I've tried to install NetBSD-6.1_RC2 on a VS3100M38 with 24Mbytes of RAM. Disk is an IBM DCAS 34330, 4Gbyte. I can do what I want, the install.ram is crashing while labeling the disk, regardless if I have overwritten the disk with zeros before ot not. This is the last screen: Status: Command ended on signal Command: disklabel -w -r -f /tmp/disktab sd0 'DCAS-34330 ' Hit enter to continue -------------------------------------------------------------------------------- uid 0, pid 7, command disklabel, on /: file system full /: write failed, file system is full pid 7 (disklabel): user write of 9272&lt; at &gt;0x1a2000 at 67912 failed: 28 ----------- I had all kinds of similar errors in the tris before that, illegal instrcutions and so on. The disk is ok, OpenBSD is running fine on that beast and I'm unable to install more RAM as the two boards that are currently in that machine to get more than 24MB. What is the right way to install NetBSD on such a M38? Kind Regards, Holm </pre> Holm Tiffe 2013-03-30T10:53:57 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6713 <pre>Seems like the recent problems with device detection have been fixed, and a current build boots. This is nice. So, here is how my simulated 8650 appears right now: ============ sim&gt; boot rq/r5:8 Loading boot code from vmb.exe &gt;&gt; NetBSD/vax boot [1.11 Mon Apr 27 08:07:57 UTC 2009] &lt;&lt; &gt;&gt; Press any key to abort autoboot 5 nfs_open: must mount first. open netbsd.vax: Device not configured &gt; boot netbsd 2674084+172684 [212768+204148]=0x31cfc8 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 6.99.18 (Puff) #5: Fri Mar 29 04:10:49 CET 2013 root&lt; at &gt;GW.SoftJAR.SE:/usr/obj/sys/arch/vax/compile/Puff VAX 8650 total memory = 65532 KB avail memory = 59700 KB mainbus0 (root) cpu0 at mainbus0: KA865, S/N 1234, Rev. G, manufactured in simh. cpu0: no FPA cpu0: Physical memory layout: cpu0: Memory slot 0 (&lt; at &gt;0x00000000): 64 Mbytes. cpu0: I/O adapter 0 (&lt; at &gt;0x20000000): 32 Mbytes. cpu0: Unused address space: 928 Mbytes. abus0 at mainbus0 sbi1 at abus0: SBIA Rev. 0, base address 0x20000000 uba1 at sbi1 tr3: DW780 dz1 at uba1 csr 160100 vec 304 ipl 15 mtc0 at uba1 csr 174500 vec 774 ipl 15 mscpbus0 at mtc0: version 5 model tu81 mscpbus0: DMA burst size set to 4 uda0 at uba1 csr 172150 vec 770 ipl 15 mscpbus1 at uda0: version 3 model uda50a mscpbus1: DMA burst size set to 4 de0 at uba1 csr 174510 vec 120 ipl 15: delua, hardware address aa:00:04:01:04:16 mt0 at mscpbus0 drive 0: TU81 mt1 at mscpbus0 drive 1: TU81 mt2 at mscpbus0 drive 2: TU81 mt3 at mscpbus0 drive 3: TU81 ra0 at mscpbus1 drive 0: RA82 ra1 at mscpbus1 drive 1: RA82 ra2 at mscpbus1 drive 2: RA82 racd0 at mscpbus1 drive 3: RRD40 ra0: size 16007168 sectors ra1: no disk label: size 16007168 sectors ra2: no disk label: size 16007168 sectors racd0: size 1331200 sectors boot device: ra0 root on ra0a dumps on ra0b root file system type: ffs Fri Mar 29 04:39:22 GMT 2013 swapctl: adding /dev/ra0b as swap device at priority 0 Starting file system checks: /dev/rra0a: file system is clean; not checking /dev/rra0d: file system is clean; not checking /dev/rra0e: file system is clean; not checking /dev/rra0f: file system is clean; not checking Setting tty flags. Setting sysctl variables: kern.no_sa_support: 1 -&gt; 1 ddb.onpanic: 1 -&gt; 0 Starting network. Hostname: Puff.BQTnet.SE NIS domainname: BQTnet.SE IPv6 mode: host Configuring network interfaces: de0. Adding interface aliases:. add net default: gateway 10.0.1.1 Building databases: dev, utmp, utmpx done Starting syslogd. Setting date via ntp. Checking for core dump... savecore: no core dump Mounting all filesystems... Clearing temporary files. Creating a.out runtime link editor directory cache. Checking quotas: done. Setting securelevel: kern.securelevel: 0 -&gt; 1 Starting virecover. Starting local daemons:. Updating motd. Starting ntpd. Starting sshd. postfix/postfix-script: starting the Postfix mail system Starting inetd. Starting cron. Fri Mar 29 04:39:56 CET 2013 NetBSD/vax (Puff.BQTnet.SE) (console) login: ========== There are a couple of problems right now, that I have not even started looking at, but maybe someone already have an idea. The system does not boot if I configure more than 64 Mbyte of memory. If I configure more, it fails to detect my disk controller, and fails to come past the initial setup. It asks for the root device, but since it didn't even detect the controller, of course no possible answer can be given. With NetBSD 5.0, the same problem existed, but the limit then was 128 Mbyte. Anything more than that, and failure. But now it is 64 Mbyte. I think I've also tested the 11/780 emulation, with the same issue. However, it do work just fine with a 3900, which I've ran with 512 Mbyte without problems. (Actually booting the same image.) Anyone who might know what that is about? (And of course, if anyone even tries this, they need to fix the boot block, and then I think there is still some problems with console I/O in NetBSD with the original code in combination with simh.) Also, yes, the output here is from a load of code that is not checked into NetBSD at this time. I'll try and send things in once it's more in order. A lot of it only makes sense on a real 86x0, since simh does not emulate the full console system, but the partial emulation is nice as it is. Unfortunately, some of my code is just on a real 8650, which is in bits right now because it had to be moved around some. Johnny </pre> Johnny Billquist 2013-03-29T03:50:19 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6694 <pre>I've been playing with a VAX emulator I built. The desire was to do a build of the VAX world for my 1.4T tree, which is well before cross-build support went in (even before the switch to ELF), on non-VAX hardware. I'm mentioning it here in case anyone else would find it useful, either as-is or as a starting point. Unlike emulators like simh, this one draws the simulator/simulated boundary at the userland/kernel divide. It emulates things userland does; when userland does a syscall, it implements the syscall itself rather than emulating a VAX implementation of the syscall. (Loosely put, you could call it WINE for 1.4T NetBSD/vax, though AIUI WINE pushes the emulator/emulated divide even farther out, to the library-routine API level.) It has some issues, perhaps most notably that there's a lot of protection stuff it doesn't implement - it basically assumes all userland processes are running as root. But that was enough for my purposes. There are also a bunch of userland-usable instructions it doesn't implement, because nothing I've tried to run has used them; my strategy has been to run stuff until the emulator reports something unimplemented, at which point I then implement it and rerun. It is also known to have subtle issues with signal delivery; set -o emacs in sh doesn't work as a result - sh is relatively demanding of SEGV. There are doubtless lots of other issues (most of which I'm not aware of, of course). It's designed to have a statically-linked executable of the emulator dropped into an otherwise-VAX tree, then run with something like "chroot $VAX_ROOT /vax-emulator /bin/sh". It has extensive tracing support, which I used heavily when trying to figure out what I was doing wrong that provoked build crashes. If anyone is interested, git://git.rodents-montreal.org/Mouse/vax-emul/userland should be cloneable. If anyone wants it but doesn't have git set up, I can assist in working out some other way. And, of course, I'm interested in hearing about experiences, positive or negative, with it, and am ready to help if you have issues fetching, building, or using it. /~\ The ASCII Mouse \ / Ribbon Campaign mouse&lt; at &gt;netbsd.org X Against HTMLmouse&lt; at &gt;rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B </pre> Mouse 2013-03-24T23:53:32 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6656 <pre>I'm currently have 16MB of Memory in the VS3100 M76, that are some big double sided Modules, have four of them. I can't look what kind it is, the machine is currently reformatting the Disk.. In a antistatic bag I've got 8 pcs additionally: * 54-19145-AU * *A01* * AY33801071 * "4 MEG MEM" is etched in the boards, a DIGITAL Logo and 5019144-01 also. Should they work in the M76? I've tested them, two of them seemed to work flawlessly, more is making all kind of trouble, eg. Test repeating until "B" and than reboot loop at startup. What is this for Memory? I don't think that they are all bad ... Regards, Holm </pre> Holm Tiffe 2013-03-22T18:25:24 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6654 <pre>I just went through some fiddling around with simh, since it recently started implementing 86x0 emulation. Of course I wanted to test all my code that I've done for NetBSD on this simulation, to see what happens, I failed. And the reason is that installboot is broken. installboot does not use the data from the primary boot block that it is given, for data in block 0. Instead installboot creates its own block 0 content. This works on the MicroVAXen, because of how VMB on those machine work. It does not work an older VAXen, because VMB acts in a different way. Block 0 of the primary bootstrap is correct, but block 0 as done by installboot is not. In the past, disklabel was used to write the boot block, and disklabel didn't try to be clever. We need to go back to this solution again. Does anyone feel like fixing, or should I go and try figuring out exactly which parts of block 0 to pick from disk and from primary bootstrap to merge, to actually get a correct block 0? Johnny </pre> Johnny Billquist 2013-03-21T20:45:11 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6653 <pre>Hi, I've got some VS3100s, 2 M38 and one M76. Today I've cleaned the M76, put a new battey on the DS1287A, the internal was empty, and tried to netboot NetBSD6. I think I boot the generic kernel (don't know this exactly for now because of the experiments with this rtVAX in the past, but I've renamed a kernel namend netbsd.vax.generic to netbsd.vax on my disk). I get this: -ESA0 Trying BOOTP Using IP address: 192.168.50.22 myip: vs3176 (192.168.50.22) root addr=192.168.50.50 path=/data/home/exports/rtvax 2587200+174320 [244+211280+200960stray interrupt: vector 0x28, ipl 31 stray interrupt: vector 0x28, ipl 31 stray interrupt: vector 0x28, ipl 31 stray interrupt: vector 0x28, ipl 31 stray interrupt: vector 0x28, ipl 31 ...what's this? KA43-A V1.2 ID 08-00-2B-23-C2-5A MONO 0000.0001 ? CLK 0000.0005 NVR 0000.0001 ? DZ 0000.4001 00000001 00000001 00000001 00004001 00000000 00000000 MEM 0010.0001 01000000 FP 0000.0001 IT 0000.0001 SCSI-A 0404.0001 V1.60 FFFFFF05 FFFFFF05 00000001 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF03 FFFFFF05 ? SCSI-B 0000.4001 V1.60 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF05 FFFFFF03 FFFFFF05 SYS 0000.0001 ? SPGFX 100F.1F63 V1.3 00000060 00000068 00000068 00000000 00000000 00000000 NI 0100.0001 (Connected only a serial terminal to the printer port and the network) Regards, Holm </pre> Holm Tiffe 2013-03-21T19:10:46 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6652 <pre>Open The Attachment and read.</pre> info< at >mnitmail.mnit.ac.in 2013-03-19T03:53:17 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6641 <pre>Hello, i've got hands on a VaxStation 2000, with 14 MB RAM, but without monitor or harddrive. Fortunately i have an old 20 MB RLL Harddrive, which i could format with the ROM Test 70 command. (It has 782 cyl, 2 heads, and as a MFM drive 17 sec/track - 12 MB formatted). I can see the drive from an netbooted NetBSD, make an installboot, copy the kernel, etc. But i cannot bootstrap from it. I would like to bootstrap from MFM and then use a bigger SCSI harddrive to hold the root-filesystem, etc. KA410-B V2.3 F_..E...D...C...B...A...9...8...7...6...5...4_..3_..2_..1... ? E 0040 0000.0005 ? C 0080 0000.4001 ? 6 00A0 0000.4001 83 BOOT SYS ?02 EXT HLT PC = 000014C2 -DUA0 %VMB-F-ERR, PC = 00000765 %VMB-I-STS, R0 = 000008C2 84 FAIL Are there known compatibility issues with non-dec MFM drives and booting? maybe i did an error in specifing the disk as an RD51? I've tried several NetBSD and OpenBSD versions, the several installboot, or disklabel commands proceeded without error, i've even tried to dd the bootblock from a known bootable scsi drive to the mfm drive, or writing the bootblock directly onto rd0c. </pre> romanis< at >gmx.ch 2013-03-07T10:00:14 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6640 <pre>Hi all, I recently booted up my VS4000/90 to play with NetBSD. The CPU seems a bit faster than my Amiga 3000 with WarpEngine 40MHz 68040) and it has the benefit that it can do a complete build without failing, while my Amiga has some intermittent RAM or bus corruption that causes random GCC build failures every few days (especially frustrating when it takes 4-5 hours for an incremental build to proceed to the point where the previous build crashed). The SCSI controller is slower than the Amiga (it appears to be limited to 6.25MB/s transfers) and the Ethernet seems a bit slower as well, but the VS4000 is quite solid. I'd like to upgrade my build to use GCC 4.5.x, since the VAX is the only platform remaining on GCC 4.1.3. The first step would be to get a cross-build working, and then I believe gmp, mpfr, and/or mpc still need to be ported for a native build to work. The generated code seems to be almost identical, at least when the same CFLAGS are used, but I had to patch share/mk/bsd.sys.mk to add "-Wno-uninitialized" for VAX to fix some build failures for uninitialized variable warnings (this flag was already added for SH3 and m68k): diff -d -u -r1.223 bsd.sys.mk --- bsd.sys.mk 27 Jan 2013 02:31:44 -0000 1.223 +++ bsd.sys.mk 6 Mar 2013 19:15:50 -0000 &lt; at &gt;&lt; at &gt; -75,7 +75,8 &lt; at &gt;&lt; at &gt; &amp;&amp; (${MACHINE_ARCH} == "sh3eb" || \ ${MACHINE_ARCH} == "sh3el" || \ ${MACHINE_ARCH} == "m68k" || \ - ${MACHINE_ARCH} == "m68000")) + ${MACHINE_ARCH} == "m68000" || \ + ${MACHINE_ARCH} == "vax")) # XXX GCC 4.5 for sh3 and m68k (which we compile with -Os) is extra noisy for # cases it should be better with CFLAGS+= -Wno-uninitialized My kernel built with GCC 4.5 works fine, but I experienced some strange failures trying to start in multiuser after installing the system (the first being that /etc/rc seems to get bad output from rcorder and fails to run "d/swap2", with other scripts failing). I created a chroot to try to find the source of the problems and discovered a highly reproducible SIGILL crash starting /usr/bin/vi. Tracking down that crash revealed the following bug: In early startup of nvi, the function cl_keyval() is called via a pointer which is initialized in cl_func_std() in cl/cl_main.c. I discovered via gdb that cl_keyval was pointing to data rather than code, and the GDB disassembly showed this: 415 gp-&gt;scr_insertln = cl_insertln; 0x000161a8 &lt;+194&gt;: movl 0xfffffff8(fp),r0 0x000161ac &lt;+198&gt;: movab *0x860f4 &lt;_GLOBAL_OFFSET_TABLE_+820&gt;,0xacc(r0) 416 gp-&gt;scr_keyval = cl_keyval; 0x000161b5 &lt;+207&gt;: movl 0xfffffff8(fp),r0 0x000161b9 &lt;+211&gt;: movab *0x86170 &lt;__progname&gt;,0xac8(r0) 417 gp-&gt;scr_move = cl_move; 0x000161c2 &lt;+220&gt;: movl 0xfffffff8(fp),r0 0x000161c6 &lt;+224&gt;: movab *0x860f0 &lt;_GLOBAL_OFFSET_TABLE_+816&gt;,0xad4(r0) instead of: 415 gp-&gt;scr_insertln = cl_insertln; 0x00016402 &lt;+194&gt;: movl 0xfffffff8(fp),r0 0x00016406 &lt;+198&gt;: movab *0x8a8b4 &lt;_GLOBAL_OFFSET_TABLE_+832&gt;,0xacc(r0) 416 gp-&gt;scr_keyval = cl_keyval; 0x0001640f &lt;+207&gt;: movl 0xfffffff8(fp),r0 0x00016413 &lt;+211&gt;: movab *0x8a930 &lt;_GLOBAL_OFFSET_TABLE_+956&gt;,0xac8(r0) 417 gp-&gt;scr_move = cl_move; 0x0001641c &lt;+220&gt;: movl 0xfffffff8(fp),r0 0x00016420 &lt;+224&gt;: movab *0x8a8b0 &lt;_GLOBAL_OFFSET_TABLE_+828&gt;,0xad4(r0) Then I discovered that the link command had failed for vi and a few other binaries, with: /usr/src/netbsd/current/tools.vax/bin/../lib/gcc/vax--netbsdelf/4.5.4/../../../../vax--netbsdelf/bin/ld: BFD (NetBSD Binutils nb1) 2.21.1 assertion fail /usr/src/netbsd/current/src/tools/binutils/../../external/gpl3/binutils/dist/bfd/elf32-vax.c:1492 Adding some debug lines showed that the linker was trying to reference cl_keyval in the global offset table at 1 index past the end of the table: /usr/src/netbsd/current/tools.vax/bin/../lib/gcc/vax--netbsdelf/4.5.4/../../../../vax--netbsdelf/bin/ld: cl_main.o: h-&gt;got.offset=212 sgot-&gt;size=212 for `cl_keyval' from .text section The other failures all showed the same pattern. It seems like the size of the GOT is 1 entry too small, and the failure occurs only when I link with the GCC 4.5 version of /usr/lib/libgcc.a. So either there's a bug in binutils for VAX that's only triggered by the new GCC, or there's something wrong with GCC 4.5's libgcc. I compared recent NetBSD patches for GCC 4.1 for VAX to see which hadn't been copied to GCC 4.5. The only one I found was the patch to ffssi2, which can be applied to GCC 4.5 like this (but doesn't fix the linker bug): cvs diff: Diffing . Index: builtins.md =================================================================== RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/config/vax/builtins.md,v retrieving revision 1.2 diff -d -u -r1.2 builtins.md --- builtins.md 10 Nov 2011 17:16:30 -0000 1.2 +++ builtins.md 6 Mar 2013 19:30:34 -0000 &lt; at &gt;&lt; at &gt; -37,7 +37,7 &lt; at &gt;&lt; at &gt; " { rtx label = gen_label_rtx (); - emit_insn (gen_ffssi2_internal (operands[0], operands[1])); + emit_insn (gen_unspec_ffssi2 (operands[0], operands[1])); emit_jump_insn (gen_condjump (gen_rtx_NE(VOIDmode, cc0_rtx, const0_rtx), label)); emit_insn (gen_negsi2 (operands[0], const1_rtx)); emit_label (label); &lt; at &gt;&lt; at &gt; -45,10 +45,16 &lt; at &gt;&lt; at &gt; DONE; }") -(define_insn "ffssi2_internal" - [(set (match_operand:SI 0 "nonimmediate_operand" "=rQ") - (ffs:SI (match_operand:SI 1 "general_operand" "nrmT"))) - (set (cc0) (match_dup 0))] +;; +;; Set cc0 to match argument 1 since if it is 0, Z will be set just as +;; if a tst:SI was performed. If we did a match_dup 0, that wouldn't be +;; right since 0 will be set to (0+32) [the position (relative to the base) +;; of a bit one position to the left of the specified field]. +;; +(define_insn "unspec_ffssi2" + [(set (match_operand:SI 0 "nonimmediate_operand" "=g") + (unspec:SI [(match_operand:SI 1 "general_operand" "nrQ")] VUNSPEC_FFS)) + (set (cc0) (match_dup 1))] "" "ffs $0,$32,%1,%0") Index: vax.md =================================================================== RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/config/vax/vax.md,v retrieving revision 1.3 diff -d -u -r1.3 vax.md --- vax.md 5 Feb 2012 17:38:21 -0000 1.3 +++ vax.md 6 Mar 2013 19:30:34 -0000 &lt; at &gt;&lt; at &gt; -33,6 +33,7 &lt; at &gt;&lt; at &gt; [(VUNSPEC_BLOCKAGE 0) ; `blockage' insn to prevent scheduling across an ; insn in the code. (VUNSPEC_SYNC_ISTREAM 1) ; sequence of insns to sync the I-stream + (VUNSPEC_FFS 2) ; internal FFS for the expand (VAX_AP_REGNUM 12) ; Register 12 contains the argument pointer (VAX_FP_REGNUM 13) ; Register 13 contains the frame pointer (VAX_SP_REGNUM 14) ; Register 14 contains the stack pointer I tried to investigate how the GOT is created and sized, but can't figure out what's happening. I did notice in binutils/dist/bfd/elf32-vax.c that there are some comments about the first two entries of the GOT being reserved, but another section of code fills in the first three entries in the global offset table. So that could be the cause of the off-by-one index, but I don't see the code where the initial GOT is being allocated... /* Get the offset into the .got table of the entry that corresponds to this function. Each .got entry is 4 bytes. The first two are reserved. */ got_offset = (plt_index + 3) * 4; ... /* Fill in the first three entries in the global offset table. */ if (sgot-&gt;size &gt; 0) { if (sdyn == NULL) bfd_put_32 (output_bfd, (bfd_vma) 0, sgot-&gt;contents); else bfd_put_32 (output_bfd, sdyn-&gt;output_section-&gt;vma + sdyn-&gt;output_offset, sgot-&gt;contents); bfd_put_32 (output_bfd, (bfd_vma) 0, sgot-&gt;contents + 4); bfd_put_32 (output_bfd, (bfd_vma) 0, sgot-&gt;contents + 8); } elf_section_data (sgot-&gt;output_section)-&gt;this_hdr.sh_entsize = 4; I'll try to track this down further, but I'm hoping this info will be enough for someone else on the list with more experience in these areas to see what's going wrong. I'll be happy to test any patches anyone has (I'm doing cross-builds from a much faster box). The other question I have, since people have been discussing slow VAX performance recently on the list, is why these function pointers are being accessed via the global offset table anyway? The affected binaries are linking against shared libs but aren't themselves shared, but I've also seen it mentioned that the VAX ABI defines all code as PIC, but maybe that was referring to SVR4 or VMS? It seems like the linker should be able to create a direct reference to these function pointers. I also discovered that the linker is inserting a whole bunch of extra calls to reload r0 when I compile with "-g" (as in the above GDB output), so the non-debug version of the assembly code looks like: movl 16(%r7),%r0 movab cl_addstr,2704(%r0) movab cl_waddstr,2708(%r0) movab cl_attr,2712(%r0) ... which turns into: 0x0001501a &lt;+294&gt;: movl 0x10(r7),r0 0x0001501e &lt;+298&gt;: movab *0x63184 &lt;_GLOBAL_OFFSET_TABLE_+912&gt;,0xa90(r0) 0x00015027 &lt;+307&gt;: movab *0x630f8 &lt;_GLOBAL_OFFSET_TABLE_+772&gt;,0xa94(r0) 0x00015030 &lt;+316&gt;: movab *0x630f4 &lt;_GLOBAL_OFFSET_TABLE_+768&gt;,0xa98(r0) but the "-g" version of vi (compiled with "-O1 -fgcse -fstrength-reduce -fgcse-after-reload"), which doesn't inline cl_func_std(), turns into the following instructions: 0x000160ef &lt;+9&gt;: movl 0x10(r0),0xfffffff8(fp) 0x000160f4 &lt;+14&gt;: movl 0xfffffff8(fp),r0 0x000160f8 &lt;+18&gt;: movab *0x86158 &lt;_GLOBAL_OFFSET_TABLE_+920&gt;,0xa90(r0) 0x00016101 &lt;+27&gt;: movl 0xfffffff8(fp),r0 0x00016105 &lt;+31&gt;: movab *0x860cc &lt;_GLOBAL_OFFSET_TABLE_+780&gt;,0xa94(r0) 0x0001610e &lt;+40&gt;: movl 0xfffffff8(fp),r0 0x00016112 &lt;+44&gt;: movab *0x860c8 &lt;_GLOBAL_OFFSET_TABLE_+776&gt;,0xa98(r0) I have no idea why it keeps reloading r0 after every line, but it seems to be inserted by the linker, as the GCC assembly output for the "-g" version looks like: .LM84: movl 16(%r7),%r0 .LVL41: .LM85: movab cl_addstr,2704(%r0) .LM86: movab cl_waddstr,2708(%r0) .LM87: movab cl_attr,2712(%r0) One more anomaly that I noticed was that the version of /usr/bin/gdb compiled with GCC 4.1 fails to start from a GCC 4.5 chroot due to this error: Undefined symbol "__clz_tab" referenced from COPY relocation in /usr/bin/gdb-gcc41 So there's another data point that might help solve these linker mysteries. Thanks in advance for anyone who can help with this. Regards, Jake </pre> Jake Hamby 2013-03-06T19:58:09 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6638 <pre>Hi, I wish I could say I had the time to check this out in detail myself, but if anyone would like to look into why a NetBSD 6 VAX can be paniced from compiling, try to compile parallel/openmp or devel/sparsehash from pkgsrc and see why it's panicing. Thanks, John </pre> John Klos 2013-02-15T17:46:44 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6637 <pre>http://www.bellihan.com/biscuitattack/show.u.php?vision2 </pre> Элинка Задорожный 2013-02-11T11:53:14 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6620 <pre>Hello, nice to see the activity on this list :-) My vaxen (vaxes?) have spent a while asleep in storage, now I think it's time to power them up again. I converted the vax 6610 from three phase to single phase around ten years ago, it worked fine on single phase power. Now I plugged it in, turned the key and after a short audible pop nothing happened. Turning the key just results in a relay clicking, no fans, nothing, so I assume I must be something in the very beginning of the power distribution that made the pop noise. When I did the 3p-1p conversion, all I had were some descriptions, I did some sanity checks and rewired the box. Now I would like to have some schematics or at least block diagrams since there are quite a few enclosures inside the vax itself and I don't have a clue what they should be doing. There's nothing on bitsavers, does someone here have documentation for the vax6000 series? Or a pointer to some information? Regards, Lo </pre> hugl 2013-02-06T18:46:10 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6605 <pre>Since I want to post mortem debug my broken netbsd kernels with that scn driver, that auto restart at a halt instruction is annoying. As I wrote before I've set HALT to 3 before booting, but when the kernel is crashing it is set to 0 automagically. The Netbsd bootloader is faking an RPB in autoconf.c: ----------------------------------------------------------------------- long *bootregs; /* * Do some initial setup. Also create a fake RPB for net-booted machines * that don't have an in-prom VMB. */ void autoconf(void) { int copyrpb = 1; int fromnet = (bootregs[12] != -1); findcpu(); /* Configures CPU variables */ consinit(); /* Allow us to print out things */ scbinit(); /* Fix interval clock etc */ #define Holm #ifdef Holm vax_siedata = *(int *)(0x20040004); /* SIE address */ vax_boardtype |= vax_siedata &gt;&gt; 24; printf("\nvax_boardtype(sie): %x\n",vax_boardtype); #endif #ifdef DEV_DEBUG printf("\nRegister contents:\n"); for (copyrpb = 0; copyrpb &lt; 13; copyrpb++) printf("r%d: %lx\n", copyrpb, bootregs[copyrpb]); #endif switch (vax_boardtype) { case VAX_BTYP_780: case VAX_BTYP_790: case VAX_BTYP_8000: case VAX_BTYP_9CC: case VAX_BTYP_9RR: case VAX_BTYP_1202: if (fromnet == 0) break; copyrpb = 0; bootrpb.devtyp = bootregs[0]; bootrpb.adpphy = bootregs[1]; bootrpb.csrphy = bootregs[2]; bootrpb.unit = bootregs[3]; bootrpb.rpb_bootr5 = bootregs[5]; bootrpb.pfncnt = 0; break; break; case VAX_BTYP_RT300: if (fromnet == 0) break; copyrpb = 0; bootrpb.devtyp = 100; bootrpb.csrphy = 0x20008000; bootrpb.unit = 0; bootrpb.pfncnt = 0; break; ----------------------------------------------------------------------- ...and I think that the behavior with the reboot has something todo with that "bootregs". so I've looked at the ../../include/rpb.h file: ----------------------------------------------------------------------- /* * Look at "VAX/VMS Internals and Data Structures" around page 907 * to get more info about RPB. */ struct rpb { /* size description */ struct rpb *rpb_base; /* 4 physical base address of block */ void (*rpb_restart)(void);/* 4 physical address of restart routine */ long rpb_chksum;/* 4 checksum of first 31 longwords of restart */ long rpb_rstflg; /* 4 Restart in progress flag */ long rpb_haltpc; /* 4 PC at HALT/restart */ /* offset: 20 */ long rpb_haltpsl;/* 4 PSL at HALT/restart */ long rpb_haltcode;/* 4 reason for restart */ long rpb_bootr0;/* 24 Saved bootstrap parameters (R0 through R5) */ long rpb_bootr1; long rpb_bootr2; long rpb_bootr3; long rpb_bootr4; long rpb_bootr5; long iovec; /* 4 Address of bootstrap driver */ long iovecsz;/* 4 Size (in bytes) of bootstrap driver */ /* offset: 60 */ long fillbn; /* 4 LBN of seconday bootstrap file */ long filsiz; /* 4 Size (in blocks) of seconday bootstrap file */ long pfnmap[2]; /* 8 Descriptor of PFN bitmap */ long pfncnt; /* 4 Count of physical pages */ /* offset: 80 */ long svaspt; /* 4 system virtual address of system page table */ long csrphy; /* 4 Physical Address of UBA device CSR */ long csrvir; /* 4 Virtual Address of UBA device CSR */ long adpphy; /* 4 Physical Address of adapter configurate reg. */ long adpvir; /* 4 Virtual Address of adapter configurate reg. */ ----------------------------------------------------------------------- ...and so I need to know a little more. Above in rpb.h is the hint about that Look at "VAX/VMS Internals and Data Structures" around page 907 But this manual seems to be not existing as PDF or so. Does anyone have this on paper and could please doo a look at it? I want to know if the "HALT" Value from the firmware loader is lokated somewhere in the rpb astructure so I can it set right in the loader. I thought it is set somewhere in the 24 saved values and enabled DEV_DEBUG while building, but I can see nowhere a "3" in the registers at the start auf the autoconf: ----------------------------------------------------------------------- 2..1..0.. vax_boardtype(sie): a000009 Register contents: r0: 20042f75 r1: ffea00 r2: 1000 r3: ffba00 r4: 0 r5: 0 r6: 0 r7: 3fe6a8 r8: 800 r9: 1800 r10: 1800 r11: 0 r12: 200 ----------------------------------------------------------------------- Or what is that rpb_rstflag meaning, I read somewhere in the rtVAX manual that a restart should be prevented when the booted Os is broken (for debugging purposes). THX, Holm </pre> Holm Tiffe 2013-02-05T11:08:17 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6602 <pre>Hi! I wanted to do some GCC hacking, as it seems there might still be some hidden bugs in its current (trunk) version. So I installed NetBSD (6.0.1) in SIMH and built trunk GCC with the system GCC (4.1.3). This worked quite well and the driver itself works. However, `cc1', the actual C compiler, does not: root&lt; at &gt;simh-netbsd-1:/mnt/darkeye/src/linux/netbsd-install/bin# ./gcc ~/test.c gcc: error trying to exec '/mnt/darkeye/src/linux/netbsd-install/libexec/gcc/vax-unknown-netbsdelf6.0.1/4.8.0/cc1': execv: Cannot allocate memory I tried to run cc1 from within GDB, but that wasn't helpful either. As there's no `strace', I guess that it's really execv() that's failing. How do I debug this? root&lt; at &gt;simh-netbsd-1:/mnt/darkeye/src/linux/netbsd-install/libexec/gcc/vax-unknown -netbsdelf6.0.1/4.8.0# readelf -e ./cc1 ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Digital VAX Version: 0x1 Entry point address: 0xb3234 Start of program headers: 52 (bytes into file) Start of section headers: 9464244 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 6 Size of section headers: 40 (bytes) Number of section headers: 30 Section header string table index: 27 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .interp PROGBITS 000100f4 0000f4 000017 00 A 0 0 1 [ 2] .note.netbsd.iden NOTE 0001010c 00010c 000018 00 A 0 0 4 [ 3] .note.netbsd.pax NOTE 00010124 000124 000014 00 A 0 0 4 [ 4] .hash HASH 00010138 000138 0119ac 04 A 5 0 4 [ 5] .dynsym DYNSYM 00021ae4 011ae4 026580 10 A 6 1 4 [ 6] .dynstr STRTAB 00048064 038064 062c3a 00 A 0 0 1 [ 7] .gnu.version VERSYM 000aac9e 09ac9e 004cb0 02 A 5 0 2 [ 8] .gnu.version_r VERNEED 000af950 09f950 000030 00 A 6 1 4 [ 9] .rela.dyn RELA 000af980 09f980 0027e4 0c A 5 0 4 [10] .rela.plt RELA 000b2164 0a2164 000858 0c A 5 12 4 [11] .init PROGBITS 000b29bc 0a29bc 000011 00 AX 0 0 2 [12] .plt PROGBITS 000b29d0 0a29d0 000864 0c AX 0 0 4 [13] .text PROGBITS 000b3234 0a3234 523024 00 AX 0 0 4 [14] .fini PROGBITS 005d6258 5c6258 00000a 00 AX 0 0 2 [15] .rodata PROGBITS 005d6264 5c6264 09f3f0 00 A 0 0 4 [16] .eh_frame PROGBITS 00675654 665654 27a678 00 A 0 0 4 [17] .ctors PROGBITS 008ffccc 8dfccc 00002c 00 WA 0 0 4 [18] .dtors PROGBITS 008ffcf8 8dfcf8 000008 00 WA 0 0 4 [19] .jcr PROGBITS 008ffd00 8dfd00 000004 00 WA 0 0 4 [20] .data.rel.ro PROGBITS 008ffd04 8dfd04 0204d4 00 WA 0 0 4 [21] .dynamic DYNAMIC 009201d8 9001d8 0000f8 08 WA 6 0 4 [22] .got PROGBITS 009202d0 9002d0 001014 04 WA 0 0 4 [23] .data PROGBITS 009212e4 9012e4 00552c 00 WA 0 0 4 [24] .bss NOBITS 00926810 906810 028f54 00 WA 0 0 4 [25] .comment PROGBITS 00000000 906810 000078 01 MS 0 0 1 [26] .ident PROGBITS 00000000 906888 000037 00 0 0 1 [27] .shstrtab STRTAB 00000000 9068bf 0000f3 00 0 0 1 [28] .symtab SYMTAB 00000000 906e64 08ad60 10 29 25727 4 [29] .strtab STRTAB 00000000 991bc4 1287e0 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00010034 0x00010034 0x000c0 0x000c0 R E 0x4 INTERP 0x0000f4 0x000100f4 0x000100f4 0x00017 0x00017 R 0x1 [Requesting program interpreter: /usr/libexec/ld.elf_so] LOAD 0x000000 0x00010000 0x00010000 0x8dfccc 0x8dfccc R E 0x10000 LOAD 0x8dfccc 0x008ffccc 0x008ffccc 0x26b44 0x4fa98 RW 0x10000 DYNAMIC 0x9001d8 0x009201d8 0x009201d8 0x000f8 0x000f8 RW 0x4 NOTE 0x00010c 0x0001010c 0x0001010c 0x0002c 0x0002c R 0x4 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.netbsd.ident .note.netbsd.pax .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame 03 .ctors .dtors .jcr .data.rel.ro .dynamic .got .data .bss 04 .dynamic 05 .note.netbsd.ident .note.netbsd.pax MfG, JBG </pre> Jan-Benedict Glaw 2013-02-02T17:36:24 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6600 <pre>I tried to install 6.0.1 on my VS4000/60 last night and discovered that the le0 ethernet was not detected by the kernel in netboot install.ram.gz I am using the netboot loader from NetBSD 3.1 and it loads the image fine, but the kernel doesn't detect le0 and I can't continue with the install because there is no network device. I tried the same thing with older NetBSD installs and had to go back to 3.1.1 to get one that would detect the ethernet device. Anyone have similar problems with the VS4000/60. I notice that the VS4000/90 we've been reading about uses a different ethernet device. -chuck </pre> Charles Dickman 2013-01-30T18:16:37 http://comments.gmane.org/gmane.os.netbsd.ports.vax/6580 <pre> </pre> Secure HelpDesk Copyright © 2013-01-27T23:16:50 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.ports.vax