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
> 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.
Nobody has fixed this driver for 2.4 yet
> 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
Yep. Most probably it needs munging to use isa_memcpy_fromio and the like
or ioremap.
> 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...
Are you willing to be test victim for fixes ?
Alan Cox <[email protected]> wrote:
> Nobody has fixed this driver for 2.4 yet
I sort of guessed this....
> > 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
>
> Yep. Most probably it needs munging to use isa_memcpy_fromio and the like
> or ioremap.
Right... OK.... I'll leave that to someone else
> Are you willing to be test victim for fixes ?
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
> 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 :)
Well the driver is hideous (and apparently so is the hardware) so it may have
to wait until someone has plenty of time
>
> > > eth0: memprobe, Can't find memory at 0xc0000!
> > > 3c523.c: No 3c523 cards found
> >
> > Yep. Most probably it needs munging to use isa_memcpy_fromio and the
like
> > or ioremap.
>
> Right... OK.... I'll leave that to someone else
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.
> > Are you willing to be test victim for fixes ?
>
> Yes.
> And if you think the NFS problems might be fixable, I'll be pleased to
> keep the card out of the bucket.
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
> > > > eth0: memprobe, Can't find memory at 0xc0000!
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.
>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.
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. (-:
>Even if you don't use the card, it's be nice to have another user test it
>out before I submit the patch.
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/
On Thu, 01 Feb 2001 01:44:01 Tom Sightler wrote:
> 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.
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
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
--- 3c523.c.241 Fri Feb 2 21:09:20 2001
+++ 3c523.c Sun Feb 4 21:02:18 2001
@@ -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