Re: DM9102A & Netra X1 (Was Re: Netra X1 boot getting closer)
On Thu, Aug 16, 2001 at 08:30:56PM -0400, Ben Collins wrote: > 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. Nope. There are no local windows boxes on this lan and those IP addresses are not local. > > A few things to try. How about sending larger ping packets > > > > ping -s 1000 # ping -s 1000 64.21.79.61 PING 64.21.79.61 (64.21.79.61): 1000 data bytes 1008 bytes from 64.21.79.61: icmp_seq=0 ttl=255 time=3.2 ms 1008 bytes from 64.21.79.61: icmp_seq=1 ttl=255 time=0.5 ms 1008 bytes from 64.21.79.61: icmp_seq=2 ttl=255 time=0.5 ms 1008 bytes from 64.21.79.61: icmp_seq=3 ttl=255 time=0.5 ms 1008 bytes from 64.21.79.61: icmp_seq=4 ttl=255 time=0.5 ms --- 64.21.79.61 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.5/1.0/3.2 ms > > 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. It autonegotiates 100Mbps FDX under solaris. The Linux driver doesn't report the speed -- is there any way to obtain this information from ifconfig? I can have the network engineer force the port to 100FDX, so we can be sure that's what it's at if there is no other way to tell. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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)
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 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)
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 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] ' `---=--===-=-=-=-===-==---=--=---'
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)
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)
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. Later, David S. Miller davem@redhat.com
DM9102A & Netra X1 (Was Re: Netra X1 boot getting closer)
Good news I now have the network working. I'm seeing a number of transmit timeouts (see below) but don't seem to be losing packets. I found that as well as clearing bit 21 in csr0 that I also had to clear bit 24. That makes the csr0 assignment static int csr0 = 0x0080 | 0x9000 I suspect that the timeouts that I'm seeing probably have something to do with other dm9102A/pci effects. I will keep trying differing settings to see what effects they have. As for the timeouts I'm seeing NETDEV WATCHDOG: eth1 transmit timed out Whilst doing pings I get this message around 8 times a minute. Sometimes I see a number of pings sitting waiting to go and then suddenly I get a flurry of them (maybe up to 15 seconds late). I think that this is consistent with the transmit timeouts. Richard P.S. This is running 2.4.6-pre7 or thereabouts. I didn't need to go back to earlier versions to get the network errors removed. I guess that I ought to update to current cvs now that I seem to be making definite progress. Richard Mortimer writes: > Ben Collins writes: > > On Sat, Jul 21, 2001 at 12:14:49AM +0100, Richard Mortimer wrote: > > > We may be able to scrap the dmfe.c idea and keep with tulip. I did a > > > bit of looking into why I was seeing pci errors with the tulip > > > driver. After a bit of scratching around and a bit of a helpful > > > suggestion from a colleague it seems that the dm9102a chip has a bit > > > of a problem with Memory Read Multiple pci transactions (That is CSR0 > > > bit 21). If the MRM bit is cleared the pci errors go away and the chip > > > starts to act a bit more reasonably. > > > > This sounds an awful lot like the problems I am having with tulip on my > > g4, so it may not be an X1 issue. I had to back down to a version from > > around 2.4.[34]. Maybe you could try copying the tulip directory from > > that kernel version to 2.4.7, apply your patch and see how that works? > > I tried that and got the same result. Do you think it might be worth > trying 2.4.[34] on the X1 (with hand crafted patches to get the > machine to run at all?). > > Richard > > -- > Richard Mortimer - [EMAIL PROTECTED] dot netscapeonline dot co dot uk >
Re: Netra X1 boot getting closer
Ben Collins writes: > On Sat, Jul 21, 2001 at 12:14:49AM +0100, Richard Mortimer wrote: > > We may be able to scrap the dmfe.c idea and keep with tulip. I did a > > bit of looking into why I was seeing pci errors with the tulip > > driver. After a bit of scratching around and a bit of a helpful > > suggestion from a colleague it seems that the dm9102a chip has a bit > > of a problem with Memory Read Multiple pci transactions (That is CSR0 > > bit 21). If the MRM bit is cleared the pci errors go away and the chip > > starts to act a bit more reasonably. > > This sounds an awful lot like the problems I am having with tulip on my > g4, so it may not be an X1 issue. I had to back down to a version from > around 2.4.[34]. Maybe you could try copying the tulip directory from > that kernel version to 2.4.7, apply your patch and see how that works? I tried that and got the same result. Do you think it might be worth trying 2.4.[34] on the X1 (with hand crafted patches to get the machine to run at all?). Richard -- Richard Mortimer - [EMAIL PROTECTED] dot netscapeonline dot co dot uk
Re: Netra X1 boot getting closer
On Sat, Jul 21, 2001 at 12:14:49AM +0100, Richard Mortimer wrote: > Richard Mortimer writes: > > Diff below. Hope this is useful. > > > > Richard > > > > P.S. Sorry for slow turnaround. I had a few day job issues to sort out > > :-( > > > > Jeff Garzik writes: > > > Here is the patch I just checked in, which fixes some of the easier > > > issues. If you could diff against this, that would be great. > > Ok, > > We may be able to scrap the dmfe.c idea and keep with tulip. I did a > bit of looking into why I was seeing pci errors with the tulip > driver. After a bit of scratching around and a bit of a helpful > suggestion from a colleague it seems that the dm9102a chip has a bit > of a problem with Memory Read Multiple pci transactions (That is CSR0 > bit 21). If the MRM bit is cleared the pci errors go away and the chip > starts to act a bit more reasonably. This sounds an awful lot like the problems I am having with tulip on my g4, so it may not be an X1 issue. I had to back down to a version from around 2.4.[34]. Maybe you could try copying the tulip directory from that kernel version to 2.4.7, apply your patch and see how that works? Ben -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Netra X1 boot getting closer
Richard Mortimer writes: > Diff below. Hope this is useful. > > Richard > > P.S. Sorry for slow turnaround. I had a few day job issues to sort out > :-( > > Jeff Garzik writes: > > Here is the patch I just checked in, which fixes some of the easier > > issues. If you could diff against this, that would be great. Ok, We may be able to scrap the dmfe.c idea and keep with tulip. I did a bit of looking into why I was seeing pci errors with the tulip driver. After a bit of scratching around and a bit of a helpful suggestion from a colleague it seems that the dm9102a chip has a bit of a problem with Memory Read Multiple pci transactions (That is CSR0 bit 21). If the MRM bit is cleared the pci errors go away and the chip starts to act a bit more reasonably. That is I have changed csr0 as follows #elif defined(__sparc__) || defined(__hppa__) /* The UltraSparc PCI controllers will disconnect at every 64-byte * crossing anyways so it makes no sense to tell Tulip to burst * any more than that. */ static int csr0 = 0x0180 | 0x9000; /* static int csr0 = 0x01A0 | 0x9000; */ I know that this isn't a good way to do it (should probably have a check in tulip_init_one for the particular chip/rev maybe only on SPARC). Things don't really work (ideas as to what may be going wrong gratefully received). I can see data but things are getting very garbled i.e. From the remote (not Netra X1) side I can see 23:43:11.598499 B arp who-has patricia tell pingu 23:43:11.598499 > arp reply patricia (0:0:c0:a0:ce:14) is-at 0:0:c0:a0:ce:14 (8:0:20:1:2:3) 23:43:11.598499 < pingu > patricia: icmp: echo request (DF) 23:43:11.598499 > patricia > pingu: icmp: echo reply (DF) 23:43:11.598499 < pingu > patricia: icmp: echo request (DF) 23:43:11.598499 > patricia > pingu: icmp: echo reply (DF) 23:43:11.598499 < pingu > patricia: icmp: echo request (DF) 23:43:11.598499 > patricia > pingu: icmp: echo reply (DF) 23:43:12.598499 < pingu > patricia: icmp: echo request (DF) 23:43:12.598499 > patricia > pingu: icmp: echo reply (DF) 23:43:13.598499 < pingu > patricia: icmp: echo request (DF) 23:43:13.598499 > patricia > pingu: icmp: echo reply (DF) 23:43:14.598499 < pingu > patricia: icmp: echo request (DF) 23:43:14.598499 > patricia > pingu: icmp: echo reply (DF) 23:43:16.598499 > arp who-has pingu tell patricia (0:0:c0:a0:ce:14) 23:43:16.598499 < arp reply pingu is-at 8:0:20:1:2:3 (0:0:c0:a0:ce:14) Unfortunately something seems to go wrong on the Netra X1 side with reads because ping reports the following. linux:~ # ping patricia PING patricia (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=8 ttl=255 time=55.770 ms wrong data byte #8 should be 0x8 but was 0x0 39 77 80 16 0 1 0 0 0 0 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 64 bytes from 192.168.1.1: icmp_seq=7 ttl=255 time=1056.247 ms wrong data byte #8 should be 0x8 but was 0x0 39 77 80 15 0 1 0 0 0 0 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 64 bytes from 192.168.1.1: icmp_seq=6 ttl=255 time=2056.490 ms wrong data byte #8 should be 0x8 but was 0x0 39 77 80 14 0 1 0 0 0 0 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 Looking at these on the X1 with tcp dump seems to show that everything is ok linux:~ # less /tmp/eth0.dump User level filter, protocol ALL, datagram packet socket tcpdump: listening on eth0 23:47:30.938669 arp who-has patricia tell pingu (8:0:20:1:2:3) 23:47:30.939133 arp reply patricia is-at 0:0:c0:a0:ce:14 (8:0:20:1:2:3) 23:47:30.939173 pingu > patricia: icmp: echo request (DF) 23:47:30.939742 patricia > pingu: icmp: echo reply (DF) 23:47:31.930012 pingu > patricia: icmp: echo request (DF) 23:47:31.930603 patricia > pingu: icmp: echo reply (DF) 23:47:32.929982 pingu > patricia: icmp: echo request (DF) 23:47:32.930562 patricia > pingu: icmp: echo reply (DF) 23:47:33.929982 pingu > patricia: icmp: echo request (DF) 23:47:33.930562 patricia > pingu: icmp: echo reply (DF) 23:47:34.929989 pingu > patricia: icmp: echo request (DF) 23:47:34.930569 patricia > pingu: icmp: echo reply (DF) 23:47:35.927439 arp who-has pingu tell patricia 23:47:35.927481 arp reply pingu (8:0:20:1:2:3) is-at 8:0:20:1:2:3 (0:0:c0:a0:ce:14) Now with tcpdump -e -x (sorry different set of packets but same symptoms) cat /tmp/eth0.dump User level filter, protocol ALL, datagram packet socket tcpdump: listening on eth0 23:53:36.328546 0:0:0:0:0:0 8:0:20:1:2:3 ip 98: pingu > patricia: icmp: echo req uest (DF) 4500 0054 4000 4001 b750 c0a8 0107 c0a8 0101 0800 4bb9 01a2 3977 82f0 0005 0335 0809 0a0b 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 2627
Re: console=ttya (was Re: Netra X1 boot getting closer)
Richard Mortimer writes: > I took console=ttya out and it still works fine. I guess I shouldn't > be quite so lazy next time. Thanks for making sure this works :-) Later, David S. Miller davem@redhat.com
console=ttya (was Re: Netra X1 boot getting closer)
David S. Miller writes: > > Richard Mortimer writes: > > I just give the boot options > > > > console=ttya > > This bit should actually not be necessary. The kernel should ask the > boot firmware for the input-device and output-device variables and > they should point to the serial device. > > If this isn't happening on your X1, this is a bug. It would be nice > to fix it (hint hint :-) I took console=ttya out and it still works fine. I guess I shouldn't be quite so lazy next time. Richard -- Richard Mortimer - [EMAIL PROTECTED] dot netscapeonline dot co dot uk
Re: Netra X1 boot getting closer
Diff below. Hope this is useful.
Richard
P.S. Sorry for slow turnaround. I had a few day job issues to sort out
:-(
Jeff Garzik writes:
> Here is the patch I just checked in, which fixes some of the easier
> issues. If you could diff against this, that would be great.
> --
> Jeff Garzik | Andre the Giant has a posse.
> Building 1024|
> MandrakeSoft |
--- linux-cvs/linux/drivers/net/dmfe.c Sat Jun 30 13:10:18 2001
+++ drivers/net/dmfe.c Wed Jul 4 01:12:53 2001
@@ -77,9 +77,11 @@
#include
#include
+#if 0
#if BITS_PER_LONG == 64
#error FIXME: driver does not support 64-bit platforms
#endif
+#endif
/* Board/System/Debug information/definition */
@@ -127,8 +129,8 @@
#define DMFE_TXTH_1K 0xC000 /* TX TH 1K byte */
#define DMFE_TIMER_WUT (jiffies + HZ * 1)/* timer wakeup time : 1 second */
-#define DMFE_TX_TIMEOUT (HZ * 1.5) /* tx packet time-out time 1.5 s" */
-#define DMFE_TX_KICK (HZ * 0.5) /* tx packet Kick-out time 0.5 s" */
+#define DMFE_TX_TIMEOUT ((unsigned long) (HZ * 1.5)) /* tx packet time-out
time 1.5 s" */
+#define DMFE_TX_KICK ((unsigned long) (HZ * 0.5))/* tx packet Kick-out
time 0.5 s" */
#define DMFE_DBUG(dbug_now, msg, value) if (dmfe_debug || (dbug_now))
printk(KERN_ERR ": %s %lx\n", (msg), (long) (value))
@@ -161,18 +163,28 @@
/* Structure/enum declaration --- */
struct tx_desc {
u32 tdes0, tdes1, tdes2, tdes3;
+#if __sparc_v9__
+ unsigned long tx_buf_ptr;
+ unsigned long next_tx_desc;
+#else
u32 tx_skb_ptr;
u32 tx_buf_ptr;
u32 next_tx_desc;
u32 reserved;
+#endif
};
struct rx_desc {
u32 rdes0, rdes1, rdes2, rdes3;
+#ifdef __sparc_v9__
+ unsigned long rx_skb_ptr;
+ unsigned long next_rx_desc;
+#else
u32 rx_skb_ptr;
u32 rx_buf_ptr;
u32 next_rx_desc;
u32 reserved;
+#endif
};
struct dmfe_board_info {
@@ -392,7 +404,7 @@
const struct pci_device_id *ent)
{
unsigned long pci_iobase;
- u8 pci_irqline;
+ int pci_irqline;
struct dmfe_board_info *db; /* board information structure */
int i;
struct net_device *dev;
@@ -852,11 +864,14 @@
{
struct tx_desc *txptr;
unsigned long ioaddr = dev->base_addr;
+ u32 tdes0, tdes1;
txptr = db->tx_remove_ptr;
while(db->tx_packet_cnt) {
/* printk(": tdes0=%x\n", txptr->tdes0); */
- if (txptr->tdes0 & 0x8000)
+ tdes0 = le32_to_cpu(txptr->tdes0);
+ tdes1 = le32_to_cpu(txptr->tdes1);
+ if (tdes0 & 0x8000)
break;
/* A packet sent completed */
@@ -864,29 +879,29 @@
db->stats.tx_packets++;
/* Transmit statistic counter */
- if ( txptr->tdes0 != 0x7fff ) {
- /* printk(": tdes0=%x\n", txptr->tdes0); */
- db->stats.collisions += (txptr->tdes0 >> 3) & 0xf;
- db->stats.tx_bytes += txptr->tdes1 & 0x7ff;
- if (txptr->tdes0 & TDES0_ERR_MASK) {
+ if ( tdes0 != 0x7fff ) {
+ /* printk(": tdes0=%x\n", tdes0); */
+ db->stats.collisions += (tdes0 >> 3) & 0xf;
+ db->stats.tx_bytes += tdes1 & 0x7ff;
+ if (tdes0 & TDES0_ERR_MASK) {
db->stats.tx_errors++;
- if (txptr->tdes0 & 0x0002) {/* UnderRun */
+ if (tdes0 & 0x0002) { /* UnderRun */
db->tx_fifo_underrun++;
if ( !(db->cr6_data & CR6_SFT) ) {
db->cr6_data = db->cr6_data |
CR6_SFT;
update_cr6(db->cr6_data,
db->ioaddr);
}
}
- if (txptr->tdes0 & 0x0100)
+ if (tdes0 & 0x0100)
db->tx_excessive_collision++;
- if (txptr->tdes0 & 0x0200)
+ if (tdes0 & 0x0200)
db->tx_late_collision++;
- if (txptr->tdes0 & 0x0400)
+ if (tdes0 & 0x0400)
db->tx_no_carrier++;
- if (txptr->tdes0 & 0x0800)
+ if (tdes0 & 0x0800)
db->tx_loss_carrier++;
- if (txptr->tdes0 & 0x4000)
+ if (tdes0 & 0x4000)
db->tx_jabbe
Re: Netra X1 boot getting closer
Hi, Jeff Garzik writes: > FWIW dmfe.c is going to shrink very shortly. 2.5 is around the corner, > and it will start sharing code with other tulip clones, where possible. > Doing so will automatically fix some of the issues you probably haven't > even hit yet. I'm sure that I haven't hit some things yet...or at least I don't know that I haven't hit them! > Finally, are these dmfe boards available anywhere? I would love to get > my hands on one, as I have no test cards that use this driver. In this case (Netra-X1) the dmfe chip is built onto the motherboard of the box. Richard
Re: Netra X1 boot getting closer
Richard Mortimer writes: > I just give the boot options > > console=ttya This bit should actually not be necessary. The kernel should ask the boot firmware for the input-device and output-device variables and they should point to the serial device. If this isn't happening on your X1, this is a bug. It would be nice to fix it (hint hint :-) Later, David S. Miller davem@redhat.com
Re: Netra X1 boot getting closer
FWIW dmfe.c is going to shrink very shortly. 2.5 is around the corner, and it will start sharing code with other tulip clones, where possible. Doing so will automatically fix some of the issues you probably haven't even hit yet. (and if anyone is curious, dmfe is separate because it has differing alignment and CRC constraints than general tulip, and supporting both with one driver would slow down the main tulip) In theory the main tulip is supposed to work with the most recent DMFE's, but as we are seeing that doesn't appear to be the case... Finally, are these dmfe boards available anywhere? I would love to get my hands on one, as I have no test cards that use this driver. -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft |
Re: Netra X1 boot getting closer
Here is the patch I just checked in, which fixes some of the easier
issues. If you could diff against this, that would be great.
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |Index: drivers/net/dmfe.c
===
RCS file: /cvs/linux/drivers/net/dmfe.c,v
retrieving revision 1.27
diff -u -r1.27 dmfe.c
--- drivers/net/dmfe.c 2001/06/22 10:54:39 1.27
+++ drivers/net/dmfe.c 2001/06/29 00:20:00
@@ -130,7 +130,7 @@
#define DMFE_TX_TIMEOUT (HZ * 1.5) /* tx packet time-out time 1.5 s" */
#define DMFE_TX_KICK (HZ * 0.5) /* tx packet Kick-out time 0.5 s" */
-#define DMFE_DBUG(dbug_now, msg, vaule) if (dmfe_debug || dbug_now)
printk(KERN_ERR ": %s %x\n", msg, vaule)
+#define DMFE_DBUG(dbug_now, msg, value) if (dmfe_debug || (dbug_now))
printk(KERN_ERR ": %s %lx\n", (msg), (long) (value))
#define SHOW_MEDIA_TYPE(mode) printk(KERN_ERR ": Change Speed to %sMhz
%s duplex\n",mode & 1 ?"100":"10", mode & 4 ? "full":"half");
@@ -182,7 +182,7 @@
struct pci_dev * net_dev; /* PCI device */
spinlock_t lock;
- u32 ioaddr; /* I/O base address */
+ long ioaddr;/* I/O base address */
u32 cr0_data;
u32 cr5_data;
u32 cr6_data;
@@ -206,10 +206,10 @@
struct rx_desc *first_rx_desc;
struct rx_desc *rx_insert_ptr;
struct rx_desc *rx_ready_ptr; /* packet come pointer */
- u32 tx_packet_cnt; /* transmitted packet count */
- u32 tx_queue_cnt; /* wait to send packet count */
- u32 rx_avail_cnt; /* available rx descriptor count */
- u32 interval_rx_cnt;/* rx packet count a callback time */
+ unsigned long tx_packet_cnt;/* transmitted packet count */
+ unsigned long tx_queue_cnt; /* wait to send packet count */
+ unsigned long rx_avail_cnt; /* available rx descriptor
count */
+ unsigned long interval_rx_cnt; /* rx packet count a callback
time */
u16 HPNA_command; /* For HPNA register 16 */
u16 HPNA_timer; /* For HPNA remote device check */
@@ -357,15 +357,15 @@
static int dmfe_do_ioctl(struct DEVICE *, struct ifreq *, int);
static u16 read_srom_word(long ,int);
static void dmfe_interrupt(int , void *, struct pt_regs *);
-static void dmfe_descriptor_init(struct dmfe_board_info *, u32);
+static void dmfe_descriptor_init(struct dmfe_board_info *, unsigned long);
static void allocated_rx_buffer(struct dmfe_board_info *);
-static void update_cr6(u32, u32);
+static void update_cr6(u32, unsigned long);
static void send_filter_frame(struct DEVICE * ,int);
static void dm9132_id_table(struct DEVICE * ,int);
-static u16 phy_read(u32, u8, u8, u32);
-static void phy_write(u32, u8, u8, u16, u32);
-static void phy_write_1bit(u32, u32);
-static u16 phy_read_1bit(u32);
+static u16 phy_read(unsigned long, u8, u8, u32);
+static void phy_write(unsigned long, u8, u8, u16, u32);
+static void phy_write_1bit(unsigned long, u32);
+static u16 phy_read_1bit(unsigned long);
static u8 dmfe_sense_speed(struct dmfe_board_info *);
static void dmfe_process_mode(struct dmfe_board_info *);
static void dmfe_timer(unsigned long);
@@ -607,7 +607,7 @@
static void dmfe_init_dm910x(struct DEVICE *dev)
{
struct dmfe_board_info *db = dev->priv;
- u32 ioaddr = db->ioaddr;
+ unsigned long ioaddr = db->ioaddr;
DMFE_DBUG(0, "dmfe_init_dm910x()", 0);
@@ -693,7 +693,7 @@
/* No Tx resource check, it never happen nromally */
if (db->tx_queue_cnt >= TX_FREE_DESC_CNT) {
spin_unlock_irqrestore(&db->lock, flags);
- printk(KERN_ERR ": No Tx resource %d\n",
db->tx_queue_cnt);
+ printk(KERN_ERR ": No Tx resource %ld\n",
db->tx_queue_cnt);
return 1;
}
@@ -742,7 +742,7 @@
static int dmfe_stop(struct DEVICE *dev)
{
struct dmfe_board_info *db = dev->priv;
- u32 ioaddr = dev->base_addr;
+ unsigned long ioaddr = dev->base_addr;
DMFE_DBUG(0, "dmfe_stop", 0);
@@ -785,7 +785,7 @@
{
struct DEVICE *dev = dev_id;
struct dmfe_board_info *db = (struct dmfe_board_info *) dev->priv;
- u32 ioaddr = dev->base_addr;
+ unsigned long ioaddr = dev->base_addr;
unsigned long flags;
DMFE_DBUG(0, "dmfe_interrupt()", 0);
@@ -851,7 +851,7 @@
static void dmfe_free_tx_pkt(struct DEVICE *dev, struct dmfe_board_info * db)
{
struct tx_desc *txptr;
- u32 ioaddr = dev->base_addr;
+ unsigned long ioaddr = dev->base_addr;
txptr = db->tx_remove_ptr;
while(db->tx_packet_cnt) {
@@ -1275,7 +1275,7 @@
* Using Chain structure, and allocated Tx/Rx buffer
*/
-static void dmfe_descriptor_init(struct dmfe_board_info *db, u32 ioaddr)
+static void dm
Re: Netra X1 boot getting closer
Some of this is right but key things are wrong. The PCI DMA usage in
this driver is fundamentally fsck'd up, and it needs fixing.
The changes approach what needs to be done... but you need to adjust the
skip area in a portable manner, and do other changes to PCI DMA.
> @@ -157,18 +157,28 @@
> /* Structure/enum declaration --- */
> struct tx_desc {
> u32 tdes0, tdes1, tdes2, tdes3;
> +#if __sparc_v9__
> + ulong tx_buf_ptr;
> + ulong next_tx_desc;
> +#else
> u32 tx_skb_ptr;
> u32 tx_buf_ptr;
> u32 next_tx_desc;
> u32 reserved;
> +#endif
> };
>
> struct rx_desc {
> u32 rdes0, rdes1, rdes2, rdes3;
> +#ifdef __sparc_v9__
> + ulong rx_skb_ptr;
> + ulong next_rx_desc;
> +#else
> u32 rx_skb_ptr;
> u32 rx_buf_ptr;
> u32 next_rx_desc;
> u32 reserved;
> +#endif
> };
>
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
Re: Netra X1 boot getting closer
On Fri, Jun 29, 2001 at 12:17:12AM +0100, Richard Mortimer wrote: > Adam McKenna writes: > > On Mon, Jun 25, 2001 at 11:20:01PM +0100, Richard Mortimer wrote: > > > As for getting things to work on a Netra-X1 I have am able to get to > > > full multiuser mode (Suse-7.1) but have no network so that makes it > > > quite difficult to do things at present. I've still got a few issues > > > with the realtime clock (it always seems to report year as 2000) but > > > the network is my main priority at the moment. > > > > How did you get past that "initial console" error message? > > > I just give the boot options > > console=ttya > So in other words, boot -p console=ttya, or were you able to pass these options to TILO in some other way? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Netra X1 boot getting closer
David S. Miller writes:
>
> > > The dmfe in the X1 is identified as a Davicom 9102 on boot, it doesn't
> say
> > > DM9102(A) though.
> >
> > The tulip driver reports it as a DM9102(A) I guess that is probably
> > telling the truth but you never know.
> >
> > As for getting things to work on a Netra-X1 I have am able to get to
> > full multiuser mode (Suse-7.1) but have no network so that makes it
> > quite difficult to do things at present. I've still got a few issues
> > with the realtime clock (it always seems to report year as 2000) but
> > the network is my main priority at the moment.
>
> Have you been in contact with Jeff Garzik, the tulip maintainer?
> He can certainly assist you.
>
Yes, he suggested trying the dmfe.c driver. I have included a patch
for what I have done so far. The device isn't working as yet but the
driver does seem to be trying to talk to the card and isn't
complaining too much but I'm not seeing any traffic on my network
though.
The driver is basically reporting
"eth1: Tx timeout - resetting"
a couple of times when I try to configure the card. I have tried
specifying debug (level 5) when I do the modprobe. That gives the
following messages. Oh and I did use ifconfig to give an ethernet
address prior to assigning an inet address.
Jun 27 23:55:00 linux kernel: Davicom DM9xxx net driver, version 1.36p1 (May
12, 2001)
Jun 27 23:55:00 linux kernel: : dmfe_init_one() 0
Jun 27 23:55:00 linux kernel: eth0: Davicom DM9102 at 0x1fe02010100,
00:00:00:00:00:00, IRQ 7176448
Jun 27 23:55:00 linux kernel: : dmfe_init_one() 0
Jun 27 23:55:00 linux kernel: eth1: Davicom DM9102 at 0x1fe0201,
00:00:00:00:00:00, IRQ 7175744
Jun 27 23:55:08 linux kernel: : dmfe_open 0
Jun 27 23:55:08 linux kernel: : dmfe_init_dm910x() 0
Jun 27 23:55:08 linux kernel: : dmfe_parse_srom() 0
Jun 27 23:55:08 linux kernel: : dmfe_descriptor_init() 0
Jun 27 23:55:08 linux kernel: : send_filter_frame() 0
Jun 27 23:55:08 linux kernel: : dmfe_set_filter_mode() 0
Jun 27 23:55:08 linux kernel: : Set multicast address 0
Jun 27 23:55:08 linux kernel: : send_filter_frame() 0
Jun 27 23:55:08 linux kernel: : dmfe_set_filter_mode() 0
Jun 27 23:55:08 linux kernel: : Set multicast address 1
Jun 27 23:55:08 linux kernel: : send_filter_frame() 0
Jun 27 23:55:08 linux kernel: : dmfe_set_filter_mode() 0
Jun 27 23:55:08 linux kernel: : Set multicast address 2
Jun 27 23:55:08 linux kernel: : send_filter_frame() 0
Jun 27 23:55:08 linux kernel: : dmfe_set_filter_mode() 0
Jun 27 23:55:08 linux kernel: : Set multicast address 3
Jun 27 23:55:08 linux kernel: : send_filter_frame() 0
Jun 27 23:55:08 linux kernel: : dmfe_set_filter_mode() 0
Jun 27 23:55:08 linux kernel: : Set multicast address 3
Jun 27 23:55:08 linux kernel: : send_filter_frame() 0
Jun 27 23:55:09 linux kernel: : dmfe_start_xmit 0
Jun 27 23:55:10 linux kernel: : dmfe_start_xmit 0
Jun 27 23:55:11 linux kernel: : dmfe_timer() 0
Jun 27 23:55:13 linux kernel: : dmfe_start_xmit 0
Jun 27 23:55:14 linux last message repeated 2 times
...
Some comments on what I put in the patch.
1) Increased interrupt value from 1 byte to an integer.
2) Not sure about the entries in rx_desc and tx_desc. I put 2 ulongs
in there and dropped the 2 u32 values which do not seem to be used. I
don't think that these are used by the device (just for the driver to
remember what it did) so I think that it is ok.
3) I converted everything that looked like an ioaddr into a long.
Richard
--- /mnt/sunos/linux/src/linux-cvs/linux/drivers/net/dmfe.c Sun May 20
06:01:50 2001
+++ drivers/net/dmfe.c Fri Jun 29 00:07:36 2001
@@ -123,8 +123,8 @@
#define DMFE_TXTH_1K 0xC000 /* TX TH 1K byte */
#define DMFE_TIMER_WUT (jiffies + HZ * 1)/* timer wakeup time : 1 second */
-#define DMFE_TX_TIMEOUT (HZ * 1.5) /* tx packet time-out time 1.5 s" */
-#define DMFE_TX_KICK (HZ * 0.5) /* tx packet Kick-out time 0.5 s" */
+#define DMFE_TX_TIMEOUT ((ulong)(HZ * 1.5))/* tx packet time-out time 1.5
s" */
+#define DMFE_TX_KICK ((ulong)(HZ * 0.5)) /* tx packet Kick-out time 0.5
s" */
#define DMFE_DBUG(dbug_now, msg, vaule) if (dmfe_debug || dbug_now)
printk(KERN_ERR ": %s %x\n", msg, vaule)
@@ -157,18 +157,28 @@
/* Structure/enum declaration --- */
struct tx_desc {
u32 tdes0, tdes1, tdes2, tdes3;
+#if __sparc_v9__
+ ulong tx_buf_ptr;
+ ulong next_tx_desc;
+#else
u32 tx_skb_ptr;
u32 tx_buf_ptr;
u32 next_tx_desc;
u32 reserved;
+#endif
};
struct rx_desc {
u32 rdes0, rdes1, rdes2, rdes3;
+#ifdef __sparc_v9__
+ ulong rx_skb_ptr;
+ ulong next_rx_desc;
+#else
u32 rx_skb_ptr;
u32 rx_buf_ptr;
u32 next_rx_desc;
u32 reserved;
+#endif
};
struct dmfe_board_info {
@@ -178,7 +188,7 @@
struct pci_dev * net_dev; /* PCI device */
spinlock_t lock;
- u32 ioaddr; /* I/O
Re: Netra X1 boot getting closer
Adam McKenna writes: > On Mon, Jun 25, 2001 at 11:20:01PM +0100, Richard Mortimer wrote: > > As for getting things to work on a Netra-X1 I have am able to get to > > full multiuser mode (Suse-7.1) but have no network so that makes it > > quite difficult to do things at present. I've still got a few issues > > with the realtime clock (it always seems to report year as 2000) but > > the network is my main priority at the moment. > > How did you get past that "initial console" error message? > I just give the boot options console=ttya and everything comes up ok I also had to edit /etc/inittab to take away the mingetty's on tty1 to tty6 and enable the following line S0:123:respawn:/sbin/agetty -L 9600 ttyS0 In addition to that I had to add ttyS0 to /etc/securetty so that I could login as root on the console.
Re: Netra X1 boot getting closer
On Mon, Jun 25, 2001 at 11:20:01PM +0100, Richard Mortimer wrote: > As for getting things to work on a Netra-X1 I have am able to get to > full multiuser mode (Suse-7.1) but have no network so that makes it > quite difficult to do things at present. I've still got a few issues > with the realtime clock (it always seems to report year as 2000) but > the network is my main priority at the moment. How did you get past that "initial console" error message? --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Netra X1 boot getting closer
Richard Mortimer writes: > Yes I had a quick go with that but it hasn't been made big endian/64 > bit aware. I've done a bit of work to do this but have really been > concentrating my efforts on the tulip driver. Right. > > The dmfe in the X1 is identified as a Davicom 9102 on boot, it doesn't say > > DM9102(A) though. > > The tulip driver reports it as a DM9102(A) I guess that is probably > telling the truth but you never know. > > As for getting things to work on a Netra-X1 I have am able to get to > full multiuser mode (Suse-7.1) but have no network so that makes it > quite difficult to do things at present. I've still got a few issues > with the realtime clock (it always seems to report year as 2000) but > the network is my main priority at the moment. Have you been in contact with Jeff Garzik, the tulip maintainer? He can certainly assist you. Later, David S. Miller davem@redhat.com
Re: Netra X1 boot getting closer
Adam McKenna writes: > On Fri, Jun 22, 2001 at 01:19:27AM -0700, David S. Miller wrote: > > > > Adam McKenna writes: > > > Has anyone gotten this to successfully boot into the installer on an X1? > > > Also, it doesn't look as if the Ethernet device was detected. From > > posts I > > > read last week, this should be ok in 2.4.6? > > > > The ethernet issue was not resolved. > > Have you tried this driver?: > > PCI DM9102(A)/DM9132/DM9801 support > CONFIG_DM9102 > This driver is for DM9102(A)/DM9132/DM9801 compatible PCI cards from > Davicom ( http://www.davicom.com.tw ). If you have such a network > (Ethernet) card, say Y. Some information is contained in the file > Documentation/networking/dmfe.txt. > Yes I had a quick go with that but it hasn't been made big endian/64 bit aware. I've done a bit of work to do this but have really been concentrating my efforts on the tulip driver. > The dmfe in the X1 is identified as a Davicom 9102 on boot, it doesn't say > DM9102(A) though. The tulip driver reports it as a DM9102(A) I guess that is probably telling the truth but you never know. As for getting things to work on a Netra-X1 I have am able to get to full multiuser mode (Suse-7.1) but have no network so that makes it quite difficult to do things at present. I've still got a few issues with the realtime clock (it always seems to report year as 2000) but the network is my main priority at the moment. Richard
Re: Netra X1 boot getting closer
Adam McKenna writes: > On Fri, Jun 22, 2001 at 01:19:27AM -0700, David S. Miller wrote: > > The ethernet issue was not resolved. > > Have you tried this driver?: I haven't tried any driver, I don't have an X1 :-) Later, David S. Miller davem@redhat.com
Re: Netra X1 boot getting closer
On Fri, Jun 22, 2001 at 01:19:27AM -0700, David S. Miller wrote: > > Adam McKenna writes: > > Has anyone gotten this to successfully boot into the installer on an X1? > > Also, it doesn't look as if the Ethernet device was detected. From posts I > > read last week, this should be ok in 2.4.6? > > The ethernet issue was not resolved. Have you tried this driver?: PCI DM9102(A)/DM9132/DM9801 support CONFIG_DM9102 This driver is for DM9102(A)/DM9132/DM9801 compatible PCI cards from Davicom ( http://www.davicom.com.tw ). If you have such a network (Ethernet) card, say Y. Some information is contained in the file Documentation/networking/dmfe.txt. The dmfe in the X1 is identified as a Davicom 9102 on boot, it doesn't say DM9102(A) though. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Netra X1 boot getting closer
Adam McKenna writes: > Has anyone gotten this to successfully boot into the installer on an X1? > Also, it doesn't look as if the Ethernet device was detected. From posts I > read last week, this should be ok in 2.4.6? The ethernet issue was not resolved. Plus it doesn't show up in your boot because the driver for it (Tulip) is not built statically into Ben's kernels. But it won't work yet on this board anyways. Later, David S. Miller davem@redhat.com
Netra X1 boot getting closer
Well, I can *almost* boot my X1 now with the sun4u tftpboot.img on http://auric.debian.org/~bcollins. (6/21/01) -- Here's my dmesg: Boot device: /[EMAIL PROTECTED],0/[EMAIL PROTECTED] File and args: -p Using Onboard Transceiver - Link Up. Timeout waiting for ARP/RARP packet 28e200 240600 Server IP address: 165.254.98.30 Client IP address: 165.254.98.31 TILO Selecting sun4u kernel... / PROMLIB: Sun IEEE Boot Prom 4.0.6 2001/02/19 09:56 Linux version 2.4.4 ([EMAIL PROTECTED]) (gcc version 3.0 20010426 (Debian prerelease)) # 1 Thu May 17 11:59:44 EDT 2001 ARCH: SUN4U Ethernet address: 00:03:ba:04:d6:84 Remapping the kernel... done. On node 0 totalpages: 15586 zone(0): 16228 pages. zone(1): 0 pages. zone(2): 0 pages. Booting Linux... Found CPU 0 (node=f0071fb0,mid=0) Found 1 CPU prom device tree node(s). Kernel command line: -p Calibrating delay loop... 799.53 BogoMIPS Memory: 122632k available (1816k kernel code, 472k data, 200k init) [f80 0,67ec8000] Dentry-cache hash table entries: 16384 (order: 5, 262144 bytes) Buffer-cache hash table entries: 1024 (order: 0, 8192 bytes) Page-cache hash table entries: 16384 (order: 4, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 131072 bytes) POSIX conformance testing by UNIFIX PCI: Probing for controllers. PCI: Found SABRE, main regs at 01fe, wsync at 01fe1c20 SABRE: Shared PCI config space at 01fe0100 SABRE: DVMA at 6000 [2000] PCI: Address space collision on region 0 of device PCI device 1282:9102 PCI: Address space collision on region 0 of device PCI device 1282:9102 PCI: Address space collision on region 0 of device PCI device 10b9:5229 PCI: Address space collision on region 1 of device PCI device 10b9:5229 PCI: Address space collision on region 2 of device PCI device 10b9:5229 PCI: Address space collision on region 3 of device PCI device 10b9:5229 PCI: Address space collision on region 4 of device PCI device 10b9:5229 PCI0(PBMA): Bus running at 33MHz isa0: [dma] [rtc] [power] [SUNW,lomh] [serial] [serial] [flashprom] ebus: No EBus's found. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured Linux video capture interface: v1.00 block: queued sectors max/low 80901kB/26967kB, 256 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ALI15X3: IDE controller on PCI bus 00 dev 68 ALI15X3: chipset revision 195 ALI15X3: 100% native mode on irq 1,7cc ide0: BM-DMA at 0x1fe02000620-0x1fe02000627, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x1fe02000628-0x1fe0200062f, BIOS settings: hdc:pio, hdd:pio hda: ST320413A, ATA DISK drive ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide0 at 0x1fe02000600-0x1fe02000607,0x1fe0200060a on irq 1,7cc hda: 39102336 sectors (20020 MB) w/512KiB Cache, CHS=38792/16/63, UDMA(66) Partition check: hda: hda1 hda2 hda3 hda5 hda6 hda7 RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1431k freed loop: loaded (max 8 devices) rtc_init: no PC rtc found SCSI subsystem driver Revision: 1.00 request_module[scsi_hostadapter]: Root fs not mounted request_module[scsi_hostadapter]: Root fs not mounted request_module[scsi_hostadapter]: Root fs not mounted usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-ohci.c: USB OHCI at membase 0x1ff0100, IRQ 14,7e4 usb-ohci.c: usb-00:0a.0, PCI device 10b9:5237 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected usb.c: registered new driver hid mice: PS/2 mouse device common for all mice NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 16384 bind 16384) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem). Warning: unable to open an initial console. Has anyone gotten this to successfully boot into the installer on an X1? Also, it doesn't look as if the Ethernet device was detected. From posts I read last week, this should be ok in 2.4.6? Thanks, --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
