Re: DM9102A & Netra X1 (Was Re: Netra X1 boot getting closer)
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.
> 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.
Hmmm you say that you were using telnet but the bad checksums are from
UDP with services dns (53) and netbios-ns (137).
> 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.
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.
> This is with a current vger CVS kernel (as of a few hours ago).
>
Yup, that looks to be what I was expecting although I have checked
about a week later!
> 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!
--
Richard Mortimer - richm@oldelvet dot netscapeonline dot co dot uk
Reply to: