As I hear nothing from David Hinds, I'll try here...
I have a Sony Vaio PCG-C1X portable with generic NE2000 compatible
10/100 MBit PCMCIA ethercard (PCMCIA Technology OEM). With 2.0.38 this
works fine using pcnet_cs from pcmcia-cs-3.0.14 (I had to add line to
hw_info as instructed in PCMCIA-HOWTO).
On 2.2. series with pcmcia-cs-3.1.10 and on 2.3.99-pre2 with pcnet_cs
distributed with the kernel it only works partially. When I insert the
card it gets detected normally and interface is set up correctly (but
the detection event gets logged twice (?)). When I ping external
computer I get following line twice in my syslog, but then the ping
works.
Mar 29 20:24:39 moebius kernel: eth0: interrupt(s) dropped!
If I try pinging my machine from the external machine (Solaris 2.6),
most of the time the ping does not work at all, but sometimes it
temporarily works, especially if I try to initiate TCP connection from
my machine (seems as if the remote machine learned temporarily the MAC
address of my machine from the TCP connection negotiation).
If I try opening TCP connections I sometimes get past connection
negotiation and receive some data back from the remote side, but just
as often it just hangs during connection negotiation. I never get past
receiving or sending more than a very small (<200 bytes payload)
quantity of data. Trying to open TCP connection from the remote to my
machine never seems to work.
Further weirdness is that after a while (10-50 packets) the ping
starts to display consistent 1 second roundtrip time (normal is
10ms). Starting ping again restores the 10ms behaviour. It seems as if
ping packets got somehow crossed so receiving side is out of sync from
sending side by one packet.
Associated with ping weirness following syslog messages appear now and
then
Mar 29 20:26:42 moebius kernel: eth0: Too much work at interrupt,
status 0x02
or
Mar 29 20:26:42 moebius kernel: eth0: Too much work at interrupt,
status 0x40
With ifconfig I can see that errors, dropped, and overruns are all zero.
Our network uses some sort of Cisco switch in autolearning mode. I
have observed that it usually takes 10-20 seconds of continuous
pinging for it to learn that my computer is connected, but from there
on things work. I doubt this is the cause because everything works
well with 2.0.38. Unfortunately I do not have control over the switch.
I have checked and double checked and I believe I do not have
interrupt conflict. The interrupts are assigned exatly the same way as
they are assigned under 2.0.38, namely I force the ethercard to IRQ 11
by using exclude statements to make sure that's the only one available
for PCMCIA. I believe this IRQ is not used by any of the built-in
hardware.
With symptoms this weird, I'd appreciate some ideas. Please tell me what
I can do to debug this or to help to debug this.
--Sampo
P.S. Please find appended a patch to fix the hw_info in pcnet_cs.c
diff -c pcnet_cs.c.orig pcnet_cs.c
*** pcnet_cs.c.orig Wed Mar 29 22:29:54 2000
--- pcnet_cs.c Wed Mar 29 22:31:15 2000
***************
*** 212,218 ****
{ /* SuperSocket RE450T */ 0x0110, 0x00, 0xe0, 0x98, 0 },
{ /* Volktek NPL-402CT */ 0x0060, 0x00, 0x40, 0x05, 0 },
{ /* NEC PC-9801N-J12 */ 0x0ff0, 0x00, 0x00, 0x4c, 0 },
! { /* PCMCIA Technology OEM */ 0x01c8, 0xa0, 0x0c, 0 }
};
#define NR_INFO (sizeof(hw_info)/sizeof(hw_info_t))
--- 212,218 ----
{ /* SuperSocket RE450T */ 0x0110, 0x00, 0xe0, 0x98, 0 },
{ /* Volktek NPL-402CT */ 0x0060, 0x00, 0x40, 0x05, 0 },
{ /* NEC PC-9801N-J12 */ 0x0ff0, 0x00, 0x00, 0x4c, 0 },
! { /* PCMCIA Technology OEM */ 0x01c8, 0x00, 0xa0, 0x0c, 0 }
};
#define NR_INFO (sizeof(hw_info)/sizeof(hw_info_t))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:29 EST