Re: eepro100 problems in 2.4.0

Re: eepro100 problems in 2.4.0

[Micah Gorrell]

Because of the problems we where having we are no longer using the machine
with 3 nics.  We are now using a machine with just one and it is going live
next week.  We do need kernel 2.4 because of the process limits in 2.2.
Does the 'Enable Power Management (EXPERIMENTAL)' option fix the no
resources problems?

Micah
___
The irony is that Bill Gates claims to be making a stable operating system
and Linus Torvalds claims to be trying to take over the world
-----Original Message-----
From: "Tom Sightler" <ttsig@tuxyturvy.com>
To: "Micah Gorrell" <angelcode@myrealbox.com>;
<linux-kernel@vger.kernel.org>
Date: Thursday, January 25, 2001 1:48 PM
Subject: Re: eepro100 problems in 2.4.0


> > I have doing some testing with kernel 2.4 and I have had constant
>problems
>> with the eepro100 driver.  Under 2.2 it works perfectly but under 2.4 I
am
>> unable to use more than one card in a server and when I do use one card I
>> get errors stating that eth0 reports no recources.  Has anyone else seen
>> this kind of problem?
>
>I had a similar problem with a server that had dual embedded eepro100
>adapters however selecting the 'Enable Power Management (EXPERIMENTAL)'
>option for the eepro100 seemed to make the problem go away.  I don't really
>know why but it might be worth trying if it wasn't already selected.
>
>Later,
>Tom
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>Please read the FAQ at http://www.tux.org/lkml/
>
>

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

[PATCH] Re: eepro100 problems in 2.4.0

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

Micah Gorrell wrote:
> Because of the problems we where having we are no longer using the machine
> with 3 nics.  We are now using a machine with just one and it is going live
> next week.  We do need kernel 2.4 because of the process limits in 2.2.
> Does the 'Enable Power Management (EXPERIMENTAL)' option fix the no
> resources problems?

Does the attached patch, against 2.4.1-pre10, help matters any?

pci_enable_device() must to be called before any accesses to the
pci_dev->irq and pci_dev->resource[] members.  Plug-n-play may fill in
those values.  I didn't see your original report, but "no resources"
sounds to me like pci_enable_device() needs to be called earlier in the
speedo_init_one function.  The attached patch does just that.

	Jeff


> -----Original Message-----
> From: "Tom Sightler" <ttsig@tuxyturvy.com>
> To: "Micah Gorrell" <angelcode@myrealbox.com>;
> <linux-kernel@vger.kernel.org>
> Date: Thursday, January 25, 2001 1:48 PM
> Subject: Re: eepro100 problems in 2.4.0
[...]
> >I had a similar problem with a server that had dual embedded eepro100
> >adapters however selecting the 'Enable Power Management (EXPERIMENTAL)'
> >option for the eepro100 seemed to make the problem go away.  I don't really
> >know why but it might be worth trying if it wasn't already selected.


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

[-- Attachment #2: eepro100.patch --]
[-- Type: text/plain, Size: 872 bytes --]

Index: drivers/net/eepro100.c
===================================================================
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/eepro100.c,v
retrieving revision 1.1.1.9.42.2
diff -u -r1.1.1.9.42.2 eepro100.c
--- drivers/net/eepro100.c	2001/01/24 15:56:16	1.1.1.9.42.2
+++ drivers/net/eepro100.c	2001/01/25 21:00:48
@@ -560,6 +560,9 @@
 	if (speedo_debug > 0  &&  did_version++ == 0)
 		printk(version);
 
+	if (pci_enable_device(pdev))
+		return -EIO;
+
 	if (!request_region(pci_resource_start(pdev, 1),
 			pci_resource_len(pdev, 1), "eepro100")) {
 		printk (KERN_ERR "eepro100: cannot reserve I/O ports\n");
@@ -597,9 +600,6 @@
 		pci_read_config_word(pdev, pm + PCI_PM_CTRL, &pwr_command);
 		acpi_idle_state = pwr_command & PCI_PM_CTRL_STATE_MASK;
 	}
-
-	if (pci_enable_device(pdev))
-		goto err_out_free_mmio_region;
 
 	pci_set_master(pdev);
 

Re: [PATCH] Re: eepro100 problems in 2.4.0

[Jeff Garzik]

Jeff Garzik wrote:
> 
> Micah Gorrell wrote:
> > Because of the problems we where having we are no longer using the machine
> > with 3 nics.  We are now using a machine with just one and it is going live
> > next week.  We do need kernel 2.4 because of the process limits in 2.2.
> > Does the 'Enable Power Management (EXPERIMENTAL)' option fix the no
> > resources problems?
> 
> Does the attached patch, against 2.4.1-pre10, help matters any?
> diff -u -r1.1.1.9.42.2 eepro100.c
> --- drivers/net/eepro100.c      2001/01/24 15:56:16     1.1.1.9.42.2
> +++ drivers/net/eepro100.c      2001/01/25 21:00:48
> @@ -560,6 +560,9 @@
>         if (speedo_debug > 0  &&  did_version++ == 0)
>                 printk(version);
> 
> +       if (pci_enable_device(pdev))
> +               return -EIO;
> +

Oops, sorry guys.  Thanks to DaveM for correcting me -- my patch has
nothing to do with the "card reports no resources" problem.  My
apologies.

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: eepro100 problems in 2.4.0

[Andrey Savochkin]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

Hi,

On Thu, Jan 25, 2001 at 04:19:27PM -0500, Jeff Garzik wrote:
> Oops, sorry guys.  Thanks to DaveM for correcting me -- my patch has
> nothing to do with the "card reports no resources" problem.  My
> apologies.

No problems.

However, there is a real problem with eepro100 when the system resumes
operations after a sleep.
May be, you could guess what's wrong in this case?

Best regards
		Andrey

[-- Attachment #2: l1 --]
[-- Type: text/plain, Size: 14305 bytes --]

Return-Path: <scott@robhome.dyndns.org>
Delivered-To: saw-main@saw.sw.com.sg
Received: (qmail 5459 invoked by uid 577); 18 Jan 2001 01:39:41 -0000
Received: (qmail 5453 invoked from network); 18 Jan 2001 01:39:38 -0000
Received: from sea-pm3-10-p213.wolfenet.com (HELO mail.robhome.dyndns.org) (206.159.18.213)
  by saw.sw.com.sg with SMTP; 18 Jan 2001 01:39:38 -0000
Received: from tara.robhome.dyndns.org (tara.mvdomain [10.1.1.66])
	by mail.robhome.dyndns.org (Postfix) with ESMTP id 16645BBE9
	for <saw@saw.sw.com.sg>; Wed, 17 Jan 2001 17:39:18 -0800 (PST)
Received: by tara.robhome.dyndns.org (Postfix, from userid 1000)
	id 5D43A17183E; Wed, 17 Jan 2001 17:39:10 -0800 (PST)
Date: Wed, 17 Jan 2001 17:39:08 -0800
From: Scott Robinson <scott@tranzoa.com>
To: Andrey Savochkin <saw@saw.sw.com.sg>
Subject: Re: EEPRO100 Power Management problem?
Message-ID: <20010117173908.A7129@robhome.dyndns.org>
In-Reply-To: <20010105151822.A14053@robhome.dyndns.org> <20010116171916.C29594@saw.sw.com.sg>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H"
User-Agent: Mutt/1.0.1i
In-Reply-To: <20010116171916.C29594@saw.sw.com.sg>; from saw@saw.sw.com.sg on Tue, Jan 16, 2001 at 05:19:16PM +0800
X-Disclaimer: The contents of this e-mail, unless otherwise stated, are the property of David Ryland Scott Robinson. Copyright (C)2001, All Rights Reserved.
X-Operating-System: Linux tara 2.4.0-test10 
Sender: scott@robhome.dyndns.org


--4SFOXa2GPu3tIq4H
Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP"


--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Well, it appears *something* like that is happening. However, I can't think
of how to fix it. Everything goes "disabled".

Attached are the two 'lspci -v' executed pre and post-suspend. Also attached
is a diff file between them. If you have any further ideas, please e-mail me
back?

Scott.

* Andrey Savochkin translated into ASCII [Tue, Jan 16, 2001 at 05:19:16PM +=
0800][<20010116171916.C29594@saw.sw.com.sg>]
> Hello,
>=20
> On Fri, Jan 05, 2001 at 03:18:23PM -0800, Scott Robinson wrote:
> > The following occurs when I suspend my Dell Inspiron 8000 with an inter=
nal
> > MiniPCI Actiontec MP100IM. I'm using 2.4.0-final with power-management
> > turned on and off. The logs below are with power-management turned on.
> >=20
> > I checked with a eepro100 diagnostic tool, and according to it, the ent=
ire
> > EEPROM has been FF'ed out. (and it's larger than before)
> >=20
> > I have tried unloading the driver before suspend. No dice. Is there a
> > hard-reset command for a card?
> >=20
> > I was looking at the source code and maybe if I suspend the pci card in
> > _suspend()? I'm not certain what power state I need to tell it, though.=
 D3?
> >=20
> > When I power-cycle the machine, I end up having to hard-reset otherwise=
 I
> > freeze in the bios startup. Something seriously harsh is happening.
>=20
> The first idea that comes to mind is an old issue of cleared PCI
> configuration on sleep.
> Run `lspci -v' after wakeup and compare how the output look with how it d=
id
> before the sleep.
>=20
> Best regards
> 					Andrey V.
> 					Savochkin
>=20

--=20
jabber:quad@jabber.org         - Universal ID (www.jabber.org)
http://dsn.itgo.com/           - Personal webpage
robhome.dyndns.org             - Home firewall

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT dpu s+: a--- C++ UL++++ P+ L+++ E- W+ N+ o+ K++ w++
O M V PS+ PE Y+ PGP++ t++ 5++ X+ R tv b++++ DI++++ D++
G+ e+ h! r-- y-
------END GEEK CODE BLOCK------

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="lspci.presuspend"

00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 02)
	Flags: bus master, fast devsel, latency 0
	Memory at e4000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [88] #09 [f104]
	Capabilities: [a0] AGP version 2.0

00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, 66Mhz, fast devsel, latency 32
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: fc000000-fdffffff
	Prefetchable memory behind bridge: e8000000-ebffffff

00:1e.0 PCI bridge: Intel Corporation: Unknown device 2448 (rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=02, subordinate=08, sec-latency=32
	I/O behind bridge: 0000d000-0000ffff
	Memory behind bridge: f2000000-fbffffff

00:1f.0 ISA bridge: Intel Corporation: Unknown device 244c (rev 02)
	Flags: bus master, medium devsel, latency 0

00:1f.1 IDE interface: Intel Corporation: Unknown device 244a (rev 02) (prog-if 80 [Master])
	Subsystem: Intel Corporation: Unknown device 4541
	Flags: bus master, medium devsel, latency 0
	I/O ports at bfa0 [size=16]

00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation: Unknown device 4541
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at bce0 [size=32]

01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 4d46 (prog-if 00 [VGA])
	Subsystem: Dell Computer Corporation: Unknown device 00a4
	Flags: VGA palette snoop, stepping, 66Mhz, medium devsel, IRQ 11
	Memory at e8000000 (32-bit, prefetchable) [size=64M]
	I/O ports at cc00 [size=256]
	Memory at fcffc000 (32-bit, non-prefetchable) [size=16K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [50] AGP version 2.0
	Capabilities: [5c] Power Management version 2

02:03.0 Multimedia audio controller: ESS Technology: Unknown device 1998 (rev 10)
	Subsystem: Dell Computer Corporation: Unknown device 00a4
	Flags: bus master, medium devsel, latency 32, IRQ 5
	I/O ports at dc00 [size=256]
	Memory at f6ffe000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: [c0] Power Management version 2

02:06.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100 (rev 11) (prog-if 00 [Normal decode])
	Flags: bus master, medium devsel, latency 32
	Bus: primary=02, secondary=08, subordinate=08, sec-latency=32
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: f8000000-f9ffffff
	Capabilities: [80] Power Management version 2
	Capabilities: [90] #06 [0000]

02:0f.0 CardBus bridge: Texas Instruments: Unknown device ac42
	Subsystem: Texas Instruments: Unknown device ac42
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at f2000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=02, secondary=09, subordinate=0c, sec-latency=32
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	16-bit legacy interface ports at 0007

02:0f.1 CardBus bridge: Texas Instruments: Unknown device ac42
	Subsystem: Texas Instruments: Unknown device ac42
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at f2001000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=02, secondary=0d, subordinate=10, sec-latency=32
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	16-bit legacy interface ports at 0007

02:0f.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 8027 (prog-if 10 [OHCI])
	Subsystem: Dell Computer Corporation: Unknown device 00a4
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at f6ffd800 (32-bit, non-prefetchable) [size=2K]
	Memory at f6ff8000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2

08:04.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
	Subsystem: Action Tec Electronics Inc: Unknown device 1100
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at f8fff000 (32-bit, non-prefetchable) [size=4K]
	I/O ports at ecc0 [size=64]
	Memory at f8e00000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [dc] Power Management version 2

08:08.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)
	Subsystem: Action Tec Electronics Inc: Unknown device 2400
	Flags: bus master, medium devsel, latency 0, IRQ 11
	Memory at f8ffec00 (32-bit, non-prefetchable) [size=256]
	I/O ports at ecb8 [size=8]
	I/O ports at e800 [size=256]
	Capabilities: [f8] Power Management version 2


--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="lspci.postsuspend"

00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 02)
	Flags: bus master, fast devsel, latency 0
	Memory at e4000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [88] #09 [f104]
	Capabilities: [a0] AGP version 2.0

00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, 66Mhz, fast devsel, latency 32
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: fc000000-fdffffff
	Prefetchable memory behind bridge: e8000000-ebffffff

00:1e.0 PCI bridge: Intel Corporation: Unknown device 2448 (rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=02, subordinate=08, sec-latency=32
	I/O behind bridge: 0000d000-0000ffff
	Memory behind bridge: f2000000-fbffffff

00:1f.0 ISA bridge: Intel Corporation: Unknown device 244c (rev 02)
	Flags: bus master, medium devsel, latency 0

00:1f.1 IDE interface: Intel Corporation: Unknown device 244a (rev 02) (prog-if 80 [Master])
	Subsystem: Intel Corporation: Unknown device 4541
	Flags: bus master, medium devsel, latency 0
	I/O ports at bfa0 [size=16]

00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Intel Corporation: Unknown device 4541
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at bce0 [size=32]

01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 4d46 (prog-if 00 [VGA])
	Subsystem: Dell Computer Corporation: Unknown device 00a4
	Flags: VGA palette snoop, stepping, 66Mhz, medium devsel, IRQ 11
	Memory at e8000000 (32-bit, prefetchable) [size=64M]
	I/O ports at cc00 [size=256]
	Memory at fcffc000 (32-bit, non-prefetchable) [size=16K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [50] AGP version 2.0
	Capabilities: [5c] Power Management version 2

02:03.0 Multimedia audio controller: ESS Technology: Unknown device 1998 (rev 10)
	Subsystem: Dell Computer Corporation: Unknown device 00a4
	Flags: bus master, medium devsel, latency 32, IRQ 5
	I/O ports at dc00 [size=256]
	Memory at f6ffe000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: [c0] Power Management version 2

02:06.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100 (rev 11) (prog-if 00 [Normal decode])
	Flags: bus master, medium devsel, latency 32
	Bus: primary=02, secondary=08, subordinate=08, sec-latency=32
	I/O behind bridge: 0000e000-0000efff
	Capabilities: [80] Power Management version 2
	Capabilities: [90] #06 [0000]

02:0f.0 CardBus bridge: Texas Instruments: Unknown device ac42
	Subsystem: Texas Instruments: Unknown device ac42
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at f2000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=02, secondary=09, subordinate=0c, sec-latency=32
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	16-bit legacy interface ports at 0007

02:0f.1 CardBus bridge: Texas Instruments: Unknown device ac42
	Subsystem: Texas Instruments: Unknown device ac42
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at f2001000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=02, secondary=0d, subordinate=10, sec-latency=32
	I/O window 0: 00000000-00000003
	I/O window 1: 00000000-00000003
	16-bit legacy interface ports at 0007

02:0f.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 8027 (prog-if 10 [OHCI])
	Subsystem: Dell Computer Corporation: Unknown device 00a4
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at f6ffd800 (32-bit, non-prefetchable) [size=2K]
	Memory at f6ff8000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2

08:04.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
	Subsystem: Action Tec Electronics Inc: Unknown device 1100
	Flags: medium devsel, IRQ 11
	[virtual] Memory at f8fff000 (32-bit, non-prefetchable) [disabled] [size=4K]
	I/O ports at ecc0 [disabled] [size=64]
	[virtual] Memory at f8e00000 (32-bit, non-prefetchable) [disabled] [size=1M]
	Capabilities: [dc] Power Management version 2

08:08.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)
	Subsystem: Action Tec Electronics Inc: Unknown device 2400
	Flags: medium devsel, IRQ 11
	[virtual] Memory at f8ffec00 (32-bit, non-prefetchable) [disabled] [size=256]
	I/O ports at ecb8 [disabled] [size=8]
	I/O ports at e800 [disabled] [size=256]
	Capabilities: [f8] Power Management version 2


--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="lspci.suspend.diff"

54d53
< 	Memory behind bridge: f8000000-f9ffffff
85,88c84,87
< 	Flags: bus master, medium devsel, latency 32, IRQ 11
< 	Memory at f8fff000 (32-bit, non-prefetchable) [size=4K]
< 	I/O ports at ecc0 [size=64]
< 	Memory at f8e00000 (32-bit, non-prefetchable) [size=1M]
---
> 	Flags: medium devsel, IRQ 11
> 	[virtual] Memory at f8fff000 (32-bit, non-prefetchable) [disabled] [size=4K]
> 	I/O ports at ecc0 [disabled] [size=64]
> 	[virtual] Memory at f8e00000 (32-bit, non-prefetchable) [disabled] [size=1M]
93,96c92,95
< 	Flags: bus master, medium devsel, latency 0, IRQ 11
< 	Memory at f8ffec00 (32-bit, non-prefetchable) [size=256]
< 	I/O ports at ecb8 [size=8]
< 	I/O ports at e800 [size=256]
---
> 	Flags: medium devsel, IRQ 11
> 	[virtual] Memory at f8ffec00 (32-bit, non-prefetchable) [disabled] [size=256]
> 	I/O ports at ecb8 [disabled] [size=8]
> 	I/O ports at e800 [disabled] [size=256]

--jRHKVT23PllUwdXP--

--4SFOXa2GPu3tIq4H
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjpmSTwACgkQQzP9mY3zNDZv9gCgw9mRkLAUoFbl55kGiflEGKw1
t+AAn2xczYVf3Qfdalqcm9VuVmsX7M/g
=joc4
-----END PGP SIGNATURE-----

--4SFOXa2GPu3tIq4H--

Re: eepro100 problems in 2.4.0

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

Andrey Savochkin wrote:
> 
> Hi,
> 
> On Thu, Jan 25, 2001 at 04:19:27PM -0500, Jeff Garzik wrote:
> > Oops, sorry guys.  Thanks to DaveM for correcting me -- my patch has
> > nothing to do with the "card reports no resources" problem.  My
> > apologies.
> 
> No problems.
> 
> However, there is a real problem with eepro100 when the system resumes
> operations after a sleep.
> May be, you could guess what's wrong in this case?

The regions shouldn't be disabled, the attached patch (against
2.4.1-pre10) adds a call to pci_enable_device to enable things in
eepro100_resume().

It also includes the patch I posted previously; the patch itself is
correct -- the pci_enable_device call should be moved up -- however it
was my description of the patch ("fixes 'card has no resources'") which
was completely incorrect.

Scott, does the attached patch help you out?

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

[-- Attachment #2: eepro100.patch --]
[-- Type: text/plain, Size: 1311 bytes --]

Index: linux_2_4/drivers/net/eepro100.c
diff -u linux_2_4/drivers/net/eepro100.c:1.1.1.9 linux_2_4/drivers/net/eepro100.c:1.1.1.9.42.4
--- linux_2_4/drivers/net/eepro100.c:1.1.1.9	Sat Nov 25 15:53:20 2000
+++ linux_2_4/drivers/net/eepro100.c	Sat Jan 27 08:27:00 2001
@@ -560,6 +560,9 @@
 	if (speedo_debug > 0  &&  did_version++ == 0)
 		printk(version);
 
+	if (pci_enable_device(pdev))
+		return -EIO;
+
 	if (!request_region(pci_resource_start(pdev, 1),
 			pci_resource_len(pdev, 1), "eepro100")) {
 		printk (KERN_ERR "eepro100: cannot reserve I/O ports\n");
@@ -598,9 +601,6 @@
 		acpi_idle_state = pwr_command & PCI_PM_CTRL_STATE_MASK;
 	}
 
-	if (pci_enable_device(pdev))
-		goto err_out_free_mmio_region;
-
 	pci_set_master(pdev);
 
 	if (speedo_found1(pdev, ioaddr, cards_found, acpi_idle_state) == 0)
@@ -2146,6 +2146,13 @@
 	struct net_device *dev = pdev->driver_data;
 	struct speedo_private *sp = (struct speedo_private *)dev->priv;
 	long ioaddr = dev->base_addr;
+
+	/* Make sure power state is D0, a.k.a. alive, and also
+	 * make sure PIO and MMIO are active.  Apparently some
+	 * cases exist where PCI_COMMAND_{IO,MEM} is not set when
+	 * we return from resume. -jgarzik
+	 */
+	pci_enable_device(pdev);
 
 	/* I'm absolutely uncertain if this part of code may work.
 	   The problems are:

Re: eepro100 problems in 2.4.0

[Sergey Kubushin]

On Thu, 25 Jan 2001, Micah Gorrell wrote:

I do have such a problem with the machines that have only one eepro100 nic.

> Because of the problems we where having we are no longer using the
> machine
> with 3 nics.  We are now using a machine with just one and it is going
> live
> next week.  We do need kernel 2.4 because of the process limits in 2.2.
> Does the 'Enable Power Management (EXPERIMENTAL)' option fix the no
> resources problems?
>
> Micah
> ___
> The irony is that Bill Gates claims to be making a stable operating
> system
> and Linus Torvalds claims to be trying to take over the world
> -----Original Message-----
> From: "Tom Sightler" <ttsig@tuxyturvy.com>
> To: "Micah Gorrell" <angelcode@myrealbox.com>;
> <linux-kernel@vger.kernel.org>
> Date: Thursday, January 25, 2001 1:48 PM
> Subject: Re: eepro100 problems in 2.4.0
>
>
> > > I have doing some testing with kernel 2.4 and I have had constant
> >problems
> >> with the eepro100 driver.  Under 2.2 it works perfectly but under
> 2.4 I
> am
> >> unable to use more than one card in a server and when I do use one
> card I
> >> get errors stating that eth0 reports no recources.  Has anyone else
> seen
> >> this kind of problem?
> >
> >I had a similar problem with a server that had dual embedded eepro100
> >adapters however selecting the 'Enable Power Management
> (EXPERIMENTAL)'
> >option for the eepro100 seemed to make the problem go away.  I don't
> really
> >know why but it might be worth trying if it wasn't already selected.
> >
> >Later,
> >Tom
> >
> >
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> >the body of a message to majordomo@vger.kernel.org
> >Please read the FAQ at http://www.tux.org/lkml/
> >
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>
>

---
Sergey Kubushin				Sr. Unix Administrator
CyberBills, Inc.			Phone:	702-567-8857
874 American Pacific Dr,		Fax:	702-567-8890
Henderson, NV, 89014

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

Re: eepro100 problems in 2.4.0

[Torben Mathiasen]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On Friday, 26 January 2001, saw@saw.sw.com.sg wrote:
> Hi,
> 
> On Thu, Jan 25, 2001 at 04:19:27PM -0500, Jeff Garzik wrote:
> > Oops, sorry guys.  Thanks to DaveM for correcting me -- my patch has
> > nothing to do with the "card reports no resources" problem.  My
> > apologies.
> 
> No problems.
> 
> However, there is a real problem with eepro100 when the system resumes
> operations after a sleep.
> May be, you could guess what's wrong in this case?
> 

I had to add this small patch to make it work properly with my Armada
M700. It basiclly just does something similar to what happens when we
get TX timeouts. Its just a quick hack, as I got tired of the eepro100
driver dumping the tx/rx queues when resuming.

Regards,

Torben Mathiasen


[-- Attachment #2: ee100apm.diff --]
[-- Type: application/octet-stream, Size: 976 bytes --]

--- /opt/kernel/kernels/linux/drivers/net/eepro100.c	Tue Nov 28 02:58:32 2000
+++ linux/drivers/net/eepro100.c	Wed Jan 24 16:26:14 2001
@@ -2145,7 +2145,7 @@
 {
 	struct net_device *dev = pdev->driver_data;
 	struct speedo_private *sp = (struct speedo_private *)dev->priv;
-	long ioaddr = dev->base_addr;
+	long ioaddr = dev->base_addr, flags;
 
 	/* I'm absolutely uncertain if this part of code may work.
 	   The problems are:
@@ -2154,12 +2154,19 @@
 		  reinitialization;
 		- serialization with other driver calls.
 	   2000/03/08  SAW */
+	outl(PortReset, ioaddr + SCBPort);
+	udelay(10);
 	outw(SCBMaskAll, ioaddr + SCBCmd);
+	synchronize_irq();
+	spin_lock_irqsave(&sp->lock, flags);
 	speedo_resume(dev);
-	netif_device_attach(dev);
+	dev->trans_start = jiffies;
 	sp->rx_mode = -1;
+	spin_unlock_irqrestore(&sp->lock, flags);
+	netif_device_attach(dev);
 	sp->flow_ctrl = sp->partner = 0;
 	set_rx_mode(dev);
+	reset_mii(dev);
 }
 #endif /* CONFIG_EEPRO100_PM */
 

eepro100 problems in 2.4.0

[Micah Gorrell]

I have doing some testing with kernel 2.4 and I have had constant problems
with the eepro100 driver.  Under 2.2 it works perfectly but under 2.4 I am
unable to use more than one card in a server and when I do use one card I
get errors stating that eth0 reports no recources.  Has anyone else seen
this kind of problem?

Micah
___
The irony is that Bill Gates claims to be making a stable operating system
and Linus Torvalds claims to be trying to take over the world

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

Re: eepro100 problems in 2.4.0

[Sergey Kubushin]

On Thu, 25 Jan 2001, Micah Gorrell wrote:

I have it too. Kernel spits a lot of "eepro100: wait_for_cmd_done timeout!"
and network doesn't work. 2.2 is fine. This behaviour is not persistent,
sometimes the eepro100 module is loaded without such an error and works fine
then.

The eepro100 in question is the built-in one based on 82559 chip.


> I have doing some testing with kernel 2.4 and I have had constant
> problems
> with the eepro100 driver.  Under 2.2 it works perfectly but under 2.4 I
> am
> unable to use more than one card in a server and when I do use one card
> I
> get errors stating that eth0 reports no recources.  Has anyone else
> seen
> this kind of problem?
>
> Micah
> ___
> The irony is that Bill Gates claims to be making a stable operating
> system
> and Linus Torvalds claims to be trying to take over the world
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
>
>

---
Sergey Kubushin				Sr. Unix Administrator
CyberBills, Inc.			Phone:	702-567-8857
874 American Pacific Dr,		Fax:	702-567-8890
Henderson, NV, 89014

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

Re: eepro100 problems in 2.4.0

[Tom Sightler]

 > I have doing some testing with kernel 2.4 and I have had constant
problems
> with the eepro100 driver.  Under 2.2 it works perfectly but under 2.4 I am
> unable to use more than one card in a server and when I do use one card I
> get errors stating that eth0 reports no recources.  Has anyone else seen
> this kind of problem?

I had a similar problem with a server that had dual embedded eepro100
adapters however selecting the 'Enable Power Management (EXPERIMENTAL)'
option for the eepro100 seemed to make the problem go away.  I don't really
know why but it might be worth trying if it wasn't already selected.

Later,
Tom



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

Re: eepro100 problems in 2.4.0

[Andrey Savochkin]

Hello,

On Thu, Jan 25, 2001 at 01:20:03PM -0700, Micah Gorrell wrote:
> I have doing some testing with kernel 2.4 and I have had constant problems
> with the eepro100 driver.  Under 2.2 it works perfectly but under 2.4 I am
> unable to use more than one card in a server and when I do use one card I
> get errors stating that eth0 reports no recources.  Has anyone else seen
> this kind of problem?

It's a known problem.
I submitted the patch to Linus and the mailing list this weekend.

Best regards
					Andrey V.
					Savochkin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/