sky2 1.3-rc1

sky2 1.3-rc1

[Stephen Hemminger]

Here is a new version that addresses some of the outstanding bugs.
* There was a race in receive processing that would cause hang
* Some more support for Yukon Ultra found in dual-core Centrino
  laptops (I want one of these).

It does not fix the problems with dual port cards corrupting receive
data (and possibly memory).

	http://developer.osdl.org/shemminger/prototypes/sky2-1.3-rc1.tar.bz2

If this works for most people, I'll post as separate patches for 2.6.17
tomorrow.

Re: sky2 1.3-rc1

[Daniel Drake]

Stephen Hemminger wrote:
> Here is a new version that addresses some of the outstanding bugs.
> * There was a race in receive processing that would cause hang
> * Some more support for Yukon Ultra found in dual-core Centrino
>   laptops (I want one of these).
> 
> It does not fix the problems with dual port cards corrupting receive
> data (and possibly memory).
> 
> 	http://developer.osdl.org/shemminger/prototypes/sky2-1.3-rc1.tar.bz2
> 
> If this works for most people, I'll post as separate patches for 2.6.17
> tomorrow.
> 

Barry Shilliday at http://bugs.gentoo.org/132056 reports that 1.3-rc1 
solves his earlier problems introduced in v1.1 are solved. However, it's 
not perfect, as latencies are much higher than they used to be.

v0.15:
64 bytes from 10.0.0.138: icmp_seq=2 ttl=64 time=0.467 ms

v1.3-rc1:
64 bytes from 10.0.0.138: icmp_seq=4 ttl=64 time=32.9 ms

Daniel

Re: sky2 1.3-rc1

[Thomas Glanzmann]

Hello,

> >	http://developer.osdl.org/shemminger/prototypes/sky2-1.3-rc1.tar.bz2

> v0.15:
> 64 bytes from 10.0.0.138: icmp_seq=2 ttl=64 time=0.467 ms

> v1.3-rc1:
> 64 bytes from 10.0.0.138: icmp_seq=4 ttl=64 time=32.9 ms

I can't confirm this. For me it is just perfect:

64 bytes from 89.106.66.1: icmp_seq=1 ttl=64 time=0.278 ms

0000:04:00.0 Ethernet controller: Marvell Technology Group Ltd.: Unknown device 4361 (rev 17)

        Thomas

Re: sky2 1.3-rc1

[Stephen Hemminger]

On Fri, 5 May 2006 19:35:09 +0200
Thomas Glanzmann <sithglan@stud.uni-erlangen.de> wrote:

> Hello,
> 
> > >	http://developer.osdl.org/shemminger/prototypes/sky2-1.3-rc1.tar.bz2
> 
> > v0.15:
> > 64 bytes from 10.0.0.138: icmp_seq=2 ttl=64 time=0.467 ms
> 
> > v1.3-rc1:
> > 64 bytes from 10.0.0.138: icmp_seq=4 ttl=64 time=32.9 ms
> 
> I can't confirm this. For me it is just perfect:
> 
> 64 bytes from 89.106.66.1: icmp_seq=1 ttl=64 time=0.278 ms
> 
> 0000:04:00.0 Ethernet controller: Marvell Technology Group Ltd.: Unknown device 4361 (rev 17)
> 
>         Thomas

What is happening is that if there is a misconfiguration and irq routing
is messed up (ie edge trigged). The driver will degenerate to polling every 100ms.
If your system is this misconfigured, then ACPI or the BIOS needs to be fixed
and the driver really only needs to work well enough to get the bug report out ;-)

The older driver was doing rewhacking the Transmit IRQ status timer,
so it would give a bogus transmit status interrupt and that was masking
issues.

Re: sky2 1.3-rc1

[Daniel Drake]

Stephen Hemminger wrote:
> What is happening is that if there is a misconfiguration and irq routing
> is messed up (ie edge trigged). The driver will degenerate to polling every 100ms.
> If your system is this misconfigured, then ACPI or the BIOS needs to be fixed
> and the driver really only needs to work well enough to get the bug report out ;-)

Ok, thanks for the explanation.

Can you give any hints as to how we can classify this misconfiguration? 
Barry's system has a level triggered IRQ assigned to sky2, and that IRQ 
is not shared:

http://bugs.gentoo.org/show_bug.cgi?id=132056#c3

I'm just looking for something I can take to the ACPI developers, other 
than "its broken because Stephen said so" ;)

Thanks.
Daniel

Re: sky2 1.3-rc1

[Stephen Hemminger]

On Fri, 05 May 2006 19:42:27 +0100
Daniel Drake <dsd@gentoo.org> wrote:

> Stephen Hemminger wrote:
> > What is happening is that if there is a misconfiguration and irq routing
> > is messed up (ie edge trigged). The driver will degenerate to polling every 100ms.
> > If your system is this misconfigured, then ACPI or the BIOS needs to be fixed
> > and the driver really only needs to work well enough to get the bug report out ;-)
> 
> Ok, thanks for the explanation.
> 
> Can you give any hints as to how we can classify this misconfiguration? 
> Barry's system has a level triggered IRQ assigned to sky2, and that IRQ 
> is not shared:
> 
> http://bugs.gentoo.org/show_bug.cgi?id=132056#c3
> 
> I'm just looking for something I can take to the ACPI developers, other 
> than "its broken because Stephen said so" ;)

Try running idle_timeout=0 module parameter.  In that case there will be no
polling timer.  If it just hangs, then the problem is missed interrupt.

You could use this to see if you are getting irq's

--- sky2.orig/drivers/net/sky2.c
+++ sky2/drivers/net/sky2.c
@@ -2125,6 +2125,9 @@ static int sky2_poll(struct net_device *
 	int work_done = 0;
 	u32 status = sky2_read32(hw, B0_Y2_SP_EISR);
 
+	if (netif_msg_intr((struct sky2_port *) netdev_priv(dev0)))
+		printk(KERN_DEBUG PFX "poll status %#x\n", status);
+
 	if (status & Y2_IS_HW_ERR)
 		sky2_hw_intr(hw);
 
@@ -2183,6 +2186,9 @@ static irqreturn_t sky2_intr(int irq, vo
 	if (status == 0 || status == ~0)
 		return IRQ_NONE;
 
+	if (netif_msg_intr((struct sky2_port *) netdev_priv(dev0)))
+		printk(KERN_DEBUG PFX "irq status %#x\n", status);
+
 	prefetch(&hw->st_le[hw->st_idx]);
 	if (likely(__netif_rx_schedule_prep(dev0)))
 		__netif_rx_schedule(dev0);