3Com 3c523 in IBM PS/2 9585: Can't load module in kernel 2.4.1

My first linux bug report :)

As some may have noticed I have been struggling with an MCA machine of the above type (see subject) for the last couple of days. I installed 2.4.1 to take advantage of devfs and potentially ReiserFS.

The machine has a 3Com 3c523 Etherlink/MC card installed. It worked under 2.2.17 but I can't load the module in 2.4.1.

When I modprobe 3c523 I get:

eth0: 3c523 adapter found in slot 3
eth0: 3Com 3c523 Rev 0xe at 0x1300
eth0: memprobe, Can't find memory at 0xc0000!
3c523.c: No 3c523 cards found

I also tried changing the 'Pack Buffer RAM Address Range' setting of the card, in the BIOS, to 0D8000-0DDFFF; I get the same error, but the 'Can't find memory at ...' error changes to 0xd8000.

cat /proc/mca/slot3 produces a segfault, I think it was Invalid EAP, but not sure as I am trying to fix the machine now so can't reproduce...

--
Michael Pacey
[email protected]
ICQ: 105498469

wd21 ltd - world domination in the 21st century

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Nobody has fixed this driver for 2.4 yet

Yep. Most probably it needs munging to use isa_memcpy_fromio and the like or ioremap.

Are you willing to be test victim for fixes ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I sort of guessed this....

Right... OK.... I'll leave that to someone else

Yes.

I must warn, however, that my testing may only get this detected and not much else; the card seems to have some problems even in 2.2.17; particularly, in NFS transfers it keeps saying NFS server not responding then NFS server OK. The NFS server is fine. I had put this down to a dodgy co-ax cable (I've run out of external TP transceivers) but I've replaced the
cable and terminators, and it is still bad.

I've now got the machine working smoothly with a previously-thought-dead 3c529 (currently 2.2.17, planning to upgrade to 2.4.1 - any probs?)

However, pings in 2.2.17 with the 3c523 work fine with even large packet size, so I'm not sure what's going on there.

The 3c529 was previously DOA. I cleaned the MCA contacts and wham! it sprang into life. Perhaps I should try this with the 3c523 :)

So, I don't know if the 3c523 hardware is OK. Therefore my testing might be of limited use. However, if you think it would help I'd be happy to be a test bed for patches to 2.4.1. Let me know what to patch. I'm off work for a week as of tomorrow lunchtime so the timing is pretty good :)

And if you think the NFS problems might be fixable, I'll be pleased to keep the card out of the bucket.

--
Michael Pacey
[email protected]
ICQ: 105498469

wd21 ltd - world domination in the 21st century

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Well the driver is hideous (and apparently so is the hardware) so it may have to wait until someone has plenty of time

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

like

I have patches that I believe fix this, but their own my box at home that I can't get do right now. When I get back from LinuxWorld tomorrow I'll pull them off and post them.

My patches also include changes that should improve this, but I doubt it will eliminate the problem. The basic thing here is that it's a horrid card in regards to performance and most of them only have 8K of buffer, it's just too easy to overrun the buffer, especially since the default is to allocate 4 transmit and 1 receive buffer (or 6 receive buffers it your lucky enough to have a 16K card). Because of this the card drops packets like crazy, which is bad for NFS, especially over UDP. My patches basically change the buffer allocation to only a single transmit buffer and whatever is left to receive buffers, this puts the card in a different mode of operation which seems to allow it to almost keep up. For me, this made the card usable, I still get drops, but their now much lower.

I'm not sure this is your problem, but I bet if you look at you ifconfig stats when your having the problem you'll see lots of dropped packets.

Even if you don't use the card, it's be nice to have another user test it out before I submit the patch.

Later,
Tom

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I get the same memprobe error. Haven't bothered with it for some time as I had problems getting the IBMMCASCSI recognized in 2.4.x but that seems to have been fixed now.

Can't wait. Once I get this working I should be able to get Linux installed on this old PS/2 box. Can't remember the model number off hand as I am in the lab at the moment but it's a 486DX2/50 with 10 (or 12) Mib RAM, a 300Mib SCSI disk or so with 3c523 ethernet card attached to a AUI-RJ45 transceiver and then to a 10Mbit hub (works under DOS) and two graphics cards (the internal one and an additional XGA/2 IIRC). Should make a nice MCA test system once I get it networked and can install Linux on it... And a nice serial console for kernel debugging, for that matter. (-:

I definitely will use it. You have just found another keen to test the patch person. (-:

Anton

"I strongly believe that trying to be clever is detrimental to your health." - Linus Torvalds
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Yes, lot's of dropped packets during NFS dropout.

This is great, even though I probably won't use the card; My friend has another 9585 and needs an ethernet card for that, and I'll be happy to test it on his behalf.

My machine's working perfectly now... IBM PS/2 9585, 3Com 32529, Adaptec AHA1640, Linux 2.4.1, a 9GB RAID0 array care of the md driver, and ReiserFS running on top of that... filled with MP3's! (just testing...)

Look forward to your patches.

--
Michael Pacey
[email protected]
ICQ: 105498469

wd21 ltd - world domination in the 21st century

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Ok all, here's a patch that attempts to make the 3c523 driver work again in 2.4.1. It includes the following changes:

- fix addresses with bus_to_virt
- reduce xmit buffers from 4 to 1 (puts driver in noop mode like ni52 driver)
- increase recv buffers from 6 to 9 (should help decrease dropped packets)
- add short delay to detect routine (makes cards detectable on fast machines)
- use eth_copy_and_sum for receiving packets

It passed basic stress testing with multiple, simultaneous ftp transfers.

Know bugs:

- Multicast still doesn't work at all (I have patches that seem to fix this but they have other problems)
- Still drops packets under heavy traffic (can be reduced further by lowering MTU on interface)
- Sometimes requires host to send a packet before it starts receiving (I can't reproduce this on my equipment anymore, but needs more testing)

Anyone with this card please test and report back.

Later,
Tom

@@ -148,9 +148,9 @@
 
 #define RECV_BUFF_SIZE 1524	/* slightly oversized */
 #define XMIT_BUFF_SIZE 1524	/* slightly oversized */
-#define NUM_XMIT_BUFFS 4	/* config for both, 8K and 16K shmem */
-#define NUM_RECV_BUFFS_8  1	/* config for 8K shared mem */
-#define NUM_RECV_BUFFS_16 6	/* config for 16K shared mem */
+#define NUM_XMIT_BUFFS 1	/* config for both, 8K and 16K shmem */
+#define NUM_RECV_BUFFS_8  4	/* config for 8K shared mem */
+#define NUM_RECV_BUFFS_16 9	/* config for 16K shared mem */
 
 #if (NUM_XMIT_BUFFS == 1)
 #define NO_NOPCOMMANDS		/* only possible with NUM_XMIT_BUFFS=1 */

@@ -303,13 +303,13 @@
 	char *iscp_addrs[2];
 	int i = 0;
 
- p->base = where + size - 0x01000000;
- p->memtop = phys_to_virt(where) + size;
- p->scp = (struct scp_struct *)phys_to_virt(p->base + SCP_DEFAULT_ADDRESS);
+ p->base = (unsigned long) bus_to_virt((unsigned long)where) + size - 0x01000000;
+ p->memtop = bus_to_virt((unsigned long)where) + size;
+ p->scp = (struct scp_struct *)(p->base + SCP_DEFAULT_ADDRESS);
 	memset((char *) p->scp, 0, sizeof(struct scp_struct));
 	p->scp->sysbus = SYSBUSVAL;	/* 1 = 8Bit-Bus, 0 = 16 Bit */
 
- iscp_addrs[0] = phys_to_virt(where);
+ iscp_addrs[0] = bus_to_virt((unsigned long)where);
 	iscp_addrs[1] = (char *) p->scp - sizeof(struct iscp_struct);
 
 	for (i = 0; i < 2; i++) {

@@ -325,6 +325,7 @@
 
 		/* apparently, you sometimes have to kick the 82586 twice... */
 		elmc_id_attn586();
+ 

	DELAY(1);

if (p->iscp->busy) { /* i82586 clears 'busy' after successful init */

	return 0;

@@ -344,8 +345,8 @@
elmc_id_reset586();
DELAY(2);

- p->scp = (struct scp_struct *) phys_to_virt(p->base + SCP_DEFAULT_ADDRESS);
- p->scb = (struct scb_struct *) phys_to_virt(dev->mem_start);
+ p->scp = (struct scp_struct *) (p->base + SCP_DEFAULT_ADDRESS);
+ p->scb = (struct scb_struct *) bus_to_virt(dev->mem_start);
p->iscp = (struct iscp_struct *) ((char *) p->scp - sizeof(struct iscp_struct));

memset((char *) p->iscp, 0, sizeof(struct iscp_struct));
@@ -518,7 +519,8 @@
}
dev->mem_end = dev->mem_start + size; /* set mem_end showed by 'ifconfig' */

- ((struct priv *) (dev->priv))->base = dev->mem_start + size - 0x01000000;
+ ((struct priv *) (dev->priv))->memtop = bus_to_virt(dev->mem_start) + size;
+ ((struct priv *) (dev->priv))->base = (unsigned long) bus_to_virt(dev->mem_start) + size - 0x01000000; alloc586(dev);

elmc_id_reset586(); /* make sure it doesn't generate spurious ints */
@@ -944,7 +946,8 @@

		if (skb != NULL) {
 	 
			skb->dev = dev;
 	 
			skb_reserve(skb, 2);	/* 16 byte alignment */
- 
				memcpy(skb_put(skb, totlen), (u8 *)phys_to_virt(p->base) + (unsigned long) rbd->buffer, totlen);
+ 
				skb_put(skb,totlen);
+ 
				eth_copy_and_sum(skb, (char *) p->base+(unsigned long) rbd->buffer,totlen,0);
 	 
			skb->protocol = eth_type_trans(skb, dev);
 	 
			netif_rx(skb);
 	 
			p->stats.rx_packets++;

@@ -1086,6 +1089,7 @@
static int elmc_send_packet(struct sk_buff *skb, struct net_device *dev) {
int len;
+ int i;
#ifndef NO_NOPCOMMANDS
int next_nop;
#endif

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/