3c59x and cardbus

DISCUSSION christophe barbé 4 participants 14 messages Feb 26, 2002 – Mar 2, 2002 Networking

Share & tools

christophe barbé

author

2002-02-26 17:31 UTC #0 lore raw

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

Signature · 4 lines

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.

Andrew Morton

2002-02-26 17:42 UTC #1 lore raw

Quoted 10 lines · christophe barbé

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?

christophe barbé

author

2002-02-26 17:59 UTC #2 lore raw

In reply to christophe barbé

Quoted 9 lines · Andrew Morton

Quoted 8 lines · christophe barbé
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 7 lines

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?
-

Signature · 5 lines

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é

author

2002-02-26 18:17 UTC #3 lore raw

In reply to christophe barbé

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

Quoted 35 lines · christophe barbé

Quoted 9 lines · Andrew Morton
Quoted 8 lines · christophe barbé
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
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?
-
Signature · 5 lines
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

Signature · 5 lines

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

Andrew Morton

2002-02-26 18:53 UTC #4 lore raw

In reply to christophe barbé

Quoted 6 lines · christophe barbé

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

net/3c59x.c +3 -0

diff -u -r1.74.2.7 3c59x.c
@@ -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é

author

2002-02-26 18:59 UTC #5 lore raw

In reply to christophe barbé

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

Quoted 34 lines · Andrew Morton

Quoted 6 lines · christophe barbé
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
net/3c59x.c +3 -1
@@ -2898,6 +2898,9 @@
 		BUG();
 	}
 
+	if (vp->card_idx == vortex_cards_found)
+		vortex_cards_found--;
+
 	vp = dev->priv;
 
 	/* AKPM: FIXME: we should have
 
 
-

Signature · 5 lines

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é

author

2002-02-26 23:00 UTC #6 lore raw

In reply to christophe barbé

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

Quoted 50 lines · christophe barbé

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
Quoted 34 lines · Andrew Morton
Quoted 6 lines · christophe barbé
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
net/3c59x.c +3 -1
@@ -2898,6 +2898,9 @@
 		BUG();
 	}
 
+	if (vp->card_idx == vortex_cards_found)
+		vortex_cards_found--;
+
 	vp = dev->priv;
 
 	/* AKPM: FIXME: we should have
 
 
-
Signature · 5 lines
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

Signature · 5 lines

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

Pozsar Balazs

2002-02-27 00:30 UTC #7 lore raw

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.

Quoted 93 lines · 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
Quoted 42 lines · christophe barbé
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
Quoted 33 lines · Andrew Morton
Quoted 6 lines · christophe barbé
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
net/3c59x.c +3 -0
@@ -2898,6 +2898,9 @@
 		BUG();
 	}
 
+	if (vp->card_idx == vortex_cards_found)
+		vortex_cards_found--;
+
 	vp = dev->priv;
 
 	/* AKPM: FIXME: we should have
Quoted 8 lines
Quoted 1 line
-
--
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

Signature · 1 line

pozsy

[email protected]

2002-02-27 00:33 UTC #8 lore raw

I've gotten this exact same error on various 3c905x cards. What it usually means for me is IRQ problems of some type.
Nick

Quoted 114 lines · Pozsar Balazs

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.
Quoted 93 lines · 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
Quoted 42 lines · christophe barbé
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
Quoted 33 lines · Andrew Morton
Quoted 6 lines · christophe barbé
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
net/3c59x.c +3 -0
@@ -2898,6 +2898,9 @@
 		BUG();
 	}
 
+	if (vp->card_idx == vortex_cards_found)
+		vortex_cards_found--;
+
 	vp = dev->priv;
 
 	/* AKPM: FIXME: we should have
Quoted 8 lines
Quoted 1 line
-
--
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
Signature · 7 lines
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/

Pozsar Balazs

2002-02-27 00:44 UTC #9 lore raw

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.

Quoted 121 lines · 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
Quoted 114 lines · Pozsar Balazs
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.
Quoted 86 lines · 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
Quoted 42 lines · christophe barbé
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
Quoted 33 lines · Andrew Morton
Quoted 6 lines · christophe barbé
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
net/3c59x.c +3 -0
@@ -2898,6 +2898,9 @@
 		BUG();
 	}
 
+	if (vp->card_idx == vortex_cards_found)
+		vortex_cards_found--;
+
 	vp = dev->priv;
 
 	/* AKPM: FIXME: we should have
Quoted 8 lines
Quoted 1 line
-
--
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
Quoted 7 lines
--
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/

Signature · 1 line

pozsy

christophe barbé

author

2002-02-27 00:41 UTC #10 lore raw

In reply to Pozsar Balazs

Quoted 4 lines · 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

Quoted 122 lines · Pozsar Balazs

Quoted 98 lines
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.
Quoted 86 lines · 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
Quoted 50 lines · christophe barbé
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
Quoted 24 lines · Andrew Morton
Quoted 6 lines · christophe barbé
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
net/3c59x.c +0 -0
@@ -2898,6 +2898,9 @@
 		BUG();
 	}
net/3c59x.c
Quoted 10 lines
net/3c59x.c +3 -1
 
+	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
Quoted 17 lines
Quoted 7 lines
--
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
Signature · 7 lines
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/

Signature · 4 lines

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.

Andrew Morton

2002-02-26 23:34 UTC #11 lore raw

In reply to christophe barbé

Quoted 7 lines · christophe barbé

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?

christophe barbé

author

2002-02-26 23:39 UTC #12 lore raw

In reply to christophe barbé

Quoted 4 lines · Andrew Morton

Quoted 3 lines · christophe barbé
Now that the forget_option bug is solved I have the following :

Quoted 9 lines

Quoted 4 lines
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

Signature · 4 lines

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.

christophe barbé

author

2002-03-02 21:09 UTC #13 lore raw

In reply to christophe barbé

Quoted 4 lines · Andrew Morton

Quoted 3 lines · christophe barbé
Now that the forget_option bug is solved I have the following :

Quoted 8 lines

Quoted 4 lines
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

Quoted 7 lines

(quoted diff) +0 -2
-
-
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/

Signature · 5 lines

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

vortex-diag.c:v2.05 5/15/2001 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html
Index #1: Found a 3CCFE575CT CardBus adapter at 0x4000. Initial window 7, registers values by window:
Window 0: 0000 0000 0002 0000 0808 06ff ffff 0000. Window 1: 0000 0000 0000 0000 0000 0000 0000 2000. Window 2: 0100 d302 1ede 0000 0000 0000 4102 4000. Window 3: 0000 0060 05ea 0000 0040 1000 0800 6000. Window 4: 0000 0000 0000 0ce0 0003 8800 0000 8000. Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000. Window 6: 0000 0000 0000 0000 0000 0000 0000 c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0x4000
0x4010: 00000000 00000000 00000016 00000000 0x4020: 00000020 00000000 00080000 00000004 0x4030: 00000000 75718a8f 00c2e030 00080004
Indication enable is 06c6, interrupt enable is 06ce. No interrupt sources are pending.
Transceiver/media interfaces available: MII.
Transceiver type in use: MII.
MAC settings: half-duplex.
Station address set to 00:01:02:d3:de:1e. Configuration options 4102.

vortex-diag.c:v2.05 5/15/2001 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html
Index #1: Found a 3CCFE575CT CardBus adapter at 0x4000. Initial window 7, registers values by window:
Window 0: 0000 0000 0000 0000 5555 06ff ffff 0000. Window 1: 0000 0000 0000 0000 0000 0000 0000 2000. Window 2: 0100 d302 1ede 0000 0000 0000 4102 4000. Window 3: 0000 0060 05ea 0000 0040 1000 0800 6000. Window 4: 0000 0000 0000 0ce0 0003 8800 0000 8000. Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000. Window 6: 0000 0000 0000 0000 0000 0000 0000 c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0x4000
0x4010: 00000000 00000000 00000000 00000000 0x4020: 00000020 00000000 00080000 00000004 0x4030: 00000000 2c01d3ff 00c2e000 00080004
Indication enable is 06c6, interrupt enable is 06ce. No interrupt sources are pending.
Transceiver/media interfaces available: MII.
Transceiver type in use: MII.
MAC settings: half-duplex.
Station address set to 00:01:02:d3:de:1e. Configuration options 4102.

Basic registers of MII PHY #0: 3100 782d 0300 e54b 01e1 0000 0000 0000.
Basic mode control register 0x3100: Auto-negotiation enabled. You have link beat, and everything is working OK.
Your link partner does not do autonegotiation, and this transceiver type
does not report the sensed link speed.
End of basic transceiver information.