Is via-velocity broken in 2.6.34?

Is via-velocity broken in 2.6.34?

[Matt Causey]

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

Hello,

I'm running a vanilla 2.6.34 on a fleet of thin clients.  We just got
some devices that have a via VT61xx gigabit network card, and we
discovered that the networking does not start on this new hardware.
I've searched the archives here but have not seen similar reports -
though this network adapter might not be in wide circulation
yet....not sure.

The network driver loads just fine, and I'm able to create eth0.  I
can run a dhcp client on the interface, and my dhcp server recieves
the DHCPDISCOVER messages, immediately sending DHCPOFFERs, however the
dhcp client does not acknowledge the offers.  When running ifconfig
while this is happening, the RX packets field increments slowly, while
the TX packets field does not do anything.  It stays at 0.  I would
expect the DHCPDISCOVER packets (since they are transmitting to my
server) to be incrimenting the TX packets field.

When I assign an IPV4 address to the interface, I cannot ping devices
on the same subnet.  When I run tcpdump on other linux hosts on the
same subnet, I can see that the client does an ARP request for the ip
address it is trying to ping.  I also see the arp-replies on the wire,
but the client continuously sends arp-requests.

The previous version we had working was 2.6.29, and the via-velocity
driver there works fine on this particular hardware.  I've just
compiled 2.6.34-6 and the problem is the same.

Attached is debug.tar.  It contains dmesg, config.gz, ethtool,
ifconfig, and lspci output.  I'm not sure what else to do at this
point.  Is there some debugging I can enable in the kernel to give
more clues as to what's gone wrong?

Cheers!

--
Matt

[-- Attachment #2: debug.tar --]
[-- Type: application/x-tar, Size: 19456 bytes --]

Re: Is via-velocity broken in 2.6.34?

[Francois Romieu]

Please Cc: netdev@vger.kernel.org

Matt Causey <matt.causey@gmail.com> :
[2.6.29 -> 2.6.34 regression]
> Attached is debug.tar.  It contains dmesg, config.gz, ethtool,
> ifconfig, and lspci output.  I'm not sure what else to do at this
> point.  Is there some debugging I can enable in the kernel to give
> more clues as to what's gone wrong?

Any chance you could bisect the regression or narrow it down a bit ?

Otherwise may I assume that there is no difference in the
userspace tools (just in case) ?

-- 
Ueimor

Re: Is via-velocity broken in 2.6.34?

[David Miller]

Please always CC: netdev@vger.kernel.org for networking reports.

Give this patch a try:

--------------------
via-velocity: Turn scatter-gather support back off.

It causes all kinds of DMA API debugging assertions and
all straight-forward attempts to fix it have failed.

So turn off SG, and we'll tackle making this work
properly in net-next-2.6

Reported-by: Dave Jones <davej@redhat.com>
Tested-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/via-velocity.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index fd69095..f534123 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -2824,7 +2824,7 @@ static int __devinit velocity_found1(struct pci_dev *pdev, const struct pci_devi
 	netif_napi_add(dev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
 
 	dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER |
-		NETIF_F_HW_VLAN_RX | NETIF_F_IP_CSUM | NETIF_F_SG;
+		NETIF_F_HW_VLAN_RX | NETIF_F_IP_CSUM;
 
 	ret = register_netdev(dev);
 	if (ret < 0)
-- 
1.7.2.2

Re: Is via-velocity broken in 2.6.34?

[Matt Causey]

On Tue, Sep 7, 2010 at 4:29 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Please Cc: netdev@vger.kernel.org

Done, cheers for that I didn't know.

>
> Matt Causey <matt.causey@gmail.com> :
> [2.6.29 -> 2.6.34 regression]
>> Attached is debug.tar.  It contains dmesg, config.gz, ethtool,
>> ifconfig, and lspci output.  I'm not sure what else to do at this
>> point.  Is there some debugging I can enable in the kernel to give
>> more clues as to what's gone wrong?
>
> Any chance you could bisect the regression or narrow it down a bit ?
>

I've never bisected before.  But I'll lookup some documentation and
give it a go.  :-)

> Otherwise may I assume that there is no difference in the
> userspace tools (just in case) ?
>

That's a valid assumption.  The userland was exactly the same, just
different kernel version.

--
Matt

Re: Is via-velocity broken in 2.6.34?

[Matt Causey]

On Tue, Sep 7, 2010 at 4:33 PM, David Miller <davem@davemloft.net> wrote:
>
> Please always CC: netdev@vger.kernel.org for networking reports.
>
> Give this patch a try:
>
> --------------------
> via-velocity: Turn scatter-gather support back off.
>
> It causes all kinds of DMA API debugging assertions and
> all straight-forward attempts to fix it have failed.
>
> So turn off SG, and we'll tackle making this work
> properly in net-next-2.6
>
> Reported-by: Dave Jones <davej@redhat.com>
> Tested-by: Dave Jones <davej@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
>  drivers/net/via-velocity.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
> index fd69095..f534123 100644
> --- a/drivers/net/via-velocity.c
> +++ b/drivers/net/via-velocity.c
> @@ -2824,7 +2824,7 @@ static int __devinit velocity_found1(struct pci_dev *pdev, const struct pci_devi
>        netif_napi_add(dev, &vptr->napi, velocity_poll, VELOCITY_NAPI_WEIGHT);
>
>        dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER |
> -               NETIF_F_HW_VLAN_RX | NETIF_F_IP_CSUM | NETIF_F_SG;
> +               NETIF_F_HW_VLAN_RX | NETIF_F_IP_CSUM;
>
>        ret = register_netdev(dev);
>        if (ret < 0)

So before I posted to the list, I actually dug through looking for
recent changes which would be trivial for me to back out.  This was
the only one I had found, so I tried it.  :-)  No luck though...same
result.

Thanks,

--
Matt

Re: Is via-velocity broken in 2.6.34?

[David Miller]

From: Matt Causey <matt.causey@gmail.com>
Date: Tue, 7 Sep 2010 17:13:14 -0700

> So before I posted to the list, I actually dug through looking for
> recent changes which would be trivial for me to back out.  This was
> the only one I had found, so I tried it.  :-)  No luck though...same
> result.

Thanks, please continue reading up on how to bisect this down,
that will help us figure out what the problem is.

Thanks.

Re: Is via-velocity broken in 2.6.34?

[Matt Causey]

On Tue, Sep 7, 2010 at 5:24 PM, David Miller <davem@davemloft.net> wrote:
> From: Matt Causey <matt.causey@gmail.com>
> Date: Tue, 7 Sep 2010 17:13:14 -0700
>
>> So before I posted to the list, I actually dug through looking for
>> recent changes which would be trivial for me to back out.  This was
>> the only one I had found, so I tried it.  :-)  No luck though...same
>> result.
>
> Thanks, please continue reading up on how to bisect this down,
> that will help us figure out what the problem is.
>

Apologies, my troubleshooting was faulty.  In my testing when I was
switching between 2.6.29 / 2.6.34 there was a .config change that I
failed to notice.  In my  2.6.29 config I had all the default
config_pm and acpi options enabled, whereas in the later config I had
them all disabled.

So, the minimum acpi stuff needed for the driver to function is
CONFIG_PM and CONFIG_ACPI.  None of the timer stuff or anything else
appears to be necessary.  If that's the case (others can correct me if
not...) could we patch the Kconfig to look like this:

config VIA_VELOCITY
        tristate "VIA Velocity support"
        depends on PCI && PM && ACPI

since today it's only depending on pci.

If this is the right thing to do I can submit a patch .  Apologies
again for the red herring.  :-)

Cheers,

--
Matt

Re: Is via-velocity broken in 2.6.34?

[David Miller]

From: Matt Causey <matt.causey@gmail.com>
Date: Wed, 8 Sep 2010 08:27:19 -0700

> config VIA_VELOCITY
>         tristate "VIA Velocity support"
>         depends on PCI && PM && ACPI
> 
> since today it's only depending on pci.
> 
> If this is the right thing to do I can submit a patch .  Apologies
> again for the red herring.  :-)

Needing ACPI for proper functioning of a moden x86 system
is no surprise, and isn't a VIA specific issue :-)

Re: Is via-velocity broken in 2.6.34?

[David Miller]

From: Matt Causey <matt.causey@gmail.com>
Date: Thu, 9 Sep 2010 10:42:21 -0700

> So it wasn't immediately intuitive that we would need power
> management enabled in order to use other parts of the system.

ACPI is not power management.

It's a set of infrastructure (including an interpreter and small
firmware programs to drive specialized hardware) that allows the
important details of your motherboard to be described accurately to
the kernel by firmware authors.

That's why it's called "Advanced Configuration and Power Interface"
and not just "Advanced Power Interface" :-)

It also provides more accurate tables to describe things like
the cpus in your system etc., to replace deprecated mechanisms
for that such as MPS.

Re: Is via-velocity broken in 2.6.34?

[Robert Hancock]

On 09/09/2010 01:57 PM, David Miller wrote:
> From: Matt Causey<matt.causey@gmail.com>
> Date: Thu, 9 Sep 2010 10:42:21 -0700
>
>> So it wasn't immediately intuitive that we would need power
>> management enabled in order to use other parts of the system.
>
> ACPI is not power management.
>
> It's a set of infrastructure (including an interpreter and small
> firmware programs to drive specialized hardware) that allows the
> important details of your motherboard to be described accurately to
> the kernel by firmware authors.
>
> That's why it's called "Advanced Configuration and Power Interface"
> and not just "Advanced Power Interface" :-)
>
> It also provides more accurate tables to describe things like
> the cpus in your system etc., to replace deprecated mechanisms
> for that such as MPS.

I'd think we'd save some trouble if we forced ACPI to on unless EMBEDDED 
was set or something, to indicate you shouldn't turn it off unless you 
really know what you're doing..