Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

HEADS UP: call for nve(4) users to test a patch

2 views
Skip to first unread message

Maxime Henrion

unread,
Sep 12, 2005, 1:28:54 PM9/12/05
to cur...@freebsd.org
Hi,

If any of you are using an nve(4) card and are experiencing "device
timeout" errors, I'd like you to test a very simple patch. One person
already reported success with it, but I'd like to see more reports
before committing and hopefully MFC'ing it in time for 6.0-RELEASE.

This patch just reduces the size of the TX ring by one. Many NIC chips
in existence today have such bugs and require similar fixes, so I'm not
really surprised. It also seems Linux's forcedeth driver does such a
thing, but it's hard to tell because it uses an entirely different API
than us.

Thanks,
Maxime

nve.patch

Andrew Gallatin

unread,
Sep 12, 2005, 3:28:49 PM9/12/05
to Maxime Henrion, cur...@freebsd.org

Maxime Henrion writes:
> This patch just reduces the size of the TX ring by one. Many NIC chips
> in existence today have such bugs and require similar fixes, so I'm not

I'm sorry, but it does not work for me on my Nforce4 based
motherboard running FreeBSD/amd64:

nve0: <NVIDIA nForce MCP9 Networking Adapter> port 0xb400-0xb407 mem 0xfebf9000-0xfebf9fff irq 22 at device 10.0 on pci0
nve0: Ethernet address 00:01:29:f5:6b:91
miibus1: <MII bus> on nve0
ciphy0: <Cicada CS8201 10/100/1000TX PHY> on miibus1
ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
nve0: Ethernet address: 00:01:29:f5:6b:91
nve0: [GIANT-LOCKED]
nve0: link state changed to DOWN
nve0: link state changed to UP
nve0: device timeout (2)

I'm totally unable to send or receive any traffic under FreeBSD with this
nic. It doesn't randomly timeout, it never manages to transmit (or receive)
anything.

I can provide more details about this board upon request..


> really surprised. It also seems Linux's forcedeth driver does such a
> thing, but it's hard to tell because it uses an entirely different API
> than us.

The Solaris driver (from http://homepage2.nifty.com/mrym3/taiyodo/eng) uses the
same interface as we do, and uses the same version of the nvidia libs. It
has been bulletproof for me so far on this same machine when it is booted
into Solaris.


Drew


_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

Maxime Henrion

unread,
Sep 12, 2005, 4:45:55 PM9/12/05
to Andrew Gallatin, cur...@freebsd.org
Andrew Gallatin wrote:
>
> Maxime Henrion writes:
> > This patch just reduces the size of the TX ring by one. Many NIC chips
> > in existence today have such bugs and require similar fixes, so I'm not
>
> I'm sorry, but it does not work for me on my Nforce4 based
> motherboard running FreeBSD/amd64:
>
> nve0: <NVIDIA nForce MCP9 Networking Adapter> port 0xb400-0xb407 mem 0xfebf9000-0xfebf9fff irq 22 at device 10.0 on pci0
> nve0: Ethernet address 00:01:29:f5:6b:91
> miibus1: <MII bus> on nve0
> ciphy0: <Cicada CS8201 10/100/1000TX PHY> on miibus1
> ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
> nve0: Ethernet address: 00:01:29:f5:6b:91
> nve0: [GIANT-LOCKED]
> nve0: link state changed to DOWN
> nve0: link state changed to UP
> nve0: device timeout (2)

Ok, I should have said that this patch will only help if you get a
"device timeout (64)" message, so it won't help here unfortunately.

> I'm totally unable to send or receive any traffic under FreeBSD with this
> nic. It doesn't randomly timeout, it never manages to transmit (or receive)
> anything.
>
> I can provide more details about this board upon request..
>
>
> > really surprised. It also seems Linux's forcedeth driver does such a
> > thing, but it's hard to tell because it uses an entirely different API
> > than us.
>
> The Solaris driver (from http://homepage2.nifty.com/mrym3/taiyodo/eng) uses the
> same interface as we do, and uses the same version of the nvidia libs. It
> has been bulletproof for me so far on this same machine when it is booted
> into Solaris.

I'll look into this ASAP.

Thanks,
Maxime

alan bryan

unread,
Sep 13, 2005, 2:09:36 AM9/13/05
to Maxime Henrion, Andrew Gallatin, cur...@freebsd.org

--- Maxime Henrion <m...@FreeBSD.org> wrote:
> Ok, I should have said that this patch will only
> help if you get a
> "device timeout (64)" message, so it won't help here
> unfortunately.

Thanks! - I hope this works.

I get these all the time (was about to go buy a PCIe
network card as the daily or more reboots were getting
to me). I'll try this patch and report back in the
next day or so.

Running FreeBSD 6 on nForce 4 on i386. (Shuttle
SN25P)

--Alan Bryan

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

alan bryan

unread,
Sep 13, 2005, 5:36:10 PM9/13/05
to Maxime Henrion, cur...@freebsd.org
Well, I tried it and it's still broken. I patched and
re-compiled last night (FreeBSD 6 beta 1). The only
change is that it didn't go to 64 before dying, it now
died at 63 (whatever these numbers stand for).

For example from my demsg:
nve0: device timeout (62)


nve0: link state changed to DOWN
nve0: link state changed to UP

nve0: device timeout (63)


nve0: link state changed to DOWN
nve0: link state changed to UP

> ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
ping: sendto: No buffer space available
ping: sendto: No buffer space available
(10.0.0.1 is the gateway)

It lasted about 12 hours while slowly counting up to
63 before dying.

nForce 4 from the onboard nve in the Shuttle SN25P
small form factor PC.

If you need anything else just let me know.

Thanks for trying!

--Alan


--- Maxime Henrion <m...@FreeBSD.org> wrote:

> > ? nve.patch
> Index: if_nvereg.h
>
=========================
=========================
=================
> RCS file: /home/ncvs/src/sys/dev/nve/if_nvereg.h,v
> retrieving revision 1.3
> diff -u -r1.3 if_nvereg.h
> --- if_nvereg.h 10 Jun 2005 16:49:12 -0000 1.3
> +++ if_nvereg.h 12 Sep 2005 17:21:21 -0000
> @@ -49,9 +49,9 @@
>
> #define NV_RID 0x10
>
> -#define TX_RING_SIZE 64
> +#define TX_RING_SIZE 63
> #define RX_RING_SIZE 64
> -#define NV_MAX_FRAGS 63
> +#define NV_MAX_FRAGS 62
>
> #define FCS_LEN 4


>
> > _______________________________________________
> freebsd...@freebsd.org mailing list
>
http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"freebsd-curre...@freebsd.org"


__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005

alan bryan

unread,
Sep 17, 2005, 11:22:28 PM9/17/05
to Maxime Henrion, cur...@freebsd.org
Just a followup after a few days to confirm that I'm
still seeing the same thing - it now goes to "63" and
then networking (nve) dies - it does this about every
12 hours or so on my desktop machine with normal web
browsing as the main thing using networking. Is there
any way short of a reboot to "reset" the nve or am I
stuck rebooting this machine every 12 hours or so?

Is there anything else that may work or anything else
you want to try? If not I'll have to find some other
network card as this rebooting is getting old fast.

Thanks again for trying!

--Alan

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

jason

unread,
Sep 19, 2005, 1:34:30 AM9/19/05
to alan bryan, Maxime Henrion, cur...@freebsd.org
alan bryan wrote:

>Just a followup after a few days to confirm that I'm
>still seeing the same thing - it now goes to "63" and
>then networking (nve) dies - it does this about every
>12 hours or so on my desktop machine with normal web
>browsing as the main thing using networking. Is there
>any way short of a reboot to "reset" the nve or am I
>stuck rebooting this machine every 12 hours or so?
>
>Is there anything else that may work or anything else
>you want to try? If not I'll have to find some other
>network card as this rebooting is getting old fast.
>
>Thanks again for trying!
>
>--Alan
>
>
>
>

If you do not compile nve into the kernel load it as a module. You
could then write a script to reload nve every 11 or 10 hours.

0 new messages