PCI Intel EtherExpressPro100 strangeness on C200 machine.

Hello list. For some reason my onboard LAN devices all mysteriously died and disappeared from the firmware, so I purchased an eepro100 card to try and get some networking connectivity back.

When I modprobe eepro100 it seems to be ok. I can do an 'ifup -a' and then ifconfig lists my eth0 and it appears to be configured properly. I can ping other servers in my LAN, and I can do an ftp login, but as soon a I type "ls" it goes out to lunch and locks up.

Likewise I can ping numeric ip's on the internet, but name resolution is not working.

Could this be an endianness problem? Any ideas?

Any tips on how to reactivate the onboard ether devices would be greatly appreciated too.

Hi,

just append " || defined(__hppa__)" to line 47 of drivers/net/eepro100.c I got mine working that way.

Regards,
andreas

@@ -44,7 +44,7 @@
 /* Set the copy breakpoint for the copy-only-tiny-buffer Rx method.
    Lower values use more memory, but are faster. */
 #if defined(__alpha__) || defined(__sparc__) || defined(__mips__) || \
-    defined(__arm__)
+    defined(__arm__) || defined(__hppa__)
 static int rx_copybreak = 1518;
 #else
 static int rx_copybreak = 200;

I tried your suggestions and built a new kernel, but it still behaves as it did prior to the modification.

To summarize (with eepro100 in PCI slot ):

- can ping using a dotted quad
- cannot ping using dns
- can ftp login to another machine on my LAN
- when I try to list files or download it locks up.

Onboard tulip and LASI ethernet devices seem to have died.

This is a major headache. I don't believe that the Debian 3.0 cdrom will boot on the C200, and without network I can't upgrade the 0.9.3 cdrom. Its a catch-22!

Just to be sure, you did rebuild the eepro100 module too?

I'm using the nic for hours now and it is working perfectly.

With the original module (2.4.19-pa2) I wasn't able to receive ip packets larger than approx 150 bytes. For example a ping -s 100 went through while ping -s 200 didn't.

Btw. the diff was from 2.4.19-pa2. Maybe there have been other changes if you are using an older kernel.

The address of the maintainer Andrey V. Savochkin <[email protected]> seems to be broken. So no help from there.

regards
andreas

Yes I made a monolithic kernel, so it rebuilt eepro100.c

Prior, I was using a stock Debian vmlinux-2.4.18-32 kernel so there is a good chance that the Debian packager had made the same modification to the source.

Hmmm....

I guess I will try that one then. Thanks.

The RX_ALIGN shouldn't strictly be needed. It's a performance improvement. It means the misaligned access handling isn't working right. And should be spewing something to the kernel dmesg buf. IIRC, Randolph Chung has done a great job on getting most of the misaligned access emulation working right. If you get console/dmesg output when using eepro100, please post it here.

If someone with CVS access has time, please enable the RX_ALIGN code for __hppa__ as well. I have other changes outstanding (cpqfc) that I want to finished up and committed first.

grant

Here is my dmesg output that your requested, and my ifconfig status right after booting. I typed this in by hand, hopefully no typos.

eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[email protected]> and others
eth0: Intel Corp. 82557 [Ethernet Pro 100], 00:90:27:60:CB:E6, IRQ 130.
Board assembly 721383-006, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x8b51f404).

eth0 Link encap:Ethernet HWaddr:00:90:27:60:CB:E6

        inet addr:192.168.100.115  Bcast:192.168.100.255  Mask:255.255.255.0
        RX packets:25 errors:0 dropped:0 overruns:0 frame:0
        TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:100
        RX bytes:2668 (2.6 KiB)  TX bytes:558 (558.0 b)
        Interrupt:130 Base address:0xf000

Well, I'm heading out to camp. Back on Monday.

Cheers!
- Doug

Ok, I'm back from camp ( and work ). Here's what I did today:

(a) Installed new coin battery on motherboard
(b) Switched EtherPro100 card to 5V/32bit PCI slot

None of this brought back my motherboard's original ethernet devices. I wish I could figure out what happened, but I know that the never worked again after plugging a HCRX-24Z card into the GSC bus. I got one error somewhere that said something like

"... Something really bad has happened ..." but it never re-appeared, and neither did the tulip or LASI ether devices.

Ok, through methodical emperical experimentation I have found that the command:

"# ping -s 157 servername"

Will succeed. However,

"# ping -s 158 servername"

Will fail.

I have kernel 2.1.18, and will try 2.4.19 but I have to burn a cd to get it on the machine so I have procrastinated. I will give it a shot tonight, apply Andreas's patch and recompile.

About the last thing in the world I want to do is buy a tape drive just to reload my firmware. Maybe one of you wizards could cook up a way to flash it from linux like is done on a Netwinder?

Later!
- Doug

Sounds like static or something fried the GSC devices on that bus.

ouch.

...

If you can ressurrect built-in LAN or find an add-on Tulip card, you could netboot the firmware update (it's a LIF image).

grant

Perhaps that old type of install, build SCSI disk on different machine, physically move disk ot C200.

Mike

Michael S. Zick writes...

Yeah or a scsi cdrom. Just use cdrecord to burn the firmware update lifimage straight to the disk.

Matt Taggart
[email protected]

Just an update, I managed to burn the firmware update to cdrom, boot it, and have updated my firmware to the latest (6.3) for this machine. It did not fix the onboard ethernet devices, however :-(

Now I have managed to get the source for linux-2.4.19-pa3 onto the machine, made the small patch on line 47 of eepro100.c, and
it is busily compiling away. Will post results later.

- Doug

Victory! The 2.4.19-pa3 kernel was the charm!

PCI IntelEtherExpressPro100 now working on C200!

I did add the " || defined(__hppa__)"
on line 47 of eepro100.c

Thanks very much to everybody for all the help,
this box has a new lease on life now!

Yaay!

Sorry - I just noticed that eepro100 for 2.4.19 is substantially different from 2.4.18. My previous repl was WRT 2.4.18 (RX_ALIGN).

BTW, rx_copybreak is a module param and there must be some way of passing that in as a boot param too.

grant

All along I wondered why people would quote line numbers instead of code bits (and linenumbers).

Didn't you notice the attachment?

I guess I should put patches inline next time...

For some definition of "working".
That #ifdef "forces" the RX copy *most* of the time.
If the dev_alloc_skb() call fails , the "broken" code path is taken anyway.

The code needs to differentiate architectures that *could* (but it's not efficient) avoid the copy from architectures that *must* copy.

Patch below assumes the archs listed in the ifdef *must* copy. If the dev_alloc_skb() fails, we drop the packet and update stats. Not sure if I'm doing the right thing in the failure case though...

grant

Index: drivers/net/eepro100.c
===================================================================
RCS file: /var/cvs/linux/drivers/net/eepro100.c,v
retrieving revision 1.17

diff -u -p -r1.17 eepro100.c
@@ -1,4 +1,3 @@
-/* drivers/net/eepro100.c: An Intel i82557-559 Ethernet driver for Linux. */
 /*
    NOTICE: For use with late 2.3 kernels only.
    May not compile for kernels 2.3.43-47.

@@ -43,11 +42,13 @@ static int rxdmacount /* = 0 */;
 
 /* Set the copy breakpoint for the copy-only-tiny-buffer Rx method.
    Lower values use more memory, but are faster. */
+static int rx_copybreak = 200;
+
 #if defined(__alpha__) || defined(__sparc__) || defined(__mips__) || \
-    defined(__arm__)
-static int rx_copybreak = 1518;
+    defined(__arm__) || defined(__hppa__)
+#define RX_COPY(x)		1
 #else
-static int rx_copybreak = 200;
+#define RX_COPY(x) (x < rx_copybreak)
 #endif
 
 /* Maximum events (Rx packets, etc.) to handle at each interrupt. */

@@ -1760,10 +1761,17 @@ speedo_rx(struct net_device *dev)
 		} else {
 			struct sk_buff *skb;
 
-			/* Check if the packet is long enough to just accept without
-			   copying to a properly sized skbuff. */
-			if (pkt_len < rx_copybreak
-				&& (skb = dev_alloc_skb(pkt_len + 2)) != 0) {
+			/* Check if the packet is long enough to just accept
+			 * without copying to a properly sized skbuff.
+			 */
+			if (RX_COPY(pkt_len)) {
+				skb = dev_alloc_skb(pkt_len + 2);
+				if (!skb) {
+					printk(KERN_ERR "%s: dropping packet,"
+						"no user space buffer!",
+						status);
+					goto update_stats;
+				}
 				skb->dev = dev;
 				skb_reserve(skb, 2);	/* Align IP on 16 byte boundaries */
 				/* 'skb_put()' points to the start of sk_buff data area. */

@@ -1797,6 +1805,7 @@ speedo_rx(struct net_device *dev)
 			sp->stats.rx_packets++;
 			sp->stats.rx_bytes += pkt_len;
 		}
+update_stats:
 		entry = (++sp->cur_rx) % RX_RING_SIZE;
 		sp->rx_ring_state &= ~RrPostponed;
 		/* Refill the recently taken buffers.

Andreas,
I've just committed this change to 2.4.19-pa8.
Works on my c3000 too.

I wasn't real happy with this method of disabling something we know doesn't work. The compiler can't optimize it away. The alternative I was playing with is at
ftp://ftp.parisc-linux.org/patches/eepro100-rxcopy.diff

but I'm not comfortable committing that since I don't know if other arches *can't* support it or just prefer it be disabled.

thanks,
grant

Well, got KDE to work, but it just seems slow even with my 1.6MB of RAM and 2GB of swap on my C180. I guess my questions would be what would be an alternative that might run faster and/or be better overall than KDE? Gnome? I guess I'm looking for what you guys think is the best desktop environment to run. Thanks.

derek

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

17Mb is pushing it. KDE/GNOME are about the same size. xfce/rox need a lot less

Nothing like applying a little hardware to cure speed demons.

I would suggest more memory, at least 32MB and even 64MB and or a faster hard disk drive (: 10k rpm :) the latter has sped my 712/60 to twice the normal performance when using a GUI.

Hehe... you should try running a 715 or 712! The C-Class machines positively scream! I agree though, KDE is somewhat sluggish on my C200, but really not too bad, its usable. I've heard rumors that someday the hppa c-library could be optimized to run _much_ faster but its still a baby as far as linux is concerned - I'm just tickled that it even works... I wanted another non-x86 machine (also have a Netwinder), but SGI's are pretty exotic (though tempting), Alpha's seem super cool but are somewhat expensive and often in bad disrepair, and Sun machines are either too expensive or too old. The hppa boxes provided a nice economy and are very much contenders with any of the aforementioned architectures. In its day a C200 running HP/UX was supposedly able to smoke a 600MHz Alpha! Obviously there is a lot of optimization still to do...

I started off with a 715/80, got Woody running good on it, played with it for almost a year, then sold it on Ebay for a small profit (Debian sells!) and rolled my dough into the C200. I'm rather happy with its performance, although it doesn't hold a candle to my super dual pentium-II 450 monster box, still its a cool and useful machine, and very nice for making sure that your app is portable, compiling your own hppa debs, etc. I don't run mine 24/7 because it has pretty high power consumption, so the Netwinder is my little server machine -> http://www.gyrodynamic.net

Well, I sent you a private email with my suggestions about E, but now that I think about it, BlackBox isn't too bad with 8bpp color. Assuming that somebody has fixed "update-menus" really any Debian window manager should work with KDE, Gnome, and other X apps. The Debian menus should provide access to all the installed packages which is all you really need.

BTW, regarding "update-menus" - the last time I tried it on hppa it worked as root but segfaulted as a normal user.

- Doug

Hehe... you should try running a 715 or 712! The C-Class machines positively scream! I agree though, KDE is somewhat sluggish on my C200, but really not too bad, its usable. I've heard rumors that someday the hppa c-library could be optimized to run _much_ faster but its still a baby as far as linux is concerned - I'm just tickled that it even works... I wanted another non-x86 machine (also have a Netwinder), but SGI's are pretty exotic (though tempting), Alpha's seem super cool but are somewhat expensive and often in bad disrepair, and Sun machines are either too expensive or too old. The hppa boxes provided a nice economy and are very much contenders with any of the aforementioned architectures. In its day a C200 running HP/UX was supposedly able to smoke a 600MHz Alpha! Obviously there is a lot of optimization still to do...

I started off with a 715/80, got Woody running good on it, played with it for almost a year, then sold it on Ebay for a small profit (Debian sells!) and rolled my dough into the C200. I'm rather happy with its performance, although it doesn't hold a candle to my super dual pentium-II 450 monster box, still its a cool and useful machine, and very nice for making sure that your app is portable, compiling your own hppa debs, etc. I don't run mine 24/7 because it has pretty high power consumption, so the Netwinder is my little server machine -> http://www.gyrodynamic.net

Well, I sent you a private email with my suggestions about E, but now that I think about it, BlackBox isn't too bad with 8bpp color. Assuming that somebody has fixed "update-menus" really any Debian window manager should work with KDE, Gnome, and other X apps. The Debian menus should provide access to all the installed packages which is all you really need.

BTW, regarding "update-menus" - the last time I tried it on hppa it worked as root but segfaulted as a normal user.

- Doug

whoops...meant to say 1.6GB.....;)

sorry...

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com