Date: Fri, 25 Nov 2005 14:29:15 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: FreeBSD current mailing list <current@freebsd.org> Subject: Re: nve locking fixes round 2 Message-ID: <20051125142713.M23990@maildrop.int.zabbadoz.net> In-Reply-To: <200511242329.jAONTEkr055790@apollo.backplane.com> References: <200511231406.06282.jhb@freebsd.org> <200511242329.jAONTEkr055790@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Nov 2005, Matthew Dillon wrote: Hi, > :Ok, now that the first set of locking overhaul is in the tree, can folks with > :working nve(4) adapters test the patch referenced below and make sure there > :are no regressions. Having the IFF_UP fiddling turned off may or may not > :help folks getting the TX timeouts as well, btw, so if people are feeling > :brave they can try this patch as well. Note it is only applicable to recent > :current. > : > :http://www.FreeBSD.org/~jhb/patches/nve_locking.patch > : > :-- > :John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > :"Power Users Use the Power to Serve" = http://www.FreeBSD.org > > The reason I set sc->pending_txs to 0 in DFly after the reinit is > because when a watchdog timeout occurs and you reset the device, > *ALL* mbufs still sitting in the transmit ring are lost. They will > never be acknowledged, ever. So pending_txs will never drop back to 0 on > its own. This is what led to continuous watchdog timeout reports > when, in fact, only one timeout actually occured. the problem is that with some versions of the hardware you are not even able to get the first packet out. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051125142713.M23990>