[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: tme and ./MY-SUN4C:8: tme/machine/sun4: No such file or directory
On Tue, 18 Mar 2008, fredette%csail.mit.edu@localhost wrote:
> > #1 0x00007f7ff83058af in tme_scsi_device_target_f ()
> > from /usr/pkg/lib/tme/tme_scsi.so.0
> I haven't tried 4.0 myself. This looks like a SCSI opcode
> that I haven't emulated yet. The SCSI emulation is poor and
> just indexes an array of function pointers with the opcode -
> and when the entry for an opcode is NULL it segfaults.
I am looking for a way to document some steps and take some screenshots of
installing some sun or sparc system with NetBSD 4.0 or newer. I am writing
about NetBSD, but it mostly covers installation on i386 or amd64, so I
want to mention sun2, sun3, sparc, and/or sparc64 also.
Does anyone know if other NetBSD 4.0 or newer will install with tme? I
only tried NetBSD/sparc.)
Since 3.1 did work for me does anyone know if the initial display before
sysinst starts is the same as 4.0? (Or I can try to tell by reading
source.) I see other docs for tme are for NetBSD 1.6 -- I didn't try that
Or any other emulator to try?
> > Any suggestions or examples for accessing the host system over network?
> Outbound packets injected using bpf are never passed up the host's
> network stack; they're just transmitted directly out the interface,
> so you can't communicate with the local host. Adding a NAT-like
> network option that will use regular sockets instead of bpf is on
> the list of things tme needs.
Thanks for the info. I couldn't ping my gateway either. I was using
a wireless adapter so maybe that is not allowed.
How does it know what interface? I also tried assigning IP on network for
my other interface but can't get to devices on that network either.
> Those bpf3s are documentation bugs. It looks like multiple /dev/bpfN
> devices aren't needed anymore in recent NetBSD, opening the single
> /dev/bpf multiple times must work now.
Thanks again for the info. And thanks for your software.
Jeremy C. Reed
Main Index |
Thread Index |