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 = 0x0080 | 0x9000 Can you try values 0x00e0 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 0x1fe0201, 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 - [EMAIL PROTECTED] dot netscapeonline dot co dot uk
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 = 0x0080 | 0x9000 Can you try values 0x00e0 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 0x1fe0201, 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 \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: DM9102A Netra X1 (Was Re: Netra X1 boot getting closer)
On Sun, Aug 05, 2001 at 05:50:53PM +0100, Richard Mortimer wrote: Hi, David S. Miller writes: Richard Mortimer writes: static int csr0 = 0x0080 | 0x9000 Can you try values 0x00e0 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. 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 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. This is with a current vger CVS kernel (as of a few hours ago). 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 0x1fe0201, 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. -- .--===-=-==-=---==-=-. / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: DM9102A Netra X1 (Was Re: Netra X1 boot getting closer)
On Fri, Aug 10, 2001 at 10:57:15PM -0400, Ben Collins wrote: On Sun, Aug 05, 2001 at 05:50:53PM +0100, Richard Mortimer wrote: Hi, David S. Miller writes: Richard Mortimer writes: static int csr0 = 0x0080 | 0x9000 Can you try values 0x00e0 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. And before you ask Dave, I compiled them with egcs64 :) -- .--===-=-==-=---==-=-. / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: DM9102A Netra X1 (Was Re: Netra X1 boot getting closer)
Ben Collins writes: Excellent. I'm sure there are some happy X1 users out there :) Dave, if this looks ok, I can rip a new set of boot images with this patch and see if I can round up a few X1 users to test (I know of a few). I have no problems with it, I was going to put it into my tree and push it to Linus this evening. Later, David S. Miller davem@redhat.com
Re: DM9102A Netra X1 (Was Re: Netra X1 boot getting closer)
Hi, David S. Miller writes: Richard Mortimer writes: static int csr0 = 0x0080 | 0x9000 Can you try values 0x00e0 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 0x00e0 - network not working (has MRM bit set so not surprising). 0x00c0 - as above but without MRM - seems to work ok 0x0 - seems to work ok 0x00809000 - seems to work ok. (this is my original settings). With these results in mind it seems most sensible to use the last value because this has the correct address boundary alignment value for SPARC. Find below a patch which seems to work for me. I've assumed that this is generic to all DM9102 based cards so it isn't protected by any ifdefs or whatever. I would be grateful if people could try this and see if it works for you. patch is based on cvs as of today. Richard diff --recursive -u linux-cvs.010805.orig/drivers/net/tulip/tulip_core.c linux-cvs.010805/drivers/net/tulip/tulip_core.c --- linux-cvs.010805.orig/drivers/net/tulip/tulip_core.cSun Aug 5 11:16:04 2001 +++ linux-cvs.010805/drivers/net/tulip/tulip_core.c Sun Aug 5 15:50:51 2001 @@ -1420,6 +1420,10 @@ if (chip_idx == LC82C168) csr0 = ~0xfff1; /* zero reserved bits 31:20, 16 */ + /* DM9102A MRM doesn't work... */ + if (pdev-vendor == 0x1282 pdev-device == 0x9102) + csr0 = ~0x0120; /* zero MRM bit 21 bit 24 too */ + /* * And back to business */ @@ -1762,9 +1766,9 @@ kfree (tp-mtable); #ifndef USE_IO_OPS iounmap((void *)ioaddr); -#endif err_out_free_res: +#endif pci_release_regions (pdev); err_out_free_netdev: -- Richard Mortimer - [EMAIL PROTECTED] dot netscapeonline dot co dot uk
Re: DM9102A Netra X1 (Was Re: Netra X1 boot getting closer)
On Sun, Aug 05, 2001 at 05:50:53PM +0100, Richard Mortimer wrote: Hi, David S. Miller writes: Richard Mortimer writes: static int csr0 = 0x0080 | 0x9000 Can you try values 0x00e0 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 Excellent. I'm sure there are some happy X1 users out there :) Dave, if this looks ok, I can rip a new set of boot images with this patch and see if I can round up a few X1 users to test (I know of a few). Ben -- .--===-=-==-=---==-=-. / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
