[Simh] trouble selecting VAX ethernet on CentOS
Michael L. Umbricht
mike at umbricht.org
Tue Feb 28 18:20:17 EST 2012
Very cool! I have one more busy day before I can play. I'll try this out
in the next couple days and send a full report by Saturday.
I currently have these 6 interfaces, but that does not include the PC
Card that gets named eth1
Thank you very much,
-mikeu
[mikeu at rigel Desktop]$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:26:B9:24:D8:B0
inet addr:192.168.214.254 Bcast:192.168.214.255
Mask:255.255.255.0
inet6 addr: fe80::226:b9ff:fe24:d8b0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33064 errors:0 dropped:0 overruns:0 frame:0
TX packets:31810 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32485115 (30.9 MiB) TX bytes:6032798 (5.7 MiB)
Interrupt:17
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:82 errors:0 dropped:0 overruns:0 frame:0
TX packets:82 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5624 (5.4 KiB) TX bytes:5624 (5.4 KiB)
pan0 Link encap:Ethernet HWaddr 4E:4D:DF:52:34:08
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
virbr0 Link encap:Ethernet HWaddr 52:54:00:4D:C2:17
inet addr:192.168.122.1 Bcast:192.168.122.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:2093 (2.0 KiB)
virbr0-nic Link encap:Ethernet HWaddr 52:54:00:4D:C2:17
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
wlan0 Link encap:Ethernet HWaddr 00:21:6A:AE:D9:08
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[mikeu at rigel Desktop]$ cat /proc/net/dev
Inter-| Receive |
Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo: 5624 82 0 0 0 0 0 0
5624 82 0 0 0 0 0 0
eth0:32487353 33078 0 0 0 0 0 0
6039459 31828 0 0 0 0 0 0
wlan0: 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
pan0: 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
virbr0: 0 0 0 0 0 0 0 0
2093 22 0 0 0 0 0 0
virbr0-nic: 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
> -------- Original Message --------
> Subject: RE: [Simh] trouble selecting VAX ethernet on CentOS
> From: Mark Pizzolato - Info Comm <Mark at infocomm.com>
> Date: Tue, February 28, 2012 5:16 pm
> To: "simh at trailing-edge.com" <simh at trailing-edge.com>, "Michael L.
> Umbricht" <mike at umbricht.org>
> Cc: Mark Pizzolato - Info Comm <Mark at infocomm.com>
>
>
> On Monday, February 27, 2012 at 2:48 PM, Mark Pizzolato wrote:
>
> > On Monday, February 27, 2012 at 2:37 PM, Michael L. Umbricht wrote:
>
> > > My version info is below.
>
> > >
>
> > > I pulled pcap from the CentOS repo, and it looks very old. Circa 2008/9 if the
>
> > > version number is correct. That could be part of the trouble.
>
> > > I'll try getting the latest from tcpdump later in the week when I have a bit
>
> > > more time to fiddle with this.
>
> >
>
> > I've just downloaded CentOS 6.2 x64 and am in the process of installing a
>
> > VirtualBox VM running it.
>
> >
>
> > Do not bother messing with the www.tcpdump.org libpcap. All observations
>
> > to date have shown that current OS distributed libpcap is sufficient for the
>
> > needs of simh. The distro's libpcap (and libpcap-devel) is always much easier
>
> > to install in a consistent fashion. I just asked to be sure I wasn't chasing what
>
> > appeared to be a OS distributed libpcap but wasn't.
>
> >
>
> > Thanks for the info.
>
> >
>
> > I'll let you know what I find.
>
>
>
> I downloaded an ISO image: CentOS-6.2-x86_64-bin-DVD1.iso
>
> I installed a VM using this Image onto an empty virtual disk which is 64GB in size.
>
> During the install I selected a Desktop install.
>
>
>
> Once the install finished, I created my user account and logged in.
>
> I needed to install gcc and libpcap-devel
>
>
>
> I pulled down the current simh source from github with wget and built a vax simulator.
>
> I then (as root) ran the resulting vax binary. I was able to attach eth0 without any problem.
>
> I shutdown the VM and added 2 more network interfaces (attached externally to different networks).
>
> I started the system and once again, things worked completely as expected (without any SegFaults).
>
> I looked for differences in your and my systems. Your 'uname -a' had centos.plus while mine didn't. I changed the configuration to use the centos.plus kernel components and tried again.
>
> Things still work as expected...
>
>
>
> Clearly there is something different about your system and the network devices it may have, as compared to the simple case of my virtual machine with only Ethernet devices.
>
>
>
> Can you send me the output of 'ifconfig -a'? Also the contents of /proc/net/dev
>
>
>
> The difference between my working environment and your non-working one must have something to do with the difference in hardware/network stacks in use. That is why I asked for your 'ifconfig -a' output and the /proc/net/dev content.
>
>
>
> By the way, your observation that 'attach xq eth' worked for you was actually a bug in the name matching logic. The code in eth_open tries to accommodate several different forms of 'names'. The first checked is the ethN form which I previously described. The second is a check against the device description, which if an exact match is found the corresponding interface is opened. The third check is against the OS device name. The names and/or description checks are against the data which is shown in the output of 'show xq eth'. The bug which the 'attach xq eth' found was that the device name check was only using the length of the argument (eth in this case 3) to compare against each of the actual device names and it considered a match if the first 3 bytes of the names matched. Since the scan went in the order displayed by 'show xq eth' the match found your eth0 interface.
>
>
>
> Each of those scanning mechanisms (as well as the code which produces the output of 'show xq eth') use a common routine to build the array of device names/descriptions. I can't really explain why in your case the process which creates this table for the number lookup is failing while each of the other cases doesn't fail ('show xq eth' works for you and the fact that you can do a 'atta xq wlan0' works means that BOTH the description check didn't SegFault and the Device name didn't segfault AND it actually found the name.
>
>
>
> AHHH HAHHH!!!!
>
>
>
> I found the issue. The common routine which builds the above mentioned list could overrun the list by 1 if the set of potential pcap connectable devices was greater than 10 (it must be on your system but not on my test system). I changed the constant which determines the size of this table from 10 to 3 and I reproduced the SegFault failure. The difference in behavior for the 3 cases which used this common routine had to do with the different number of local variables on the stack which got overwritten by the error.
>
>
>
> The code has been fixed and is available at https://github.com/markpizz/simh/zipball/master
>
>
>
>
>
> > - Mark
>
> >
>
> >
>
> > >
>
> > > -mikeu
>
> > >
>
> > >
>
> > > [mikeu at rigel Desktop]$ cat /etc/redhat-release CentOS release 6.2 (Final)
>
> > > [mikeu at rigel Desktop]$ uname -a Linux rigel 2.6.32-
>
> > > 220.4.2.el6.centos.plus.x86_64 #1 SMP Mon Feb 13
>
> > > 23:42:47 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux [mikeu at rigel
>
> > > Desktop]$
>
> > >
>
> > > [mikeu at rigel Desktop]$ yum info libpcap* Loaded plugins: fastestmirror,
>
> > > refresh-packagekit Loading mirror speeds from cached hostfile
>
> > > * base: yum.singlehop.com
>
> > > * centosplus: mirror.vcu.edu
>
> > > * extras: centos.mirror.nac.net
>
> > > * rpmforge: fr2.rpmfind.net
>
> > > * updates: mirror.umd.edu
>
> > > Installed Packages
>
> > > Name : libpcap
>
> > > Arch : x86_64
>
> > > Epoch : 14
>
> > > Version : 1.0.0
>
> > > Release : 6.20091201git117cb5.el6
>
> > > Size : 324 k
>
> > > Repo : installed
>
> > > From repo : anaconda-CentOS-201106060106.x86_64
>
> > > Summary : A system-independent interface for user-level packet
>
> > > capture
>
> > > URL : http://www.tcpdump.org
>
> > > License : BSD with advertising
>
> > > Description : Libpcap provides a portable framework for low-level network
>
> > > : monitoring. Libpcap can provide network statistics collection,
>
> > > : security monitoring and network debugging. Since almost every
>
> > > system
>
> > > : vendor provides a different interface for packet capture, the libpcap
>
> > > : authors created this system-independent API to ease in porting and
>
> > > to
>
> > > : alleviate the need for several system-dependent packet capture
>
> > > modules
>
> > > : in each application.
>
> > > :
>
> > > : Install libpcap if you need to do low-level network traffic monitoring
>
> > > : on your network.
>
> > >
>
> > > Name : libpcap-devel
>
> > > Arch : x86_64
>
> > > Epoch : 14
>
> > > Version : 1.0.0
>
> > > Release : 6.20091201git117cb5.el6
>
> > > Size : 134 k
>
> > > Repo : installed
>
> > > From repo : base
>
> > > Summary : Libraries and header files for the libpcap library
>
> > > URL : http://www.tcpdump.org
>
> > > License : BSD with advertising
>
> > > Description : Libpcap provides a portable framework for low-level network
>
> > > : monitoring. Libpcap can provide network statistics collection,
>
> > > : security monitoring and network debugging. Since almost every
>
> > > system
>
> > > : vendor provides a different interface for packet capture, the libpcap
>
> > > : authors created this system-independent API to ease in porting and
>
> > > to
>
> > > : alleviate the need for several system-dependent packet capture
>
> > > modules
>
> > > : in each application.
>
> > > :
>
> > > : This package provides the libraries, include files, and other
>
> > > : resources needed for developing libpcap applications.
>
> > >
>
> > >
>
> > >
>
> > > > -------- 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 3:02 pm
>
> > > > To: "Michael L. Umbricht" <mike at umbricht.org>, Mark Pizzolato - Info
>
> > > > Comm <Mark at infocomm.com>
>
> > > >
>
> > > >
>
> > > > On Monday, February 27, 2012 at 9:21 AM, Michael L. Umbricht wrote:
>
> > > >
>
> > > > > 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.
>
> > > >
>
> > > >
>
> > > >
>
> > > > These are definitely odd, but they each exercise (or avoid) a common
>
> > code
>
> > > path. The failing cases are each trying to translate a simh ethN name to an
>
> > OS
>
> > > device name by calling eth_getname.
>
> > > >
>
> > > >
>
> > > >
>
> > > > > I'm in a cafe with no 10b2 network :) but I'll try ETH 3 / eth1 later.
>
> > > >
>
> > > >
>
> > > >
>
> > > > Given the pattern of failures calling eth_getname, I now think this will
>
> > also
>
> > > fail.
>
> > > >
>
> > > >
>
> > > >
>
> > > > NONE of them should fail (at least not with a SegFault), so your case is
>
> > > somewhat simplified.
>
> > > >
>
> > > >
>
> > > >
>
> > > > Can you describe the exact version of CentOS you are running. Maybe I
>
> > > can reproduce this here and get directly to the root cause.
>
> > > >
>
> > > >
>
> > > >
>
> > > > Did you install the OS supplied libpcap-devel package or did you
>
> > download
>
> > > the latest source from www.tcpdump.org and somehow build it to
>
> > > install/replace the OS supplied code?
>
> > > >
>
> > > >
>
> > > >
>
> > > > I know the makefile announces that you are using the Linux vendor's
>
> > > libpcap components, but it makes that determination by finding the pcap.h
>
> > > include files in /usr/include/pcap.h and finding the libpcap.so file available.
>
> > A
>
> > > creative install of the www.tcpdump.org components could cause this
>
> > > announcement and determination to be incorrect.
>
> > > >
>
> > > >
>
> > > >
>
> > > > Let me know.
>
> > > >
>
> > > >
>
> > > >
>
> > > > - Mark
>
> > > >
>
> > > >
>
> > > >
>
> > > > > -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