From: Andrew Morton <akpm@zip.com.au>
To: "christophe barbé" <christophe.barbe.ml@online.fr>
Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 3c59x and resume
Date: Sat, 23 Mar 2002 10:39:39 -0800 [thread overview]
Message-ID: <3C9CCBEB.D39465A6@zip.com.au> (raw)
In-Reply-To: <20020323161647.GA11471@ufies.org>
christophe barbé wrote:
>
> Here is a small patch tested with 2.4.18 and 2.4.19-pre4.
> It was proposed by Andrew but not integrated in pre4.
>
> The problem is when using the vortex driver and suspend/resuming the
> machine.
The patch looks fine to me.
This is a common bug in the Linux ethernet drivers. Let's
review it:
- The module init function keeps a driver-wide `card_idx'
- Every time a new card is detected, card_idx is incremented
and is associated with that card.
- The card instance's card_idx is used to index module options
arrays.
- The global card_idx counter is never decremented.
So each time you hotplug a card, it gets the next index, and
eventually the index exceeds the size of the module options array
and the driver falls into its "oh, I've got more than eight
cards" mode.
The fix in this patch is to simply decrement card_idx in the
remove_one function. Which somewhat assumes that cards are
removed and inserted in LIFO order, but that's true for
just one card :)
Same bug appears to be present in about eight divers - just
grep for card_idx.
I don't immediately see a simple and clean fix for this.
If we have, say,
options 3c59x enable_wol=1,1,0,1,1,0,0,0
in modules.conf, and we really have eight NICS, and they're
being plugged and unplugged, how can we reliably associate
that option with the eight cards? So the right option is
applied to each card eash time it's inserted? Should the
option be associated with a card, or with a bus position?
Fun.
Anyway. Let's apply the patch.
-
next prev parent reply other threads:[~2002-03-23 18:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-23 16:16 [PATCH] 3c59x and resume christophe barbé
2002-03-23 18:39 ` Andrew Morton [this message]
2002-03-23 20:06 ` Robert Love
2002-03-23 22:44 ` christophe barbé
2002-03-24 8:07 ` Greg KH
2002-03-24 14:25 ` christophe barbé
2002-03-25 18:01 ` Greg KH
2002-03-25 18:19 ` christophe barbé
2002-03-25 19:11 ` Greg KH
2002-03-25 20:27 ` christophe barbé
2002-03-25 20:58 ` christophe barbé
2002-03-25 11:34 ` Joachim Breuer
2002-03-25 11:53 ` Xavier Bestel
2002-03-25 21:31 ` Joachim Breuer
2002-03-25 19:44 ` Bill Davidsen
2002-03-25 20:16 ` christophe barbé
2002-03-26 0:57 ` Jeff Garzik
2002-03-26 1:40 ` christophe barbé
2002-03-26 4:10 ` Jeff Garzik
2002-03-26 4:39 ` christophe barbé
2002-03-26 4:50 ` Andrew Morton
2002-03-26 16:56 ` christophe barbé
2002-03-26 16:57 ` Jeff Garzik
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=3C9CCBEB.D39465A6@zip.com.au \
--to=akpm@zip.com.au \
--cc=christophe.barbe.ml@online.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox