The problem i was experiencing (albeit with 2.4.10-ac11) was losing
connectivity for 2-10s at a time, no messages in the logs, and the machine
would resume activity as normal afterwards. The machine is connected to
the network via two NICs (3c59x and eepro100) and i only get these freezes
when connecting to the IP address on the eepro100. Unfortunately, due to
the lack of error messages, this report doesn't help much. But i was
wondering wether this was what some people were experiencing.
connected via switch with moderately high network load (general purpose
server)
Cheers,
Zwane Mwaikambo
PS i have 2.4.17-pre5 and so far haven't noticed it, but haven't done much
testing either.
I just tried this patch against the 2.4.17 kernel. I was able to
completely freeze my D815EEA2 motherboard based computer by trying
to copy a large directory over NFS. The machine is connected to a
10bt HUB, and this setup has shown lockups before with various
eepro100 drivers. The e100 seems to work fine in this setup...
An older eepro driver (the one with RH's 2.4.9-13 kernel) does not
lock up the machine, but I do see incessant wait-for-cmd-done-timeout
messages, and the network is basically un-usable.
On other machines, connected to a 100bt-FD switch, the new patch
seems to work just fine, btw.
The eepro lockup is repeatable, so let me know if there is any
information I can get for you that will help.
Thanks,
Ben
Tim Hockin wrote:
> This patch was developed here to resolve a number of eepro100 issues we
> were seeing. I'd like to get people to try this on their eepro100 chips and
> beat on it for a while.
>
> volunteers?
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
I have a friend who has had headaches with a D815EEA board with a 2nd
eepro100+ nic installed.
He compiled a new kernel and used a driver from intel's website, and it's
all good now.
FYI
----- Original Message -----
From: "Ben Greear" <[email protected]>
To: "Tim Hockin" <[email protected]>
Cc: "Linux Kernel Mailing List" <[email protected]>;
<[email protected]>; <[email protected]>; <[email protected]>
Sent: Sunday, December 23, 2001 7:24 PM
Subject: Re: [PATCH] eepro100 - need testers
> I just tried this patch against the 2.4.17 kernel. I was able to
> completely freeze my D815EEA2 motherboard based computer by trying
> to copy a large directory over NFS. The machine is connected to a
> 10bt HUB, and this setup has shown lockups before with various
> eepro100 drivers. The e100 seems to work fine in this setup...
>
> An older eepro driver (the one with RH's 2.4.9-13 kernel) does not
> lock up the machine, but I do see incessant wait-for-cmd-done-timeout
> messages, and the network is basically un-usable.
>
> On other machines, connected to a 100bt-FD switch, the new patch
> seems to work just fine, btw.
>
> The eepro lockup is repeatable, so let me know if there is any
> information I can get for you that will help.
>
> Thanks,
> Ben
>
> Tim Hockin wrote:
>
> > This patch was developed here to resolve a number of eepro100 issues we
> > were seeing. I'd like to get people to try this on their eepro100 chips
and
> > beat on it for a while.
> >
> > volunteers?
>
>
> --
> Ben Greear <[email protected]> <Ben_Greear AT excite.com>
> President of Candela Technologies Inc http://www.candelatech.com
> ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I just applied Tim Hockin's eepro100 patch of Tue, 04 Dec 2001 against an
otherwise stock 2.4.17. Result summary: no joy. Stock or patched, a ping
-f against a neighboring machine causes the driver to fail after a short
while (time < coffee-run) with that old standby:
eepro100: wait_for_cmd_done timeout!
Doing the ping -f test with the unpatched OR patched module loaded as:
modprobe eepro100 debug=6
gives very dubious output along the lines of (unpatched module gives
similar output....):
----- cut here -----
kernel: eepro100.c: Debug level is 6.
kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[email protected]> and others
kernel: Found Intel i82557 PCI Speedo, MMIO at 0xff8ff000, IRQ 3.
kernel: PCI: Found IRQ 3 for device 01:08.0
kernel: eth0: Intel Corp. 82820 (ICH2) Chipset Ethernet Controller, 00:03:47:0E:62:F3, IRQ 3.
kernel: Board assembly 000000-000, Physical connectors present: RJ45
kernel: Primary interface chip i82555 PHY #1.
kernel: General self-test: passed.
kernel: Serial sub-system self-test: passed.
kernel: Internal registers self-test: passed.
kernel: ROM checksum self-test: passed (0x04f4518b).
sysctl: net.ipv4.ip_forward = 0
sysctl: net.ipv4.conf.default.rp_filter = 1
sysctl: kernel.sysrq = 0
network: Setting network parameters: succeeded
network: Bringing up interface lo: succeeded
network: Bringing up interface eth0: succeeded
kernel: nterrupt status=0x0050.
kernel: tatus=0x0050.
kernel: tatus=0x0050.
kernel: <nterrupt status=0x0050.
kernel: eth0: exiting interrupt, status=0x0050.
kernel: <7nterrupt status=0x0050.
kernel: nterrupt status=0x0050.
kernel: <7rrupt status=0x4050.
kernel: <x0050.
kernel: status=0x0050.
kernel: nterrupt status=0x0050.
kernel: x2050.
kernel: x0050.
kernel: t status=0x0050.
kernel: nterrupt status=0x2050.
kernel: status=0x2050.
kernel: <7x0050.
kernel: nterrupt status=0x0050.
kernel: nterrupt status=0x0050.
kernel: <nterrupt status=0x0050.
kernel: <x4050.
kernel: nterrupt status=0x0050.
kernel: <7x2050.
kernel: th0: interrupt status=0x0050.
kernel: <x0050.
kernel: e candidate 39 status 400ca000.
kernel: nterrupt status=0x0050.
kernel: <7status=0x0050.
kernel: <7nterrupt status=0x0050.
kernel: <7h0: interrupt status=0x0050.
kernel: .
kernel: nterrupt, status=0x0050.
kernel: eepro100: wait_for_cmd_done timeout!
last message repeated 14 times
kernel: h0: 396 00000001.
----- cut here -----
Trying to balance the need to send details versus avoiding list-flood...
Let me know if any other bits would be useful. I wrote a cheezy network
watchdog script which *should* let me back in from home after the next
hare-brained experiment... :)
System Info:
- Dell Dimension 4100 "EA81510A.10A.0022.P06.0008291722"
- BIOS Version A04
- i686 800MHz "Pentium(R)III 800EB MHz"
- 256M PC133 RAM
- Hub is 10Mb/s (no easy way to test w/ 100Mb/s hub.)
- Int 3 (eth0) is not shared.
- Fully patched RedHat 7.2
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
glibc-2.2.4-19.3 (i386)
Regards,
Pete.
Jeremy Jackson wrote:
> I have a friend who has had headaches with a D815EEA board with a 2nd
> eepro100+ nic installed.
> He compiled a new kernel and used a driver from intel's website, and it's
> all good now.
> FYI
Yes, I have good results with e100 too. However, I look forward
to the day that I don't have to download/compile/install 3rd party
drivers to get my machines working...
Thanks,
Ben
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear