From: Martin Knoblauch <Martin.Knoblauch@TeraPort.de>
To: Martin.Knoblauch@TeraPort.de
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
kai@tp1.ruhr-uni-bochum.de
Subject: [PATCH] Re: eepro100 2.4.7-ac3 problems (apm related)
Date: Wed, 01 Aug 2001 12:02:51 +0200 [thread overview]
Message-ID: <3B67D3CB.DFF4E178@TeraPort.de> (raw)
[-- Attachment #1: Type: text/plain, Size: 2132 bytes --]
> Re: eepro100 2.4.7-ac3 problems (apm related)
>
>
> Kai Germaschewski wrote:
> >
> >
> > Martin, if you want to spend some work on your problem, you could try to
> > collect some more data an your problem, particularly what about using
> > another state (D1/D3) when the interface is down. D3 will probably mean
> > that you have to save/restore PCI config space, so it's a bit more
> > tedious. Also, is there anything which makes your card work again after it
> > was in state D2? Like suspend/resume, or putting it into D3 and back into
> > D0? Does a warm reboot suffice, or do you need to power cycle.
> >
>
> Hmm. I am kind of lost now. I just redid the tests I did with 2.4.6-ac2
> under 2.4.7-ac3 and my eepro100 merrily survives any number of
> D0->D2->D0 transitions. The only difference besides the kernels is the
> ambient temperature. It is quite hot right now - and we don't have AC.
>
very interesting. After cooling down the whole pile of junk I can
reproduce the transition problems with both D2 and D1 as the sleep
state. With D2 it is 100% reproducible, with D1 I had rare cases where
the adaptor survived the transition. Apparently something is very weird
with my notebook.
Removing the module does not help in *most* of the cases. Meaning - I
had one case where removing the module helped.
In order to play with the problem I have modified my initial "patch". I
have introduced an option "apm_sleep" that can take values between 0 and
3, with a default of 2, representing the levles D0-D3. Applies against
2.4.7-ac3. Adding the line:
option eepro100 apm_sleep=0
to /etc/modules.conf solves my problem. Without the line the default
behaviour is used. I do some sanity checking on the value of apm_sleep.
0-2 are tested, 3 most likely needs some work wrt. saving/restoring
device state.
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: Martin.Knoblauch@TeraPort.de
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
[-- Attachment #2: eepro100-apm_sleep.txt --]
[-- Type: text/plain, Size: 2145 bytes --]
--- linux-2.4.7-ac3/drivers/net/eepro100.c-ac3-orig Tue Jul 31 11:20:56 2001
+++ linux-2.4.7-ac3/drivers/net/eepro100.c Wed Aug 1 10:54:12 2001
@@ -55,6 +55,9 @@
/* Maximum number of multicast addresses to filter (vs. rx-all-multicast) */
static int multicast_filter_limit = 64;
+/* Defines apm power saving mode. Set to 0 for some flaky adapters. MKN */
+static int apm_sleep = 2;
+
/* 'options' is used to pass a transceiver override or full-duplex flag
e.g. "options=16" for FD, "options=32" for 100mbps-only. */
static int full_duplex[] = {-1, -1, -1, -1, -1, -1, -1, -1};
@@ -125,6 +128,7 @@
MODULE_PARM(rx_copybreak, "i");
MODULE_PARM(max_interrupt_work, "i");
MODULE_PARM(multicast_filter_limit, "i");
+MODULE_PARM(apm_sleep, "i");
MODULE_PARM_DESC(debug, "eepro100 debug level (0-6)");
MODULE_PARM_DESC(options, "eepro100: Bits 0-3: tranceiver type, bit 4: full duplex, bit 5: 100Mbps");
MODULE_PARM_DESC(full_duplex, "eepro100 full duplex setting(s) (1)");
@@ -136,6 +140,7 @@
MODULE_PARM_DESC(rx_copybreak, "eepro100 copy breakpoint for copy-only-tiny-frames");
MODULE_PARM_DESC(max_interrupt_work, "eepro100 maximum events handled per interrupt");
MODULE_PARM_DESC(multicast_filter_limit, "eepro100 maximum number of filtered multicast addresses");
+MODULE_PARM_DESC(apm_sleep, "eepro100 power save mode (0-3,[2])");
#define RUN_AT(x) (jiffies + (x))
@@ -778,7 +783,14 @@
udelay(10);
/* Put chip into power state D2 until we open() it. */
- pci_set_power_state(pdev, 2);
+ /* For some flaky adaptors use value of apm_sleep instead of D2. MKN */
+ if ((apm_sleep < 0) || (apm_sleep > 3)) {
+ apm_sleep = 2;
+ printk(KERN_INFO " apm_sleep option outside range. Defaulted to 2.\n");
+ }
+ else if (apm_sleep != 2)
+ printk(KERN_INFO " Nondefault apm_sleep = %d.\n",apm_sleep);
+ pci_set_power_state(pdev, apm_sleep);
pci_set_drvdata (pdev, dev);
@@ -1833,7 +1845,7 @@
if (speedo_debug > 0)
printk(KERN_DEBUG "%s: %d multicast blocks dropped.\n", dev->name, i);
- pci_set_power_state(sp->pdev, 2);
+ pci_set_power_state(sp->pdev, apm_sleep);
MOD_DEC_USE_COUNT;
reply other threads:[~2001-08-01 10:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B67D3CB.DFF4E178@TeraPort.de \
--to=martin.knoblauch@teraport.de \
--cc=kai@tp1.ruhr-uni-bochum.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.