Re: DM9102A & Netra X1 (Was Re: Netra X1 boot getting closer)
On Fri, Aug 17, 2001 at 12:53:14AM +0100, Richard Mortimer wrote:
> Hi,
>
> Sorry for the delayed response hope that it is still of some use.
>
> Ben Collins writes:
> > On Sun, Aug 05, 2001 at 05:50:53PM +0100, Richard Mortimer wrote:
> > > Hi,
> > >
> > > David S. Miller writes:
> > > >
> > > > Richard Mortimer writes:
> > > > > static int csr0 = 0x00800000 | 0x9000
> > > >
> > > > Can you try values 0x00e00000 or just plain 0x0?
> > > >
> > > > These are the values the dmfe.c driver uses.
> > >
> > > Well the Tx timeouts seem to have stopped happening without me doing
> > > anything! I did try a number of different values - as follows
> >
> > Well, I've gotten serial console to an X1 to test out a new set of
> > debian tftp install images (thanks to Adam McKenna). Boots fine, and
> > the ethernet devices come up, however I'm having no luck getting things
> > working.
> >
>
> Can you point me to the tftp install images (are they somewhere to
> download) I will try them on my setup and see what happens.
http://auric.debian.org/~bcollins/disks-sparc/current/sun4u/tftpboot.img
> > Basically pings work, but the tx is recorded as a carrier error. If I
> > telnet to a known closed port, I get a connection refused, but if I
> > telnet to a known open port, the connection hangs and I get this to
> > kernel log:
> >
> > UDP: bad checksum. From 217.145.64.251:137 to 64.21.79.60:137 ulen 58
> > UDP: bad checksum. From 217.145.64.251:137 to 64.21.79.60:137 ulen 58
> > UDP: bad checksum. From 217.145.64.251:137 to 64.21.79.60:137 ulen 58
> > UDP: bad checksum. From 159.158.53.9:53 to 64.21.79.60:53 ulen 51
> > UDP: bad checksum. From 159.158.53.9:53 to 64.21.79.60:53 ulen 51
> > UDP: bad checksum. From 159.158.53.9:53 to 64.21.79.60:53 ulen 51
> >
>
> Are you seeing this on the X1 or on your other machines? I'm guessing
> that is was the X1 but I just want to check.
On the X1.
> Hmmm you say that you were using telnet but the bad checksums are from
> UDP with services dns (53) and netbios-ns (137).
Yeah, I suspect that is from getaddrinfo() call. The netbios is
impossible, since I have nothing that should be using that. Perhaps
something else on the lan.
> > Note, 64.21.79.60 is the local interface, and the connection I tried was
> > to 64.21.79.61:80, which is also the nameserver. Sorry I can't get
> > tcpdumps, since these are base disks, and I've no way to remotely get
> > anything else on there right now.
> >
>
> A few things to try. How about sending larger ping packets
>
> ping -s 1000
>
> or something similar.
Will do.
> Was this on 100 base-T or 10 base-T connections? Full or half
> duplex. I have only got a 10 base-T connection at the moment maybe
> that has something to do with it.
Did check. I'm check that later aswell.
> > Any ideas, or other tests? Note, I did check to be sure that the test to
> > clear the MRM was getting done. Cards are detected as so:
> >
> > eth0: Davicom DM9102/DM9102A rev 49 at 0x1fe02010100, EEPROM not present, 00:4C:69:6E:75:79, IRQ 6867584.
> > eth1: Davicom DM9102/DM9102A rev 49 at 0x1fe02010000, EEPROM not present, 00:4C:69:6E:75:7A, IRQ 6866880.
> > (the prom reports 0:3:ba:4:d6:84, weird)
> >
> > I'm using eth1, since that is what the person has connected.
> >
>
> One thing to note. It seems that eth0 is what Solaris calls dmfe1 and
> that eth1 is dmfe0 I guess that this doesn't make a difference. I use
> eth1 too!
Same for this case :)
--
.----------=======-=-======-=========-----------=====------------=-=-----.
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: