[Simh] trouble selecting VAX ethernet on CentOS
Michael L. Umbricht
mike at umbricht.org
Mon Feb 27 12:21:29 EST 2012
Ok, I'll give that and the other suggestions a try. I'm busy at work for
the next two days, but I'll work on this more later in the week.
One odd thing. If I type "at xq eth" (with no "0") it attaches to eth0
and works fine. However, if I type "at xq eth0" I get the segfault. I
would think eth0 would work with either naming scheme and point to the
same device...
Also, "at xq eth1" should attach to wlan0 from what you are saying, but
instead causes a segfault. Using "at xq wlan0" works.
I'm in a cafe with no 10b2 network :) but I'll try ETH 3 / eth1 later.
-mikeu
> -------- Original Message --------
> Subject: RE: [Simh] trouble selecting VAX ethernet on CentOS
> From: Mark Pizzolato - Info Comm <Mark at infocomm.com>
> Date: Mon, February 27, 2012 9:31 am
> To: "Michael L. Umbricht" <mike at umbricht.org>
> Cc: "simh at trailing-edge.com" <simh at trailing-edge.com>, Jan-Benedict
> Glaw <jbglaw at lug-owl.de>
>
>
> Hi Mike,
>
> I just got off a red-eye airplane flight and on the drive home from the airport I realized part of the problem you are having.
>
> I suspect that things will work just fine for you if you have "attach xq eth3" in your vax.ini
>
> This is due to the simh generic naming for Ethernet devices. Simh has names "eth0", "eth1".... which correspond to the number in column 1 of the output of 'show xq eth'.
>
> > > > ETH devices:
> > > > 0 eth0 (No description available) ! on-board gig ethernet
> > > > 1 wlan0 (No description available) ! on-board wireless
> > > > 2 virbr0 (No description available) ! used by VirtualBox
> > > > 3 eth1 (No description available) ! PCMCIA 10b2 or 10bT
>
> The simh Ethernet names take precedence over the physical device names. This means that if a name is of the form "ethN" then the simh naming convention is used. If the name doesn't have that form, then an open is attempted presuming that the name supplied is a physical Ethernet device name. If things succeed, then all is well.
>
> I don't have a good explanation for the segfault (that shouldn't happen), but I'll look into that later today. I may need to ask you to run some tests since I don't have a system which produces this failure.
>
> - Mark
>
> > -----Original Message-----
> > From: simh-bounces at trailing-edge.com [mailto:simh-bounces at trailing-
> > edge.com] On Behalf Of Michael L. Umbricht
> > Sent: Sunday, February 26, 2012 4:50 PM
> > To: Jan-Benedict Glaw
> > Cc: simh at trailing-edge.com
> > Subject: Re: [Simh] trouble selecting VAX ethernet on CentOS
> >
> > Here is the GDB output. -mikeu
> >
> > [root at rigel vms]# gdb ./vax
> > GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6) Copyright (C) 2010 Free
> > Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law. Type "show
> > copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-redhat-linux-gnu".
> > For bug reporting instructions, please see:
> > <http://www.gnu.org/software/gdb/bugs/>...
> > Reading symbols from /home/mikeu/Downloads/simhv38-
> > 2/vms/vax...done.
> > (gdb) run
> > Starting program: /home/mikeu/Downloads/simhv38-2/vms/vax
> > [Thread debugging using libthread_db enabled]
> >
> > VAX simulator V3.8-2
> > NVR: buffering file in memory
> > [New Thread 0x7ffff7fe0700 (LWP 3555)]
> > [New Thread 0x7fffd6e64700 (LWP 3556)]
> > RQ2: unit is read only
> > [New Thread 0x7fffd6462700 (LWP 3557)]
> > RQ3: unit is read only
> > [New Thread 0x7fffd5a60700 (LWP 3558)]
> > Listening on port 2020 (socket 13)
> > Modem control activated
> > Auto disconnect activated
> > sim> at xq eth1
> > libpcap version 1.0.0
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00000000004533e1 in eth_open (dev=Cannot access memory at address
> > 0x7fff00366877
> > ) at sim_ether.c:1454
> > 1454 savname = eth_getname(num, temp);
> > Missing separate debuginfos, use: debuginfo-install
> > glibc-2.12-1.47.el6_2.5.x86_64
> > libpcap-devel-1.0.0-6.20091201git117cb5.el6.x86_64
> > ncurses-devel-5.7-3.20090208.el6.x86_64
> > ncurses-libs-5.7-3.20090208.el6.x86_64 readline-devel-6.0-3.el6.x86_64
> > (gdb)
> >
> >
> >
> > > -------- Original Message --------
> > > Subject: Re: [Simh] trouble selecting VAX ethernet on CentOS
> > > From: Jan-Benedict Glaw <jbglaw at lug-owl.de>
> > > Date: Sun, February 26, 2012 5:45 pm
> > > To: "Michael L. Umbricht" <mike at umbricht.org>
> > > Cc: Mark Pizzolato - Info Comm <Mark at infocomm.com>,
> > > "simh at trailing-edge.com" <simh at trailing-edge.com>
> > >
> > >
> > > On Sun, 2012-02-26 15:16:21 -0700, Michael L. Umbricht
> > <mike at umbricht.org> wrote:
> > > > Yeah, I didn't have such a great night of sleep last night... I kind
> > > > of noticed "-aa" was but just did a c&p. Anyway, now it compiles!
> > > > Thank you, all, for the suggestions and help.
> > > >
> > > > Same sort of trouble, though. It only allows me to choose "eth"
> > > > which grabs eth0 or I can choose "wlan0" to grab the wireless. Any
> > > > attempt to attach to either "eth0" or "eth1" fails with a seg fault.
> > > >
> > > > -mikeu
> > > >
> > > > VAX simulator V3.8-2
> > > >
> > > > sim> at xq ?
> > > > libpcap version 1.0.0
> > > > ETH devices:
> > > > 0 eth0 (No description available) ! on-board gig ethernet
> > > > 1 wlan0 (No description available) ! on-board wireless
> > > > 2 virbr0 (No description available) ! used by VirtualBox
> > > > 3 eth1 (No description available) ! PCMCIA 10b2 or 10bT
> > > > 4 tap:tapN (Integrated Tun/Tap support) Select device (ethX or
> > > > <device_name>)? eth0 Segmentation fault (core dumped)
> > > >
> > > > sim> at xq eth
> > > > libpcap version 1.0.0
> > > > Eth: opened OS device eth0
> > > > sim> at xq wlan0
> > > > Eth: closed eth0
> > > > Eth: opened OS device wlan0
> > > > sim> at xq eth1
> > > > Eth: closed wlan0
> > > > Segmentation fault (core dumped)
> > >
> > > Are all object files built with -g and is the `vax' binary not
> > > stripped? Then you'd just run it with gdb:
> > >
> > > $ gdb ./vax .....
> > >
> > > Then do your work (-> make it segfault) and when you're back at GDB's
> > > prompt, use the `bt' command to show us where it's breaking.
> > >
> > > MfG, JBG
> > >
> > > --
> > > Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481
> > > Signature of: The real problem with C++ for kernel modules is:
> > > the second : the language just sucks.
> > > -- Linus Torvalds
> >
> > _______________________________________________
> > Simh mailing list
> > Simh at trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
More information about the Simh
mailing list