3c59x and cardbus

3c59x and cardbus

[christophe barbé]

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

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é <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

There is no snooze button on a cat who wants breakfast.

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: 3c59x and cardbus

[Andrew Morton]

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?


-

Re: 3c59x and cardbus

[christophe barbé]

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

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é <christophe.barbe@ufies.org>
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

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: 3c59x and cardbus

[christophe barbé]

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

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é <christophe.barbe@ufies.org>
> 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é <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

In a cat's eye, all things belong to cats.
--English proverb

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: 3c59x and cardbus

[Andrew Morton]

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


-

Re: 3c59x and cardbus

[christophe barbé]

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

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é <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Imagination is more important than knowledge.
   Albert Einstein, On Science

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: 3c59x and cardbus

[christophe barbé]

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

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é <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> 
> Imagination is more important than knowledge.
>    Albert Einstein, On Science



-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Imagination is more important than knowledge.
   Albert Einstein, On Science

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: 3c59x and cardbus

[Andrew Morton]

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?

-

Re: 3c59x and cardbus

[christophe barbé]

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

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é <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

Dogs believe they are human. Cats believe they are God.

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: 3c59x and cardbus

[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.


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é <christophe.barbe@ufies.org>
> > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> >
> > Imagination is more important than knowledge.
> >    Albert Einstein, On Science
>
>
>
> --
> Christophe Barbé <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
>
> Imagination is more important than knowledge.
>    Albert Einstein, On Science
>

-- 
pozsy

Re: 3c59x and cardbus

[nick]

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é <christophe.barbe@ufies.org>
> > > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> > >
> > > Imagination is more important than knowledge.
> > >    Albert Einstein, On Science
> >
> >
> >
> > --
> > Christophe Barbé <christophe.barbe@ufies.org>
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: 3c59x and cardbus

[christophe barbé]

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

On Tue, Feb 26, 2002 at 07:32:59PM -0500, nick@snowman.net 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é <christophe.barbe@ufies.org>
> > > > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> > > >
> > > > Imagination is more important than knowledge.
> > > >    Albert Einstein, On Science
> > >
> > >
> > >
> > > --
> > > Christophe Barbé <christophe.barbe@ufies.org>
> > > 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 majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Christophe Barbé <christophe.barbe@ufies.org>
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.

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: 3c59x and cardbus

[Pozsar Balazs]

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 nick@snowman.net 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é <christophe.barbe@ufies.org>
> > > > GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> > > >
> > > > Imagination is more important than knowledge.
> > > >    Albert Einstein, On Science
> > >
> > >
> > >
> > > --
> > > Christophe Barbé <christophe.barbe@ufies.org>
> > > 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>

-- 
pozsy

Re: 3c59x and cardbus

[christophe barbé]

[-- Attachment #1.1: Type: text/plain, Size: 1620 bytes --]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

In a cat's eye, all things belong to cats.
--English proverb

[-- Attachment #1.2: vdiag-aa.output.ok --]
[-- Type: text/plain, Size: 1064 bytes --]

vortex-diag.c:v2.05 5/15/2001 Donald Becker (becker@scyld.com)
 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.

[-- Attachment #1.3: vdiag-aa.output.pb --]
[-- Type: text/plain, Size: 1064 bytes --]

vortex-diag.c:v2.05 5/15/2001 Donald Becker (becker@scyld.com)
 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.

[-- Attachment #1.4: mii-diag.output --]
[-- Type: text/plain, Size: 344 bytes --]

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.


[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]