When you remove a 3c59x-based cardbus, the fonction vortex_remove_one
is called and this function end with kfree(dev).
I was looking why enable_wol loose its value after a remove/insert cycle
but this value is store in the private part of dev so it's free with
dev.
The driver is not unloaded during the remove/insert cycle so it's a
kernel space problem.
Have I missed something here ?
Christophe
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
There is no snooze button on a cat who wants breakfast.
christophe barb? wrote:
>
> When you remove a 3c59x-based cardbus, the fonction vortex_remove_one
> is called and this function end with kfree(dev).
>
> I was looking why enable_wol loose its value after a remove/insert cycle
> but this value is store in the private part of dev so it's free with
> dev.
>
> The driver is not unloaded during the remove/insert cycle so it's a
> kernel space problem.
Yes, all driver state is destroyed when the hardware is removed.
Look at it the other way: if this was not done, the driver would
have a memory leak.
I guess it would be possible to retain some state across insertion
cycles, keyed off the MAC address or something. What's it needed
for?
-
On Tue, Feb 26, 2002 at 09:40:39AM -0800, Andrew Morton wrote:
> christophe barb? wrote:
> >
> > When you remove a 3c59x-based cardbus, the fonction vortex_remove_one
> > is called and this function end with kfree(dev).
> >
> > I was looking why enable_wol loose its value after a remove/insert cycle
> > but this value is store in the private part of dev so it's free with
> > dev.
> >
> > The driver is not unloaded during the remove/insert cycle so it's a
> > kernel space problem.
>
> Yes, all driver state is destroyed when the hardware is removed.
> Look at it the other way: if this was not done, the driver would
> have a memory leak.
Yes but as I said the driver is not unloaded.
So when I reinsert the card the kernel himself take care of it (no way
to give an option) but the result is that the enable_wol is lost.
>
> I guess it would be possible to retain some state across insertion
> cycles, keyed off the MAC address or something. What's it needed
> for?
>
>
> -
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
Cats seem go on the principle that it never does any harm to ask for
what you want. --Joseph Wood Krutch
Ok I have found why.
When I resinsert the card, the driver give it a new id (this driver
supports multiple cards) and the option as I set it is only defined for
the card #0. I would expect that the driver give the same id back.
Christophe
On Tue, Feb 26, 2002 at 12:58:19PM -0500, christophe barb? wrote:
> On Tue, Feb 26, 2002 at 09:40:39AM -0800, Andrew Morton wrote:
> > christophe barb? wrote:
> > >
> > > When you remove a 3c59x-based cardbus, the fonction vortex_remove_one
> > > is called and this function end with kfree(dev).
> > >
> > > I was looking why enable_wol loose its value after a remove/insert cycle
> > > but this value is store in the private part of dev so it's free with
> > > dev.
> > >
> > > The driver is not unloaded during the remove/insert cycle so it's a
> > > kernel space problem.
> >
> > Yes, all driver state is destroyed when the hardware is removed.
> > Look at it the other way: if this was not done, the driver would
> > have a memory leak.
>
> Yes but as I said the driver is not unloaded.
> So when I reinsert the card the kernel himself take care of it (no way
> to give an option) but the result is that the enable_wol is lost.
>
> >
> > I guess it would be possible to retain some state across insertion
> > cycles, keyed off the MAC address or something. What's it needed
> > for?
> >
> >
> > -
>
> --
> Christophe Barb? <[email protected]>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
>
> Cats seem go on the principle that it never does any harm to ask for
> what you want. --Joseph Wood Krutch
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
In a cat's eye, all things belong to cats.
--English proverb
christophe barb? wrote:
>
> Ok I have found why.
> When I resinsert the card, the driver give it a new id (this driver
> supports multiple cards) and the option as I set it is only defined for
> the card #0. I would expect that the driver give the same id back.
>
hrm. OK, hotplugging and slot-positional module parameters weren't
designed to live together.
This should fix it for single cards. For multiple cards, you'll
have to make sure you eject them in reverse scan order :)
Index: drivers/net/3c59x.c
===================================================================
RCS file: /opt/cvs/lk/drivers/net/3c59x.c,v
retrieving revision 1.74.2.7
diff -u -r1.74.2.7 3c59x.c
--- drivers/net/3c59x.c 2002/02/13 21:03:03 1.74.2.7
+++ drivers/net/3c59x.c 2002/02/26 18:49:24
@@ -2898,6 +2898,9 @@
BUG();
}
+ if (vp->card_idx == vortex_cards_found)
+ vortex_cards_found--;
+
vp = dev->priv;
/* AKPM: FIXME: we should have
-
Thank you, I have done something similar and that solve it in my case at
least. This driver was clearly not designed for cardbus.
I am still looking for my resume/suspend problem.
Hope to find the solution soon.
Christophe
On Tue, Feb 26, 2002 at 10:51:08AM -0800, Andrew Morton wrote:
> christophe barb? wrote:
> >
> > Ok I have found why.
> > When I resinsert the card, the driver give it a new id (this driver
> > supports multiple cards) and the option as I set it is only defined for
> > the card #0. I would expect that the driver give the same id back.
> >
>
> hrm. OK, hotplugging and slot-positional module parameters weren't
> designed to live together.
>
> This should fix it for single cards. For multiple cards, you'll
> have to make sure you eject them in reverse scan order :)
>
> Index: drivers/net/3c59x.c
> ===================================================================
> RCS file: /opt/cvs/lk/drivers/net/3c59x.c,v
> retrieving revision 1.74.2.7
> diff -u -r1.74.2.7 3c59x.c
> --- drivers/net/3c59x.c 2002/02/13 21:03:03 1.74.2.7
> +++ drivers/net/3c59x.c 2002/02/26 18:49:24
> @@ -2898,6 +2898,9 @@
> BUG();
> }
>
> + if (vp->card_idx == vortex_cards_found)
> + vortex_cards_found--;
> +
> vp = dev->priv;
>
> /* AKPM: FIXME: we should have
>
>
> -
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
Imagination is more important than knowledge.
Albert Einstein, On Science
Now that the forget_option bug is solved I have the following :
Each time I suspend, the card resume in a bad state but return in a good
state after that :
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e000.
diagnostics: net 0ee0 media 8800 dma 000000a0.
Flags; bus-master 1, dirty 20(4) current 36(4)
Transmit list 00af8300 vs. c0af8300.
0: @c0af8200 length 80000062 status 00000062
1: @c0af8240 length 80000062 status 00000062
2: @c0af8280 length 80000062 status 80000062
3: @c0af82c0 length 80000062 status 80000062
4: @c0af8300 length 80000062 status 00000062
5: @c0af8340 length 8000003c status 0000003c
6: @c0af8380 length 80000062 status 00000062
7: @c0af83c0 length 80000062 status 00000062
8: @c0af8400 length 8000003c status 0000003c
9: @c0af8440 length 80000062 status 00000062
10: @c0af8480 length 80000062 status 00000062
11: @c0af84c0 length 80000036 status 00000036
12: @c0af8500 length 80000062 status 00000062
13: @c0af8540 length 80000062 status 00000062
14: @c0af8580 length 80000062 status 00000062
15: @c0af85c0 length 80000062 status 00000062
eth0: Resetting the Tx ring pointer.
The tx ring seems to be in a good state, no ?
Christophe
On Tue, Feb 26, 2002 at 01:59:07PM -0500, christophe barb? wrote:
> Thank you, I have done something similar and that solve it in my case at
> least. This driver was clearly not designed for cardbus.
>
> I am still looking for my resume/suspend problem.
> Hope to find the solution soon.
>
> Christophe
>
> On Tue, Feb 26, 2002 at 10:51:08AM -0800, Andrew Morton wrote:
> > christophe barb? wrote:
> > >
> > > Ok I have found why.
> > > When I resinsert the card, the driver give it a new id (this driver
> > > supports multiple cards) and the option as I set it is only defined for
> > > the card #0. I would expect that the driver give the same id back.
> > >
> >
> > hrm. OK, hotplugging and slot-positional module parameters weren't
> > designed to live together.
> >
> > This should fix it for single cards. For multiple cards, you'll
> > have to make sure you eject them in reverse scan order :)
> >
> > Index: drivers/net/3c59x.c
> > ===================================================================
> > RCS file: /opt/cvs/lk/drivers/net/3c59x.c,v
> > retrieving revision 1.74.2.7
> > diff -u -r1.74.2.7 3c59x.c
> > --- drivers/net/3c59x.c 2002/02/13 21:03:03 1.74.2.7
> > +++ drivers/net/3c59x.c 2002/02/26 18:49:24
> > @@ -2898,6 +2898,9 @@
> > BUG();
> > }
> >
> > + if (vp->card_idx == vortex_cards_found)
> > + vortex_cards_found--;
> > +
> > vp = dev->priv;
> >
> > /* AKPM: FIXME: we should have
> >
> >
> > -
>
> --
> Christophe Barb? <[email protected]>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
>
> Imagination is more important than knowledge.
> Albert Einstein, On Science
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
Imagination is more important than knowledge.
Albert Einstein, On Science
christophe barb? wrote:
>
> Now that the forget_option bug is solved I have the following :
>
> Each time I suspend, the card resume in a bad state but return in a good
> state after that :
>
> NETDEV WATCHDOG: eth0: transmit timed out
The transceiver didn't power up, or came up in silly
mode. I'll see if I can reproduce any of this.
What NIC are you using?
-
On Tue, Feb 26, 2002 at 03:32:23PM -0800, Andrew Morton wrote:
> christophe barb? wrote:
> >
> > Now that the forget_option bug is solved I have the following :
> >
> > Each time I suspend, the card resume in a bad state but return in a good
> > state after that :
> >
> > NETDEV WATCHDOG: eth0: transmit timed out
>
> The transceiver didn't power up, or came up in silly
> mode. I'll see if I can reproduce any of this.
> What NIC are you using?
>
My card is a 3com Megahertz 10/100 model 3CCFE575CT
Could you give me a hint of where to look in the source or/and in the
output from my previous mail ? I would like to understand the problem.
Thanks,
Christophe
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
Dogs believe they are human. Cats believe they are God.
I get very similar error if I remove the module and then reload it (rmmod
followed by a modprobe). So once I rmmod it, It will never be usable again
until i reboot.
I have to pci 3com 905's, I can send the pci id's if those matters
tomorrow.
On Tue, 26 Feb 2002, christophe [iso-8859-15] barb? wrote:
> Now that the forget_option bug is solved I have the following :
>
> Each time I suspend, the card resume in a bad state but return in a good
> state after that :
>
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: transmit timed out, tx_status 00 status e000.
> diagnostics: net 0ee0 media 8800 dma 000000a0.
> Flags; bus-master 1, dirty 20(4) current 36(4)
> Transmit list 00af8300 vs. c0af8300.
> 0: @c0af8200 length 80000062 status 00000062
> 1: @c0af8240 length 80000062 status 00000062
> 2: @c0af8280 length 80000062 status 80000062
> 3: @c0af82c0 length 80000062 status 80000062
> 4: @c0af8300 length 80000062 status 00000062
> 5: @c0af8340 length 8000003c status 0000003c
> 6: @c0af8380 length 80000062 status 00000062
> 7: @c0af83c0 length 80000062 status 00000062
> 8: @c0af8400 length 8000003c status 0000003c
> 9: @c0af8440 length 80000062 status 00000062
> 10: @c0af8480 length 80000062 status 00000062
> 11: @c0af84c0 length 80000036 status 00000036
> 12: @c0af8500 length 80000062 status 00000062
> 13: @c0af8540 length 80000062 status 00000062
> 14: @c0af8580 length 80000062 status 00000062
> 15: @c0af85c0 length 80000062 status 00000062
> eth0: Resetting the Tx ring pointer.
>
> The tx ring seems to be in a good state, no ?
>
> Christophe
>
> On Tue, Feb 26, 2002 at 01:59:07PM -0500, christophe barb? wrote:
> > Thank you, I have done something similar and that solve it in my case at
> > least. This driver was clearly not designed for cardbus.
> >
> > I am still looking for my resume/suspend problem.
> > Hope to find the solution soon.
> >
> > Christophe
> >
> > On Tue, Feb 26, 2002 at 10:51:08AM -0800, Andrew Morton wrote:
> > > christophe barb? wrote:
> > > >
> > > > Ok I have found why.
> > > > When I resinsert the card, the driver give it a new id (this driver
> > > > supports multiple cards) and the option as I set it is only defined for
> > > > the card #0. I would expect that the driver give the same id back.
> > > >
> > >
> > > hrm. OK, hotplugging and slot-positional module parameters weren't
> > > designed to live together.
> > >
> > > This should fix it for single cards. For multiple cards, you'll
> > > have to make sure you eject them in reverse scan order :)
> > >
> > > Index: drivers/net/3c59x.c
> > > ===================================================================
> > > RCS file: /opt/cvs/lk/drivers/net/3c59x.c,v
> > > retrieving revision 1.74.2.7
> > > diff -u -r1.74.2.7 3c59x.c
> > > --- drivers/net/3c59x.c 2002/02/13 21:03:03 1.74.2.7
> > > +++ drivers/net/3c59x.c 2002/02/26 18:49:24
> > > @@ -2898,6 +2898,9 @@
> > > BUG();
> > > }
> > >
> > > + if (vp->card_idx == vortex_cards_found)
> > > + vortex_cards_found--;
> > > +
> > > vp = dev->priv;
> > >
> > > /* AKPM: FIXME: we should have
> > >
> > >
> > > -
> >
> > --
> > Christophe Barb? <[email protected]>
> > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
> >
> > Imagination is more important than knowledge.
> > Albert Einstein, On Science
>
>
>
> --
> Christophe Barb? <[email protected]>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
>
> Imagination is more important than knowledge.
> Albert Einstein, On Science
>
--
pozsy
I've gotten this exact same error on various 3c905x cards. What it
usually means for me is IRQ problems of some type.
Nick
On Wed, 27 Feb 2002, Pozsar Balazs wrote:
>
> I get very similar error if I remove the module and then reload it (rmmod
> followed by a modprobe). So once I rmmod it, It will never be usable again
> until i reboot.
>
> I have to pci 3com 905's, I can send the pci id's if those matters
> tomorrow.
>
>
> On Tue, 26 Feb 2002, christophe [iso-8859-15] barb? wrote:
>
> > Now that the forget_option bug is solved I have the following :
> >
> > Each time I suspend, the card resume in a bad state but return in a good
> > state after that :
> >
> > NETDEV WATCHDOG: eth0: transmit timed out
> > eth0: transmit timed out, tx_status 00 status e000.
> > diagnostics: net 0ee0 media 8800 dma 000000a0.
> > Flags; bus-master 1, dirty 20(4) current 36(4)
> > Transmit list 00af8300 vs. c0af8300.
> > 0: @c0af8200 length 80000062 status 00000062
> > 1: @c0af8240 length 80000062 status 00000062
> > 2: @c0af8280 length 80000062 status 80000062
> > 3: @c0af82c0 length 80000062 status 80000062
> > 4: @c0af8300 length 80000062 status 00000062
> > 5: @c0af8340 length 8000003c status 0000003c
> > 6: @c0af8380 length 80000062 status 00000062
> > 7: @c0af83c0 length 80000062 status 00000062
> > 8: @c0af8400 length 8000003c status 0000003c
> > 9: @c0af8440 length 80000062 status 00000062
> > 10: @c0af8480 length 80000062 status 00000062
> > 11: @c0af84c0 length 80000036 status 00000036
> > 12: @c0af8500 length 80000062 status 00000062
> > 13: @c0af8540 length 80000062 status 00000062
> > 14: @c0af8580 length 80000062 status 00000062
> > 15: @c0af85c0 length 80000062 status 00000062
> > eth0: Resetting the Tx ring pointer.
> >
> > The tx ring seems to be in a good state, no ?
> >
> > Christophe
> >
> > On Tue, Feb 26, 2002 at 01:59:07PM -0500, christophe barb? wrote:
> > > Thank you, I have done something similar and that solve it in my case at
> > > least. This driver was clearly not designed for cardbus.
> > >
> > > I am still looking for my resume/suspend problem.
> > > Hope to find the solution soon.
> > >
> > > Christophe
> > >
> > > On Tue, Feb 26, 2002 at 10:51:08AM -0800, Andrew Morton wrote:
> > > > christophe barb? wrote:
> > > > >
> > > > > Ok I have found why.
> > > > > When I resinsert the card, the driver give it a new id (this driver
> > > > > supports multiple cards) and the option as I set it is only defined for
> > > > > the card #0. I would expect that the driver give the same id back.
> > > > >
> > > >
> > > > hrm. OK, hotplugging and slot-positional module parameters weren't
> > > > designed to live together.
> > > >
> > > > This should fix it for single cards. For multiple cards, you'll
> > > > have to make sure you eject them in reverse scan order :)
> > > >
> > > > Index: drivers/net/3c59x.c
> > > > ===================================================================
> > > > RCS file: /opt/cvs/lk/drivers/net/3c59x.c,v
> > > > retrieving revision 1.74.2.7
> > > > diff -u -r1.74.2.7 3c59x.c
> > > > --- drivers/net/3c59x.c 2002/02/13 21:03:03 1.74.2.7
> > > > +++ drivers/net/3c59x.c 2002/02/26 18:49:24
> > > > @@ -2898,6 +2898,9 @@
> > > > BUG();
> > > > }
> > > >
> > > > + if (vp->card_idx == vortex_cards_found)
> > > > + vortex_cards_found--;
> > > > +
> > > > vp = dev->priv;
> > > >
> > > > /* AKPM: FIXME: we should have
> > > >
> > > >
> > > > -
> > >
> > > --
> > > Christophe Barb? <[email protected]>
> > > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
> > >
> > > Imagination is more important than knowledge.
> > > Albert Einstein, On Science
> >
> >
> >
> > --
> > Christophe Barb? <[email protected]>
> > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
> >
> > Imagination is more important than knowledge.
> > Albert Einstein, On Science
> >
>
> --
> pozsy
>
> -
> 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/
>
On Tue, Feb 26, 2002 at 07:32:59PM -0500, [email protected] wrote:
> I've gotten this exact same error on various 3c905x cards. What it
> usually means for me is IRQ problems of some type.
> Nick
>
This is a timeout for a tx packet.
Each time you have a problem with a network card, you will see a tx
timeout. This is a result not a cause.
So I guess that you have NOT the same problem expecially if it's IRD
related.
Christophe
> On Wed, 27 Feb 2002, Pozsar Balazs wrote:
>
> >
> > I get very similar error if I remove the module and then reload it (rmmod
> > followed by a modprobe). So once I rmmod it, It will never be usable again
> > until i reboot.
> >
> > I have to pci 3com 905's, I can send the pci id's if those matters
> > tomorrow.
> >
> >
> > On Tue, 26 Feb 2002, christophe [iso-8859-15] barb? wrote:
> >
> > > Now that the forget_option bug is solved I have the following :
> > >
> > > Each time I suspend, the card resume in a bad state but return in a good
> > > state after that :
> > >
> > > NETDEV WATCHDOG: eth0: transmit timed out
> > > eth0: transmit timed out, tx_status 00 status e000.
> > > diagnostics: net 0ee0 media 8800 dma 000000a0.
> > > Flags; bus-master 1, dirty 20(4) current 36(4)
> > > Transmit list 00af8300 vs. c0af8300.
> > > 0: @c0af8200 length 80000062 status 00000062
> > > 1: @c0af8240 length 80000062 status 00000062
> > > 2: @c0af8280 length 80000062 status 80000062
> > > 3: @c0af82c0 length 80000062 status 80000062
> > > 4: @c0af8300 length 80000062 status 00000062
> > > 5: @c0af8340 length 8000003c status 0000003c
> > > 6: @c0af8380 length 80000062 status 00000062
> > > 7: @c0af83c0 length 80000062 status 00000062
> > > 8: @c0af8400 length 8000003c status 0000003c
> > > 9: @c0af8440 length 80000062 status 00000062
> > > 10: @c0af8480 length 80000062 status 00000062
> > > 11: @c0af84c0 length 80000036 status 00000036
> > > 12: @c0af8500 length 80000062 status 00000062
> > > 13: @c0af8540 length 80000062 status 00000062
> > > 14: @c0af8580 length 80000062 status 00000062
> > > 15: @c0af85c0 length 80000062 status 00000062
> > > eth0: Resetting the Tx ring pointer.
> > >
> > > The tx ring seems to be in a good state, no ?
> > >
> > > Christophe
> > >
> > > On Tue, Feb 26, 2002 at 01:59:07PM -0500, christophe barb? wrote:
> > > > Thank you, I have done something similar and that solve it in my case at
> > > > least. This driver was clearly not designed for cardbus.
> > > >
> > > > I am still looking for my resume/suspend problem.
> > > > Hope to find the solution soon.
> > > >
> > > > Christophe
> > > >
> > > > On Tue, Feb 26, 2002 at 10:51:08AM -0800, Andrew Morton wrote:
> > > > > christophe barb? wrote:
> > > > > >
> > > > > > Ok I have found why.
> > > > > > When I resinsert the card, the driver give it a new id (this driver
> > > > > > supports multiple cards) and the option as I set it is only defined for
> > > > > > the card #0. I would expect that the driver give the same id back.
> > > > > >
> > > > >
> > > > > hrm. OK, hotplugging and slot-positional module parameters weren't
> > > > > designed to live together.
> > > > >
> > > > > This should fix it for single cards. For multiple cards, you'll
> > > > > have to make sure you eject them in reverse scan order :)
> > > > >
> > > > > Index: drivers/net/3c59x.c
> > > > > ===================================================================
> > > > > RCS file: /opt/cvs/lk/drivers/net/3c59x.c,v
> > > > > retrieving revision 1.74.2.7
> > > > > diff -u -r1.74.2.7 3c59x.c
> > > > > --- drivers/net/3c59x.c 2002/02/13 21:03:03 1.74.2.7
> > > > > +++ drivers/net/3c59x.c 2002/02/26 18:49:24
> > > > > @@ -2898,6 +2898,9 @@
> > > > > BUG();
> > > > > }
> > > > >
> > > > > + if (vp->card_idx == vortex_cards_found)
> > > > > + vortex_cards_found--;
> > > > > +
> > > > > vp = dev->priv;
> > > > >
> > > > > /* AKPM: FIXME: we should have
> > > > >
> > > > >
> > > > > -
> > > >
> > > > --
> > > > Christophe Barb? <[email protected]>
> > > > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
> > > >
> > > > Imagination is more important than knowledge.
> > > > Albert Einstein, On Science
> > >
> > >
> > >
> > > --
> > > Christophe Barb? <[email protected]>
> > > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
> > >
> > > Imagination is more important than knowledge.
> > > Albert Einstein, On Science
> > >
> >
> > --
> > pozsy
> >
> > -
> > 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/
> >
>
> -
> 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/
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
L'experience, c'est une connerie par jour mais jamais la m?me.
But the weird fact is that after the _first_ load of the module (3c59x),
both of my cards work perfectly. The problem only occurs (and can be only
helped by reboot) if I rmmod it, and then try to reload. I don't think i'm
having irq problems, but i can check it tomorrow.
On Tue, 26 Feb 2002 [email protected] wrote:
> I've gotten this exact same error on various 3c905x cards. What it
> usually means for me is IRQ problems of some type.
> Nick
>
> On Wed, 27 Feb 2002, Pozsar Balazs wrote:
>
> >
> > I get very similar error if I remove the module and then reload it (rmmod
> > followed by a modprobe). So once I rmmod it, It will never be usable again
> > until i reboot.
> >
> > I have to pci 3com 905's, I can send the pci id's if those matters
> > tomorrow.
> >
> >
> > On Tue, 26 Feb 2002, christophe [iso-8859-15] barb? wrote:
> >
> > > Now that the forget_option bug is solved I have the following :
> > >
> > > Each time I suspend, the card resume in a bad state but return in a good
> > > state after that :
> > >
> > > NETDEV WATCHDOG: eth0: transmit timed out
> > > eth0: transmit timed out, tx_status 00 status e000.
> > > diagnostics: net 0ee0 media 8800 dma 000000a0.
> > > Flags; bus-master 1, dirty 20(4) current 36(4)
> > > Transmit list 00af8300 vs. c0af8300.
> > > 0: @c0af8200 length 80000062 status 00000062
> > > 1: @c0af8240 length 80000062 status 00000062
> > > 2: @c0af8280 length 80000062 status 80000062
> > > 3: @c0af82c0 length 80000062 status 80000062
> > > 4: @c0af8300 length 80000062 status 00000062
> > > 5: @c0af8340 length 8000003c status 0000003c
> > > 6: @c0af8380 length 80000062 status 00000062
> > > 7: @c0af83c0 length 80000062 status 00000062
> > > 8: @c0af8400 length 8000003c status 0000003c
> > > 9: @c0af8440 length 80000062 status 00000062
> > > 10: @c0af8480 length 80000062 status 00000062
> > > 11: @c0af84c0 length 80000036 status 00000036
> > > 12: @c0af8500 length 80000062 status 00000062
> > > 13: @c0af8540 length 80000062 status 00000062
> > > 14: @c0af8580 length 80000062 status 00000062
> > > 15: @c0af85c0 length 80000062 status 00000062
> > > eth0: Resetting the Tx ring pointer.
> > >
> > > The tx ring seems to be in a good state, no ?
> > >
> > > Christophe
> > >
> > > On Tue, Feb 26, 2002 at 01:59:07PM -0500, christophe barb? wrote:
> > > > Thank you, I have done something similar and that solve it in my case at
> > > > least. This driver was clearly not designed for cardbus.
> > > >
> > > > I am still looking for my resume/suspend problem.
> > > > Hope to find the solution soon.
> > > >
> > > > Christophe
> > > >
> > > > On Tue, Feb 26, 2002 at 10:51:08AM -0800, Andrew Morton wrote:
> > > > > christophe barb? wrote:
> > > > > >
> > > > > > Ok I have found why.
> > > > > > When I resinsert the card, the driver give it a new id (this driver
> > > > > > supports multiple cards) and the option as I set it is only defined for
> > > > > > the card #0. I would expect that the driver give the same id back.
> > > > > >
> > > > >
> > > > > hrm. OK, hotplugging and slot-positional module parameters weren't
> > > > > designed to live together.
> > > > >
> > > > > This should fix it for single cards. For multiple cards, you'll
> > > > > have to make sure you eject them in reverse scan order :)
> > > > >
> > > > > Index: drivers/net/3c59x.c
> > > > > ===================================================================
> > > > > RCS file: /opt/cvs/lk/drivers/net/3c59x.c,v
> > > > > retrieving revision 1.74.2.7
> > > > > diff -u -r1.74.2.7 3c59x.c
> > > > > --- drivers/net/3c59x.c 2002/02/13 21:03:03 1.74.2.7
> > > > > +++ drivers/net/3c59x.c 2002/02/26 18:49:24
> > > > > @@ -2898,6 +2898,9 @@
> > > > > BUG();
> > > > > }
> > > > >
> > > > > + if (vp->card_idx == vortex_cards_found)
> > > > > + vortex_cards_found--;
> > > > > +
> > > > > vp = dev->priv;
> > > > >
> > > > > /* AKPM: FIXME: we should have
> > > > >
> > > > >
> > > > > -
> > > >
> > > > --
> > > > Christophe Barb? <[email protected]>
> > > > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
> > > >
> > > > Imagination is more important than knowledge.
> > > > Albert Einstein, On Science
> > >
> > >
> > >
> > > --
> > > Christophe Barb? <[email protected]>
> > > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
> > >
> > > Imagination is more important than knowledge.
> > > Albert Einstein, On Science
> > >
> >
> > --
> > pozsy
> >
> > -
> > 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/
> >
>
--
pozsy
On Tue, Feb 26, 2002 at 03:32:23PM -0800, Andrew Morton wrote:
> christophe barb? wrote:
> >
> > Now that the forget_option bug is solved I have the following :
> >
> > Each time I suspend, the card resume in a bad state but return in a good
> > state after that :
> >
> > NETDEV WATCHDOG: eth0: transmit timed out
>
> The transceiver didn't power up, or came up in silly
> mode. I'll see if I can reproduce any of this.
> What NIC are you using?
I have played a little with mii-diag and vortex-diag without success.
'mii-diag' didn't show differences between good and bad states.
'vortex-diag' show a difference with the -aa option, I attach the
output.
I have tried some modifications in the driver, basically to do what
tx_timeout does in the resume function without success.
After that I have realized that the timeout, which occurs most of the
time 1 minute after the resume, is not the reason why the card returns
in the correct state (watchdog is set to 1000) otherwise it would occurs
earlier.
Andrew, will you send a patch to marcello for the 'always bigger card
id' bug or do you want me to do it ?
Christophe
>
> -
> -
> 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/
--
Christophe Barb? <[email protected]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
In a cat's eye, all things belong to cats.
--English proverb