qfe problems on x86

qfe problems on x86

[Aaron Sethman]

I'm currently having a problem with my qfe card on an intel box.
Basically what will happen is when I load the module and bring it up, I
will get the "eth0: Switching to 100Mbps at full duplex." Followed by a
"eth0: Link status change.".  For some reason, it gets stuck in a loop and
I get a continual stream of these and the system is pretty much useless
from that point on.  Any ideas of something I could try?

Regards,

Aaron

Re: qfe problems on x86

[David S. Miller]

You didn't bother mentioning what kernel verions you see this with so
I basically have no way to help you out.

Re: qfe problems on x86

[David S. Miller]

   From: Aaron Sethman <androsyn@ratbox.org>
   Date: Tue, 23 Apr 2002 06:47:43 -0400 (EDT)

   My fault, this was on both 2.4.18 and 2.4.19-pre7.
   
Are you hooked up to a switch or a hub?

Re: qfe problems on x86

[David S. Miller]

   From: Aaron Sethman <androsyn@ratbox.org>
   Date: Tue, 23 Apr 2002 07:04:24 -0400 (EDT)

   Its attached to a D-Link mini switch(your average $20 piece of junk).
   
If it is $20 it isn't a switch, I can assure you
this. :-)  More seriously, please be sure its' a switch.

99 out of 100 reports about not getting full duplex turn
out to be the person is attached to a 100baseT hub, not
a switch.

Re: qfe problems on x86

[Aaron Sethman]

My fault, this was on both 2.4.18 and 2.4.19-pre7.

Regards,

Aaronn

On Mon, 22 Apr 2002, David S. Miller wrote:

>
> You didn't bother mentioning what kernel verions you see this with so
> I basically have no way to help you out.
>

Re: qfe problems on x86

[David S. Miller]

   From: Aaron Sethman <androsyn@ratbox.org>
   Date: Tue, 23 Apr 2002 07:19:25 -0400 (EDT)

   I'm *certain* this is a switch, albeit a cheap, unmanaged one, I've got
   other devices hanging off of it that are just happy at 100MB/full duplex
   right now. Also I am not forcing it to full duplex, this is what it is
   trying to do on its own.
   
It means it cannot negotiate this with the switch for some reason.

Does trying to force full duplex using 'ethtool' have any
effect?

Re: qfe problems on x86

[Aaron Sethman]

Its attached to a D-Link mini switch(your average $20 piece of junk).

Regards,

Aaron

On Tue, 23 Apr 2002, David S. Miller wrote:

>    From: Aaron Sethman <androsyn@ratbox.org>
>    Date: Tue, 23 Apr 2002 06:47:43 -0400 (EDT)
>
>    My fault, this was on both 2.4.18 and 2.4.19-pre7.
>
> Are you hooked up to a switch or a hub?
>

Re: qfe problems on x86

[Aaron Sethman]

I'm *certain* this is a switch, albeit a cheap, unmanaged one, I've got
other devices hanging off of it that are just happy at 100MB/full duplex
right now. Also I am not forcing it to full duplex, this is what it is
trying to do on its own.

Regards,

Aaron

On Tue, 23 Apr 2002, David S. Miller wrote:

>    From: Aaron Sethman <androsyn@ratbox.org>
>    Date: Tue, 23 Apr 2002 07:04:24 -0400 (EDT)
>
>    Its attached to a D-Link mini switch(your average $20 piece of junk).
>
> If it is $20 it isn't a switch, I can assure you
> this. :-)  More seriously, please be sure its' a switch.
>
> 99 out of 100 reports about not getting full duplex turn
> out to be the person is attached to a 100baseT hub, not
> a switch.
>
>

Re: qfe problems on x86

[David S. Miller]

   From: Aaron Sethman <androsyn@ratbox.org>
   Date: Tue, 23 Apr 2002 07:57:00 -0400 (EDT)

   Okay, tried it this time.  It worked for a short period of time, as I
   could ping the default gateway.  When I tried to ping it from another
   host, that is when it decided it would go dead.  This time, it did not go
   crazy and lock the system up at least.  I tried at both full and half
   duplex, with the same experience.
   
What MAC address do the qfe interfaces come up with?

Re: qfe problems on x86

[David S. Miller]

   From: Aaron Sethman <androsyn@ratbox.org>
   Date: Tue, 23 Apr 2002 08:00:59 -0400 (EDT)

   Initially they came up with 00:00:00:00:00:00

With the current 2.4.19-pre7 sunhme driver this should
never happen.  At worst it should use a random number
as the MAC address.

Re: qfe problems on x86

[David S. Miller]

   From: Aaron Sethman <androsyn@ratbox.org>
   Date: Tue, 23 Apr 2002 08:07:25 -0400 (EDT)

   You are correct, I was still doing this from my experiences with 2.4.18.
   It came up with 08:00:20:f4:0d:34-7.  I tried it again without setting the
   macaddr, same thing with it hanging after pinging it from another host.
   
   What is strange is that I can ping the gateway just fine, and all the
   sudden it stops right when I ping it from elsewhere.

Can you turn on spin lock debugging for the 2.4.19-preX case?
I bet that will catch what locks it up.

You said this is an SMP box right?

Re: qfe problems on x86

[David S. Miller]

   From: Aaron Sethman <androsyn@ratbox.org>
   Date: Tue, 23 Apr 2002 08:11:41 -0400 (EDT)

   This is actually a single cpu Pentium 150 with 96MB ram, compiled
   uniprocessor of course.
   
I don't know where to go from here then, it works fine on my
Athlon and thats the only x86 I have for testing my one qfe
card.

Re: qfe problems on x86

[Aaron Sethman]

Okay, tried it this time.  It worked for a short period of time, as I
could ping the default gateway.  When I tried to ping it from another
host, that is when it decided it would go dead.  This time, it did not go
crazy and lock the system up at least.  I tried at both full and half
duplex, with the same experience.

Regards,

Aaron



On Tue, 23 Apr 2002, David S. Miller wrote:

>    From: Aaron Sethman <androsyn@ratbox.org>
>    Date: Tue, 23 Apr 2002 07:19:25 -0400 (EDT)
>
>    I'm *certain* this is a switch, albeit a cheap, unmanaged one, I've got
>    other devices hanging off of it that are just happy at 100MB/full duplex
>    right now. Also I am not forcing it to full duplex, this is what it is
>    trying to do on its own.
>
> It means it cannot negotiate this with the switch for some reason.
>
> Does trying to force full duplex using 'ethtool' have any
> effect?
>

Re: qfe problems on x86

[David S. Miller]

   From: Aaron Sethman <androsyn@ratbox.org>
   Date: Tue, 23 Apr 2002 08:19:43 -0400 (EDT)

   Hmmm...I just noticed something curious in the dmesg output I hadn't
   noticed before now..
   
   PCI: Failed to allocate resource 0(e0000000-dfffffff) for 01:01.0
   PCI: Failed to allocate resource 0(e0000000-dfffffff) for 01:02.0
   PCI: Failed to allocate resource 1(e0000000-dfffffff) for 01:02.0
   
   I'm not sure if that is normal or not, but those devices are part of the
   QFE.

It's an annoying message, but the only result is that the sunhme
driver uses other methods to select the MAC address.

Re: qfe problems on x86

[Aaron Sethman]

Initially they came up with 00:00:00:00:00:00, but I did pass a
macaddr=0x08,0x01,0x03,0x01,0x01,0x08, this being a rather arbitrary MAC
address that I know isn't on my network currently.

Regards,

Aaron

On Tue, 23 Apr 2002, David S. Miller wrote:

>    From: Aaron Sethman <androsyn@ratbox.org>
>    Date: Tue, 23 Apr 2002 07:57:00 -0400 (EDT)
>
>    Okay, tried it this time.  It worked for a short period of time, as I
>    could ping the default gateway.  When I tried to ping it from another
>    host, that is when it decided it would go dead.  This time, it did not go
>    crazy and lock the system up at least.  I tried at both full and half
>    duplex, with the same experience.
>
> What MAC address do the qfe interfaces come up with?
>

Re: qfe problems on x86

[Aaron Sethman]

You are correct, I was still doing this from my experiences with 2.4.18.
It came up with 08:00:20:f4:0d:34-7.  I tried it again without setting the
macaddr, same thing with it hanging after pinging it from another host.

What is strange is that I can ping the gateway just fine, and all the
sudden it stops right when I ping it from elsewhere.

Regards,

Aaron
On Tue, 23 Apr 2002, David S. Miller wrote:

>    From: Aaron Sethman <androsyn@ratbox.org>
>    Date: Tue, 23 Apr 2002 08:00:59 -0400 (EDT)
>
>    Initially they came up with 00:00:00:00:00:00
>
> With the current 2.4.19-pre7 sunhme driver this should
> never happen.  At worst it should use a random number
> as the MAC address.
>
>

Re: qfe problems on x86

[Aaron Sethman]

This is actually a single cpu Pentium 150 with 96MB ram, compiled
uniprocessor of course.

Regards,

Aaron

On Tue, 23 Apr 2002, David S. Miller wrote:

>    From: Aaron Sethman <androsyn@ratbox.org>
>    Date: Tue, 23 Apr 2002 08:07:25 -0400 (EDT)
>
>    You are correct, I was still doing this from my experiences with 2.4.18.
>    It came up with 08:00:20:f4:0d:34-7.  I tried it again without setting the
>    macaddr, same thing with it hanging after pinging it from another host.
>
>    What is strange is that I can ping the gateway just fine, and all the
>    sudden it stops right when I ping it from elsewhere.
>
> Can you turn on spin lock debugging for the 2.4.19-preX case?
> I bet that will catch what locks it up.
>
> You said this is an SMP box right?
>

Re: qfe problems on x86

[Aaron Sethman]

Hmmm...I just noticed something curious in the dmesg output I hadn't
noticed before now..

PCI: Failed to allocate resource 0(e0000000-dfffffff) for 01:01.0
PCI: Failed to allocate resource 0(e0000000-dfffffff) for 01:02.0
PCI: Failed to allocate resource 1(e0000000-dfffffff) for 01:02.0

I'm not sure if that is normal or not, but those devices are part of the
QFE.

Regards,

Aaron

On Tue, 23 Apr 2002, David S. Miller wrote:

>    From: Aaron Sethman <androsyn@ratbox.org>
>    Date: Tue, 23 Apr 2002 08:11:41 -0400 (EDT)
>
>    This is actually a single cpu Pentium 150 with 96MB ram, compiled
>    uniprocessor of course.
>
> I don't know where to go from here then, it works fine on my
> Athlon and thats the only x86 I have for testing my one qfe
> card.
>

Re: qfe problems on x86

[David S. Miller]

This log doesn't tell me anything, sorry.

I think you're going to have to work on tracking this down
yourself or find someone who can debug it and can reproduce
the problem.

Re: qfe problems on x86

[Aaron Sethman]

I ended up compiling the module with a bunch of the debugging options
turned here is what while i was pinging my gateway then started ping it
from another host. Towards the end around TX<[13]> is where the problems
come up and this stop working.

Regards,

Aaron

eth0: Link has been forced up using internal transceiver at happy_meal_tcvr_read: reg=0x00 value=2100
100Mb/s, Full Duplex.
happy_meal_tcvr_read: reg=0x00 value=2100
happy_meal_interrupt: status=03000000 TXALL TX<[0]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[0 len=60 csum=58d9]>done
happy_meal_interrupt: status=03000000 TXALL TX<[1]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[1 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[2]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[2 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[3]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[3 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[4]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[4 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[5]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[5 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[6]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[6 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[7]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[7 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[8]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[8 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[9]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[9 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[10]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[10 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[11]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[11 len=98 csum=   0]>done
happy_meal_interrupt: status=03000000 TXALL TX<[12]>done
happy_meal_interrupt: status=00010000 RXTOHOST RX<[12 len=98 csum=   0]>done
happy_meal_interrupt: status=03010000 TXALL TX<[13]>RXTOHOST RX<[13 len=60 csum=b959]>done
happy_meal_interrupt: status=03000000 TXALL TX<[14]>done
happy_meal_interrupt: status=03000000 TXALL TX<[15]>done
happy_meal_interrupt: status=03000000 TXALL TX<[16]>done
happy_meal_interrupt: status=03000000 TXALL TX<[17]>done
happy_meal_interrupt: status=03000000 TXALL TX<[18]>done
happy_meal_interrupt: status=03000000 TXALL TX<[19]>done
happy_meal_interrupt: status=03000000 TXALL TX<[20]>done
happy_meal_interrupt: status=03000000 TXALL TX<[21]>done
happy_meal_interrupt: status=03000000 TXALL TX<[22]>done
happy_meal_interrupt: status=03000000 TXALL TX<[23]>done
happy_meal_interrupt: status=03000000 TXALL TX<[24]>done